How do IAM teams decide where passkeys should be mandatory first?

Why This Matters for Security Teams

Passkeys are not just a user convenience upgrade. They are a control-selection problem, because the first places they become mandatory shape adoption, help desk volume, phishing resistance, and the quality of fallback recovery. IAM teams usually get the best results when they target applications where password resets are frequent, phishing exposure is high, and identity proofing is already mature enough to support stronger sign-in without creating recovery chaos. That makes prioritisation a governance decision, not a branding exercise. The practical risk is that broad enforcement can fail if the surrounding identity lifecycle is weak. If recovery remains email-only, if device enrollment is inconsistent, or if exceptions are granted too freely, passkeys can reduce one risk while amplifying another. Current guidance aligns with least privilege and strong authentication baselines in NIST SP 800-53 Rev 5 Security and Privacy Controls, but the rollout order still matters more than the control itself. NHI Management Group research shows how often identity programs lag behind the threat surface: the Ultimate Guide to NHIs reports that 88.5% of organisations say their non-human IAM practices lag human IAM, which is a useful reminder that any authentication change must be staged carefully. In practice, many security teams discover that passkey rollout problems are really recovery and exception-management failures only after users start failing to sign in.

How It Works in Practice

Most IAM teams decide on a mandatory-passkey wave by scoring applications across a few operational dimensions: phishing exposure, user population size, authentication friction, recovery maturity, and business criticality. The first wave usually targets internal apps with high help desk volume, repeated password reset tickets, and predictable user onboarding. The second wave often includes externally facing apps where phishing is a known concern and the sign-in flow can tolerate a stronger authenticator. A workable sequence usually looks like this:

• Identify applications with the highest password reset and account takeover exposure.
• Confirm that account recovery uses strong identity proofing, not ad hoc manual approval.
• Require passkeys first for a pilot group with low exception needs.
• Expand to high-friction apps where passwordless sign-in will reduce support demand.
• Delay enforcement where shared devices, kiosk use, or recovery gaps create operational risk.

Passkeys work best when IAM teams treat them as part of the whole authentication journey, not as a single MFA replacement. That means checking device binding, recovery escalation, session risk policies, and enrollment quality before setting a mandatory date. The most successful programs also keep a limited fallback path for edge cases while they harden recovery and support workflows. For implementation patterns around identity compromise and secret handling, NHI Management Group guidance in the 2024 Non-Human Identity Security Report and incident patterns such as JetBrains GitHub plugin token exposure underscore how quickly weak fallback paths become abuse paths. These controls tend to break down in environments with unmanaged BYOD, shared endpoints, or fragmented identity proofing because enforcement and recovery cannot be kept equally strong.

Common Variations and Edge Cases

Tighter passkey enforcement often increases support overhead at first, so organisations must balance phishing resistance against recovery friction and rollout speed. That tradeoff is especially sharp in customer-facing services, regulated workflows, and global workforces with mixed device capability. There is no universal standard for mandatory-passkey sequencing yet, so current guidance suggests using environment risk and recovery maturity rather than a one-size-fits-all department list. For example, engineering and admin populations often adopt earlier because they already use stronger devices and higher scrutiny, while contractor populations may need a slower path because device ownership and recovery assurance are less stable. A common edge case is service-desk dependency. If the recovery desk cannot reliably verify identity, mandatory passkeys can simply move attackers to social engineering the fallback process. Another is legacy app compatibility, where the app itself supports modern auth but downstream session controls or browser constraints do not. Teams also need to watch for “shadow exceptions,” where a pilot succeeds on paper but broad exception grants quietly weaken the policy. Where teams are still maturing, the most useful anchor is to start with applications that combine high phishing exposure and low recovery ambiguity, then expand only after support metrics stabilise.

Related resources from NHI Mgmt Group

• How do teams decide which IAM findings to fix first?
• How do IAM and NHI teams decide where to automate revocation first?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?