A passkey migration starts with three questions: which applications support passkeys, what happens to legacy systems, and how will users recover access? For security leaders reviewing multi-factor authentication (MFA), those answers should shape the pilot, supplier shortlist and eventual retirement of passwords.
Where passkeys fit into multi-factor authentication
Passkeys replace passwords, not the need to verify users.
They can provide MFA when possession of a cryptographic key is combined with user verification, such as a PIN or biometric check. Two-factor authentication requires two distinct factor types, but they do not need to involve separate devices.
Passkeys use FIDO standards, including FIDO2 and WebAuthn, to bind authentication to the legitimate service and resist phishing. Biometric verification happens locally, so fingerprints or facial images are not sent to the service.
The deployment model also matters. Device-bound passkeys remain on one authenticator, while synced passkeys can move between devices through a credential manager.
Single sign-on (SSO) solves a different problem. Applications trust a central identity provider, where passkey authentication can support access to connected services without rebuilding every application login.
Passkeys still depend on secure devices, credential managers and identity controls. They strengthen authentication rather than replacing those surrounding controls.
Audit legacy compatibility before choosing a supplier
FIDO Alliance found that 82% of surveyed organisations aimed for fully passwordless workforce authentication, but only 28% reported achieving it.
The gap between ambition and deployment often sits in the existing estate.
A compatibility audit should map:
- applications and versions
- login methods
- identity providers
- user devices
- desktop clients
- remote access
- administrator accounts
- and service-account or script dependencies
Each application can then follow one of three routes.
1. Native or federated support
Applications that support passkeys directly, or trust an identity provider through federation, provide the cleanest migration route.
Testing should confirm that the required authentication policy applies consistently and that local accounts or direct login paths do not bypass it.
FIDO’s enterprise guidance recommends identifying supported applications before mapping users and devices.
2. A supported integration layer
Some applications can sit behind an access gateway or proxy, allowing stronger authentication to be introduced without changing the application itself.
That does not automatically remove passwords. A passwordless user experience may still depend on a stored credential behind the integration layer.
Testing should therefore cover direct-access restrictions, failure scenarios and recovery.
Directory architecture can also limit compatibility. Microsoft’s documented FIDO2 security-key route supports eligible hybrid environments but excludes devices joined only to on-premises Active Directory.
One successful integration does not prove compatibility across the wider estate.
3. No viable integration yet
Mainframe, industrial and point-of-sale systems may have no supported passkey route.
In those cases, the existing authentication method remains an exception rather than disappearing from the migration plan. Each exception needs:
- An owner: Responsibility for the remaining password dependency should be explicit.
- A review date: Exceptions should be reconsidered rather than allowed to remain indefinitely.
- An upgrade dependency: The technical change required to remove the exception should be documented.
Operational technology may also require brokered or restricted access rather than direct exposure.
Shared terminals introduce another constraint: individual accountability, permitted authenticators and loss-of-connectivity scenarios all need testing.
Where ageing infrastructure is the blocker, passkey migration may need to sit within a wider legacy modernisation strategy.
Plan the rollout around evidence
Once compatibility is understood, the rollout should test the full authentication lifecycle rather than successful sign-in alone.
That includes enrolment, everyday authentication, recovery, emergency access and offboarding. Each stage should be proven before deployment expands.
Weeks 1-4: discovery and design
Complete the application register and agree on permitted authenticators.
Decide where synced passkeys are acceptable and where device-bound keys are required. Define recovery, emergency access and pilot success criteria.
Weeks 5-8: representative pilot
Test supported applications with users across different devices, working patterns and accessibility needs.
Include the service desk. Test enrolment, lost-device recovery and rollback before enforcing the policy.
Weeks 9-12: controlled expansion
Add applications and user groups in waves.
Bring privileged accounts into scope once recovery and emergency-access procedures have been proven. Pause expansion if sign-in failures or support demand exceed agreed thresholds.
Thereafter: resolve exceptions and remove weaker routes
Retire password access only when dependencies are resolved, and recovery works.
Test leaver deprovisioning, credential revocation and session termination.
Measure actual passkey sign-ins, fallback use, failed logins, support contacts and recovery times. Agree acceptable thresholds before each rollout wave.
Design fallback and recovery before enforcement
Recovery is one of the easiest ways to undermine a stronger authentication model.
A spare authenticator solves a different problem from account recovery. A second pre-registered FIDO2 security key can maintain access when the primary device is unavailable, while loss of all authenticators requires a controlled recovery process.
NIST recommends maintaining separate authentication methods to reduce recovery dependence.
Where password-plus-MFA remains during transition, access should be restricted to defined users and systems with a clear retirement point. Leaving it available as an unrestricted fallback preserves the weaker route the migration is intended to remove.
A hardware token displaying one-time codes is also different from a FIDO2 key. Manually entered codes remain vulnerable to phishing.
Enrolment and re-enrolment therefore need controls comparable to sign-in itself:
- Requester verification: The recovery process must establish that the person requesting access is the legitimate account holder.
- Approval: Replacement credentials need a defined approval route.
- Temporary access: Any recovery access should expire rather than become a permanent bypass.
- Notification: Users should be informed when credentials are added or replaced.
- Revocation: Compromised or lost authenticators need to be removed promptly.
The service desk should test those procedures before enforcement.
Emergency administrative access needs a separate recovery path. Administrators should not depend on the same unavailable identity service they are trying to restore.
Compare vendors on rollout support
Supplier assessment should focus on difficult access scenarios rather than a successful login on a new device.
A simple scorecard can distinguish documentation from proven capability:
0 = unsupported; 1 = documented; 2 = demonstrated; 3 = proven in your pilot.
Roadmap features should remain outside the current score until they are available.
| Evaluation area | Evidence to request |
| Passkey availability | Generally available features, limitations and dated roadmap commitments. |
| Legacy compatibility | Your protocols and directory tested, including remaining password dependencies. |
| Device coverage | Supported browsers, operating systems, shared terminals and accessibility needs. |
| Migration tooling | Staged policies, enrolment support, test environments and rollback. |
| Administrative visibility | Actual usage, failures, fallback sign-ins and credential changes. |
| Recovery and offboarding | Lost-all-devices testing, controlled re-enrolment, revocation and session termination. |
| Delivery support | Named specialists, escalation routes, training, responsibilities and implementation costs. |
Mandatory requirements should be assessed before weighted totals.
An unsupported critical application or weak recovery process cannot be offset by stronger scores elsewhere.
Take defined passkey migration requirements into provider conversations
A passkey rollout should prove more than successful sign-in. It needs to show which applications are supported, how legacy exceptions will be handled and how users recover access without reopening weaker authentication routes.
A strong requirement therefore combines application compatibility, device coverage, recovery, fallback controls and evidence from the pilot. That gives authentication providers a clear basis for demonstrating whether their platform can support the migration.
The Cyber Secure Forum brings security decision-makers together with relevant identity and authentication providers through pre-arranged one-to-one meetings.
Organisations planning a passkey rollout or wider MFA modernisation can meet providers against their passkey migration requirements and use those requirements to guide supplier conversations.
Frequently asked questions
Are passkeys always MFA?
They provide MFA when the authentication requires possession of the key plus user verification through a PIN or biometric. Check the enforced policy rather than relying on a product’s “passwordless” label.
Can shared-device users adopt passkeys?
Potentially. Individual hardware security keys can suit shared workstations, but test connectivity, user switching and recovery. Do not assume staff can use personal phones or store personal passkeys on shared profiles.
How long should enterprise migration take?
Estimate discovery, pilot and expansion separately. Application dependencies, recovery readiness and change windows determine the schedule. The illustrative twelve-week sequence above is not a promise of full migration.
When can password fallback be removed?
When affected users have a supported alternative, recovery has been tested and application owners confirm that dependencies are resolved. Keep any remaining exceptions visible, with owners and review dates.
Image credit: https://unsplash.com/photos/google-sign-in-to-chrome-screen-PmVlOIClaVo
