Security Posture
Defensible by construction. Published honestly.
We do not claim this cannot be bypassed. What it takes, what it covers, and what it does not, are all on this page.
What holds
Four things that hold without anyone choosing to let them.
Each of these is enforced by something other than our own good behaviour: by the phone's hardware, by the signature itself, or by a constant the server does not get to override. That is what makes them worth listing separately from everything else on this page.
The key is made in the phone and stays there
Every signing key is generated inside Android's StrongBox or the TEE, or inside the iOS Secure Enclave, and there is no export path out of it. Nothing on our servers could produce a person's signature, because nothing on our servers holds what makes one.
It will not sign without the person
The key is created so it can only be used after a live fingerprint or face, and the phone's own hardware holds that condition rather than our code or yours. Adding, removing or changing a biometric on the device destroys the key.
The approval covers the action it was made for
What the person approved travels inside the signature rather than beside it. Change the amount or the payee afterwards and the approval no longer matches what it was made for, and your backend refuses it.
An approval is good once, in its own lane
Approvals for routine actions and approvals for consequential ones are counted in separate lanes, so one cannot be turned into the other. A number that repeats or goes backwards is refused, and there is deliberately no fallback lane for one to land in.
And one that is not an invariant
The phone also reports what its platform says about its own integrity, and that report travels with the approval. Whether an action stops on a bad report is a policy setting in your tenant rather than a fixed property, and the platform signal is stronger on Android than on iOS. It is a signal your policy weighs, and this page does not list it with the four above.
Threat Model
What it closes. What it does not.
Closed
- Phishing and proxied logins — there is no credential and no one-time code at the action layer
- Stolen sessions and cookies — a session gets someone into the account, not through the approval
- Intercepted codes and SIM swap — no phone number sits anywhere in the trust anchor
- Approval fatigue — on Android every prompt names the action it is asking about
- Replay — an approval is good for the one action it was made for, and for that action once
- Backdating — an action's place in the record is fixed when the record is written
- A stolen phone, already unlocked — the key still asks for the fingerprint or face
- Remote-control sessions — reported in the state the device carries before it is allowed to sign
- Overlays and screen sharing — reported at signing time; what each platform can do about them differs
- Denial afterwards — the approval is a signature made in the person's own phone and released by them
Not closed, and named on purpose
Someone talked into approving it themselves
In an investment, romance, purchase or advance-fee scam, the person performs the transfer under full and sincere belief that the other party is legitimate. The signature they make is valid, because the fingerprint and the intent at that moment are genuinely theirs. Those four categories are roughly 85% of UK authorised-push-payment losses in the UK Finance Half-Year Fraud Report 2025. It is a behavioural and regulatory problem, and no authentication primitive closes it. the full breakdown, scoped to the published figures.
Who the person is in the first place
Yuthent settles that the enrolled person is present at the moment of the action. Establishing who that person is in the world, before they ever enrol, is yours to run, and it composes with whichever identity check you already use.
Your own verification step, if something goes around it
The check runs in your backend, which is what makes your backend the enforcement point. A second path that reaches the same operation without that check will reach it. What is not required is not controlled, and that is a property of the design rather than a gap in it.
The phone's own operating system, below the application layer
Exploits against the secure hardware of specific device models sit below anything an application can reach, here or anywhere. So does a phone rooted or jailbroken before enrolment with that state successfully hidden from the platform's own reporting.
Merchant-side fraud
This is issuer-side infrastructure. Merchant-side risk scoring, chargeback management and acceptance optimisation are served by other categories of product, and Yuthent is not one of them.
The network layer
It does not replace a WAF, DDoS protection, network segmentation or transport security. It operates above all of them, on whether a person authorized this action.
Naming these limits is intentional. A vendor that claims to solve everything solves nothing in particular.
Shared Responsibility
Where our job ends and yours begins.
The enforcement point is your backend, by design. That decides most of what follows.
Ours
- The SDK, and the cryptography inside it
- Verifying signatures and refusing repeats at the control plane
- Carrying the platform's integrity signal through to your policy
- The integrity of the record and its daily seals
- Honest release notes and security advisories
- Running the control plane with each tenant's data kept to itself
Yours
- Deciding which actions are consequential enough to need a person
- Verifying the approval in your own backend before the action runs
- Defining what the person is shown and approves
- Handling revocation webhooks and passing them downstream
- Managing who on your side has access to your tenant of the control plane
- Protecting your own verification step and the key it uses
Data Posture
What we hold about you, and what never reaches us.
Most of this is a property of where things are kept rather than a promise about how we behave. A privacy statement is worth what it would cost us to break, and these cost more than a change of mind.
The biometric never reaches us
Matching happens inside the phone's own secure hardware, Android's StrongBox or the TEE or the iOS Secure Enclave, through the platform's biometric APIs. What the control plane receives is a signature anchored to the enrolment — never the biometric, never a template, never an image. There is no central store of any of them for anyone to go after.
The signing key never reaches anyone
It is generated inside the phone's secure hardware and has no export path. It does not leave that boundary, to us or to you, and no configuration on either side changes that.
Your business data never reaches us
The control plane takes an action identity, a reference you can join back to your own records, and the approval. It does not take, and does not keep, amounts, payees, patient records or anything else your business runs on.
Losing the network stops things rather than waving them through
Past the window your contract sets, which you can tighten at any time from the control plane, the SDK blocks further sensitive actions until it syncs. Inside it, queued actions sync with replay protection when the phone reconnects. A dropped connection never quietly authorizes anything.
The record is kept, then archived
Action records stay in hot storage for ninety days and then leave on a daily archival export. Longer cold retention is contracted per tenant as an entitlement rather than applied to everyone by default.
Turning a device off
A tenant administrator revokes a device from the control plane. It stops producing approvals from that moment, on every action it used to cover, and coming back means enrolling again.
Each tenant sees its own data and no one else's
Isolation is enforced at the datastore: every read and every write carries the authenticated tenant identity. The Yuthent team sees none of it without support consent you give, which is logged.
The public website does not collect or process biometric data. This page describes the product. The privacy page describes the website.
Compliance Posture
What is certified, and what is not.
Nothing on this page is a certification. This is the difference between what the architecture was built to satisfy and what somebody independent has signed.
Designed against
- PSD2 strong customer authentication, dynamic linking (RTS Article 5)
- DORA operational resilience
- EU AI Act Article 14, human oversight
- PCI-DSS v4.0.1 phishing-resistant authentication
- HIPAA minimum-necessary and audit controls
- DEA EPCS, for controlled-substance prescribing
Not claimed
No SOC 2 certification
None is claimed. Control-level mappings are maintained and available for review under NDA today, and readiness is scoped and in progress.
No completed penetration test
An external test is scoped and in progress. There is no report to show you yet, and we will not describe one before there is.
No completed cryptographic review
An independent review is scoped and in progress, on the same terms.
None of the six is an audit result
The list opposite describes what the architecture was built to satisfy. It is not a finding, and nobody has issued it.
We will not present any of them as complete before they are.
Questions
Security, answered plainly.
Do you claim this cannot be bypassed?
No. Making an approval takes the enrolled phone and the person's own fingerprint or face together, and where that pair can be reached, this does not stop it. Every limit we know of is on this page rather than in a document you have to ask for.
Where does the biometric go?
Nowhere. Matching runs on the phone, inside Android's StrongBox or the TEE or the iOS Secure Enclave, through the platform's own APIs. The control plane receives a signature anchored to the enrolment, never the biometric, a template or an image.
Can a past record be changed?
Each record is tied to the one before it and rolled into a daily seal, so a change to an old one does not pass unnoticed against the next seal. What we do not claim is that this makes the record independently verifiable without us; that is a separate property and it is not shipped.
What happens when a device goes offline?
It stops rather than waving things through. Past the window your contract sets, the SDK blocks further sensitive actions until it syncs; queued routine ones sync with replay protection on reconnect. The most consequential actions wait for your backend to countersign, so offline they are refused, never quietly allowed.
Responsible Disclosure
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 deployment 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 behaviour, the release note says so. Security posture does not move quietly.
See it on your own flow.
Your app, your call, our SDK.