Every objection here is fair.
None of them closes the gap.
Seven things enterprise buyers say when they first hear this, and what we say back. The first three all begin the same way: we already have that. The argument for the category is on the home page. This is what comes after it.
The session identifies. The signature authorizes.
That inversion is the entire product. Authentication, authorization and audit each answer their own question correctly; none is the one that matters at the moment money moves.
The seven we hear every time.
We already have passkeys.
Keep them. A passkey is the right tool for login and nothing here replaces it. What it proves is that the right key was present when the session opened, and it binds nothing to the amount, the payee, or the command that runs an hour later inside that session. 88% of basic web-application attacks use valid stolen credentials (Verizon 2025 DBIR). A passkey proves it is your device. Yuthent proves it is your decision.
We already have FIDO2 and an identity provider.
Nothing here replaces them. Your identity provider still decides who gets in, your MFA still hardens that decision, and your passkeys still make the login unphishable. Keep all three. Yuthent starts where they finish, at the action: they establish who holds the session, and the question after that is whether this specific payment or command carries authority the named human signed. Adding that does not mean removing anything.
We already have human-in-the-loop.
Most human-in-the-loop is an Approve button. It records that someone pressed, on a screen the requesting system drew, so it cannot show what was on that screen. Change the amount after the click and the record reads the same. Here the signature covers what was displayed, and it is made either for that action or for the boundary the action falls inside, so routine work still runs without stopping for anyone. Afterwards you can show what was agreed to, not that a click happened.
Isn't an audit log enough for compliance?
Under DORA Article 9 and EU AI Act Article 14 the question is not whether you have a policy or a process, it is whether you can produce an artifact showing an authorized human approved a specific action. A log line is a sentence your own system wrote about itself: testimony from the party in question.
This sounds like friction our users will hate.
Applied to everything, yes. That is why it is tiered. Passive is a device attestation with no biometric and no interruption. Silent opens a short window for routine work. Explicit requires a fresh press per action. Authoritative adds a synchronous server co-signature. Your policy picks the tier, and the top two are for the actions you would want a record of.
Do you store biometric data?
No, and we could not if we wanted to. Verification runs entirely on-device inside StrongBox, TEE or Secure Enclave using OS-native APIs. Our servers receive device-signed proofs and server acknowledgements. There is no central biometric database to breach, to leak, or to subpoena.
What if you go out of business?
The proofs are signed with keys on your users' devices and verified against public keys you hold. Verification is a cryptographic operation against data in your own ledger. It does not require us to be reachable, or to exist.
A passkey is checked when the door opens. Yuthent is checked when the money leaves.
Where this applies to you.
The argument is general. The deployment is not. Five solutions, each one a specific place the assumption costs something you can measure.