Should organisations replace traditional MFA with passkeys and adaptive controls?

For most programmes, yes for the primary path and no for everything else. Passkeys should become the preferred method where device support allows it, while adaptive controls decide when extra checks are needed. Traditional MFA can remain as fallback, but it should no longer be the default for every login.

Why This Matters for Security Teams

Passkeys and adaptive controls matter because password resets, push fatigue, and weak step-up logic still leave organisations exposed after the “login” problem is supposedly solved. The real decision is not whether to keep every legacy factor forever, but whether the primary authentication path can resist phishing while the policy layer can raise assurance only when context warrants it. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, a reminder that authentication strength only helps if access decisions are equally disciplined.

Security teams often treat MFA as a binary control, then discover that users, contractors, and service access paths behave very differently in practice. A passkey-first model reduces credential replay risk, while adaptive controls can account for device posture, location, risk signals, and session sensitivity. That approach is more aligned with current Zero Trust guidance than blanket prompts that users predict and attackers learn to bypass. For broader identity control context, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference point.

In practice, many security teams encounter authentication failures only after attackers have already learned which step-up paths can be coerced or ignored.

How It Works in Practice

The most workable pattern is to make passkeys the preferred primary factor for supported users and devices, then reserve adaptive controls for exceptions, higher-risk sessions, and recovery flows. Passkeys help because they bind authentication to a device-anchored credential and remove the shared secret that phishing kits usually target. Adaptive controls then evaluate the request at runtime, rather than assuming every login deserves the same friction.

That means policy should consider signal quality, not just factor count. Common inputs include device trust, geolocation, impossible travel, session age, resource sensitivity, and whether the request is a fresh login or a privileged action inside an existing session. Where assurance must increase, the step-up should be proportionate to the risk. Where risk is low, friction should stay low. This is one reason modern identity programmes are moving away from static “MFA everywhere” rules and toward conditional access.

• Use passkeys as the default for human interactive sign-in wherever platform support exists.
• Keep a fallback method for recovery, but constrain it with stronger verification and tighter lifecycle rules.
• Apply adaptive policies to risky events such as new devices, high-value applications, or admin actions.
• Log every step-up decision so access reviewers can see why a challenge was issued or bypassed.

For identity governance context, the Ultimate Guide to NHIs — Standards section is useful when teams want to align authentication decisions with broader lifecycle and control expectations. Passkeys are stronger than passwords, but they do not remove the need for session risk evaluation, recovery protection, or privileged access boundaries. These controls tend to break down in shared workstation environments and high-churn contractor fleets because device trust signals become inconsistent and recovery paths get abused.

Common Variations and Edge Cases

Tighter authentication often increases recovery overhead, requiring organisations to balance user convenience against account takeover resistance. That tradeoff is especially visible for executives, field workers, call-centre staff, and third parties, where device ownership and supportability are uneven. Current guidance suggests passkeys should be the preferred route, but there is no universal standard for deprecating every other MFA method on the same timeline.

Some environments still need traditional MFA as a fallback for older devices, break-glass access, or regulated systems that have not caught up with modern authenticators. The key is not to preserve legacy MFA as the default forever. It is to constrain its use, separate recovery from daily access, and treat every fallback as a higher-risk path that deserves extra monitoring. In incident-heavy environments, old MFA often persists because it is operationally familiar, not because it is the strongest available control.

For breach context, Microsoft Midnight Blizzard breach and Salt Typhoon US telecoms breach both reinforce the same lesson: strong authentication only helps when the surrounding access paths, recovery channels, and privileged workflows are equally hardened.

Related resources from NHI Mgmt Group

• Why does MFA remain necessary even when organisations use SSO, passkeys, or other phishing-resistant controls?
• How do organisations decide when contextual access should replace traditional IGA controls?
• How do organisations operationalise NHI ownership at scale?
• What is the difference between human IAM controls and NHI governance?