Straight answers.
No decoration.

Yuthent is Execution Authority Infrastructure.

No sensitive action executes without authority a named human signed, for that action or for the boundary it falls inside. 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 first deployment. 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, so nothing is held up. A device outside trust policy is what it catches.
• ·S (Silent): One biometric opens a short session; routine actions inside it are session-cached and proceed without a further press. Past the policy bound, the next action does not. Batch sync on session end, offline-capable by design.
• ·E (Explicit): The action does not proceed without a fresh biometric for that action. Device-signed, server-verifiable proof. Minimal persistence: counter and hash, no full action document. Offline-capable with a grace window set by your contracted position.
• ·A (Authoritative): As E, plus the action blocks on a synchronous server co-signature, so it is refused rather than queued when the device is offline. Hash-chained to every prior authoritative action this user has signed.

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.

One exception, and it is deliberate. An action covered by a standing mandate produces no fresh press. The human already signed the mandate's bounds in a sealed Authoritative-tier ceremony, and inside those bounds the agent proceeds without interrupting them. An action that breaches a bound escalates to a fresh approval; a mandate that is absent, expired or revoked fails the action outright.

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. No session is issued until the integrator backend has verified it, so a login attempt that cannot produce a valid proof does not get in. 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 First deployments 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.

Losing the network does not lower the bar at E-tier: the action still does not proceed without the press, and the proof it produces verifies at the server against the published public key whenever it arrives. A-tier is the exception, and it fails rather than defers: it requires the synchronous server co-signature, so an offline Authoritative action is refused rather than queued.

In many workflows, yes.

Use S-tier for routine clock-in and clock-out: one biometric per shift scope, and nothing inside the window is held up. Use E-tier for supervisor approvals, where the approval does not go through without a fresh press for that specific 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 designed for evidentiary use in disputes, aligned with 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. The action does not run without authority the named human signed on their own device, for that action or for the boundary it falls inside.

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 First deployments 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. Nothing is held up.
• ·S-tier: one biometric opens a short session. Nothing inside the window is held up; the first action past it is.
• ·E-tier: the action does not proceed without a fresh biometric for that action.
• ·A-tier: as E, and the action blocks until the server co-signature returns.

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 deployment 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.

Tier 2 (Privilege Control) and Tier 3 (Bulk Data Export) are roadmap surfaces.

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.

A mandate-bound proof. The human signs the mandate parameters on their enrolled device: amount ceiling, counterparty scope, expiry, hashed into a sealed Authoritative-tier payload.

Yuthent produces and verifies the signature and the payload hash. Your verify step checks each agent action against the signed mandate before execution. An action outside it does not proceed on that mandate: it stops and returns to the human for a fresh approval, and an expired or revoked mandate fails outright. Either way the attempt lands in the ledger.

The payment rail authorizes the payment. The mandate authorizes the task. A dispute over an agent-initiated action terminates at an ES256 artifact, independently verifiable against a published key. See /agents and /industries/financial-transactions.

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): 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 designed for regulated data-handling environments.

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. The architecture extends the Tier 1 P/S/E/A contract into the privilege plane.

• ·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 authority the named human signed. 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, and it is not enough on its own. 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.

First deployments are paid engagements with a named integration scope, a defined objective (regulatory, threat-model, or operational), and a cryptographic evidence target. The first deployment 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.

Every capacity plan ships the same platform. Nothing is held back from a smaller plan, because throughput is the only thing the ladder meters.

Three entitlements are contracted separately, and they are the same three on every plan: a 99.99% SLA, 7-year cold audit retention, and the compliance evidence pack.

The full list of what every plan includes is on the pricing page, which is the authoritative source for it: /pricing.

Two things. Sustained rates above 150 actions per second, which the limiter supports well beyond the published top plan.

And technology or platform partnerships where a published capacity plan is not the right commercial shape. If you serve many businesses, they sit inside a single contract with usage and audit attributed to each one.

Both are scoped directly rather than quoted from a table.

No. Yuthent runs alongside Actimize, Featurespace, Sardine, Okta, CyberArk, and your existing tooling.

We contribute a single deterministic signal, human_verified = true or false, that sharpens your existing decision engine. A fraud engine scores probability; Yuthent answers a different question, and answers it with evidence. See Signal, Not Solution in the blog.

KYC is available as an optional add-on. Many customers bring their own vendor: Jumio, Onfido, Veriff, or an in-branch process.

Yuthent focuses on authorization at action time, not identity at enrollment, so the two compose cleanly either way. See also: is Yuthent the same as KYC.

Three. Hosted multi-tenant is live today on shared isolated infrastructure. Dedicated cloud and on-premise are available on request and scoped with you before anything is committed.

Deployment is an isolation choice rather than a price tier. The capacity plan sets the annual figure; the deployment is scoped alongside it and does not move it.

The full comparison of what changes between the three is on the technology page, which is the authoritative source for it: /technology.

One input: the sustained rate of authorized actions your deployment has to carry, measured in actions per second. Nothing else is metered, so nothing else moves it.

Users, devices, agents, enrollments and total action volume are uncapped on every plan, and adding more of any of them does not change the figure. Pick the position whose rate covers your peak minute and the annual number follows from that alone.

Setting it is a scoping call. Your flow inventory and the rate those actions fire at pick the position; your isolation requirements are scoped alongside it. A one-page SOW summary follows within a week. Three entitlements are contracted separately on every plan, at the same price on each: a 99.99% SLA, 7-year cold audit retention, and the compliance evidence pack.

The contracted figure is a sustained rate, not an instantaneous ceiling. A 60-second sliding window enforces sixty times the rate in any trailing minute, and arrival inside that minute is unconstrained. There is no overage charge.

Pricing is the authoritative source for this: /pricing.

No. Yuthent is enterprise-only and licensed as a fixed annual contract at one of the published capacity positions, or on a custom arrangement above them.

There is no free tier, no per-user billing, and no overage billing. Action volume is recorded for the audit ledger and your own reporting, and it is never used to bill you. The annual figure is agreed in writing during scoping, and it does not move until renewal.

Yes, and we recommend it. The first deployment is one critical flow under NDA. You get cryptographic evidence from day one and an executive-level authority gap report.

Because users and devices are never metered, starting narrow and widening later costs nothing extra until the sustained rate moves you up a position.

The full stack ships: native iOS and Android SDKs, the control plane, and the backend that enforces the contract.

Enterprise deployments begin with a scoped, paid first deployment on one critical flow, with cryptographic evidence auditable from day one.

Founder and CEO Mohamad Khalil Yossif, who authored the PSEA model, the Internet-Draft that specifies it, and a requirement now in OWASP AISVS 1.0.

Yuthent was selected by SafeNology (Takwin Ventures and S.T-Impact) and Hasoub Labs (Cohort 4).

Both, deliberately. The category is specified in the open. Yuthent authors and publishes draft-yossif-psea-02, an IETF Internet-Draft with intended status Standards Track, and authored the approval-integrity requirement merged into OWASP AISVS 1.0.

Two limits on that, stated plainly: the draft is an individual submission, it has not been adopted by an IETF working group, and it does not represent IETF consensus. The specification repository is public, so you can read exactly what it does and does not commit to.

The implementation is a proprietary, patent-pending primitive. Open category, defensible product.