Understand phishing resistance, synced versus device-bound credentials and a risk-based enterprise rollout.
- Passkeys use public-key cryptography; the service does not store a reusable secret like a password.
- FIDO/WebAuthn binds authentication to the correct domain, making fake login pages less effective than against passwords and OTPs.
- Plan enrolment, recovery, lost devices and emergency accounts before disabling older methods.
What is a passkey and how does it work?
A passkey is a FIDO credential commonly implemented through WebAuthn. During registration, the device creates a key pair: the public key goes to the service while the private key remains on a device or credential manager. During sign-in, the service issues a challenge and the device signs it after local confirmation by PIN, fingerprint or face.
The service never receives the private key and holds no reusable password secret. The credential is bound to the relying party, normally the legitimate domain, so a phishing page cannot ask the browser to sign for a different domain. This is why CISA recommends moving toward phishing-resistant FIDO/WebAuthn authentication.
- The service stores a public key.
- The device or provider protects the private key.
- Local PIN or biometrics confirm use; biometric data is not sent to the website.
Removing passwords is not merely changing the login screen. It means redesigning enrolment, recovery and identity lifecycle so strong authentication is not undone by a weak fallback.
How do passkeys differ from passwords, OTP and security keys?
A password is a shared secret that a user can type into almost any form, making phishing and reuse possible. OTP adds a factor but a code can still be entered into a fake page or intercepted in some scenarios. A passkey uses domain-bound challenge-response and does not transmit a reusable secret.
Passkeys may sync across devices through a credential provider or remain device-bound, including on a hardware security key. Synced passkeys improve convenience and resilience to device loss; device-bound credentials suit higher assurance and physical control. An organisation can use both for different user groups.
- Synced passkey: convenient across devices.
- Device-bound passkey: greater control and assurance.
- Security key: a physical FIDO device for administrators and privileged accounts.
Priority enterprise use cases
Begin with high-value accounts: email administration, domains, cloud, source control, finance and remote access. Compromise in one of these locations can open many other systems. Choose an application with mature passkey support and a pilot group small enough for careful IT support.
For customer applications, passkeys may reduce forgotten passwords and login friction, but account for shared devices, platform changes and support. Do not remove every old method on day one. Run in parallel and measure enrolment, login success, support time and recovery before expanding.
- Administrators and privileged users first.
- Applications with standards support and useful telemetry.
- A pilot group with clear devices, support and ownership.
Enrolment and recovery are the hard parts
Enrolment must strongly verify a user before adding a new passkey. An attacker with a stolen session or email account should not silently add a credential. Notify users about new passkeys, show registered devices, allow revocation and require step-up authentication for sensitive changes.
Weak recovery defeats strong authentication. Plan for lost devices, departed employees, lost provider access and failed hardware keys. Avoid reverting to security questions or email alone for privileged accounts. Maintain protected, monitored break-glass access used only for emergencies.
- Strong verification when adding or removing passkeys.
- Multiple credentials for higher-risk users.
- Tested recovery, offboarding and break-glass procedures.
A 90-day rollout
In month one, inventory applications, authentication methods, users and assurance needs. Select a pilot, define synced versus device-bound policy and prepare support. In month two, enrol users, rehearse device loss, monitor sign-in success and resolve failures. In month three, expand, disable weaker SMS or OTP where safe and reassess remaining legacy methods.
Measure enrolment, successful sign-in, login time, support tickets, recovery and fallback. The goal is not adoption alone but a real reduction in phishing exposure. If passwords remain the default fallback for everyone, passkeys are only a convenient button rather than a stronger security posture.
- Days 0–30: inventory, policy, pilot and support plan.
- Days 31–60: enrolment, recovery drills and telemetry.
- Days 61–90: expansion, weaker fallback reduction and risk review.
FAQ
Frequently asked questions
Is a passkey a password stored on a phone?
No. It is a public-key credential: the device protects a private key while the service stores only the public key, not a shared password string.
Does losing a phone mean losing the account?
Not necessarily. Synced passkeys can be restored through a credential provider; organisations should also support multiple credentials and a verified recovery process.
Do passkeys replace MFA?
They can provide strong phishing-resistant authentication, but assurance depends on credential type, device, enrolment and recovery. Evaluate each use case.
References
Sources used in this guide
We prioritise official guidance and primary technical sources. Visit each source for full context and the latest updates.