Every password-security recommendation in this Knowledge Center — length, uniqueness, breach screening, a password manager — exists to compensate for the fact that a password is, fundamentally, a shared secret that can be phished, guessed, leaked, or reused. Passwordless authentication removes that category of risk by removing the shared secret entirely. This article explains how passkeys and the underlying FIDO2/WebAuthn standard work, and what realistic adoption looks like for a business.
What "passwordless" actually means
Passwordless authentication replaces the password with public-key cryptography. Instead of a secret the user types (and a server stores, however well-hashed), the user's device holds a private key that never leaves it, while the service holds only the corresponding public key. Authenticating means proving possession of the private key — typically unlocked locally via a PIN, fingerprint, or face scan — without ever transmitting a secret the service (or an attacker intercepting the connection) could reuse or leak.
The biometric never leaves your device
A common misconception is that passkeys send your fingerprint or face scan to the website. They don't — biometrics only unlock the private key locally on your device. The website never receives, stores, or has access to any biometric data at all.
FIDO2 and WebAuthn: the standards underneath passkeys
FIDO2 is the umbrella standard from the FIDO Alliance covering passwordless authentication; WebAuthn is the specific web API (a W3C standard) that lets browsers and websites use FIDO2 authentication. Together they define how a device generates and stores a key pair, how a website requests authentication, and how the cryptographic challenge-response actually works. A "passkey" is the user-facing term for a FIDO2/WebAuthn credential — the underlying mechanism is identical to what a hardware security key uses; a passkey is simply that same credential stored on and synced across a user's own devices (via Apple, Google, or Microsoft's platform ecosystem) rather than on a separate physical key.
This cryptographic binding to the actual requesting domain is exactly what makes passkeys phishing-resistant by design, not by user vigilance — a fake login page simply cannot complete the WebAuthn challenge for the real domain, no matter how convincing it looks. See Multi-Factor Authentication: Methods and Best Practices for how this compares to code-based MFA methods, and Authentication Attacks for why that distinction matters against real adversary-in-the-middle phishing.
Passkeys vs. traditional passwords
| Property | Passkey | Password + code-based MFA |
|---|---|---|
| Phishing resistance | High — cryptographically bound to the real domain | Medium — codes can be relayed by phishing kits |
| Credential reuse risk | None — a passkey is unique per service by design | Password reuse remains a real risk even with MFA layered on |
| Breach exposure | Nothing useful to steal server-side — only a public key is stored | A breached password hash is still an offline cracking target |
| User experience | Often faster — biometric unlock, no typing | Password entry plus a second-factor step |
| Platform/browser support | Strong and growing across major platforms and browsers | Universal |
| Recovery if device is lost | Requires platform account recovery or a backup passkey/device | Password reset flow, typically well-established |
A realistic adoption path
Very few organizations can eliminate passwords across every system overnight — most business applications still require password fallback support for the foreseeable future. A practical adoption sequence:
- Enable passkey support for the identity platform itself first (e.g., Microsoft Entra ID, Google Workspace) — this is usually the fastest win and covers the login surface staff use most.
- Prioritize high-value and high-risk accounts — administrators and staff frequently targeted by phishing (finance, executives) benefit most from eliminating the phishable password/code combination first.
- Keep MFA (not passkeys specifically) mandatory everywhere passkeys aren't yet supported, rather than treating passwordless as a reason to relax requirements on systems that still require a password.
- Plan for cross-device and recovery scenarios explicitly — a lost or replaced device without a backup passkey or documented recovery path becomes a real support incident, not just a theoretical edge case.
- Expect a mixed environment for years, not months. Legacy line-of-business applications without WebAuthn support are common; a passwordless strategy needs a defined password-and-MFA fallback for exactly those systems, not an assumption they'll be replaced soon.
Passkeys and password managers are complementary, not competing
Modern password managers increasingly store and sync passkeys alongside traditional passwords. Adopting passkeys doesn't make the Password Manager Guide irrelevant — for the systems that still require a password, all the same guidance (uniqueness, generation, manager-based storage) still applies.
Common mistakes
- Assuming passwordless means MFA is no longer needed. A passkey login is itself inherently multi-factor (something you have — the device — plus something you are or know to unlock it), but systems that still use passwords need their own separate MFA requirement until they're migrated.
- Rolling out passkeys without a device-loss recovery plan, which turns a lost phone into a lockout incident rather than a routine device replacement.
- Treating passwordless as all-or-nothing. A phased rollout prioritizing the highest-risk accounts and systems delivers most of the risk reduction well before full elimination of passwords is realistic.
- Ignoring line-of-business applications that will never get WebAuthn support — these need an explicit, intentional fallback plan, not a hope that they'll eventually be replaced.
FAQ
Are passkeys the same thing as a hardware security key? They use the same underlying FIDO2/WebAuthn standard, but a hardware key is a dedicated physical device, while a passkey is typically stored on and synced across a user's existing devices (phone, laptop) through their platform account. Both are phishing-resistant for the same cryptographic reason.
Can passkeys be phished the way a password or SMS code can? No — because the cryptographic exchange is bound to the actual requesting domain, a fake login page cannot successfully complete authentication even if the user is fully fooled by the page's appearance. This is a structural property of the protocol, not a matter of user awareness.
What happens if someone loses the device their passkeys are stored on? Recovery depends on the platform ecosystem (Apple, Google, Microsoft) — passkeys are typically recoverable through the platform account's own recovery process, or via a backup passkey registered on a second device. Organizations should document and test this process before broad rollout, not discover it during an actual incident.
Do passkeys work with Microsoft 365 and Entra ID today? Yes — Microsoft Entra ID supports FIDO2 security keys and platform-based passkeys as an authentication method. See Microsoft Entra Conditional Access: A Practical Guide for how to require or prioritize phishing-resistant methods through policy.