Passkeys Are Stronger.
So Was SMS OTP on the Day We Adopted It.

How to read this article: find your lane first

How the badges work. Every section below opens with a one-line badge. It names the lanes the section is written for, the themes it touches, how deep it goes, and whether it is published openly or available on request. Skim the badges and you can build your own reading path in under a minute — or read only the badges marked with your lane and treat the rest as reference.

The five themes, in one line each. Loss — where fraud moves and what it costs. Experience — sign-in success, cost-to-serve, adoption. Proof — compliance, regulatory, evidentiary and reputational exposure. Build — technology, security, third-party dependency and resilience. Shelf life — the expiry date every control carries and nobody prints. Appendix B expands each one.

Wherever you start, read the next section first. It is ninety seconds long, and it is the argument the rest of the article defends.

The SMS OTP lesson: we have run this experiment before

Before any argument about Passkeys, it is worth remembering how the last one went. SMS one-time passcodes were, on the day the industry adopted them, a genuine and significant improvement. Nobody was wrong to deploy them, despite multiple shortcomings that were already known, or could have easily been known through a threat assessment. Account takeover fell. Customers understood them. Examiners approved of them. For roughly a decade, “we send a code to the phone on file” was a good answer to a hard question.

Then it stopped being a good answer, and the industry took another decade to say so out loud. The failure was not that we adopted SMS OTP. The failure was that we never wrote down what would eventually break it, never assigned anyone to watch for those things, and never set a date to revisit the decision. We bought the milk, put it in the fridge, and never printed an expiration date on the carton — then acted surprised, fifteen years later, when it had expired.

So the useful question about Passkeys is not whether they are strong enough. They are. The useful question is the one we failed to ask in 1998: for each thing that eventually broke SMS OTP, what is the structural equivalent in a Passkey world, and who is watching it?

↔ Swipe the table sideways to see all three columns.

Read the middle column again. Not one of those structural weaknesses was cryptographic. SMS OTP did not fall because six digits were guessable. It fell because of dependency, custody, enrollment, human suggestibility, inventory, delivery, and governance. Passkeys transform the right-hand column and barely touch the middle one. That is the whole argument of this article, and it is why the operating model that follows is organized around lifecycle and a trust fabric/framework rather than around the credential.

Three themes follow from that, and they set the stage for everything below.

• Theme 1 — Inherited trust. Every control you deploy carries dependencies you did not choose and cannot see. With SMS OTP it was the carrier and the signaling network. With Passkeys it is the platform vendor and the credential vault — and unlike the carrier, you have no contracts to leverage, no SLA, and no notification path. The institution owns the risk but not the control. This theme runs underneath the transferable-Passkey section, and it is the subject of a forthcoming article in this series on inherited risk — what an institution takes on when third and fourth parties enter its process, methodologies and standards bodies included.
• Theme 2 — Shelf life. SMS OTP had a shelf life from the first day it was used; we simply never printed the date on it or assigned an owner to watch it. Passkeys have one too. Naming the conditions that would end a control’s useful life — at adoption, not at post-mortem — converts a future emergency into a scheduled decision. A forthcoming article in this series takes up capability shelf life directly: how to assign expiration criteria to a control when you deploy it, and how to manage to that criteria rather than be surprised by it.
• Theme 3 — Accumulated complexity. The industry rarely retires anything (hat tip to KBA as an outlier). SMS OTP was added on top of passwords; Passkeys are now being added on top of both. Every path we keep is a path that must be governed, staffed, monitored, and defended forever. Financial services has done this with the deposit account itself — every account ships with the same maximum risk footprint (look for an upcoming article on this topic), nothing is ever sunset, and complexity only accretes.

Passkeys are succeeding — but they are necessary, not sufficient

Passkeys are one of the most important authentication improvements financial services has seen in years. They reduce reliance on reusable secrets, make credential phishing materially harder, and remove much of the friction that has made passwords, SMS OTP, and legacy MFA so costly to support.

That matters because authentication is no longer just a security ceremony. It is part of the customer experience, the fraud-control model, and the economics of digital banking. A login flow that fails or frustrates a customer can become a support call, an abandoned journey, a reset request, an opening for social engineering, or a lost customer.

