How should organisations phase phishing-resistant authentication when passkeys are not yet ready for every user and system?

A practical rollout is to use a hybrid model. Start with certificate-based authentication to reduce phishing exposure now, then add FIDO passkeys as the longer-term target as support matures. That sequencing gives security teams immediate resistance to credential theft while avoiding a forced big-bang migration across legacy IAM systems, user populations, and recovery workflows.

Why a phased rollout works better than waiting for universal passkey readiness

The main decision is not whether phishing-resistant authentication is worth doing, it is how to get meaningful coverage before every application, endpoint, browser, help desk flow, and legacy directory dependency can support passkeys cleanly. A phased model reduces exposure early, preserves adoption momentum, and avoids forcing the riskiest users into exceptions that often become permanent.

Certificate-based authentication is useful as the first step because it can deliver phishing resistance without depending on every user journey being redesigned at once. In practice, that means you can harden high-value access paths while the passkey programme catches up on device support, platform compatibility, and recovery design.

For organisations with identity-heavy risk, the transition should be treated as a control-maturity sequence, not a product swap. Current guidance from NIST SP 800-63 Digital Identity Guidelines supports phishing-resistant authenticators as the direction of travel, but the rollout path still has to match your operating reality.

How to sequence certificates, passkeys, and exception paths

Start where the security payoff is largest and the operational burden is smallest: privileged users, administrators, finance, support staff, and other accounts that can cause disproportionate harm if phished. Certificate-based authentication is often easier to stand up in managed environments, especially where device enrolment and corporate endpoint control already exist.

Passkeys then become the long-term default for user populations and systems that can support them reliably. That usually means prioritising modern browsers, managed devices, and applications that already have a clean authentication abstraction, then expanding into less uniform estates as recovery and device-binding patterns stabilise.

Do not let the rollout stop at “supported in principle”. A phased programme needs explicit treatment for break-glass access, lost-device recovery, shared endpoints, and legacy apps that still depend on older authentication flows. The practical risk is that one weak fallback quietly reintroduces phishing exposure for the very users the programme was meant to protect. For a broader control lens, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue is useful for mapping authentication, access control, and logging dependencies around the migration.

Where organisations need implementation help, the OWASP Cheat Sheet Series is a practical companion for session handling, authentication hardening, and recovery flow design. The key is to make the fallback path deliberately stronger than the phishing path it replaces, not merely easier to use.

What to watch during migration, and where programmes usually go wrong

Hybrid authentication programmes fail when teams assume the “modern” method will absorb all edge cases automatically. In reality, migration risk usually appears in device enrolment friction, help desk escalation volume, certificate renewal failures, and the temptation to keep insecure fallback methods alive for convenience.

The other common failure is uneven coverage. If passkeys are deployed only for the newest devices but certificate authentication and legacy passwords remain for sensitive administrative workflows, attackers will target the weakest surviving route. That is why the migration plan should be explicit about which users move first, which systems are exempt, and when those exemptions expire.

Useful prioritisation comes from focusing on blast radius, not just user count. Protect the accounts whose compromise would unlock privileged access, sensitive data, or downstream administrative control. The broader account base can follow once the recovery model is proven and support teams can handle enrolment and reauthentication without creating shadow exceptions.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	AAL — Authenticator Assurance Levels	Defines phishing-resistant digital identity requirements for this rollout.
	Phishing-Resistance — Phishing-Resistant Authentication	Directly addresses passkeys and certificate-based phishing resistance.
Recommendation — Use phishing-resistant authenticators that meet the required assurance level for each access path. Prefer phishing-resistant authenticators over reusable secrets for sensitive accounts.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Covers the access-control and authentication controls governing phased migration.
Recommendation — Define staged authentication controls that limit access according to user and system risk.
CIS Controls v8	6 — Access Control Management	Supports enforcing and reviewing stronger authentication on critical accounts.
	5 — Account Management	Applies to account lifecycle, enrolment, recovery and deprovisioning during transition.
Recommendation — Enforce strong authentication and remove unnecessary fallback access paths. Inventory accounts and retire weak authentication methods as users migrate.

Practitioner Guidance

What to prioritise: Roll out phishing-resistant authentication first on the access paths where compromise would hurt most, then expand only after recovery, device lifecycle, and support workflows are stable.

What to verify: Confirm that every fallback method is tracked, time-bounded, and at least as observable as the primary authenticator. If help desk staff can restore access without strong assurance, the migration still has a weak link.

Common mistake: Treating passkeys as a universal replacement before you have solved device portability, shared workstation use, and account recovery. That usually produces exception sprawl, not true resistance.

Practitioner takeaway: The goal is not a perfect one-step conversion, it is to remove phishing-prone access from the highest-risk paths immediately while building a migration path that users can actually complete.