How do you know whether a passkey programme is actually working?

Why This Matters for Security Teams

A passkey programme is not “working” just because users enrolled or a pilot completed. Security teams need evidence that passkeys are replacing weaker sign-in paths, reducing phishing exposure, and shrinking support load without creating brittle recovery workflows. The real measure is whether authentication becomes both safer and simpler across the applications that matter, not whether one login flow looks good in a demo. Current guidance from the NIST Cybersecurity Framework 2.0 treats identity outcomes as operational controls, which is the right lens here.

That matters because passkey programmes often fail quietly. Users may still fall back to passwords, shared devices may bypass device-bound assurance, and recovery channels can become the weakest path in the stack. NHIMG research on the Ultimate Guide to NHIs shows that identity risk is often hidden in the long tail of exceptions and unmanaged credentials, which is exactly where a passkey rollout can drift if metrics are too shallow. In practice, many security teams discover the programme is underperforming only after help desk volume, account recovery abuse, or app-by-app exceptions have already undermined the intended gains.

How It Works in Practice

A passkey programme should be measured like any other security control: by baseline, adoption, exception rate, and residual risk. Start with a pre-rollout snapshot of password logins, MFA prompts, phishing-related incidents, password resets, and recovery tickets. Then track whether passkeys are displacing those paths over time, not merely coexisting with them. The goal is a measurable reduction in password dependency and a corresponding increase in strong, phishing-resistant authentication.

Useful operating metrics usually include:

• Passkey enrollment rate by population, device type, and application.
• Login success rate with passkeys versus fallback methods.
• Rate of password fallback, step-up prompts, and denied sign-ins.
• Account recovery events, recovery abuse, and manual exception approvals.
• Application coverage, especially where policy does not yet enforce passkeys.

From a governance perspective, the programme should map to policy enforcement rather than voluntary use. A useful threshold is not “most users have passkeys,” but “most high-value applications refuse weaker methods when passkeys are available.” That aligns with broader identity hygiene concerns documented in the Ultimate Guide to NHIs, where visibility and exception handling are often the difference between control and drift. NIST’s identity guidance also supports measuring assurance at the point of authentication, not only at enrollment. In practice, teams should review telemetry by app, tenant, and user cohort so they can see whether passkeys are actually removing password dependence or simply adding another option.

Where this guidance breaks down is in mixed legacy environments with shared workstations, unsupported browsers, or applications that still require password-based service flows, because those conditions force fallback paths that dilute the control.

Common Variations and Edge Cases

Tighter passkey enforcement often increases recovery and exception-management overhead, so organisations must balance phishing resistance against operational friction. That tradeoff is especially visible during migration, when some applications support passkeys fully while others only partially support them.

There is no universal standard for measuring success yet, but current guidance suggests separating “adoption” from “effectiveness.” A high enrollment rate can still mask weak programme quality if users can bypass passkeys through password resets, SMS recovery, or unmanaged devices. The same applies to workforce groups with privileged access: strong authentication matters less if recovery processes remain broad and manual.

Common edge cases include:

• Users with multiple devices, where syncable passkey improve usability but may alter assurance assumptions.
• Bring-your-own-device environments, where device trust and loss handling need separate review.
• Admin and privileged accounts, where passkeys should be paired with stronger policy and tighter recovery controls.
• Service or shared accounts, which often sit outside typical passkey workflows and require separate governance.

A passkey programme is usually healthiest when it reduces password use without expanding recovery risk or exception debt. If the org still depends on passwords for critical apps, then the programme is not yet complete, even if the enrollment dashboard looks strong.

Related resources from NHI Mgmt Group

• How do you know if an access review programme is actually working?
• How do you know a passwordless programme is actually working?
• How do you know whether federal ICAM offboarding is actually working?
• How do you know whether AWS data controls are actually working?