Straight answers.
No decoration.

Yuthent is Authorization Infrastructure.

It produces a cryptographic proof that a specific human authorized a specific action on a specific device, at a specific moment, with intent. Not a session token. Not a probability score. A signature, on canonical bytes, verifiable against a published public key.

The SDK ships on Android and iOS with architecture parity. The control plane is live on day one of every pilot. Your app and your backend stay in control. Yuthent adds the authorization evidence layer beneath them.

Login proves a credential was presented at the start of a session. It does not prove who was present, on what device, with what intent, when a specific sensitive action executed inside that session.

Example: a supervisor authenticates at 8am. Someone else approves overtime at 3pm on the same session. The session is valid. The supervisor was never present.

Session-based authentication fails under credential sharing, session hijacking, remote-control malware, MFA fatigue, AiTM phishing, and AI agents operating inside trusted sessions. Yuthent closes the gap by moving evidence to the action layer.

• ·P (Passive): Device-signed attestation. No biometric. No persistence. Confirms the enrolled device is still within trust policy.
• ·S (Silent): One biometric establishes a short session. Subsequent routine actions are session-cached within policy bounds. Batch sync on session end. Offline-capable by design.
• ·E (Explicit): Fresh biometric per action. Device-signed, server-verifiable proof. Minimal persistence: counter and hash, no full action document. Offline-capable with a configurable grace window.
• ·A (Authoritative): Fresh biometric per action. Server co-signature. Full audit trail. Hash-chained to every prior authoritative action this user has signed. Real-time verification required.

The integrator backend policy selects the tier per action. The tier is a contract between SDK, server, and auditor on what evidence the action must produce and what the wire format contains.

It depends on the tier the integrator backend policy selects.

• ·P-tier: passive attestation, no verification per action.
• ·S-tier: one biometric per short session scope, cached within the session window.
• ·E-tier: fresh biometric per action. Signed proof returned.
• ·A-tier: fresh biometric per action plus synchronous server co-signature. The action blocks until the backend verdict returns.

For critical operations, the action should never execute until the integrator backend has verified the proof against the published public key.

Yes. Treat login as an A-tier (Authoritative) action.

The app requests authorization. The user provides a fresh biometric. The SDK produces a signed proof on canonical bytes. The integrator backend verifies the proof before issuing a session. No passwords, no SMS OTPs.

See the passwordless login use case for the full flow: /use-cases/passwordless-login.

Passkeys, FIDO2, OTPs, and MFA authenticate at login and produce a session token. The token then authorizes every downstream action with no further verification.

Sessions get stolen, replayed, bombed, and delegated to agents. FIDO2 prevents credential phishing at login but does nothing at the action layer after.

Yuthent inverts the shape. The session identifies the operator. The Yuthent proof authorizes the action. Both are checked. A stolen session against a privileged action produces no proof and no action.

Yes. The trust anchor is not a phone number. It is a hardware-bound keypair generated inside StrongBox, TEE, or Secure Enclave, tied to the specific biometric enrollment on the specific device.

A SIM swap does not migrate the key. There is no SMS code to intercept, no email to phish, no delivery channel to compromise.

Re-enrollment on a new device requires either the original device or a supervised link-enrollment grant flow operated from the control plane.

Session hijacking is one of the primary attacks Yuthent is designed to neutralize. The session carries zero action authority at E-tier and A-tier.

Every sensitive action requires a fresh biometric on the enrolled device. The trust engine continuously observes device integrity, remote-control exposure, overlay presence, behavioral anomaly, and contextual drift. When a high-severity signal fires, the SDK refuses to produce the proof at Authoritative tier.

No security model stops every form of malware. Yuthent shifts the enforcement point from the session to the action, and produces forensic-grade evidence of the refusal when one occurs.

The backend is the source of truth. The SDK is not.

• ·Tenant scope and rate limit.
• ·Enrollment and device identity lookup.
• ·Attestation security-level check, hardware-backed only.
• ·Signature verification over canonical bytes.
• ·Trust state validation.
• ·Payload hash verification.
• ·Device-attestation verdict with action-bound nonce.
• ·Per-risk-level monotonic counter check.
• ·Action idempotency.
• ·Device state drift versus enrollment baseline.
• ·Fraud decision through integrator policy or external callback.

Exact internal ordering, tuning thresholds, and fraud callback signatures are shared with Enterprise pilots under NDA.

