Modern MFA without the SMS friction.
Strong authentication should feel like less work, not more. Assure is built to replace or augment one-time codes with passkeys, verified messaging and step-up challenges that fit the risk of the action.
This page describes how Assure approaches customer authentication. Nothing here is presented as shipping unless it says so.
What is an alternative to SMS one-time codes?
Passkeys for sign-in and a verified approval request in the customer's own messaging app for sensitive actions. Both remove the step where a customer reads digits out of one app and types them into another — the step that fraudsters rely on.
Authentication is not just the login screen.
Customers meet authentication at a dozen moments. Each one has a different risk profile, and each one deserves a challenge that matches.
Sign-in
Recognise a returning customer without making them wait for a code to arrive.
Registration
Confirm a new account belongs to a reachable, real person before it is created.
Password reset
The flow attackers target first. It deserves the same assurance as the login itself.
Account recovery
Re-establish trust when the customer has lost the device or credential they used before.
Step-up authentication
Challenge the individual action — a payout, an address change, a new payee — not every session.
Transaction verification
Show the customer exactly what they are approving, then record that they approved it.
High-risk changes
Email or phone number changes, new devices, permission grants and admin actions.
Customer-service authentication
Verify the person on the line or in the chat without asking an agent to read a code back.
Choose the factor that fits the moment.
No single method suits every customer or every action. The point is to stop treating one-time codes as the default answer.
Passkeys
Device-bound public-key credentials built on FIDO2 and WebAuthn. Nothing reusable is sent, so there is nothing to intercept or read aloud.
How passkeys work →Verified messaging
An approve-or-decline request in the customer's own messaging app, from a sender they can identify. Better suited to authorization than an anonymous code.
See the verification experience →One-time codes
Still the right answer in some places — a customer with no supported device, an agent-assisted call, a legacy channel. Treat OTP as a fallback rather than the default.
Your existing identity provider
Assure is designed to complement the identity stack you already run rather than replace it, using standards-based interfaces. No partnership or integration with any identity vendor is claimed today.
Step-up challenges
Raise the assurance level for one action and return the result to the system that asked for it, so the challenge fits the risk.
SMS one-time codes vs passkeys.
Both have a place. They are not equivalent on security, cost or experience.
| SMS one-time code | Passkey | |
|---|---|---|
| Phishing resistance | Low. A code can be read out, forwarded or entered on a look-alike page. | High. The credential is bound to the origin it was created for. |
| Customer effort | Switch apps, wait, read, retype, sometimes request again. | One device gesture in the page the customer is already on. |
| Cost per authentication | A per-message fee every time, including retries and failures. | No per-message fee once the passkey is registered. |
| Deliverability | Depends on carriers, routing and roaming. Delays are common. | No delivery step at all — nothing is sent. |
| Device dependency | Works on any phone that receives text messages. | Requires a device and platform that support passkeys. |
| Recovery story | Often used as recovery, which is why it remains a target. | Needs a deliberate recovery path for new or lost devices. |
| Best used for | Fallback where no better method is available. | Everyday sign-in and step-up approvals. |
Neither column is a claim about Assure's shipping functionality. Passkey and messaging capabilities are still in development.
Authenticate the action, not just the session.
A session that started an hour ago is weak evidence that the person at the keyboard approves what is happening now. Step-up puts the decision back where it belongs.
The challenge should fit the risk — not interrupt everyone equally.
- 1A customer is already signed in and asks to move money to a new payee.
- 2Your system decides this action needs more assurance than the session provided.
- 3Assure is designed to present the exact action — amount, destination, time — to the customer.
- 4The customer approves with a passkey or in a verified conversation.
- 5Your system receives the result and proceeds, with a record of what was approved.
Recovery deserves as much assurance as login.
Attackers rarely fight the front door. They ask for a new key.
Recovery is the weakest link in most estates
An account protected by a passkey but recoverable with an emailed code is, in practice, protected by that emailed code.
Give recovery its own assurance level
Treat recovery as a high-risk action: a verified conversation with a known sender, a second trusted device, or an agent-assisted flow with real verification.
Keep the person in control
Recovery should tell the customer what is being restored and let them decline it, not just let them through.
Assure's account recovery capability is still in development.
Built on the vocabulary your security team already uses.
Standards help us describe the design precisely. They are not a substitute for certification, and we do not claim any.
FIDO2
The specification family behind phishing-resistant, device-bound credentials.
WebAuthn
The browser API that lets a website create and use those credentials natively.
NIST Digital Identity Guidelines
A useful framework for reasoning about authentication assurance levels. Our design is informed by it.
OAuth 2.0
A delegated authorization framework — it governs what a client may do on a user's behalf.
OpenID Connect
The identity and authentication layer built on top of OAuth 2.0.
REST and webhooks
Ordinary integration surfaces, so authentication results can reach the systems that need them.
Assure is designed around FIDO2, WebAuthn and the NIST Digital Identity Guidelines. No FIDO certification, NIST certification or compliance attestation is claimed.
Frequently asked.
Give customers a better way to prove it's them.
Authentication for today. Authorization for what's next.