A passkey is a sign-in credential built on public-key cryptography, defined by the WebAuthn (W3C) and FIDO2 standards. It replaces a password with a key pair: the private key stays on the device, the public key is registered with the service. Sign-in is confirmed by device biometrics or a PIN — no secret a breach could steal.
Quick Overview
What you’ll learn:
- What passkeys are and how public-key-based passwordless authentication actually works
- How passkeys compare to passwords, SMS one-time codes, and TOTP authenticator apps
- A 6-step rollout plan for passkeys inside an organization — from pilot to retiring the password fallback
- The real limitations and pitfalls of a passkey rollout (lost devices, legacy systems)
- Which major services already support passkeys, and since when
Who this article is for:
- IT administrators and security teams planning strong-authentication rollouts
- Leadership evaluating a passwordless investment in the context of NIS2
- People who own onboarding and password policy inside an organization
Reading time: 5 minutes
What Passkeys Are and How Passwordless Authentication Works
A passkey is what the WebAuthn spec calls a discoverable credential — one the operating system can surface and offer without the user typing a username first. The mechanism relies on asymmetric cryptography: during registration, the device generates a key pair. The private key is stored locally, either inside a hardware-backed secure enclave or inside an encrypted keychain synced across one ecosystem; the public key is sent to and stored by the service. At sign-in, the server issues a random challenge, and the device signs it with the private key once the user confirms their identity with biometrics (fingerprint, Face ID) or a device PIN. This is what WebAuthn — a W3C specification that reached Recommendation status in 2019 (Level 1) and was extended in 2021 (Level 2) — describes, paired with the CTAP2 protocol that the FIDO Alliance defines as FIDO2.
The key difference from a password: the server never learns or stores any shared secret. A breached passkey database contains only public keys — useless without the matching private key, which never physically leaves the user’s device, or the encrypted sync within a single ecosystem. Apple added passkey support in iOS 16 and macOS Ventura (2022), Google made passkeys the default sign-in option for Google Accounts in May 2023, and Microsoft added passkey support to Windows Hello and Microsoft Entra ID.
Passkeys vs Passwords, SMS Codes, and Authenticator Apps — Compared
The table below compares four common sign-in methods on phishing resistance and typical adoption barrier.
| Method | Phishing resistance | Requires memorizing a secret | Typical adoption barrier |
|---|---|---|---|
| Password | Low — the secret can be harvested by a cloned login page | Yes | None (supported everywhere natively) |
| SMS one-time code | Low–medium — vulnerable to SIM swapping and code relay to a fake page | No, but needs phone signal | Low |
| Authenticator app (TOTP) | Medium — a time-based code can still be typed into a fake page | No | Medium (install and pairing) |
| Passkey (WebAuthn/FIDO2) | High by design — the private key signs a challenge bound to the real domain, so a signature produced for a spoofed domain is useless | No | Medium (needs a device with biometrics/PIN support) |
Regulators share that assessment: NIST’s SP 800-63B guidelines classify FIDO2/WebAuthn-based authentication as phishing-resistant by architecture, not just in practice. That translates directly into fewer compromised accounts — Microsoft, drawing on its own service telemetry, has repeatedly stated that turning on any form of multi-factor authentication blocks over 99.9% of account-compromise attempts. Passkeys, phishing-resistant by architecture rather than by an extra step bolted on, close the gap that SMS codes and TOTP apps still leave open: the possibility of a one-time code being typed into a fake login page.
Rolling Out Passkeys in an Organization — 6 Steps
- Inventory which systems already support WebAuthn/FIDO2 — check which internal apps and SaaS tools (identity provider, email, VPN) already accept passkeys as a sign-in method, rather than assuming support upfront.
- Centralize the rollout at the identity provider — enabling passkeys at the level of Microsoft Entra ID or another central IdP covers every connected application in one move.
- Pilot with a volunteer group inside IT — before passkeys reach the whole organization, test device-loss and account-recovery scenarios end to end.
- Write a recovery procedure before go-live — a cloud-synced passkey (iCloud Keychain, Google Password Manager) survives a phone upgrade; a passkey tied only to a hardware security key needs a backup key or another recovery path.
- Keep the password as a fallback during the transition — fully retiring the password only makes sense once most users have actually registered a passkey, not on day one of the rollout.
- Measure adoption before switching off older methods — keep SMS codes and TOTP apps as a fallback until telemetry shows the large majority of sign-ins already go through a passkey.
Limitations and Pitfalls Worth Knowing About
Passkeys aren’t a zero-maintenance fix. Three practical limits show up in every rollout. First, older on-premise systems without WebAuthn support (some legacy ERP platforms, some public-sector systems) won’t accept passkeys without an additional authentication gateway. Second, syncing passkeys across ecosystems (say, from iCloud Keychain to Google Password Manager) doesn’t always happen automatically — someone switching from an iPhone to an Android device can lose access to registered keys unless a hardware security key is used as the common denominator. Third, a passkey tied to a single device with no cloud sync is a real account-lockout risk if that device is lost — which is exactly why step 4 above isn’t optional.
Read Also
- Human Risk Management in Cybersecurity: Building Awareness and Resilience — how to teach a team to spot phishing before technology fully eliminates it
- Zero Trust Architecture: Implementation and Security — how strong authentication fits into a broader Zero Trust architecture
Build Your Skills
This topic connects to the Cyber Security for Users course. Check the program and sign up to build your skills with EITT’s experts.
Frequently Asked Questions (FAQ)
What’s the difference between a passkey and a password?
A password is a secret the user memorizes and types, and the server stores it (usually hashed) — something a phishing page or a database breach can capture. A passkey is a cryptographic key pair: the private key never leaves the device, and the public key stored on the server is useless without it. Sign-in is confirmed with biometrics or a device PIN, not by typing text.
Can passkeys be phished?
Not the way a password or an SMS code can be. The cryptographic signature a passkey produces is bound to the real service’s domain — if a user lands on a spoofed page impersonating that service, the device simply won’t find a matching passkey to use, so there’s nothing to type or hand over.
What happens if I lose the phone my passkeys are stored on?
It depends on the passkey type. If it was synced to the cloud (iCloud Keychain, Google Password Manager), you regain access by signing into the same ecosystem on a new device. If the passkey was tied only to the lost hardware — for example, a hardware security key with no backup — you need a recovery method set up in advance, which is exactly why a written recovery procedure is part of any correct rollout.
Do passkeys fully replace multi-factor authentication (MFA)?
Largely yes — a passkey combines something you have (the device holding the private key) with something you are or know (biometrics or a PIN) in a single sign-in gesture, meeting the definition of multi-factor authentication. Organizations with higher security requirements can still layer passkeys with additional session- or device-level controls.