Outstanding protection. Installed in a day.
Every sensitive action is signed in hardware on the user's device, gated by a fresh biometric, and verified by your server before it executes. Attackers can't forge it. AI agents can't produce it. And it goes live behind one SDK call, hardware-bound signing, device attestation, monotonic counters, a hash-chained ledger, and an always-on trust engine, with zero architecture change.
How does Yuthent work?
Yuthent signs each sensitive action on the user's device with a hardware-bound key, gated by a fresh biometric. The server verifies the signature against canonical bytes and returns a signed ACK. Four tiers (P, S, E, A) match assurance to action risk. Every Authoritative action is hash-chained to the user's prior ones.
What it stops cold.
One primitive closes an entire column of attacks at once, the ones that operate inside a valid session, where MFA, risk scoring, and audit logs go blind. Not by scoring them. By making the action impossible to authorize without the specific human.
Credential phishing & AiTM
There is no credential or OTP at the action layer to phish, proxy, or replay.
Session & cookie theft
A stolen session carries zero action authority. It cannot produce a signed proof.
MFA fatigue & push-bombing
No generic 'approve' surface exists to spam. Every prompt binds a real action.
SIM swap & OTP interception
The trust anchor is a hardware key, not a phone number. Nothing to intercept.
Remote-control takeover
AnyDesk, TeamViewer, and accessibility abuse are detected; the proof is refused.
Overlays & screen mirroring
Clickjacking overlays and cast-based exfiltration are caught at sign time.
Replay & reordering
A per-risk monotonic counter and hash chain make a captured proof un-replayable.
Insider denial
A hardware-bound, biometric-enforced signature is forensically non-repudiable.
AI agents & prompt injection
An agent can't produce a human biometric from the secure element. Injection can't forge it.
We don't claim unbypassability. We claim the effort, privilege, and coordination required to forge a Yuthent proof exceed every existing authentication system by orders of magnitude, and every residual limit is published in the threat model below.
Three moves. Days, not quarters.
A thin layer inside your existing APIs, not a rewrite. One SDK call client-side, one verify call server-side. Your business logic never moves.
Enroll once
Bind a person to a hardware trust anchor, attestation-gated. Bring your own identity: IdP, KYC, or in person. The biometric never leaves the device.
Prove per action
One SDK call wraps the sensitive action. A fresh biometric signs the exact payload in hardware. Offline-first for low and medium risk.
Verify & ledger
Your server verifies the signed proof with ES256 before anything executes, and it lands in the tamper-evident ledger.
// client, iOS / Android SDK wraps the action.
// The SDK answers the server's challenge automatically.
const decision = await yuthent.authenticateAction({
action: "wire.transfer",
tier: "A", // Authoritative
payload: { amount: 24500, to: "DE89 3704 …" },
});
// server, @yuthent/server, Express middleware. Zero deps.
import { yuthent } from "@yuthent/server";
const requireHuman = yuthent("A", { apiKey: process.env.YUTHENT_API_KEY });
app.post("/api/transfer", requireHuman, handler); // only runs on a valid A-tier proofThe server side is @yuthent/server, a zero-dependency Express middleware. It issues the challenge, burns nonces for replay protection, forwards the proof to Yuthent’s verify service, and returns APPROVE / REJECT / STALE with 20 explicit rejection codes. A Redis nonce store drops in for multi-replica deployments.
No architecture change
- ·One SDK call client-side (iOS + Android)
- ·One line of Express middleware server-side (@yuthent/server)
- ·Bring your own identity: IdP, KYC, or in person
- ·Offline-first for low and medium risk
- ·Webhooks and audit export into your stack
What you send us
Amounts, payees, patient records, your business data stays with you. Biometrics never leave the device. No central honeypot.
Runs where your data has to live.
Same SDK, same proofs, same control plane. What changes is the isolation boundary, from a shared, fully isolated tenant to a black box inside your own perimeter. One fixed annual price per deployment, never per action.
Hosted multi-tenant
Isolation
Fully isolated tenant on Yuthent's Google Cloud
For
Regulated enterprises that want to move fast, with strict per-tenant isolation.
Dedicated cloud
Isolation
Your own single-tenant Google Cloud project
For
Enterprises with data-residency requirements and customer-held keys.
On-prem black-box
Isolation
Runs entirely inside your environment
For
Government and sovereign deployments where nothing leaves the perimeter.
In every model, audit export lands in your own storage (BigQuery to a customer-owned bucket), webhooks stream into your SIEM, and proofs verify against the published public key, independent of Yuthent.
Three enforcement layers.
One architecture. Three places it enforces: inside the application, at the admin console, and at the data plane. Each layer is deployed independently. Each one produces the same class of signed proof.
Tier 1 · App Enforcement
The SDK that ships today. Native Android and iOS integration for high-volume action verification across payments, clinical, and field operations. Proves the authorized human was present at the exact moment of execution using the P/S/E/A framework.
- ·Passive, Silent, Explicit, and Authoritative tiers
- ·Hardware-bound keys in StrongBox or TEE
- ·Server-verifiable signed action proofs
- ·Works offline. Syncs when connected.
Tier 2 · Privilege Control
Hardware-backed, just-in-time admin access. Replaces standing privileges with cryptographic, per-action human approval. The pattern extends the Tier 1 P/S/E/A contract into the privilege plane.
- ·JIT privilege elevation with biometric gate
- ·Zero standing admin access by default
- ·Hardware-bound session keys
- ·Non-repudiable receipt per escalation
Tier 3 · Bulk Data Export
Database proxies that refuse to execute bulk reads without Authoritative-tier human proof. Enforced at the data plane, validated against a target exfiltration scenario before broader release.
- ·Enforcement at the data-plane proxy
- ·Authoritative-tier approval required
- ·Blocks unauthorized bulk reads and exports
- ·Receipt anchored into the action ledger
Four tiers. One contract.
The tier is a contract between SDK, server, and auditor on what evidence an action must produce and what the wire format contains. Routine actions pay no friction. High-stakes actions produce full audit-grade proofs. The integrator picks the tier per action.
Passive
Background risk scoringThe device is still trusted. The environment is uncompromised. No remote-control session is present. A signed attestation token confirms. No user interaction. Zero server writes.
Silent
Routine in-session actionsOne biometric establishes the session. Subsequent routine actions use the cached session (bounded by 15 minutes and 50 actions). No per-action server call. Batched summary syncs on session end. Valid offline by design.
Explicit
Standard sensitive actionsFresh biometric for each action. Card-not-present transactions, account changes, sensitive data access, moderate-value transfers. Server verifies against canonical bytes and the action counter. Minimal persistence: counter and hash, no full action document.
Authoritative
High-value, regulatedFresh biometric, server co-signature, full audit trail, monotonic counter enforced server-side, hash-chained to every prior authoritative action this user has signed. Wire transfers. Controlled-substance prescriptions. Regulated attestations. Anything that belongs in a courtroom.
The key lives inside the device. It cannot be moved.
At enrollment, the SDK generates an EC P-256 keypair inside the device security element. StrongBox where the device exposes it. TEE on all others. Yuthent never sees the private key. No one does.
The private key cannot be used without a fresh biometric authentication, enforced at the Keystore layer. Any addition, removal, or modification of a biometric on the device cryptographically destroys the Yuthent key. Full re-onboarding is required to resurrect the binding.
The right to produce authorization proofs is bound to the specific biometric enrollment present on the device at the moment of Yuthent enrollment. Transfer to another device requires full re-onboarding.
The device attests. We verify against the specific action.
Every action bundle carries a device-integrity attestation token, Google Play Integrity on Android or Apple App Attest on iOS, bound to the specific action being signed. The backend recomputes the expected nonce from the action's exact parameters. If the nonce does not match, the attestation is for a different action and the proof is rejected.
The binding is the point. A stolen attestation token cannot be replayed against a different action, because the nonce baked into it is deterministically derived from the original action identity, the device key, the payload, and the ordered counter. Exact construction, field order, and separator are shared under NDA.
On iOS, App Attest is the equivalent device-integrity primitive; the action-bound nonce construction is identical.
One counter per risk level. Strictly monotonic.
The server maintains four independent monotonic counters per enrollment, one for each action risk level. Every accepted action must carry a counter strictly greater than the last accepted counter for that enrollment at that risk level. A regressed or reused counter is rejected before downstream verification.
LOW
counter
MEDIUM
counter
HIGH
counter
CRITICAL
counter
Independent counters prevent a captured low-risk proof from being replayed at a higher risk level. Combined with the hardware-bound signature and the action-bound attestation nonce, the result is deterministic: a specific enrolled human, on a specific unmodified device, produced a fresh signature, over a specific payload, at a specific ordered position in their history.
ApprovalToken. Canonical. Signed with ES256.
Signature: ES256 (ECDSA P-256 with SHA-256) over canonical bytes. Each proof binds the action identity, the monotonic counter, the payload hash, the device identity, and a fresh user-verification. A verifier confirms the exact action a specific human approved. Canonical serialization rules (key ordering, encoding) are shared with Enterprise pilots under NDA.
Hash-chained per user. Daily anchors. Tamper-evident.
Every authoritative action is committed to a per-enrollment hash chain. Each entry includes the hash of the previous action the user signed. Altering any historical entry breaks every entry after it.
At the end of each UTC day, the backend generates chain anchors across all enrollments. Cold-storage archive is populated on rolling retention. Audit export through BigQuery is available to Enterprise tier tenants under their own storage bucket (BYOS).
External Merkle commitment of the ledger is on the roadmap for third-party immutability verification.
A score runs always. The gate is binary.
A device-side trust engine observes signals continuously across five categories: biometric, device integrity, remote control, behavioral, contextual. Signals carry severity (critical, high, medium, low, info) and aggregate into a trust score from 0.0 to 1.0.
The integrator's app reads the score live for UX (adaptive friction, re-authentication prompts, telemetry). The gate at action time is binary: the action either carries a valid trusted state and produces a signed proof, or it fails.
On the wire, the ApprovalToken carries one of five operational states: TRUSTED, UNENROLLED, INVALIDATED, REVOKED, ERROR. Only the first produces a proof. The others block the action and surface a concrete reason to the integrator.
Revocation is immediate. A device that crosses into REVOKED cannot produce any further valid proof at any tier. Backend verification fails. The tenant is notified via webhook. Exit requires full re-enrollment.
Per-tenant trust policies configure the signal weights and the score threshold that drives the gate. Policies are managed through the Yuthent control plane.
Proof does not leave the door without passing every check.
Before a proof is admitted to the hash-chained ledger, the backend runs a sequenced verification pipeline. The public-safe steps:
Exact internal ordering, tuning thresholds, and fraud callback signatures are shared with Enterprise pilots under NDA.
We compose with your fraud stack. We do not replace it.
Sardine, Sift, Feedzai, your internal ML continue to score risk. Yuthent adds a signal they do not produce today: cryptographic proof that the accountholder authorized the transaction, or cryptographic proof that they did not.
Integration is bidirectional. Your fraud system can feed decisions back through the external-decision callback to trigger step-up at Yuthent. Yuthent can feed device-trust signals to your fraud system to revoke a device or flag a session. Neither system replaces the other. They combine to produce a verdict.
No network in the critical path.
Enrollment and action signing require no network. The proof is portable. It can be verified by the Yuthent backend, by the integrator's backend, by a regulator, or by a court, against the published public key.
E-tier and S-tier proofs are persisted in a durable on-device queue, transmitted on reconnection with exponential backoff. A tenant-configurable grace window (default 24 hours) caps how long E-tier actions can operate offline before the server finalizes them. An Authoritative action requires the server ACK before it executes, so an offline A is denied, never queued. Server ACK signatures are verified on-device against a pinned public key, with rotation via a well-known endpoint.
Native on both. Architecture parity.
Android (Kotlin)
StrongBox and TEE backed. Play Integrity attestation. Biometric enrollment binding. Full P/S/E/A surface, with architecture parity across platforms.
iOS (Swift)
Secure Enclave backed. App Attest for device attestation. Architecture parity with Android. Full P/S/E/A surface, verified in hardware on every action.
Honest about what we defend. Honest about what we do not.
We do not claim unbypassability. We claim that the effort, privilege, and coordination required to forge a Yuthent proof exceed every existing authentication system by orders of magnitude, and that every residual limitation is published.
Defended decisively
Credential phishing (no credential to phish). Session takeover (no session carries authorization). Remote-access takeover (detected and reflected in trust state). SIM swap (irrelevant). Replay (counter). Reordering (hash chain). Device theft (biometric enforced at secure element).
Requires additional defense
A device rooted before enrollment with root state successfully hidden (mitigated by enforceable strong-integrity attestation: Play Integrity MEETS_STRONG_INTEGRITY on Android, App Attest on iOS). Sophisticated social engineering of the legitimate user into biometrically authorizing an attacker-crafted action (mitigated by velocity, drift, and anomaly signals). Kernel-level TEE exploits against specific device models (out of scope for any application-layer system).
The complete threat model ships with the Security Architecture Whitepaper, available on request.
Published roadmap. Honest release notes.
We do not quietly change security posture. Every item above ships with release notes visible to all integrators.
Architecture, answered.
What are the four P/S/E/A tiers?
Passive is a device attestation, no biometric. Silent opens a short biometric session for routine actions. Explicit requires a fresh biometric per action with a server-verifiable proof. Authoritative adds a synchronous server co-signature and hash-chains the proof to the ledger. The integrator backend policy selects the tier per action.
Is there a server-side SDK?
Yes. @yuthent/server is a zero-dependency Express middleware. You wrap a route in one line, yuthent('A', { apiKey }), and it issues the challenge, burns nonces for replay protection, forwards the proof to Yuthent's verify service, and returns APPROVE, REJECT, or STALE with 20 explicit rejection codes. A Redis nonce store drops in for multi-replica deployments.
How does the trust engine score risk?
A device-side trust engine observes signals across five categories, biometric, device integrity, remote control, behavioral, and contextual, each carrying a severity from info to critical. It aggregates them into a continuous trust score from 0.0 to 1.0 that the app can read live for adaptive friction. At action time the gate is binary: only a TRUSTED state produces a signed proof.
What does the backend verify before accepting a proof?
Tenant scope and rate, enrollment and device identity, hardware-backed attestation level, ES256 signature over canonical bytes, trust state, payload hash, device-attestation verdict with an action-bound nonce, per-risk-level monotonic counter, action idempotency, and device-state drift versus the enrollment baseline. Fraud policy can inject a verdict through the external-decision callback.
Where does Yuthent deploy, cloud or on-prem?
Three models. Hosted multi-tenant runs on Yuthent's Google Cloud as a fully isolated tenant. Dedicated cloud runs in your own single-tenant GCP project for data residency and customer-held keys. On-prem runs entirely inside your environment for sovereign and government deployments.
Does Yuthent work offline?
Silent-tier is fully offline and Explicit-tier is offline-capable, proofs queue in a durable on-device queue and sync within a tenant-configurable grace window. Authoritative-tier requires a synchronous server co-signature and is online by design. Offline proofs verify against the published public key at any later time.
Want the whitepaper? Start a pilot?
The Security Architecture Whitepaper is available under a light NDA to senior security contacts. Enterprise pilots begin with a scoping call and ship a working integration on one critical flow.