Defensible by construction.
Published honestly.
Yuthent does not claim unbypassability. It claims 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. This page is the public-facing version of that posture. The Security Architecture Whitepaper is the complete one.
Six invariants the system depends on.
Hardware-bound keys, never exportable
Every operator and accountholder key is generated inside StrongBox, TEE, or Secure Enclave. Private material never leaves the device. A biometric enrollment change cryptographically destroys the key. No server-side key material exists for forgery.
Action-bound signatures, not session tokens
Every Authoritative action carries a signature bound to the exact action parameters through a canonical payload hash. A modified parameter invalidates the proof. Sessions identify. Signatures authorize.
Per-action device attestation
Every bundle carries a Play Integrity or App Attest token with an action-bound nonce. The server recomputes the expected nonce from the action's parameters. A token issued for a different action is rejected before downstream verification.
Per-risk-level monotonic counters
The server tracks five independent monotonic counters per enrollment, one for each of the four action risk levels and one for passive attestation. A regressed or reused counter is rejected. A captured low-risk proof cannot be replayed against a higher-risk action.
Hash-chained per-actor action ledger
Every Authoritative action is chained to the prior action by the same actor. Daily tenant anchors. Altering one record breaks every record after it.
Continuous five-category trust engine
Device integrity, remote-control exposure, overlay presence, behavioral anomaly, contextual drift. Signals carry severity and aggregate continuously. The gate at action time is binary: a valid trusted state produces a proof, any other state blocks with a reason.
What Yuthent defends. What it does not.
Defended decisively
- Credential phishing (no credential to phish at the action layer)
- Session takeover, cookie theft, AiTM proxy attacks (session carries zero action authority)
- SMS and OTP interception, SIM swap (no phone-number dependency in the trust anchor)
- MFA fatigue and push-bombing (no generic approve surface exists)
- Replay of captured proofs (monotonic counter, action-bound nonce)
- Reordering or backdating of historical actions (hash chain)
- Device theft with unlocked session (biometric enforced at secure element per action)
- Remote-control operator attacks (AnyDesk, TeamViewer, accessibility gesture injection) (RemoteDesktopDetector, AccessibilityAbuseDetector)
- UI overlay and clickjacking attacks (OverlayDetector, secure approval fragment)
- Screen-mirroring and cast-based code exfiltration (ScreenMirroringDetector)
- Insider plausible-deniability (hardware-bound, biometric-enforced signature)
What Yuthent does not solve
Persuasion-based fraud
When a verified human is socially engineered into authorizing a transaction (investment scams, romance scams, purchase scams, advance-fee fraud), Yuthent's signature will be valid, because the biometric press and the intent, at that moment, are genuinely the accountholder's. This represents approximately 85% of APP fraud losses globally (UK Finance Half-Year Fraud Report 2025) and is fundamentally a behavioral and educational problem, not an authentication problem.
Initial identity verification
Yuthent verifies that the previously-enrolled human is present at action time. KYC at enrollment, establishing who the human is in the first place, is the customer's responsibility, integrated via partner identity verification providers.
Merchant-side fraud detection
Yuthent is issuer-side Execution Authority Infrastructure. Merchant-side risk scoring, chargeback management, and acceptance optimization are served by other categories of products.
Network-layer security
Yuthent does not replace WAF, DDoS protection, network segmentation, or transport security. It operates above the network layer, on cryptographic proof of human authorization.
Naming these limits is intentional. A vendor that claims to solve everything solves nothing in particular.
Where our obligations end and yours begin.
Yuthent
- Cryptographic primitives and SDK correctness
- Device-attestation integration and policy
- Signature and counter verification at the control plane
- Hash-chained ledger integrity and daily anchors
- Publishing honest release notes and security advisories
- Operating the control plane with tenant-scoped data isolation
Integrator
- Classifying actions into the correct P/S/E/A tier
- Verifying Yuthent proofs at the integrator backend before executing privileged actions
- Publishing and managing the canonical action payload schema
- Handling revocation webhooks and propagating to downstream systems
- Operating tenant portal access per the access-management policy
- Protecting the integrator verification key and service boundary
Privacy-preserving by architecture, not by policy.
Biometric data never leaves the device
Biometric matching is performed inside the OS secure hardware (Android StrongBox, iOS Secure Enclave) using platform biometric APIs. The control plane receives a cryptographic signature anchored to the enrollment, never the raw biometric, a template, or a face image.
Hardware-bound signing keys
Device signing keys are generated inside Secure Enclave on iOS with explicit fallback to Keychain on older hardware, and inside the Android Keystore on Android. The private key is never extractable and never leaves the hardware boundary.
Fail-closed past the grace window
Your contracted position sets the default, two days on the lower two and three on the upper two, and you can tighten it freely or widen it within a fixed ceiling from the control plane. Past it, the SDK blocks further sensitive actions until sync completes. Inside it, queued actions synchronize with replay protection on reconnect. Network disruption never silently authorizes. It stops.
Monotonic counter replay protection
Every sensitive action increments a monotonic counter tracked per device and per risk tier. A reused counter value is rejected by the control plane before business logic evaluates the request. Separate counters per risk level prevent collisions when low-risk and critical actions interleave.
Attestation with nonce binding
Android Play Integrity and iOS App Attest run on every signing event. The attestation nonce is computed from action identifier, counter, device key hash, and payload hash, making it specific to the individual action and resistant to replay.
Hash-chained daily audit anchors
Action records are hash-chained into a per-tenant daily anchor (SHA-256 over date, last action hash, and action count). Tampering with a past action breaks the chain visibly against the next anchor. 90 days hot retention, then archival export.
Tenant data stays in tenant scope
Isolation is enforced at the datastore. Every read and write carries the authenticated tenant identity. The Yuthent team cannot see tenant data without explicit support consent, logged.
Long-term audit retention
Action records leave hot storage on a daily archival export. Seven-year cold audit retention is contracted separately and enforced per tenant as an entitlement, not applied by default.
Minimal wire footprint
The control plane accepts an action identity, a counter, hashes, an attestation, and a signature. It does not accept or store transaction amounts, patient records, or business payloads.
Device revocation
Tenant administrators revoke devices from the control plane. Revocation cascades through device, enrollment, and state immediately, propagates via push notification, and is enforced cryptographically on the next proof request from the revoked device.
The public website does not collect or process biometric data. This page describes the product. The privacy page describes the website.
Architected against the frameworks enterprises are audited on.
Control-level mapping and attestation roadmap available in the Security Architecture Whitepaper under NDA. SOC 2 readiness, external penetration testing, and independent cryptographic review are scoped in the enterprise first deployment and are forward items, not yet issued.
Security, answered plainly.
Do you claim to be unbypassable?
No. Yuthent does not claim unbypassability. We claim that the effort, privilege, and coordination required to forge a proof exceed every existing authentication system by orders of magnitude, and that every residual limitation is published, including the ones on this page.
Are you SOC 2 certified?
Not yet. SOC 2 readiness, an external penetration test, and an independent cryptographic review are scoped as part of the first deployment and are forward items, not yet issued. We will not present them as complete before they are. Control-level mapping and the attestation roadmap are in the Security Architecture Whitepaper under NDA.
What does Yuthent NOT defend against?
Persuasion-based fraud, where a verified human is socially engineered into a genuine approval, the signature is valid because the intent, at that moment, is real. Also initial KYC, merchant-side fraud, and network-layer security (WAF, DDoS, segmentation). We name these deliberately; a vendor that claims to solve everything solves nothing in particular.
Where is biometric data stored?
Never on our servers. Biometric matching runs on-device inside StrongBox, TEE, or Secure Enclave using the OS biometric APIs. The control plane receives a cryptographic signature anchored to the enrollment, never the raw biometric, a template, or an image. There is no central biometric database to breach.
Is the action ledger tamper-evident?
Yes. Every authoritative action is hash-chained to the prior one and rolled into a per-tenant daily anchor (SHA-256), and each is threaded through an RFC 3161 Time-Stamping Authority signed by a key the operator does not hold. Altering a past record breaks the chain visibly against the next anchor.
What happens if a device goes offline?
It fails closed. Past the grace window, the SDK blocks further sensitive actions until sync completes; your contracted position sets its default and you can retune it from the control plane; queued lower-risk actions synchronize with replay protection on reconnect. Authoritative-tier actions require the server before they execute, so an offline Authoritative action is denied, never silently authorized.
Tell us first. We will tell the world honestly.
If you believe you have found a security issue, report it to security@yuthent.com. Include a clear description, steps to reproduce, and any supporting logs or artifacts. We acknowledge receipt within two business days and communicate a remediation timeline within ten.
Do not run automated scans against production systems without prior written permission. A structured pentest engagement is part of the First deployment package and produces a shared test plan, a named technical contact, and an isolated test tenant.
Security advisories and release notes are published publicly. When we change a security-relevant behavior, the release note says so explicitly. We do not quietly change security posture.
Request a security briefing.
Senior security contacts receive the full Security Architecture Whitepaper under a light NDA, plus a live walkthrough of the control plane, the action ledger, and the signal model. First call within five business days.