The best evidence for Passkeys starts with their strengths. The October 2025 FIDO Passkey Index reported 93% successful Passkey sign-ins compared with 63% for other methods, with average authentication time decreasing from 31.2 seconds to 8.5 seconds. Participating platforms also reported up to an 81% reduction in sign-in-related help-desk incidents. Those results should be understood for what they are: anonymized, self-reported outcomes from a group of large Passkey implementers, not a guarantee that every deployment will perform the same way.

The scale evidence points the same way, and it carries a warning inside it. The FIDO Alliance’s State of Passkeys 2026 report puts 5 billion Passkeys in active use, with 90% of consumers familiar with Passkeys and 75% having enabled them on at least some accounts, while 68% of organizations are deploying, piloting, or rolling out Passkeys for employee authentication. Among organizations that have already deployed Passkeys, 57% still use passwords in parallel (as well as for enrollment, etc.). Adoption is not replacement. For as long as the old path stays open beside the new one, the institution’s real authentication strength is the weaker of the two, not the stronger. Financial institutions are most likely moving through a methodical approach to offer Passkeys in parallel with passwords to assist with adoption, with the plan to move to Passkey-only once customers feel comfortable and confident in the new authenticator. Still, the direction is clear. Passkeys are faster, easier, and meaningfully more resistant to phishing and credential replay than the tools they are replacing. Financial institutions should not slow-roll that progress. They should accelerate it, but with a more mature understanding of what Passkeys do and do not prove.

Put it in the seven words that should travel: Passkeys are necessary. They are not sufficient.

Who actually offers Passkeys today — and what type

The FIDO Alliance maintains a public Passkey Directory of live implementations, currently listing 155 entries and explicitly flagging, for each one, whether the experience is Synced — available across a user’s devices — or bound to a single device such as a FIDO security key or a mobile app. FIDO also reports that 48% of the top 100 websites now offer Passkeys, more than double the 2022 figure. Financial services is ahead of that curve rather than behind it: industry benchmarking places fintech and banking at roughly 60% active Passkey adoption among eligible users, against about 35% for ecommerce, 28% for B2B SaaS, and 18% for media — a spread driven less by technology than by the cost of an account takeover, estimated at $200 to $4,500 per incident in fraud losses and remediation.

↔ Swipe the table sideways to see all three columns.

Some observations that may matter more than the roster itself.

• The industry standardized on Synced, mostly by default. Almost every consumer financial-services deployment in production today is a Synced Passkey, riding iCloud Keychain, Google Password Manager, or something similar. Regardless, it was selected by the financial institution. It is what ships in the platform SDK, what the customer already has, and what converts. Device-bound credentials remain concentrated in workforce, treasury, and privileged-access use cases, where FIDO2 security keys are the norm — and that bank’s U2F support is the visible consumer-side exception that proves the pattern.
• Nobody in this table chose transferable Passkeys (explained further in an upcoming section). No institution in the table above chose to make its customers’ credentials transferable. None was consulted, none signed anything, and today none can see it happen barring tracking capabilities used in conjunction with the Passkey itself. Transferability arrived through an operating-system update and a credential-manager release. That is the cleanest illustration of inherited risk available to this industry right now: a material change to the custody model of your strongest authenticator, delivered by a party you have no relationship with, with no event reaching your fraud platform.
• Availability is not adoption, adoption is not replacement, and replacement is not legitimate. The 2025 and 2026 FIDO reports show tremendous progress in the roll-out of a necessary improvement. Unfortunately, the progress that financial services institutions are looking for is more about the outcomes (fraud loss, client experience, overhead, regulatory, and growth) that have been suffering from the authenticator(s) being replaced. To bring this home with a sports analogy: a suffering sports franchise recruits a flashy five-star athlete to replace a struggling, injured key player — expecting the new player to completely change their game. They haven’t invested in facilities, staff, playbooks, or other key positions, but they expect major change. The impressive progress can’t be misconstrued as points on the proverbial scoreboard — they’re simply impressive stats about the new star athlete in the gym and the practice arena. Bringing it back to Passkeys, replacement of the old, outdated “injured” authenticators is the ultimate metric we’re looking for — but even those metrics don’t mean points on the board, because it could ultimately have been fraudsters enrolling. It is mission critical to continue to invest in the entire identity and authentication “franchise” and not put all the weight on the shoulders of one authenticator.
• A hybrid and/or layered approach is table stakes. Deploying Synced Passkeys for the customer experience while separately drawing additional device signals and/or deploying an additional key (whether device-bound or not) on each device the customer uses is a conversation that should continue — to make AAL2 and/or AAL3 components in a composite authenticator assurance score, so that the bank, not the platform, knows its ultimate level of trust in a given device and the intent of the customer.

