Almost everyone is doing it, few are doing it well

The FIDO Alliance's State of Passkeys 2026 report, released in May, found that 68 percent of organizations have deployed passkeys for employee sign-in or are in the middle of doing so. Another 82 percent say fully passwordless authentication is the end goal, and 28 percent claim they have already arrived. Five billion passkeys are in use worldwide.

That is unusually fast adoption for an authentication change, and the reason is not enthusiasm. A passkey removes the one thing attackers have reliably exploited for thirty years: a secret that a user can be tricked into typing into the wrong page. The technical case closed years ago. What has not closed is the operational case, and that is where most enterprise rollouts lose momentum somewhere around month four.

The pattern is consistent. Enrollment goes well. The pilot group loves it. Then someone's laptop dies the week before a board meeting, their passkey lived in that device's secure enclave, and the recovery process turns out to be a help desk ticket, a video call and a 40 minute wait. Multiply that by a few hundred employees and the program quietly becomes optional.

What a passkey actually proves

A passkey is a FIDO2 credential built on WebAuthn. During registration, the authenticator generates a key pair and hands the public half to the server. The private half never leaves the device, or in the synced case, never leaves the provider's encrypted keychain. At login the server sends a challenge, the authenticator signs it, and the server verifies the signature against the stored public key.

The signature is bound to the origin. A passkey created for login.yourcompany.com produces a signature that is useless at login-yourcompany.com, which means a convincing clone of your login page collects nothing of value. There is no code to relay, no push notification to approve, no one-time password to read aloud to a caller claiming to be from IT. The attack classes that dominate credential theft, including adversary-in-the-middle proxies that defeat TOTP and push-based MFA, simply do not have a target.

This is why the regulatory language shifted from recommending strong MFA to specifying phishing resistance. NIST published Revision 4 of SP 800-63B on 31 July 2025. At AAL2, verifiers are now required to offer at least one phishing-resistant authentication option. At AAL3, a phishing-resistant authenticator with a non-exportable private key is mandatory, and syncable authenticators are explicitly excluded. CISA's guidance makes the same distinction, placing FIDO2 and WebAuthn above SMS and TOTP rather than alongside them.

The practical consequence for an enterprise is that "we have MFA" is no longer a complete answer in a security questionnaire. The follow-up question is which method, and whether it survives a real-time proxy.

Four places rollouts stall

None of these are protocol problems. They are process problems that surface once passkeys leave the pilot group.

Recovery is the authentication system nobody designed

Every passkey deployment needs a path for the user who has lost every device holding a credential. If that path is "call the help desk and answer three questions," you have built a phishing-resistant login and attached it to a phishable reset. Attackers know this. Help desk social engineering against recovery flows is cheaper than attacking the cryptography.

The recovery design should assume the worst case and make it auditable: identity proofing that does not rely on knowledge questions, a temporary credential with a short life and a single use, a notification to the user's manager or a second enrolled contact, and a log entry that names who approved the reset. Where the organization already issues hardware tokens, keeping one device-bound key in a safe for break-glass access is cheaper than a bespoke recovery process.

Synced versus device-bound is a policy decision

Synced passkeys (iCloud Keychain, Google Password Manager, and the equivalent in Windows) are convenient and survive device loss, which is exactly why they reduce support load. NIST permits them at AAL2 provided the sync fabric enforces encryption, MFA-protected access to the keys and local execution of the signing operation.

Device-bound credentials, meaning a hardware security key or a platform credential that cannot leave the machine, are what AAL3 requires. They are also the right choice for administrators, finance approvers and anyone whose account can move money or change access. Most mature programs end up hybrid: synced passkeys for the general workforce, device-bound keys for a defined privileged population. That split should be written down before procurement, not discovered during an audit.

Shared and non-standard devices

Passkeys assume a device that belongs to one person. Warehouse scanners, shop-floor terminals, kiosks, lab instruments running Windows 10 with a vendor-supplied login, and contractor laptops that change hands weekly do not fit that assumption. A rollout plan that ignores them will hit a wall in operations, and operations will win.

