Straight answers. No decoration.

Yuthent is Execution Authority Infrastructure.

No sensitive action executes without authority a person 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 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.

• Nobody is asked. The device simply has to be in good standing, and nothing is held up.
• One approval opens a short window. Routine work inside it proceeds without asking again; the first action past the window does not. Works offline by design.
• A fresh fingerprint or face for that action, every time. Works offline, and the approval syncs inside a window your policy sets.
• A fresh fingerprint or face, and your own backend countersigns before the action runs. Offline it is refused rather than queued, because the countersignature is the point.

Your own backend policy decides which of these an action gets, and you move that line whenever you want. Friction is spent where you want a record, and nowhere else.

It depends on what your backend policy asks for on that action.

• Nothing verified per action; the device has to be in good standing.
• One approval opens a short window; routine work inside it proceeds without asking again.
• A fresh fingerprint or face for that action, and a signed approval comes back.
• A fresh fingerprint or face, plus your backend countersigning. The action waits for that verdict.

One exception, and it is deliberate. An action covered by a standing mandate produces no fresh approval. The person already signed the mandate's bounds in a sealed ceremony on their own device, 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 one of the actions that needs a person.

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. A session carries no authority to run the actions your policy has marked.

A marked action needs a fresh fingerprint or face on the enrolled device. The device also reports what it can see about its own state — remote control, an overlay, screen sharing, an unusual context — and on a high-severity signal the SDK refuses to produce the approval at all.

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.

• The tenant and the enrolled device are who they say they are.
• The signature covers this exact action and this exact payload.
• The device has not drifted from the state it enrolled in.
• Your own fraud policy gets the last word.

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

• The lightest check is online only; it is a query rather than an approval.
• A short window after one approval is fully offline and syncs when the network returns.
• A fresh fingerprint or face works offline: the approval queues on the device and syncs inside a window your policy sets.
• The most consequential actions need the network, because your backend countersigns them. Offline they fail with an explicit code rather than queueing.

Losing the network never lowers the bar: the action still does not proceed without the person, and the approval it produces verifies whenever it arrives. The most consequential actions are the exception, and they fail rather than defer — the countersignature is what makes them what they are, so offline they are refused rather than queued.

In many workflows, yes.

Put routine clock-in and clock-out on a short window: one approval per shift, and nothing inside it is held up. Put supervisor approvals on a fresh fingerprint or face for that specific action.

For remote sites, both of those 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.

What was approved is kept as a record, exportable for audit and dispute investigation.

Yes. Put transfers and sensitive payment operations at the level that asks for a person every time.

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 enrolled 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 a continuous device-trust engine.

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 under NDA.

Yes. The trust engine detects a device being driven remotely, mirrored, or covered by something that is not your app.

When any critical signal is present the SDK refuses to produce the approval. On Android the approval surface also accepts a touch only while the system reports nothing drawn on top of it.

For the most consequential operations your own backend also countersigns before anything executes. If it refuses, the device is revoked and that reaches the endpoint straight away.

Yes, for the integrator's own account-recovery and password-reset workflows. Put them at the level that asks for a person every time. They approve with a fresh fingerprint or face, the approval carries the reset it was made for, and your backend verifies before the reset executes.

That level also supports external approval workflows, where the action stays 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 level your policy asked for on that action.
• 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.

• Nobody is asked. The device has to be in good standing, and nothing is held up.
• One approval opens a short window. Nothing inside it is held up; the first action past it is.
• The action does not proceed without a fresh fingerprint or face for that action.
• As above, and the action waits for your backend to countersign it.

Your own backend policy decides per operation. Friction is spent where you want a record, and nowhere else.

A device alone is not enough. Every level that asks for a person needs that person's own fresh fingerprint or face.

The behavioral trust engine also treats actions taken immediately after an unlock as high-risk, catching the device-theft pattern. A short approval window expires when the device locks.

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. It stops producing approvals from that moment, on every action it used to cover.

Yes, 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.
• Verify who the person is, to the standard your sector requires.
• Create a key inside the device's own secure hardware that cannot be copied off it.
• Snapshot the device's security posture, so later drift is visible.

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.
• Choose per operation, in your own backend policy, how much a person is asked for.
• Verify proofs at the integrator backend before executing sensitive actions.
• Store proof references and ACK tokens in the action ledger for audit.

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

Privilege control and data-plane export are scoped surfaces rather than shipping ones.

No. An agent can compose the request; releasing the signature takes the person.

An agent inside a valid session does not reach the key: it is generated in the phone's secure hardware and released by the person's own fingerprint or face. On Android the device's own attestation lets your server confirm the key was created so it cannot be used without that release; iOS does not give the same proof today and that path is being closed, so what this says is where the signature is released rather than that it holds identically on both.

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, sealed on their own device.

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 a record bound to the action the person authorized. 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. There is no abstract approve prompt to send: a prompt exists only because a privileged action asked for one, and it names that action. 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 credential on its own does not get there: the approval takes the enrolled device and that person's own fingerprint or face, together, at the moment of the action. A malicious insider cannot plausibly deny direct involvement.

Each entry is tied to the one before it for the same operator and rolled into a daily seal, so a change to an old one does not pass unnoticed. Nothing verifies that chain on read, and this page does not claim it does.

Yuthent addresses data exfiltration at two layers:

• Shipping today: mark bulk export as an action that needs a person, so nothing large leaves the application until someone approves it.
• Scoped, not shipping: a data-plane proxy that intercepts bulk reads and exports at the database layer, so none of them execute without a human approval. 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.

Privilege control is a scoped surface rather than a shipping one, with detail under NDA. It extends what ships today into the privilege plane.

• Zero standing admin privileges. Elevation is obtained per action.
• Elevation asks for a fresh fingerprint or face from the enrolled operator, and your backend countersigns it.
• Privilege is scoped and time-limited. Auto-revoked when the scope expires or the session ends.
• Every escalation lands in the same record as everything else.

No passwords, no shared admin credentials, no persistent elevation. What opens it is the operator's own fingerprint or face, on their own phone.

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 asks for authority the enrolled person signed. What your backend verifies is that approval, not a behavioural probability score.

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.

A stolen token gets someone into the session. It does not get them through a marked action, because that needs the enrolled person's own fresh fingerprint or face on their own device.

Someone holding the session holds the session. Releasing the approval still takes the person.

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.

Deployments are paid engagements with a named integration scope, a defined objective (regulatory, threat-model, or operational), and a cryptographic evidence target. The 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 what the ladder meters.

Two entitlements are contracted separately, and they are the same two on every plan: 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, and composes with whichever vendor you already run: 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 band. 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. Two entitlements are contracted separately on every plan, at the same price on each: 7-year cold audit retention and the compliance evidence pack.

The contracted figure is a sustained rate, not an instantaneous ceiling. It is a sustained rate, not an instantaneous ceiling, 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 plan, 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 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 engagements begin with a scoped, paid 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 category is open. The implementation is ours.