Caveats on the data shared above. Public directories and vendor-maintained trackers are not exhaustive and lag real deployments, particularly for institutions that ship quietly. And the adoption benchmarks above blend surveys, password-manager telemetry, workforce enrollment data, and vendor platform data, each with a different denominator — treat them as a range and a direction, not as a scoreboard. No data points age well, so use these as directional in nature and self-source the most recent data based on when you’re consuming this article.

A note on attribution. Individual institutions are not named in this article. Every entry above is drawn from public directories, vendor trackers, and published implementation notes, and each is described by size, market, and business model rather than by name. Nothing here discloses a non-public deployment detail about any institution. The purpose of the table is to establish the shape of the market — who has shipped, and what credential type they shipped — and that shape holds without the nameplates. Readers who want the underlying roster can work from the public directory cited above.

The root problem: authentication is not intent

The financial-services industry has a long history of confusing a stronger control with a complete control. SMS OTP was better than password-only access, but it did not end account takeover. It introduced new dependencies and new attack paths, from SIM swap fraud to social engineering and telecom exposure.

Passkeys are different and stronger, but the lesson is similar. Stronger authentication does not eliminate every fraud pathway. It reduces specific authentication risks and forces attackers to adapt.

Passkeys reduce credential-phishing and credential-replay risk. But as those paths become less productive, attacker activity migrates toward the remaining weak points: enrollment, account recovery, fallback authentication, endpoint compromise, session integrity, support workflows, and transaction authorization.

That distinction is especially important in banking, wealth, payments, and business treasury. A login event is not the same as a transaction decision. Like any other authenticator, a Passkey can authenticate a user or device in a particular ceremony, but it does not automatically prove that the customer intended to approve a specific payment, add a new payee, change an entitlement, or recover an account.

Where attacker activity migrates

When credential phishing becomes less valuable, fraudsters do not abandon the objective. They change the path. They still want money movement, account takeover, identity access, persistence, or sensitive data. The question becomes which part of the journey remains easiest to manipulate.

The most likely pressure points are the processes surrounding the Passkey rather than the protocol itself. Attackers will look for opportunities to enroll their own credential, exploit a weak recovery flow, downgrade the user to a phishable fallback method, steal or abuse an authenticated session, manipulate the endpoint, or trick a support representative into resetting access.

Recent security research reinforces this point, but it should be scoped carefully. Unit 42 reported attacks against Google Password Manager’s Synced-Passkey ecosystem in Chrome on Windows where the prerequisite was an already-compromised endpoint. The research did not show that the WebAuthn protocol was broken. It showed that attackers may target onboarding, recovery, device trust, browser state, and credential-manager implementation details when they cannot simply phish a password.

That is exactly the lesson financial services should take from the research. The Passkey event matters, but it is one signal in a broader trust decision. Institutions need to understand what happened before the Passkey was enrolled, what device and session context surrounds the event, what recovery paths remain available, and what transaction the customer is being asked to approve.

• Enrollment: A fraudster who can register a new Passkey has created durable access, especially if credential changes are not monitored or strongly confirmed.
• Recovery: If recovery still depends on email, SMS, call-center scripts, or weak identity proofing, attackers can bypass the strongest login ceremony. Recovery is not a password-reset-grade event once Passkeys are deployed; it becomes the primary residual attack surface, and it should be scrutinized with the same rigor an institution applies to a high-value payment.
• Endpoint and session: Malware, malicious extensions, stolen cookies, remote access tools, and compromised browsers can abuse a legitimate authenticated session.
• Social engineering and real-time scams: Passkeys defeat remote credential phishing. They do nothing against vishing, romance and investment scams, impersonation of the bank’s own fraud team, or any “help me move my money” script in which the victim authenticates willingly and correctly. Authorized-push-payment style losses are already among the highest-loss categories in the industry, and they are almost entirely unaffected by how strong the credential is. A perfect Passkey ceremony performed by a customer under a fraudster’s direction is still a perfect Passkey ceremony.
• Transaction context: A customer can be properly authenticated while still being socially engineered, redirected, or manipulated into approving the wrong action.
• Fallback: Passwords, SMS, email OTP, and support overrides become the practical path of least resistance if they remain available for high-risk users.
• Transfer and portability: A Passkey that can be exported from one credential manager and imported into another is a Passkey that can be moved to an attacker’s vault, or copied to a device you have never seen, without any new enrollment event at your institution.

