No. 07Week of September 23, 2026This week’s briefing
Tradecraft

Field guideNo. 03

Rolling out passkeys to retail banking customers

Passkeys are the phishing-resistant option NIST now accepts at AAL2. Getting millions of customers to use them is a product problem as much as a security one. A rollout plan, from policy to recovery.

By Reviewed by [REVIEWER NAME]Published 3 min read

For IAM engineers Product & payments Security engineers

The short answer

How should a bank roll out passkeys to its customers?

Decide which passkeys you accept for which customers, offer enrollment right after a strong sign-in, make passkeys the default for returning users, and design account recovery that doesn’t fall back to an SMS code. Keep a non-SMS alternative for customers who can’t use passkeys, and a device-bound option for staff and other high-risk users.

If you read nothing else

  1. A passkey is bound to the bank’s domain, so a look-alike phishing site gets nothing to relay.
  2. NIST 800-63-4 accepts synced passkeys at AAL2; AAL3 still calls for hardware-bound keys.
  3. Syncing moves part of the risk to the customer’s Apple, Google or password-manager account.
  4. Recovery is where passkey deployments get attacked. Don’t fall back to SMS there.
Illustration of a phone screen approving a passkey sign-in
A passkey sign-in approved on the device itself, with nothing to type and nothing to intercept. Illustration.

Why passkeys, and why now

A passkey is a FIDO2 credential: a key pair where the website keeps the public key and the private key stays with the customer. When the customer signs in, the browser or app checks the site’s domain and offers only the passkey registered for it, so a phishing page on a look-alike domain receives nothing it could replay.[3][4]

NIST’s 800-63-4 guidelines accept synced passkeys, the kind stored in Apple, Google or password-manager accounts, at authentication assurance level 2, the level most consumer and banking sign-ins target.[1][2] That gives US banks a standards-backed, phishing-resistant alternative to SMS codes for the first time.

Step 1 Decide which passkeys you accept, for whom

Tradecraft’s summary of NIST 800-63B-4 and FIDO Alliance guidance. [YOUR POLICY: which customer segments count as high-risk]
PopulationPasskey typeWhy
Retail customersSynced passkeys acceptedSurvive a lost phone; accepted at AAL2
Customers with high-value or high-risk profilesSynced, with extra checks on new devicesThe sync account becomes part of the attack surface
Staff, administrators and support agentsDevice-bound keysCredential never leaves the hardware
Use cases that require AAL3Hardware-bound keysNIST still calls for them at AAL3

Step 2 Offer enrollment at the right moment

Enroll customers right after they have signed in strongly, on a device you already trust, so the new passkey inherits a good starting point. Common moments:

  • After a successful sign-in on a recognized device.
  • During mobile app onboarding, once the device is registered.
  • When the customer next faces an SMS code, as the alternative on the same screen.

Avoid offering enrollment straight after a weak recovery, when you are least sure who is on the other end.

Step 3 Make passkeys the default for returning customers

Once a customer has a passkey, lead with it. Show other methods as a fallback, not as an equal choice, and track how often customers take the fallback: that number tells you where the passkey experience is failing. [YOUR DATA: fallback rate by platform]

Step 4 Design recovery that doesn’t fall back to SMS

Recovery is where passkey deployments get attacked. If a lost-phone flow ends in an SMS code, an attacker with a hijacked number can still walk in.

  • Recover with what the customer already has, such as a second device or another passkey.
  • Check for a recent SIM change before trusting the phone number at all. See our SIM swap response guide.
  • Slow down risky changes immediately after recovery, such as new payees or a new phone number.

Step 5 Plan for customers who can’t use passkeys

Some customers have older devices, shared devices or accessibility needs that make passkeys hard. NIST’s rules for restricted authenticators require at least one alternative that isn’t restricted,[2] so give these customers an option other than SMS, such as approval in the bank’s app on a registered device. [YOUR DATA: share of customers on devices without passkey support]

Step 6 Explain it in one sentence

Customers don’t need the cryptography. They need a reason and a promise: a passkey only works on the bank’s real website and app, so a fake site can’t steal it, and the bank will never ask for it. Put the same sentence in the app, on the website and in the support script.

Who owns this

A suggested split: R responsible, A accountable, C consulted, I informed.
ActivityIAM eng.Security eng.ProductFraud & riskSupportCISO
Passkey policy by segmentRCCCIA
Enrollment and sign-in UXCIA/RCCI
WebAuthn integrationA/RCCIII
Recovery designRCCACI
Alternatives for non-passkey customersRIACCI
Adoption reportingCIA/RCII

Questions readers ask

Are synced passkeys phishing-resistant?

Yes. A passkey is bound to the website it was created for, so it can’t be used on a look-alike site. NIST 800-63-4 accepts synced passkeys at AAL2.

What is the difference between a synced and a device-bound passkey?

A synced passkey is backed up and copied across a user’s devices by a provider such as Apple, Google or a password manager. A device-bound passkey never leaves the hardware it was created on, such as a security key.

What should a bank do for customers who can’t use passkeys?

Keep at least one alternative that isn’t a restricted authenticator, such as approval in the bank’s app on a registered device, so no customer is left with SMS as the only option.

Sources

  1. FIDO Alliance NIST cites phishing resistance of synced passkeys in digital identity guidelines update
  2. NIST SP 800-63B-4: Authentication and Authenticator Management
  3. W3C Web Authentication: An API for accessing Public Key Credentials
  4. FIDO Alliance Passkeys

Changelog

  • : First edition, assembled from Tradecraft’s sourced explainers. Awaiting editorial verification.

Cite this

Tradecraft. “Rolling out passkeys to retail banking customers.” Tradecraft, September 24, 2026. https://glide-tradecraft.pages.dev/field-guides/passkeys-for-retail-banking/

Read next

Explainer

Are synced passkeys phishing-resistant?

Yes. A passkey is bound to the website it was created for, so it can’t be entered on a look-alike site. NIST’s 800-63-4 update accepts synced passkeys at AAL2. The main new risk is the account that syncs them, which needs strong protection of its own.

Buyer’s guide

Phishing-resistant MFA: a buyer’s guide

Phishing-resistant MFA is authentication that a fake site or man-in-the-middle can’t capture and replay, because the credential is cryptographically bound to the real site. FIDO2 passkeys and hardware security keys are the common examples, and CISA also counts PKI-based smart cards. SMS codes, authenticator-app codes and simple push approvals are not phishing-resistant.

Field guide

Moving a bank off SMS OTP: the field guide

Inventory every flow that sends a code, write the risk assessment NIST SP 800-63B-4 asks for, fix account recovery and new-payee setup first, then move customers to phishing-resistant or device-bound methods such as passkeys and in-app approval. Keep SMS only as a restricted fallback, with a dated plan to remove it.

Take the checklist

Terms in this piece