The programme still leaves the majority of accounts reachable through phishing. Attackers target the weaker path, not the strongest one, so limiting phishing-resistant authentication to admins creates a false sense of coverage. Identity teams should assume every user is a target and design the baseline around broad phishing resistance, not exceptional protection for a small group.
What breaks when passkeys are rolled out only to admins?
The security model becomes uneven: the best phishing-resistant control protects only a small slice of the estate, while everyone else remains reachable through credential theft, phishing, and session abuse. That asymmetry lets attackers choose the softer path, so the programme looks modern without materially changing enterprise exposure.
Why selective passkey deployment creates a false control boundary
Passkeys work because they remove reusable secrets from the sign-in step and make phishing much harder. If only privileged users get them, the organisation has not changed the most common attack surface, it has only hardened a subset of high-value accounts. The result is a control boundary that is real for admins but imaginary for the wider user base.
That matters because attackers rarely stop at the first protected account. They look for any identity that still accepts passwords, OTPs, or weak recovery paths, then pivot through that weaker entry point. A limited rollout can therefore improve the security of the most sensitive accounts while leaving the overall phishing problem largely intact.
Selective deployment also distorts programme measurement. Teams may report passkey adoption, MFA coverage, or phishing resistance as if the organisation is broadly protected, when in practice only a narrow population benefits. The gap often sits in account recovery, help desk reset flows, and legacy authentication methods that remain available to non-privileged users.
What changes for attackers and defenders when coverage is partial
From an attacker perspective, a partial passkey deployment is still useful information. It signals that privileged accounts may be harder to harvest directly, so the adversary can target employees, contractors, support channels, or federation pathways that remain easier to compromise. That shifts the attack from the strongest account to the weakest reachable identity path.
For defenders, the main change is that identity assurance becomes inconsistent across the population. Strong authentication on admin accounts does not compensate for broad exposure elsewhere, especially where stolen sessions, social engineering, or password reset abuse can still lead to access. The practical lesson is that baseline authentication strength has to be judged at the fleet level, not by the most protected subset.
It also affects incident response. If some users are passkey protected and others are not, investigators cannot assume the environment is uniformly resistant to phishing or MFA fatigue. They need to treat a compromised non-privileged account as a potentially valid stepping stone to privileged access, SaaS data, or internal tooling.
How to judge whether the rollout is actually reducing risk
A useful test is not “do we have passkeys for admins?” but “can an ordinary user still be phished into a credential-bearing action?” If the answer is yes, the enterprise still has a broad identity attack surface. The control only becomes meaningful when it reduces the common path to compromise, not when it protects the highest-status accounts in isolation.
Another test is whether recovery, enrollment, and fallback are equally resistant. If passkeys are strong but password resets, one-time codes, or support-mediated resets remain easy, attackers can simply route around the passkey control. Good programmes treat authentication and recovery as one design problem, because the weakest recovery path often defines the real security posture.
Rollout strategy also matters. Phasing to admins first is reasonable only as a short transitional step with a clear end state for the rest of the workforce. If the programme stalls there, the organisation has created a premium control for a small group and left the majority on older, easier-to-abuse methods.
Risk and Threat Considerations
Partial passkey adoption creates uneven exposure, which is attractive to attackers because it preserves a large pool of phishable identities. It also increases the chance that teams overestimate their protection and underinvest in recovery-path hardening, where many real compromises still begin.
Failure mechanism: Attackers bypass the hardened admin path and compromise a less protected user, contractor, or support workflow, then use that access to reach data, tools, or higher privilege.
Impact: The organisation keeps the same broad phishing and takeover risk profile even after “modernising” authentication for a small privileged subset, so the control benefit is much smaller than the rollout suggests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys and phishing-resistant authentication are core to digital identity assurance. |
| Recommendation — Adopt phishing-resistant authenticators and align rollout with assurance levels across the workforce. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Partial rollout leaves weaker authentication paths that attackers can target. |
| Recommendation — Eliminate weaker sign-in and recovery paths that bypass phishing-resistant authentication. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | Selective passkey use concerns authentication controls and their consistency across users. |
| Recommendation — Standardise secure authentication across all user groups and fallback flows. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Admins only passkeys leave organizational user authentication unevenly protected. |
| IA-5 — Authenticator Management | The question hinges on whether reusable secrets and recovery mechanisms remain exposed. | |
| Recommendation — Require strong authentication for all organizational users, not just privileged accounts. Control authenticator lifecycle and remove weaker fallback credentials and reset paths. | ||
Practitioner Guidance
What to prioritise: Treat workforce coverage as the core objective. If passkeys are only on admin accounts, the next step is expanding phishing-resistant authentication to the highest-volume user populations and the recovery paths they depend on, not adding more protection to an already hardened tier.
What to verify: Check whether any non-passkey path can still lead to account recovery, session creation, or MFA reset without comparable assurance. If yes, the control is incomplete even if privileged users are already enrolled.
Decision rule: If the majority of users can still be phished, assume the enterprise is still vulnerable at the control level, regardless of how strong the privileged-user tier looks.
Practitioner takeaway: Passkeys deliver enterprise value when they shrink the ordinary attack surface, not when they merely create a protected exception for admins.
Related resources from NHI Mgmt Group
- What breaks when standing privilege is not removed for privileged users and service accounts?
- What breaks when non-privileged users can create machine accounts in managed Active Directory?
- What breaks when low privileged users can influence query clauses in a data exploration platform?
- What breaks when healthcare access reviews do not include privileged users and service accounts?