Operational and experience constraints that still force trade-offs

Every argument above is about what an attacker does. This one is about what a customer cannot do. Two operational realities routinely break the clean experience Passkeys promise, and both of them end the same way — with the institution quietly keeping a weaker method alive to absorb the failures.

Corporate clients operating in Virtual Desktop Infrastructure (VDI)

Device-bound Passkeys depend on local device hardware — a Trusted Platform Module (TPM), a Secure Enclave, or a platform authenticator — that is frequently unavailable or unreachable inside a VDI session, a thin client, or a locked-down remote workstation. The cryptographic ceremony often cannot complete cleanly, so users meet failed authentications and repeated prompts instead of the one-touch sign-in they were promised. Institutions respond the only way they can: they keep hardware tokens, soft tokens, or push MFA running in parallel. That is the whole problem in one sentence — the environment where your treasury and commercial clients actually work is the environment where your strongest credential is least likely to function, so the weakest (or most clunky) control in your stack survives precisely where the financial risk is the largest. Until VDI platforms deliver mature passthrough support for platform authenticators, corporate and treasury journeys should be designed assuming a governed fallback exists, not assuming it has been eliminated.

Cloud-Synced versus device-bound: choosing deliberately, not by default

Device-bound Passkeys are the strongest model because the private key never leaves the device, which removes the sync path from the attack surface entirely. Cloud-Synced Passkeys deliver the better experience — roaming across phone, laptop, and tablet with no re-enrollment, which is exactly what drives adoption, and adoption is what actually reduces credential-based account takeover. The trade-off is concentration risk. Leaning on a third-party credential vault imports that vendor’s breach exposure, outage exposure, master-password strength, and recovery design into your own control model.

Think of it as the difference between every customer keeping cash in a home safe and every customer keeping it in one shared depository: the depository is more convenient and usually better run, but a single failure there reaches all of them at once.

If a vault provider is compromised, synchronization stops being a convenience feature and becomes a distribution channel — attacker-controlled credentials propagating to every relying party in that vault. The answer is a written risk-versus-experience policy rather than a default: managed cloud sync is appropriate for lower-risk retail segments provided recovery, vendor risk, and breach response are hardened around it, while high-value accounts, privileged roles, and payment approvers should be held to device-bound or hardware authenticators.

The customer-experience failure modes worth naming

Beyond VDI, the predictable friction points are shared and family devices, older hardware without a usable authenticator, unsupported browser and OS combinations, kiosk and branch terminals, accessibility needs, and multi-device customers who resist enrolling a second and third time. Each one is a moment where the customer abandons the journey, calls support, or is routed to a weaker method — which means each one converts a security improvement into a support cost and a residual risk. Instrument these paths before scaling, because they are where the projected CX benefit silently leaks away.

Transferable Passkeys: when the key can leave the keyring

For most of their short life, Passkeys have been described in two flavors. A device-bound Passkey lives and dies on one authenticator, such as a hardware security key or a platform authenticator like Windows Hello or Touch ID. A Synced Passkey is replicated by a credential provider across the devices tied to one account, such as iCloud Keychain or Google Password Manager. A third flavor that is ultimately a Synced Passkey is now replacing the merely syncable Passkey, and it changes the fraud model again: the transferable Passkey.

A transferable Passkey is a Passkey that can be exported from one credential provider and imported into another — Apple Passwords into Bitwarden, Google Password Manager into 1Password, one vault into the next — in an encrypted, standardized package rather than a plaintext file. The private key is not broken or exposed in transit. It simply relocates. Apple has taken this a step further and allows an AirDrop from one device to another device with a different Apple ID.

A device-bound Passkey is a key cut for one lock and welded to one keyring. A Synced Passkey is that key copied to every keyring you own. A transferable Passkey is a key you can hand to a different keyring company entirely — and the new company issues its own copies, on its own terms, to its own customers.

That is genuinely good for consumer choice. It is also a new movement of value, and fraud follows movement.

The standards behind it

