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 four independent monotonic counters per enrollment, one per risk level. 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. Exportable to a customer-owned storage bucket.
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 authorization 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 with a 24-hour grace window
If a device cannot reach the control plane for more than 24 hours, the SDK blocks further sensitive actions until sync completes. Within the grace window, 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.
Audit export to customer-owned storage
Daily BigQuery export lands in a customer-owned Google Cloud Storage bucket. Retention policy, encryption, and access control stay under the customer.
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.
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 Enterprise pilot 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.