The workable answer is usually to scope passkeys to identity-bearing accounts and leave shared device logins on a separate, tightly restricted path with its own network controls. Trying to force a passkey onto a shared terminal produces workarounds, and workarounds are how a shared passkey ends up in a group chat.

Legacy applications that will never speak WebAuthn

Anything that authenticates with LDAP binds, an embedded form or a vendor appliance's local user table cannot accept a passkey directly. The bridge is federation: put an identity provider in front of the legacy app, enforce passkeys at the front door, and let the provider hold the legacy credential. Where federation is impossible, isolate the system and accept that it sits outside the phishing-resistant perimeter. Naming that gap is better than pretending it does not exist.

What passkeys do not fix

It is worth being precise about the boundary, because vendors are not. A passkey protects the moment of authentication. It does not protect the session that follows.

Session cookie theft still works. An infostealer running on an employee laptop can lift a valid session token after a successful passkey login and replay it from another machine, and the server has no way to tell the difference. That is why token binding, short session lifetimes, device compliance checks and anomaly detection on session reuse matter as much after a passkey rollout as before it. The same goes for OAuth consent phishing, where the attacker never asks for a password at all and simply gets a user to grant a malicious application access to their mailbox.

Passkeys also do not fix authorization. An account that can reach every record in the CRM will still reach every record in the CRM once it signs in with a passkey. Strong authentication raises the cost of impersonation. It does nothing about an over-permissioned role, and treating it as a substitute for least privilege is how organizations end up with excellent login security and a wide open data layer.

A rollout sequence that survives contact with finance

The ordering below is deliberately unglamorous. It front-loads the groups where risk reduction is largest and support impact is smallest.

• Start with privileged accounts. A few hundred administrators and finance approvers, all of whom can be issued hardware keys and all of whom have the highest blast radius. This produces visible risk reduction in the first quarter and gives the identity team real recovery experience before scale.
• Then new hires. Enroll passkeys at onboarding, before a password habit forms. This group is the cheapest to convert because there is no migration, only a default.
• Then the general workforce, opt-in first. Publish a self-service enrollment page, set a conditional access policy that prompts for passkey creation once per user, and let the early adopters generate the internal proof that it works.
• Then enforce, with a date. Pick a quarter, announce it twice, and retire password-only sign-in for the covered applications. Programs without an enforcement date tend to plateau at partial adoption and stay there.

One detail that saves months: implement conditional UI, the WebAuthn autofill flow, so the browser offers the passkey directly in the username field. Users who never see a separate "sign in with passkey" button adopt faster because there is nothing new to learn.

What to measure

Report four numbers, monthly, per application rather than organization-wide. The passkey share of successful authentications. The count of recovery and MFA reset tickets per thousand users. Median time from login page to authenticated session. And the click-through rate on phishing simulations, split between users who have enrolled a passkey and users who have not.

That last one is the number that persuades a board, because it is a direct comparison inside the same organization rather than a vendor benchmark. The FIDO Alliance's 2026 survey reports that organizations which deployed passkeys saw a 32 percent reduction in phishing-related incidents, 35 percent fewer password reset tickets and 45 percent faster employee logins. Your own figures will differ. Producing them is what turns a security project into a budget line that defends itself.

The honest costs

Passkeys are not free. Hardware keys for privileged staff cost money, and so do the spare keys you keep for the people who lose theirs. Identity provider licensing often steps up a tier. Help desk staff need a new script and a way to verify identity that does not involve asking for a birth date. Application owners need to test WebAuthn flows in browsers that your users actually have, including the browser embedded in the ERP client that has not been updated since 2021.

Against that, count the tickets that disappear. A password reset is a support cost with no security value, and it is the single most predictable line item in any help desk budget. The support savings usually cover the program cost before the phishing numbers arrive, provided passwords stop being an equal option at some point.

Where to start

Pick one application that every employee uses, put an identity provider with passkey support in front of it, and run the recovery process yourself as though you were a new hire whose phone died on a Sunday. What breaks in that exercise is the project plan.

Tech Hub Services designs and implements identity migrations, including passkey rollouts, conditional access policy and the recovery workflows that make them survivable. If your organization is partway through a rollout and stuck, the audit of what is actually enrolled is usually the fastest way to find out why.