Almost every enterprise passkey pilot works. The pilot group is IT staff and security-minded volunteers on managed laptops with recent phones, and they enroll, sign in, and report that it is faster than the password they replaced. The trouble starts at the boundary of that group: the warehouse supervisor on a shared terminal, the contractor on an unmanaged device, the finance application that predates WebAuthn, and the executive who dropped her phone in a lake on Friday.
A broad rollout is not a larger pilot. It is a different project, and the three problems that decide whether it works are account recovery, shared and deviceless users, and legacy applications.
Decide what a passkey means in your environment
Two kinds of passkey exist, and the choice shapes everything downstream. A synced passkey is stored in a platform credential manager and replicated across a user’s devices through the vendor’s cloud. A device-bound credential, such as a hardware security key or a platform key that cannot be exported, stays on one authenticator.
NIST SP 800-63B-4 draws the line plainly. It defines syncable authenticators as those that manage keys through a sync fabric, permits exportable keys at assurance levels AAL1 and AAL2, and states that syncable authenticators must not be used at AAL3, which requires a non-exportable private key in hardware-protected storage. The same document requires verifiers to offer a phishing-resistant option at AAL2 and requires federal agencies to mandate phishing-resistant authentication for their staff, contractors, and partners. You do not have to be a federal agency to borrow the structure.
A workable policy for most enterprises is two tiers: synced passkeys for the general workforce, where phishing resistance and ease of use matter most, and device-bound hardware keys for privileged administrators, sensitive systems, and any regulated workload that demands AAL3-style assurance. Write the policy before enrolling anyone, because migrating users from one class to the other later is expensive.
Recovery is the real security ceiling
A passkey rollout lives or dies on what happens when someone loses the device. If recovery falls back to an SMS code or an emailed link to a mailbox protected by a password, the attacker simply goes around the passkey, and the account is only as strong as that fallback. Phishing-resistant sign-in with a weak recovery path buys less than it appears to.
Design recovery before the first wave:
- Register at least two authenticators per user. A second passkey on another device, or a spare hardware key held securely, removes most recovery events at the source. This is the common recommendation in practitioner and vendor guidance, and it is cheap.
- Make recovery at least as strong as sign-in. NIST SP 800-63B-4 routes recovery through its own section 4.2, with saved and issued recovery codes defined as recovery mechanisms. Read that section against your helpdesk process.
- Treat the helpdesk as an authentication system. Require identity proofing that does not depend on facts an attacker can look up: a manager approval through a separate channel, an in-person or video check with a badge, or a time-delayed reset with notification to every registered method. Script it, log it, and alert on volume.
- Add a cooling-off period for new credentials. After a recovery, restrict high-risk actions such as payment changes or new admin grants for a defined window, and notify the user’s other devices.
The 2025 Unit 42 research on gift-card fraud shows why this matters: the attackers it described reset passwords through self-service flows and registered their own authenticators to persist. Whatever you let users do when they cannot authenticate, an attacker will try to do too.
Shared devices, kiosks, and users without phones
Passkeys assume an authenticator tied to a person. Retail floors, clinical workstations, call centers, and plants often have the opposite: a shared machine, no personal phone allowed, and many people per terminal. Practitioner playbooks consistently flag frontline and shared-workstation staff as the most common place a rollout stalls.
Options differ by environment:
- Hardware keys or badge-based FIDO2 tokens carried by each worker and presented at the shared terminal work where users keep a physical item. Budget for lost-key replacement.
- Cross-device authentication, where the user approves sign-in from their own phone via a QR code and Bluetooth proximity, suits shared terminals when personal phones are permitted.
- A defined exception tier for sites where neither fits, with compensating controls such as network restriction, short sessions, and monitoring, and an owner and an end date. Exceptions without an expiry become permanent.
Do not count shared-device users as “done” because the dashboard shows enrollment. Count sign-ins that actually use the passkey.
Legacy applications
The honest inventory step is to classify every application by how it authenticates: federated through your identity provider (and so inherits passkey support for free), natively WebAuthn-capable, or neither. The first group is usually the majority and should go first.
For the rest, the usual patterns are putting the application behind an identity-aware proxy or SSO gateway that performs the passkey sign-in on its behalf, using an identity provider’s integration for protocols like SAML or OIDC where the application can accept them, and reserving a small, documented group of systems (mainframe terminals, thick clients, service accounts) for compensating controls. Service accounts and non-human identities are outside the scope of passkeys altogether and need their own credential hygiene.
The goal of the migration is to remove passwords where possible, not merely to add passkeys beside them. If the password remains a valid sign-in path, the attacker’s downgrade to it will be the first thing they try. Track the number of accounts that still have a usable password and set a date to disable it for each population as it is converted.
A staged plan
- Policy and recovery first. Settle the passkey classes, the recovery process, and the helpdesk script before enrolling at scale.
- Wave one: federated apps, managed devices. Enroll employees on managed laptops and phones, requiring two authenticators each.
- Wave two: privileged users. Move administrators to device-bound hardware keys and remove password and SMS fallbacks for them.
- Wave three: shared and frontline environments. Pilot the chosen pattern in one site, measure support calls and failed sign-ins, then expand.
- Wave four: legacy and exceptions. Front what can be fronted, document the rest, and review exceptions quarterly.
- Retire the password. Disable password sign-in for each converted population.
On adoption numbers, be careful which ones you quote. The FIDO Alliance’s October 2025 Passkey Index, drawn from large consumer-facing services, reported that passkey sign-ins averaged 8.5 seconds against 31.2 for other methods and succeeded 93 percent of the time against 63 percent. Those figures describe consumer deployments and say little about your frontline terminal fleet. Measure your own.
The pilot proved that passkeys work. The rollout has to prove that your recovery desk, your shared workstations, and your oldest application can live with them.
Standards references: NIST SP 800-63B-4 and the FIDO Alliance Passkey Index announcement. Several operational recommendations above reflect vendor and practitioner guidance, not normative standards text.