Verified
The registered person approved this exact request on their trusted device. You can act on it.
Casi d’uso
Secure login
Verify who is signing in, from which device, into which account, with which role — before the session exists.
The problem
A login form asks one question and accepts one answer
Whoever supplies the right characters gets in. That is true whether they are the account holder, someone who bought the password in a breach dump, or a phishing page relaying the details in real time.
What changes
The account holder approves the specific session
The request names the site, the account, the organisation and the role, and it is signed by a key that exists only on a device the person holds. A password relayed to a look-alike domain cannot produce that signature.
How this works
From request to session
- The application asks Your site calls REAL AUTH and describes the sign-in it wants: which account, which organisation, which role, valid for how long.
- The person sees the details Their device shows exactly what is being requested, including the domain doing the asking, rather than a bare "approve?" prompt.
- The device signs, locally Face, fingerprint or PIN unlocks a key held by the device. The biometric never leaves it; REAL AUTH receives only a signature.
- Your application gets a verdict Approved, rejected or expired — bound to the exact values that were shown, so the answer cannot be reused for a different session.
Possible outcomes
Four answers, and one of them is silence
A verification request has more than two endings. Treating anything other than an explicit approval as approval is how verification systems fail people.
Rejected
The registered person saw this request and refused it. Treat it as fraudulent and report it.
Expired
The request was not answered in time and is no longer valid. Start again if it was genuine.
No response and Not verified are never shown as approval, and they never turn into approval by waiting.
Honest limits
What this does not fix
A verified login says the right person approved this session. It says nothing about what happens afterwards: malware already running on the device, a hijacked session token, or a person acting under duress remain your problem. REAL AUTH reduces the value of stolen credentials; it does not make an endpoint trustworthy.
Related use cases
Phishing and impersonation
Verify the request through a channel the attacker does not control, instead of judging whether a message looks…
Scopri di più →Deepfakes
A convincing imitation of a voice or a face still does not hold the credential. Verify the person, not the rec…
Scopri di più →Organisation authority
Not "is this a real employee", but "does this person hold this authority, right now, in this organisation".
Scopri di più →Try it against your own application
A free sandbox, real flows, and no card required.