• ·P-tier: online only. Passive attestation query.
• ·S-tier: fully offline. Session is device-local. Telemetry batch-syncs when the network returns.
• ·E-tier: offline-capable. The SDK produces the proof locally and queues it in a durable on-device queue. Syncs within a tenant-configurable grace window.
• ·A-tier: online required. Server co-signature is part of the contract. The action fails with an explicit offline code if connectivity is unavailable.

Offline proofs are verifiable at the server against the published public key at any later time. The evidentiary floor offline equals the evidentiary floor online for E-tier.

In many workflows, yes.

Use S-tier for routine clock-in and clock-out (biometric once per shift scope). Use E-tier for supervisor approvals that require audit-grade proof per action.

For remote sites, S-tier and E-tier both work offline. Proofs sync later for auditing and disputes. Whether Yuthent fully replaces a physical scanner depends on the integrator's operational constraints.

Buddy punching happens when identity is treated as a shared credential or a trusted session.

Yuthent binds a specific human to a specific device via hardware-backed enrollment. Clock-in requires the enrolled worker's biometric at action time. The key cannot be shared, borrowed, or replayed.

Proof references are stored in the hash-chained ledger and exportable for audit and dispute investigation.

Yes. Use A-tier (Authoritative) for transfers and sensitive payment operations.

The SDK produces a device-signed proof with amount, payee, and full canonical payload hashed into the signature. A parameter change post-approval invalidates the payload hash and breaks the proof.

The backend co-signs synchronously. The action blocks until the co-signature returns. Evidence is admissible in disputes under PSD2 SCA Dynamic Linking (RTS Article 5) and aligns with DORA operational resilience requirements.

No. KYC is onboarding and identity proofing. It establishes who you are at enrollment.

Yuthent is authorization at action time. It produces cryptographic proof that the authorized human approved a specific action at a specific moment on a specific device.

Many deployments use both: KYC to establish identity, then Yuthent to enforce per-action authorization afterward.

Yuthent binds a device to a specific enrolled identity using a stable, hardware-derived device hash and a per-user identity hash. The SDK validates the pairing before every action.

For shared kiosks and genuinely multi-user devices, the in-person and remote link-enrollment grant flows support supervised patterns. Talk to us and we will recommend the right approach for the operational context.

The trust anchor key lives inside StrongBox, TEE, or Secure Enclave, protected by the device's biometric security model.

If the biometric enrollment on the device changes, the OS cryptographically destroys the key. The user must re-enroll before further sensitive actions can be approved.

This is intentional. It prevents a quiet change to biometric enrollment from weakening the authorization floor.

The SDK runs continuous integrity detection across five signal categories: device integrity (root, emulator, developer options), remote-control exposure (AnyDesk, TeamViewer, accessibility abuse, ADB), overlay presence, behavioral anomaly, and contextual drift.

Device state is captured as a baseline at enrollment. The backend compares current state against the baseline and applies the tenant drift policy. Critical signals block the action before the biometric prompt appears.

Complete signal inventory, severity model, and drift policy are shared with Enterprise pilots under NDA.

Yes. The trust engine detects active remote-desktop sessions (AnyDesk, TeamViewer, wireless ADB), accessibility services with gesture-injection capability, system-alert-window overlays, and active screen mirroring or cast sessions.

When any critical signal is present, the SDK refuses to produce an Authoritative-tier proof. A separate secure-approval UI fragment rejects touch events while an overlay is active.

For A-tier operations, even if the device is partially compromised, the backend also co-signs synchronously before execution. If the backend rejects, local trust is revoked and propagates to the endpoint in real time.

Yes — for the integrator's own account-recovery and password-reset workflows. Treat them as A-tier. The user provides a fresh biometric, the SDK produces a signed proof with the reset parameters hashed into the signature, and the backend verifies synchronously before the reset executes.

A-tier supports external approval workflows where the action remains pending until a supervisor or helpdesk decision returns through the external-decision callback.

Yuthent's own enrollment has no recovery path through weak credentials, by design. Any SMS, email, or password-reset channel that could re-bind the device would downgrade the entire trust chain to the strength of that channel. If the user loses their device, re-binding a new device requires the same physical identity-verification strength as the original enrollment (document, face, liveness). The device is replaceable; the identity verification is not.

Yuthent is designed to minimize data surface. The authorization evidence layer does not need your business data.

• ·An action identifier: what operation is being authorized.
• ·The tier your policy requires: P, S, E, or A.
• ·A reference context identifier you can join back to your records.

Transaction amounts, payees, patient records, employee data, and any sensitive business payload stay with you. Biometric data never leaves the user's device. There is no central biometric honeypot.

No. All biometric verification executes on-device inside the hardware security module (StrongBox, TEE, or Secure Enclave) using OS-native biometric APIs.

