Passkeys in the Real World: Rolling Out Phishing-Resistant Logins

Turn passkeys on for your email and identity platform first, leave passwords in place as a fallback for a quarter, then remove the password only once everybody has two passkeys registered. That order is the whole project. The technology is ready and free in most business plans you already pay for; what goes wrong is sequencing, and specifically removing the old login before people have a second way in.

What a passkey actually is

A passkey is a pair of cryptographic keys created on your device for one specific website. The private half stays on the device, protected by your fingerprint, face or device PIN. The public half goes to the website. When you sign in, the site sends a challenge, your device signs it with the private key, and the site verifies the signature against the public key it already holds. Nothing reusable crosses the network.

Two consequences follow, and they are the entire reason to care. First, there is no shared secret to steal: a breach of the website’s database yields public keys, which are useless to an attacker. Second, the browser or operating system will only use a passkey on the exact origin it was created for. A convincing replica of your login page at a lookalike domain cannot trigger the passkey at all, so the user does not get the chance to make a mistake.

Most passkeys are built on the W3C WebAuthn specification, which NIST describes as flexible enough that not every deployment meets every requirement. For a business the practical version is simpler: if your identity platform offers passkeys, it is almost certainly doing this correctly, and your job is the rollout rather than the cryptography.

Why phishing resistance is the whole point

The case for passkeys is not that passwords are weak. It is that every intermediate step between passwords and passkeys can still be relayed by an attacker sitting in the middle. A one-time code from an app, a code by text message, or a push notification you approve can all be captured or triggered by a convincing proxy page. The user does everything right and the attacker still ends up with a session.

That is why the language in standards has shifted from multi-factor to phishing-resistant. NIST’s SP 800-63B-4 requires phishing resistance at its highest authentication assurance level, AAL3, and defines that level as proof of possession of a key held in a cryptographic authenticator with a non-exportable private key. CISA makes the operational version of the same argument: in its June 2026 guidance it notes that attackers compromising core networks mostly use valid credentials and exploitable configurations rather than product flaws, and points at phishing-resistant multi-factor authentication as one of the structural answers.

The scale of the credential problem is well measured. Verizon’s 2026 Data Breach Investigations Report, covering more than 22,000 confirmed breaches, attributed 13% of breaches to credential abuse as the initial access route. Phishing remains the most common attack UK businesses report, affecting 38% of them in the year to early 2026. Our guide to stopping phishing attacks covers the filtering side; passkeys are the part that makes a successful phish worth much less.

Synced or device-bound: the choice that matters

This is the one genuine decision in a passkey rollout, and it is worth ten minutes of thought rather than a default.

A synced passkey lives in a platform keychain, typically from Apple, Google, Microsoft or a password manager, and follows the user to their other devices. Convenience is the whole point: lose a phone, buy a new one, sign in to the platform account and the passkeys are there. NIST’s SP 800-63B-4 treats syncable authenticators in a normative appendix and permits them at AAL2, subject to conditions. Keys copied to a sync fabric must be stored encrypted with at least 112 bits of security strength, access to the sync fabric must itself be protected by AAL2-equivalent multi-factor authentication, and only the authenticated user may reach their keys.

A device-bound passkey, which in practice means a hardware security key or a platform credential explicitly marked as non-exportable, never leaves the device it was created on. NIST is explicit that syncing violates the non-exportability requirement of AAL3, so if you need that level, hardware is the route. For federal use the same appendix adds requirements most businesses will not face but can learn from: sync fabrics with FISMA moderate protections, device management that prevents keys syncing to unauthorised devices, and enterprise attestation so the relying party can tell what kind of authenticator it is talking to.

What the adoption numbers say about readiness

The awkwardness argument against passkeys has mostly expired. The FIDO Alliance’s State of Passkeys 2026 report, published for World Passkey Day in May 2026, found awareness at 90% and 75% of people having enabled a passkey on at least one account. Just under half, 49%, say they use passkeys regularly when the option is offered. On the workforce side, 68% of organisations have deployed or are actively deploying passkeys for employee sign-ins, 82% describe fully passwordless authentication as their eventual goal, and 28% say they have already got there.

