Why do passkey deployments still need risk-based step-up?

Why This Matters for Security Teams

Passkeys are a major improvement over passwords because they sharply reduce phishing and credential replay, but they do not turn every login into a permanent trust decision. Once a session is established, the real risks shift to device compromise, token theft, insider misuse, shared workstations, and actions taken after authentication. NIST’s Cybersecurity Framework 2.0 still expects organisations to manage risk continuously, not only at the point of initial sign-in. That is why NHI Management Group’s research on identity risk matters here: authentication strength and session assurance are different problems. A passkey can confirm the user once, but it cannot prove that the device remains trustworthy or that the action being attempted still fits the original context. In practice, many security teams discover this only after a privileged session is abused, rather than through deliberate risk design.

How It Works in Practice

Risk-based step-up adds a second decision layer after the passkey ceremony. The passkey proves the initial login, then the platform evaluates context before allowing sensitive actions. That context typically includes device posture, geo-velocity, IP reputation, session age, transaction value, role sensitivity, and whether the request is unusual for that user or workload. When risk stays low, the user moves without interruption. When risk rises, the system asks for fresh proof, such as a re-authentication, device confirmation, or a stronger factor. This approach is consistent with zero trust thinking in the NIST Cybersecurity Framework 2.0 and with the guidance in NHI Management Group’s Top 10 NHI Issues, where standing trust is treated as a liability rather than an assumption. For passkey deployments, the practical pattern is:

• use passkeys as the default primary authenticator for low-friction access;
• trigger step-up for administrative changes, data export, payment actions, and policy overrides;
• re-evaluate risk when the session crosses a time threshold or a new device appears;
• bind step-up to the actual action, not just the login event;
• log both the risk signal and the user response for investigation.

This is especially important where session hijacking or compromised endpoints can bypass the original passkey event. These controls tend to break down in legacy applications that cannot evaluate runtime context per request because the session model is too coarse-grained.

Common Variations and Edge Cases

Tighter step-up often increases friction, so organisations have to balance user experience against assurance and business criticality. There is no universal standard for exactly which events should trigger re-authentication, and current guidance suggests tuning thresholds to the sensitivity of the action rather than applying a single rule everywhere. A finance approval, an admin role change, and a read-only dashboard do not deserve the same treatment. One common edge case is “remembered device” behaviour. If the device is already compromised, remembering it simply extends the attacker’s window. Another is high-trust internal users. Even strong employees can be phished through session theft, shared browsers, or unattended terminals, so step-up should not be reserved only for external threats. Organisations should also be careful not to let passkeys become a false end state; NHI Management Group’s guidance on identity risk repeatedly shows that long-lived trust is where governance fails. Best practice is evolving toward continuous evaluation, not just stronger first-factor authentication, because the session itself can become the attack surface after a clean passkey login.

Related resources from NHI Mgmt Group

• When does a short-lived API key still create material risk?
• What is the difference between risk-based access and traditional step-up authentication?
• Who is accountable when step-up authentication fails to protect regulated access?
• Why do non-human identities create more audit risk than human accounts?