The password was never the point
A password is a shared secret: something both you and the server know, which means it's something both you and the server can lose. It can be phished, reused across a dozen accounts, guessed, or pulled straight out of somebody else's breach dump and stuffed into your login form. None of that requires a sophisticated attacker. It requires a login page that still asks for a password.
Passkeys, built on the FIDO2 and WebAuthn standards, remove the shared secret entirely. Your device holds a private key that never leaves it; the server holds a public key that's useless to anyone who steals it. There's no secret in transit to phish, because authentication is a cryptographic proof, not a string of characters typed into a form.
What to roll out first
Not every account needs the same treatment on day one. A staged rollout beats a mandate that stalls in the first month:
- Start with your highest-risk accounts. Admins, finance, anyone with standing access to sensitive systems. That's where a phished password does the most damage, and where the users are usually motivated enough to adopt something new without much friction.
- Make it the default, not an opt-in. Passkey enrollment offered as an option next to a password field gets ignored. Passkey enrollment as the default path during onboarding gets used.
- Keep a fallback, but make it worse on purpose. Legacy password-plus-MFA should still exist for the transition period, and it should be visibly more friction than the passkey path, not equally convenient. People follow the path of least resistance; make sure that path is the secure one.
What to retire, and when
SMS-based one-time codes are the biggest thing worth actively phasing out, not just deprioritizing. SIM-swapping and interception attacks against SMS codes are well understood and increasingly common, and the code itself is still a shared secret that can be phished in real time by a fake login page. If your MFA program leans on SMS as a primary factor, that's the first gap to close, ahead of any broader passkey rollout.
The most common reason a passwordless rollout stalls isn't user resistance, it's an incomplete account recovery flow. If someone loses their device, there needs to be a process that's secure without silently reintroducing a password-shaped hole. Plan recovery before you plan enrollment, not after.
This applies to agent credentials too
The same shared-secret problem shows up in service accounts and AI agent credentials, usually as an API key sitting in a config file or environment variable indefinitely. The passwordless principle, no long-lived shared secret sitting around waiting to be stolen, applies just as directly to a non-human identity as it does to a person logging into email. Scoped, short-lived, cryptographically-verified credentials belong on both sides of that line.
We help organizations design and roll out passwordless authentication programs that actually get adopted, sequenced by risk, with recovery handled up front instead of as an afterthought.
Curious where a passwordless rollout would hit friction in your environment?
Start an assessment today