Why do passkeys still need adaptive MFA in enterprise IAM programmes?

Why This Matters for Security Teams

Passkeys materially reduce phishing and password replay, but they do not eliminate the need to decide whether a session is still trustworthy after login. Enterprise IAM programmes must account for device posture drift, anomalous location, risky token use, and session hijack attempts that occur after authentication. NIST guidance on access control and continuous monitoring remains relevant here, especially when authentication strength and session risk are not the same problem.

The operational mistake is assuming that a strong authenticator is also a complete authorisation decision. A passkey can prove possession of a bound credential, but it cannot by itself interpret context such as impossible travel, endpoint compromise, or suspicious privilege escalation. That is why adaptive mfa remains a control layer, not a legacy fallback. The same logic appears in identity breach reporting around the Microsoft Midnight Blizzard breach, where access risk extended beyond simple credential strength, and in NIST's SP 800-53 Rev. 5 Security and Privacy Controls, which treats authentication as part of a broader control environment.

In practice, many security teams discover this only after a valid passkey session is abused from an unexpected device or network, rather than through intentional design of step-up policy.

How It Works in Practice

Adaptive MFA sits on top of passkeys and evaluates risk at runtime. If the login is low risk, the user completes the session with the passkey alone. If the session looks unusual, the IAM platform can request a second factor, enforce reauthentication, shorten the token lifetime, or block access entirely. The decision is usually based on a mix of device trust, network location, behavioural signals, transaction sensitivity, and identity assurance rules.

This is not a claim that passkeys are weak. It is a recognition that authentication and session governance are different functions. Passkeys are excellent at stopping phishing because the credential is bound to the relying party and cannot be replayed elsewhere. Adaptive MFA is what helps when the session itself becomes questionable. Best practice is evolving toward policy that is evaluated at sign-in and again during the session, especially for privileged actions, high-value applications, or recovery events. NHI Management Group’s Ultimate Guide to NHIs shows why standing trust is dangerous in identity systems where compromise often persists well beyond the initial compromise window.

• Use passkeys as the primary authenticator, not as the only control point.
• Trigger adaptive checks for new devices, unusual geographies, impossible travel, and high-risk actions.
• Combine adaptive MFA with session controls such as reauthentication, token binding, and continuous risk scoring.
• Prefer policies that can step up without forcing every user through the same heavy challenge.

Where this guidance breaks down is in legacy IAM environments that cannot evaluate contextual risk at session time because they rely on fixed, pre-authentication rules only.

Common Variations and Edge Cases

Tighter adaptive controls often increase friction, requiring organisations to balance user experience against the need to stop session abuse. That tradeoff is especially visible in help desks, executive access, and shared device environments, where over-challenging legitimate users can create workarounds.

There is no universal standard for what should trigger step-up MFA yet. Some organisations use device compliance and network location heavily, while others weight behaviour, transaction value, or resource sensitivity more strongly. The right mix depends on how mature the IAM programme is and how much risk the business is willing to absorb. In environments with high-assurance passkeys and strong endpoint management, adaptive MFA may be used selectively for privileged actions rather than every login. In less mature environments, it becomes a safety net for users, contractors, and recovery flows. The broader pattern is consistent with the 2024 Non-Human Identity Security Report: organisations often need dynamic controls because static identity assumptions age quickly. Similar breach patterns are visible in the Salt Typhoon US telecoms breach, where access abuse was not solved by credential strength alone.

The practical edge case is shared, unmanaged, or high-risk endpoints, where passkeys improve authentication but adaptive MFA still needs to compensate for weak device trust and limited visibility.

Related resources from NHI Mgmt Group

• Why do conditional UI passkeys matter for human IAM programmes?
• What is the difference between adaptive MFA and passkeys for account protection?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Why do MFA fatigue attacks still work in mature IAM programmes?