Read the gap between 75% and 49% as the honest state of play. Most people have tried a passkey; fewer have made it their habit. In a workplace you can close that gap by making the passkey the only convenient route, which is why the rollout order below puts enrolment before enforcement.

A rollout order that does not strand anyone

Six steps over about a quarter. The timings assume a business of twenty to eighty people with one person coordinating.

1. Week one: pick the system that matters. Your identity provider, which for most businesses means Microsoft Entra ID or Google Workspace. Everything else can follow through single sign-on later.
2. Week one: enrol yourself and two volunteers. Do it on your own accounts first and write down every prompt you see. You will discover one device in your fleet that behaves differently, and better now than during a company-wide rollout.
3. Week two: order hardware keys for administrators. Two each. Register both before you change any policy.
4. Weeks three to six: open enrolment, no enforcement. Send one short set of instructions with screenshots from your actual platform, not a vendor’s. Ask everyone to register two passkeys: usually the laptop and the phone.
5. Week seven: chase the stragglers individually. Not by broadcast email. Ten minutes each on a call gets you to full coverage; a reminder email gets you to 60%.
6. Week eight onwards: enforce. Require phishing-resistant authentication for administrators first, then for everyone. Keep one documented emergency account with a long random password in a safe, excluded from the policy and monitored for use.

That emergency account is not a shortcut, it is the standard practice for avoiding a lockout of your own tenant. Write down who can open the safe, log every use, and review the log monthly. If you have already done an MFA rollout, this will feel familiar: our multi-factor authentication guide covers the same break-glass pattern.

Recovery is the hard part

Enrolment is easy. Recovery is where passkey projects go wrong, because the question ‘what happens when someone drops their only phone in a canal’ has to be answered before it happens rather than during.

• Two passkeys per person, always. This solves 90% of recovery on its own. A laptop passkey and a phone passkey mean a lost device is an inconvenience.
• Know your platform’s recovery path. For synced passkeys the real recovery mechanism is the platform account. That account therefore needs its own strong protection, which is exactly what NIST’s AAL2-equivalent requirement on sync fabric access is getting at.
• Decide who can re-enrol a user, and how they verify identity. A phone call from somebody claiming to be a locked-out colleague is the oldest attack in the book. Use a video call and a known-good channel, not the number in the request.
• Keep a temporary access pass process. Most identity platforms can issue a short-lived code that lets a user register a new passkey. Time-box it to an hour and log it.
• Write it on one page. Recovery procedures that exist only in somebody’s head stop working the week that person is on holiday.

The awkward edges: shared logins, kiosks and old software

Three situations come up in every rollout, and none of them are reasons to abandon the project.

Shared logins. A passkey is bound to a person’s device, which makes the shared social media login or the shared accounts mailbox awkward. The right fix is to stop sharing the account: use delegated access or a shared mailbox with individual sign-in. Where the platform genuinely does not support that, keep a password in a team password manager with its own MFA, and write down that this account is the exception.

Shared and kiosk machines. Warehouse terminals and front-desk machines do not have a per-user keychain. Hardware security keys work well here because the credential travels with the person rather than the machine. A key on a lanyard is a better answer than a password on a sticky note.

Old software that only speaks passwords. Line-of-business applications with no modern authentication support are common and will outlive the rollout. Put them behind single sign-on if the vendor supports it, restrict them to the office network or a VPN if not, and treat them as an exception with a review date. The same discipline as unpatchable systems: our ransomware guide covers why those exceptions deserve extra backup attention.

What to tell your team, in four sentences

Everything above is for you. This is the version for the team, and brevity is the point. Long explanations of public-key cryptography reduce enrolment rates.

Add one sentence about what happens if they lose a device, and the name of the person to contact. That is the entire communication plan. People adopt passkeys readily when the instruction is short and the fallback is obvious, which is roughly what the FIDO Alliance’s 75% enablement figure reflects: when a platform offers it clearly, most people turn it on.

If you would rather not work out the policy templates, the conditional access rules and the recovery process from scratch, our cybersecurity services include running this rollout remotely, administrators first, with the break-glass account and the one-page recovery procedure documented at the end of it.

If you want phishing-resistant logins across your email and identity platform without a week of lockouts, we can plan the enrolment, the enforcement and the recovery process with you. Get in touch with Eudora Technology to talk about your project.