Yuthent servers never see, store, or transmit biometric data. The integrator backend receives device-signed proofs and server ACKs. Not biometrics.

The signing keys are hardware-bound, un-extractable, and cryptographically destroyed by a biometric enrollment change.

• ·P-tier: no biometric. Passive device attestation only.
• ·S-tier: one biometric per short session scope. Frictionless inside the session window.
• ·E-tier: fresh biometric per action. Audit-grade proof.
• ·A-tier: fresh biometric per action plus synchronous server co-signature.

The integrator backend policy determines the tier per operation. Friction is spent where evidence is required.

A device alone is not enough. E-tier and A-tier require the enrolled user's fresh biometric per action.

The behavioral trust engine also flags actions within two to five seconds of device unlock at high severity, catching the device-theft pattern. Short session windows at S-tier expire on device lock.

If a device is lost or an employee leaves, the enrollment is revoked from the control plane. Revocation propagates to the endpoint in real time. The device cannot produce any further valid proof at any tier.

Yes. A-tier supports external approval workflows through the external-decision callback.

The action remains in pending state while the external verdict is obtained. Examples: supervisor approval, helpdesk verification, fraud-engine decision from Sardine, Sift, Feedzai, or internal ML.

The integrator backend treats the action as pending until the final decision returns. The callback is signed and rate-limited at the control plane.

Enrollment binds a specific human to a specific device through a multi-phase process:

• ·Verify the device has a secure lock screen and biometric capability.
• ·Generate an EC P-256 trust anchor keypair inside StrongBox, TEE, or Secure Enclave.
• ·Attest the device via Play Integrity on Android or App Attest on iOS. Attestation is verified against the vendor root.
• ·Capture a device state baseline (integrity verdict, app signing hash, feature flags).
• ·Store the identity binding: user identity hash, device identity hash, enrollment identifier.

Options include identity-document plus liveness verification, in-person link enrollment under operator supervision, and remote link enrollment over video. Biometric data never leaves the device during enrollment.

• ·Add the Android or iOS SDK to the app.
• ·Select the right tier (P, S, E, or A) per operation in your backend policy.
• ·Verify proofs at the integrator backend before executing sensitive actions.
• ·Store proof references and ACK tokens in the action ledger for audit.

A first pilot scopes one high-stakes flow (payments, clinical prescribing, privileged console access, workforce payroll, field citizen verification) and ships a working integration with cryptographic evidence on day one.

Pilots are paid. Sponsored pilots are available for strategic partners. Tier 2 (Privilege Control) and Tier 3 (Bulk Data Export) are roadmap surfaces with wanted design partners.

No. Yuthent requires hardware-bound biometric proof of a real human at action time for Authoritative-tier operations.

An AI agent, bot, or automation operating inside a valid session cannot produce biometric proof from the device secure element. E-tier and A-tier require a fresh biometric from the enrolled human on the bound device. If the biometric is not present, the proof cannot be generated.

A session can be delegated to an agent. Authorization cannot. See /agents for the full agent-authorization surface.

Biometric privacy is an architectural property of Yuthent, not a policy promise.

All biometric processing happens on-device inside StrongBox, TEE, or Secure Enclave. Yuthent servers never collect, transmit, or store biometric data.

• ·BIPA: no biometric collection occurs. Biometrics never leave the hardware security module.
• ·GDPR Article 9: no special-category biometric data is processed by Yuthent servers. Only signed proofs and minimal action metadata.
• ·EU AI Act: on-device biometric verification does not trigger the high-risk classification for remote biometric identification.

There is no central biometric database to breach, subpoena, or audit.

MFA is a one-time barrier at login. Once MFA succeeds, the session token carries all authority.

If that token is stolen (AiTM phishing proxies, infostealer malware, cookie theft, OAuth consent phishing) the attacker inherits full access without ever needing to pass MFA again. Session hijacking is now the primary path for identity-driven breaches because it bypasses MFA entirely.

Yuthent requires a fresh cryptographic proof at each sensitive action. A stolen session token produces no proof and no action. See /industries/cybersecurity for the full MFA-fatigue and session-hijack analysis.

Yes. There is no generic approve surface to spam.

Every Yuthent approval prompt carries the exact action parameters on the device screen: the command, the target, the scope. An attacker cannot generate an abstract approve prompt without a corresponding privileged action request. Number-matching mitigates conventional push-bombing but does not eliminate it; payload-hash binding does.

The user sees what they are signing and presses only for operations they initiated. The psychological attack surface of MFA fatigue is gone.

