I have run enough MFA rollouts to know the pattern. We spend a year pushing push notifications and TOTP codes, we declare victory, and eighteen months later the incident report says a help desk agent approved a reset for someone with a convincing accent and a LinkedIn profile. The control didn't fail because people are stupid. It failed because the control still depends on a secret that a human can be talked out of.

That is the whole argument for passkeys, and I think it is worth being blunt about it: passwords plus a code are not phishing resistant, and the attackers figured that out long before most of our roadmaps did. So let's talk about what actually changes, what doesn't, and how to get the people who sign the checks and the people who click the buttons on your side.

Which control failed, exactly

A password, an SMS code, a TOTP code and a push prompt all share one property: the proof of identity is a value that can be relayed. An adversary in the middle proxy (Evilginx and its cousins) sits between the user and the real login page, forwards everything in real time, and walks away with a session. CISA said this plainly in its 2022 fact sheet on implementing phishing resistant MFA: app based codes and push are better than nothing, but only FIDO/WebAuthn and PKI based methods qualify as phishing resistant. NIST SP 800-63B says the same thing in more formal language, and reserves its higher assurance levels for authenticators that verify the origin.

Passkeys are the consumer friendly packaging of that model. The credential is a public/private key pair. The private key never leaves the authenticator (a phone, a laptop, a security key). During login the browser binds the signature to the relying party ID, which is your domain. If the user is on evil.example instead of login.yourcompany.com, the authenticator has no matching key and simply won't sign. There is no code to type into the wrong box. Cloudflare's own write up of the 2022 phishing campaign that hit Twilio and others is the best field evidence I know of: same lure, same attackers, and the hardware key users were not compromised because the origin check did its job.

So when someone asks me why we're doing this again after we "already did MFA," my answer is that we did MFA, we just did the version the attacker gets to participate in.

Preparing the plumbing

Before you touch users, inventory the relying parties. Every place a user types a password today either sits behind your IdP or it doesn't. The ones behind the IdP get passkeys the day you enable WebAuthn as an authentication method. The ones that don't are your real project. The good news is that this list is usually shorter and more embarrassing than you expect, which is motivating in its own way.

Then make three architecture decisions and write them down:

• Synced or device bound. Apple, Google and Microsoft all sync passkeys through their cloud accounts now. NIST's 2024 supplement to 800-63B accepts syncable authenticators at AAL2, so this is not heresy, but it does mean the passkey is only as strong as the user's iCloud or Google account recovery. For admins and privileged roles, require device bound credentials on hardware keys and enforce it with attestation where your IdP supports it.
• Recovery. This is where every passwordless program quietly reintroduces a password. Decide now what happens when the phone goes into the harbor. Ideally the answer is "a second registered passkey" and, failing that, a verified identity proofing flow, not a friendly chat with the service desk.
• Fallback and sunset. Keep push or TOTP as a fallback only for a fixed window, log every use of it, and review that log weekly. If a user has a passkey and still gets a push prompt, something is wrong and it is probably an attacker.

On the engineering side, turn on conditional UI (the browser autofill for passkeys) so the login form doesn't need a separate button nobody clicks, and test cross device login via the QR code flow, because a lot of your desktop users will authenticate with the phone in their pocket.

Winning over users

Here is the acid test: if your rollout needs a training video, you have already lost. Passkeys are the first security control in my career that is genuinely easier than the thing it replaces. Face ID, done. No code, no app to open, no "did you get the text yet." Lead with that, and register the passkey at a moment when the user is already authenticated and mildly bored, like right after a successful login. Don't force enrollment on a Monday morning before coffee; you're competing with their inbox, and the inbox will win.

Measure and publish two numbers: median login time and help desk tickets for lockouts. When both drop, and they will, tell people. Users tolerate security theater; they actively like things that give them back thirty seconds a day.

Winning over executives

Executives don't buy public key cryptography. They buy three things: reduced breach probability, reduced help desk cost, and not being the name in the headline. Verizon's DBIR has put stolen credentials at or near the top of initial access vectors year after year, so the risk story writes itself. Microsoft has argued for years that MFA blocks the overwhelming majority of account compromise attempts, and now the attackers have moved to the part MFA doesn't cover. Frame passkeys as closing that gap, not as another shiny thing from the security team.

Then pilot with the executives themselves. Give the CFO a passkey before you give one to engineering. It's the cheapest political capital you will ever earn, and if the CFO can log in with a thumb, nobody in the company gets to claim it's too hard.

Passkeys won't fix your joiner mover leaver process, your stale service accounts or your helpdesk reset policy. They fix one specific, well understood failure: the relayable secret. That is a rare thing in this industry, a control that is both stronger and more pleasant. Take the win.