The FIDO Alliance published working drafts of two complementary specifications on October 14, 2024: the Credential Exchange Format (CXF), which defines a JSON-based standard representation for Passkeys, passwords, time-based one-time password (TOTP) secrets and notes, and the Credential Exchange Protocol (CXP), which defines the encrypted transfer itself using Hybrid Public Key Encryption (HPKE). CXF advanced to Proposed Standard on August 14, 2025, with an erratum published March 9, 2026. CXP has moved more slowly; the widely referenced working draft is dated October 3, 2024 and states on its face that it is “not intended to be a basis for any implementations.” In practice, that means format has outrun protocol: much of what ships today is local, same-device migration rather than fully standardized provider-to-provider transfer.

The specifications were authored by the FIDO Alliance’s Credential Provider Special Interest Group, whose participating members include 1Password, Apple, Bitwarden, Dashlane, Enpass, Google, Microsoft, NordPass, Okta, Samsung and SK Telecom. This is not a fringe capability. It is the platform layer of the internet agreeing that credentials should move.

Who offers transferable Passkeys today

↔ Swipe the table sideways to see all three columns.

The risk this poses to the ecosystem

The protocol is not the problem. Every risk below sits in the human and process layer around the transfer, which is precisely where fraud has always lived.

• Your institution is not a party to the transfer. Passkey portability is a transaction between the customer and two credential providers. The relying party — the bank — is not consulted, does not consent, and in most designs is never notified. A credential you treated as high-assurance can change custody without a single signal reaching your fraud platform.
• Vault compromise becomes credential compromise at scale. Before portability, compromising a password manager yielded passwords. After portability, it can yield exportable phishing-resistant credentials for every relying party in the vault. The blast radius of a single vault takeover expands from “reset these passwords” to “revoke and re-enroll every Passkey.”
• A brand-new social engineering script. “Your bank is migrating to a new secure vault — tap Export to move your Passkeys.” Scam artists do not need to defeat WebAuthn if they can get the customer to hand over the credential through a legitimate, well-designed, officially blessed operating-system flow. Import-initiated models on Android make a malicious destination app especially attractive.
• Assurance-level deflation. If your CIAM team scores an authentication ceremony composed of signals with a Synced Passkey as the anchor — and that credential can now be moved by anyone who controls the customer’s vault account or platform account — the composite ceremony score is wrong. For example, and purely for illustrative purposes: if prior to transferability a CIAM team assigned AAL1, AAL2, and AAL3 a weighting of 1, 2, and 3 respectively within a group of other signals for an overall authentication assurance score, it likely makes sense that the overall score should be reduced, and thus a new weighting for AAL2 should likely be assigned — maybe 1.5.
• Post-transfer authentications look flawless. A transferred Passkey produces a valid assertion for the legitimate origin. There is no phishing artifact, no proxy, no OTP interception, no anomalous credential. The only signal available to you is context: a new device, a new platform, a new location, a changed behavioral pattern. If you are not collecting and scoring that context, you have no detection at all.
• Recovery and support channels inherit the risk. A customer who moves Passkeys and then loses access will call you. Call-center recovery is already the softest surface in most institutions; portability adds a plausible, sympathetic, technically confusing story for the fraudster to tell. Even if one of the above risk events is thwarted, it is going to drive support issues. It’s critical to start educating support functions (branch, call center, etc.) on Passkeys so they are prepared to field complex issues when the threats become real.
• The forensic and dispute picture gets murkier. When a credential can legitimately live in more than one vendor’s vault, “the customer’s Passkey authenticated this wire” proves less than it used to. Expect that argument to show up in dispute, liability, and Reg E-adjacent conversations before the controls are ready for it.

Why choose? Deploy both

Rather than choosing between a Synced Passkey and a device-bound one, some industry experts advocate for both: they let the customer enroll a Synced Passkey, because that is what converts and what recovers gracefully, and then they separately create additional trust with a secondary key (or strong device signals) — a key that is generated on the device, cannot leave it, and is never Synced or exported. The Synced Passkey answers “is this the right customer?” The institution’s proprietary device key (or strong device signals) answers a question the Synced Passkey structurally cannot: “is this a device I have seen this customer on before and trust?” Most financial institutions already deploy strong device signals in the event that a secondary device key isn’t an immediate option.

A Synced Passkey is the house key the locksmith will happily copy for the customer at any branch of any locksmith chain. The institution’s device key is the bank’s own tamper-evident seal on the door frame — it does not stop anyone entering, and it does not travel with the key, but the moment someone arrives with a valid key and no seal, you know the key has been somewhere you did not watch.