The signature is produced by a hardware-bound key that lives inside StrongBox, TEE, or Secure Enclave. The key cannot leave the device. It cannot be used without a live biometric press from the enrolled individual. It cannot be replicated remotely.

A compromised-credential defense fails forensically because the proof requires physical possession of the device plus the enrolled biometric at the exact moment of action. A malicious insider cannot plausibly deny direct involvement.

The hash-chained ledger anchors every action to the prior action by the same operator. Altering a record breaks every record after it. Insider non-repudiation is the architectural default.

Yuthent addresses data exfiltration at two layers:

• ·Tier 1 (shipping today): Gate bulk export operations with E-tier or A-tier. Require a fresh biometric proof before the export executes from inside the application.
• ·Tier 3 (roadmap, design partners wanted): A data-plane proxy that intercepts bulk SELECT, COPY, and export queries at the database layer. No bulk export executes without Authoritative-tier human proof. Architecture being co-designed with wanted design partners in regulated data-handling.

Whether the actor is an employee, a compromised account, or an AI agent, the operation blocks until a real human provides hardware-bound biometric authorization.

Tier 2 (Privilege Control) is on the roadmap with wanted design partners. The architecture extends the Tier 1 P/S/E/A contract into the privilege plane, co-designed with the first enterprise partner.

• ·Zero standing admin privileges. Elevation is obtained per action.
• ·Elevation requires A-tier authorization: fresh biometric from the enrolled human and synchronous server verification.
• ·Privilege is scoped and time-limited. Auto-revoked when the scope expires or the session ends.
• ·Full immutable audit trail for every escalation enters the hash-chained ledger.

No passwords, no shared admin credentials, no persistent elevation. Hardware-bound biometric proof is the only key.

Continuous authentication monitors behavioral signals (typing patterns, mouse movement, gait) to detect anomalies and estimate session continuity. It is probabilistic, passive, and does not produce per-action cryptographic proof.

Yuthent requires explicit, hardware-bound biometric proof that a specific enrolled human approved a specific action at a specific moment. E-tier and A-tier produce device-signed proofs verified by the integrator backend, not behavioral probability scores.

Continuous authentication asks 'is this probably the same person?'. Yuthent proves 'this specific human approved this specific action right now.'

Infostealer malware harvests saved credentials and session cookies from browsers, letting attackers hijack authenticated sessions without ever knowing the password.

Yuthent makes stolen tokens useless for privileged actions. E-tier and A-tier require a fresh biometric proof from the enrolled human on the hardware-bound device. A stolen cookie grants access to the session, but it cannot generate a signed proof on canonical bytes from the secure element.

The attacker has the session. They cannot approve anything that requires authorization evidence.

Yuthent does not perform remote biometric matching. There is no video feed for a deepfake to attack.

Biometric verification happens locally inside the device's hardware security module (StrongBox, TEE, or Secure Enclave) using OS-native biometric APIs. The biometric unlocks a hardware-bound cryptographic key that signs the proof. A deepfake cannot unlock a Secure Enclave.

Deepfake attacks target remote verification systems that compare a face over a camera feed. Yuthent's model is fundamentally different. The SDK also runs integrity and anti-tamper checks and compares current device state against the enrollment baseline.

Non-human identities outnumber humans many times over in modern enterprises and a significant share carry excessive privileges. Yuthent does not authenticate machines. It authenticates humans. That is the point.

When a machine identity needs to perform a sensitive action (privilege escalation, data export, configuration change, outbound payment), Yuthent requires a real human to authorize it with hardware-bound biometric proof.

Machines can request. Only humans can authorize. See /agents for the full agent-authorization surface.

Identity-driven intrusions account for a growing share of modern breaches. The industry consensus is that identity is the primary attack surface.

Most identity solutions still focus on authenticating access, who can log in. Yuthent focuses on authorizing actions, who approved this specific operation on what device with what intent.

Securing the login perimeter is necessary but insufficient. Attackers who get past login (infostealers, token theft, social engineering, insider access) operate freely inside trusted sessions. Authorization evidence at action time closes that gap.

Pilots are paid engagements with a named integration scope, a defined objective (regulatory, threat-model, or operational), and a cryptographic evidence target. The first pilot ships a working integration on one high-stakes flow.

Cost and timeline are scoped in the initial call based on the target flow, the integrator's fleet profile, and the evidence grade required. The control plane is live on day one.

Sponsored pilots are available for strategic partners whose regulatory position or fleet scale is load-bearing for the category. Founder reads every pilot request. First call within five business days.