Passkeys: why passwords are on the way out
Passkeys remove passwords and are phishing-resistant. We explain how they work, how they differ from MFA and how to start rolling them out.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 25 June 2026
- READING TIME
- 6 min read
- TOPIC
- Identity and Access
As an authentication method, the password has a flaw built into its very design: it’s a secret you have to hand over to log in — and what you hand over can be stolen, observed or phished. Passkeys fix this at the source, and they’re becoming the standard faster and faster. It’s worth understanding why they matter.
What a passkey is
A passkey is a credential based on public-key cryptography (the FIDO2/WebAuthn standards). At registration your device generates a key pair: the private key never leaves your phone, computer or hardware key, and the service stores only the public key. Logging in means signing a challenge with the private key, unlocked by your device’s biometrics or PIN.
The crucial difference: there is no secret to steal on the server side. A breach of the service’s database reveals nothing you can log in with.
Why they’re phishing-resistant
This is the most important property. A passkey is bound to a specific domain. Even if you click a link to a perfectly cloned page, the browser won’t use the passkey because the domain doesn’t match. An entire class of attacks — the one we describe in our piece on phishing — simply disappears. You can’t “enter your passkey” on a fake page the way you enter a password or an SMS code.
Passkey vs password and MFA
A passkey combines two factors: possession (the device holding the private key) and inherence/knowledge (the biometric or PIN that unlocks it). It’s full strong multi-factor authentication in a single gesture — no password, no retyping codes. Unlike SMS codes (interceptable) or push notifications (vulnerable to MFA fatigue), a passkey is phishing-resistant by design.
How to start rolling it out
- Turn on passkeys where they already exist — Google, Microsoft and Apple accounts, and a growing number of SaaS apps, support them natively.
- For critical accounts (admins, cloud access, email) consider FIDO2 hardware keys as the strongest variant.
- Synced passkeys (in the Apple/Google/Microsoft ecosystems) lower the barrier for ordinary users — convenience drives adoption.
- Plan the account-recovery path for a lost device — that’s the point where rollouts most often stumble.
What to expect
Passkeys will not replace passwords overnight; both will coexist for a while. The direction is clear, however: authentication resistant to conventional phishing is one of the most important login-security improvements. If you’d like to assess where passwords are your weakest link, get in touch.
What a passkey provides
A passkey is a WebAuthn credential using public-key cryptography. The private key remains under the device or synchronisation provider’s control, while the server stores a public key. The credential is bound to the service’s relying party—the correct domain—so a look-alike domain cannot request a signature for the real service.
Biometrics or a PIN unlock the key locally; they are not sent to the server as a secret. A passkey may sync across devices or remain device-bound, including on a hardware security key.
Remaining risks
Passkey resistance does not secure the whole account automatically. Weak recovery, a remaining password fallback, session theft, malicious applications or broken post-login authorisation can still lead to compromise. Users may approve a harmful action after legitimate authentication.
If an administrator uses a passkey but recovery relies on weak email without MFA, the weaker path defines security.
Organisational rollout plan
Begin with administrators and high-impact applications, while providing two controlled access methods. Define new-device enrolment, loss, employee departure and recovery. Keep a spare hardware key under a documented procedure where hardware credentials are used.
Measure passkey adoption, password fallback, recovery events and device-revocation time. Avoid forcing users back to passwords through one incompatible application flow.
Acceptance tests
Test the correct and a look-alike domain, extra-authenticator registration, device removal, synchronisation, recovery and audit. Confirm that helpdesk cannot bypass controls on a phone call alone. Use a well-designed MFA rollout for systems that do not yet support passkeys.
Sources: FIDO Alliance — Passkeys resources, W3C Web Authentication Level 2, FIDO Alliance — passkeys and phishing resistance.