It converts a silent event into a visible one. That is the entire value proposition, and it is worth being precise about it: this pattern does not prevent credential transfer. It detects it, and allows you to help determine the thin line between trust and risk. There appear to be a few paths to solve for this, but it is likely that they will require experts to work through the best options and outcomes in order to build the best approach.

Before building anything, know what you can already see. Extracting the most value from these data elements requires capture, storage, and integration prior to roll-out.

↔ Swipe the table sideways to see all three columns.

Read the last two columns together and the design principle falls out. Every signal above narrows the question; none of them answers it. The dual-credential pattern is the strongest of them because it is the only one anchored in hardware the institution verified itself rather than in a disclosure the provider elected to make. That is precisely why it is worth building, and precisely why it must not be trusted alone.

Now the costs, because they are real and they land on teams that will not have been consulted.

• It reintroduces the problem Passkeys were meant to solve. A device key cannot be recovered, by definition. Every device replacement, factory reset, or restore-from-backup breaks the binding — this is the same friction that made app-based device binding painful for banks long before Passkeys, where reinstalling from a backup silently severed the association and produced a poor customer experience. If you build this, you are signing up to run a re-binding journey forever, and that journey is now a fraud-relevant enrollment path in its own right.
• The false-positive rate is a customer-experience decision, not a technical one. Customers legitimately buy phones, borrow laptops, and travel. If an unbound device triggers a hard block, your contact center absorbs it and your abandonment rate tells the story. Score it; do not gate on it. Whoever owns digital conversion needs to be in the room when that threshold is set.
• It does not cover the whole estate. Browser-only customers, VDI and thin-client sessions, shared devices, and locked-down corporate builds are exactly where you cannot place a device key — and, as previously outlined, exactly where the largest commercial balances live. The pattern is strongest where your app is, which is not the same as where your risk is.
• It is a second credential lifecycle. Issue, inventory, rotate, revoke, reconcile, and evidence it. If nobody owns that lifecycle, the coverage figure decays quietly until the signal is meaningless and still being scored as if it were not.
• It is an unmanaged shelf-life bet. The pattern works because platforms do not currently expose device identity. That is a policy position, not a law of physics, and it can change in either direction — toward a standardized signal that makes your build redundant, or toward tighter privacy controls that break it. Date this control when you deploy it and name the conditions that would end its life, or you will be having the SMS OTP conversation about it in a decade.

A closing caution on this section. The dual-credential pattern is, as of this writing, not something institutions publish. It surfaces in practitioner conversation rather than in documentation, public case studies, or the vendor trackers cited earlier, and the account here should be read as a description of an approach that is technically sound and reportedly in use rather than as a verified survey of who is running it. That absence is itself informative: a materially different risk posture is being deployed behind an identical customer-facing experience, which means peer benchmarking on “do you offer Passkeys” is measuring the wrong thing. When you next compare notes with a peer institution, the question worth asking is not whether they have shipped Passkeys. It is whether they would know if one walked.

What to do about it

• Signal the credential lifecycle. Use the WebAuthn Signal API and provider management endpoints to keep your and the provider’s credential inventory accurate, and treat any change in authenticator attachment, transport, or platform as a risk event rather than a housekeeping detail.
• Score custody change like a device change. A first authentication from a new platform, new credential provider, or new device following a Passkey should raise risk, throttle money movement, and trigger an out-of-band confirmation — the same way a SIM change or a new-payee event does.
• Require attestation and non-exportability where the money is. For treasury, business banking approvers, privileged administrators, developers, executives and vendors, require device-bound Passkeys or hardware security keys whose private keys cannot be exported by design. Portability with weak attestation is a consumer-choice feature; it should not be a wire-room feature.
• Bind high-risk actions to intent, not to login. Step up with the Passkey again at money movement, payee addition, limit change, and entitlement change, and bind the assertion to the transaction details. Passkeys are not a login-only control, and treating them as one wastes their best property.
• Tell customers the truth in one sentence. “We will never ask you to export, transfer, or move your Passkeys.” That single line, published early and repeated often, is one of the cheapest and most durable controls available against the coming wave of transfer-themed scams.

Why customer communication still matters

The average customer does not need to understand public-key cryptography, attestation, Synced credential architecture, or WebAuthn. Asking customers to carry that cognitive burden is a control-design failure.

