Verified
The registered person approved this exact request on their trusted device. You can act on it.
Casos de utilização
Sensitive actions
Changing a payout account, adding an administrator, issuing a production key — approve the exact change, not the category.
The problem
Being signed in is treated as permission for everything
Most applications check who you are once, at the door, and then allow anything the role permits. So a stolen session, a borrowed laptop or a moment of misplaced trust grants not just reading, but the power to change who controls the account.
What changes
Re-ask, at the moment of consequence
High-consequence changes require a fresh approval that names the old value and the new one. Approving "change the payout account to X" cannot be replayed to set it to Y, because the approval is bound to the values it displayed.
How this works
Approving a specific change
- A sensitive change is requested Payout details, administrators, recovery methods, API secrets, webhook endpoints, deletion.
- Old and new values are shown together The approver sees what it is now and what it would become.
- A fresh, strong check is required A password-only session cannot authorise this. It needs a recent passkey verification.
- The change and its approval are logged Append-only, including who approved it and against which values.
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
This protects the moment a change is made. It does not protect against an authorised person who genuinely wants to do harm, and it cannot help where an application never asks REAL AUTH in the first place. Coverage is exactly as good as the list of actions the integrating application chooses to protect.
Related use cases
Organisation authority
Not "is this a real employee", but "does this person hold this authority, right now, in this organisation".
Saber mais →Secure login
Verify who is signing in, from which device, into which account, with which role — before the session exists.
Saber mais →Crypto and wallet verification
Proving ownership of a wallet is not the same as proving a person intended this transaction. Confirm both.
Saber mais →Try it against your own application
A free sandbox, real flows, and no card required.