But customers do need simple guidance. They should understand that Passkeys protect against stolen and phished passwords. They should also understand that Passkeys do not make every prompt, device, session, merchant, recovery request, or transaction legitimate. And they should know that unexpected enrollment, recovery, or device prompts should be treated as suspicious and reported.

The business consequence of this communication gap is significant. If customers and product teams internalize “Passkey equals safe,” they may treat the authentication event as complete assurance. That is misplaced assurance. The better message is narrower and more accurate: Passkeys are safer against specific credential attacks, and institutions still protect the broader journey around them.

A six-domain operating model for financial services

A mature Passkey deployment should be designed around the full authentication lifecycle, not just the availability of a new sign-in option. For financial services and fintech leaders, the control model should be organized into six domains.

What mature deployment looks like

A Passkey program is not mature simply because Passkeys are available. It is not even mature because many users have enrolled. Success should be measured by actual use, reduced fallback dependence (and availability on a customer-by-customer basis), lower credential-driven account takeover, stronger recovery controls, improved customer completion, and better fraud outcomes after enrollment and recovery events.

Financial institutions should separate three milestones that are often conflated: technical availability, credential enrollment, and password elimination. A customer may be eligible for Passkeys but not enrolled. They may be enrolled but still sign in with a password. They may sign in with a Passkey but recover through SMS. Each gap changes the risk picture.

Recommended actions

Where this series goes next

Three arguments in this article open onto questions larger than Passkeys. Each is the subject of a forthcoming piece.

• Inherited risk. Passkeys are the current example, not the general case. Every time an institution brings a third party into its process — and then inherits that party’s own vendors as a fourth — it absorbs risk it did not price, cannot see, and did not contract for. That applies to credential providers and platform vendors, and it applies to methodologies and standards bodies too: adopting a framework means inheriting its assumptions, its release cadence, and its blind spots.
• Capability shelf life. SMS OTP had an expiry date on the day it was first deployed. So does every control now in production, including this one. The discipline worth building is naming the conditions that would end a control’s useful life at the moment of adoption, assigning an owner to watch for them, and scheduling the decision — rather than discovering years later that a control everyone still calls secure has quietly become the weakest thing in the stack.
• The DDA risk footprint. Every deposit account is issued with the same maximal risk footprint regardless of how the customer will actually use it, and nothing is ever retired — paper checks included — while new capability keeps accreting on top. Passkeys are the newest layer on an account that still exposes decades of older ones.

Conclusion

The right answer is not to question whether Passkeys are valuable. They are. Financial services should lead their adoption because they reduce real authentication risk and improve customer experience.

The right answer is to deploy them with precision. Passkeys strengthen the front door, but fraud will test the enrollment desk, the recovery path, the fallback option, the endpoint, the browser session, the payment screen, and the support channel. It will also test the operational realities of enterprise environments — the VDI session that cannot reach a Secure Enclave, and the vault that holds the credential you no longer control.

Organizations should therefore assess the complete authentication lifecycle before scaling: credential selection, enrollment, device trust, recovery, fallback, session protection, and transaction authorization. The objective is not simply to eliminate passwords. It is to reduce fraud while improving customer experience without transferring institutional confidence to an authentication event that cannot prove everything the business needs to know.

Passkeys are a stronger front door. Fraud will look for the side door.

Passkeys are stronger than passwords. They are a major step forward, and financial services should lead their adoption. But the industry has been here before, with a control it also called strong, also deployed widely, and also failed to date. Passkeys are necessary. They are not sufficient. And they are not permanent. In financial services, safer authentication is only the beginning of safer digital trust.

Appendix A — Source links referenced in the article

Appendix B — Lane index: seats, themes, and tag legend

This appendix is the lookup layer. The body of the article needs only the three lanes. This is where the detail that used to sit on pages 2 through 5 now lives — every seat, its lane, and the one sentence that is true for that seat.

B.1  Which lane is your seat in?

↔ Swipe the table sideways to see all three columns.

Twenty seats, three lanes, no seat unassigned. If your title is not on this list, use the sorting question instead — a budget or a stated position is Fund it, a system or a specification is Build it, a script or a case or a customer answer is Face it.

B.2  The five themes

↔ Swipe the table sideways to see all three columns.

B.3  Badge legend

↔ Swipe the table sideways to see all three columns.