Treat the action as too risky to inherit the base login state alone. Add a separate proof requirement before the request can commit, and keep the elevated state short-lived. If the application cannot re-check device-bound assurance at the decision point, the safer choice is to slow or block the action until that control exists.
What teams should do when the step-up path is missing
When passkey-based step-up is unavailable, the right immediate response is to stop treating the base login as sufficient for the higher-risk action. The system should require a separate proof at the decision point, and if it cannot do that reliably, it should delay or block the request rather than inheriting prior assurance.
The practical test is simple: if the request would be unsafe without a fresh device-bound check, do not let an earlier sign-in state carry the decision. That is especially important when the action changes privilege, moves money, exposes data, or commits an irreversible workflow.
Why base login state is not enough for the commit
A successful sign-in proves the user reached the session, not that they still control the authenticating device at the moment of a sensitive action. Step-up exists to re-establish assurance when the risk level changes, and passkeys are valuable because they bind that proof to a device and a phishing-resistant ceremony.
Without that second check, teams often fall back to convenience controls such as trusting the current session, using a generic password re-entry, or assuming recent login equals current intent. Those substitutes can be materially weaker than the action being protected, especially when the session could already be stolen, replayed, or delegated.
For teams rolling out passwordless flows, the safest design principle is to make the sensitive action depend on a fresh authorization decision, not on the mere existence of an authenticated browser session. The NIST SP 800-63 Digital Identity Guidelines are useful here because they frame assurance by transaction context, authenticator strength, and reauthentication expectations.
What to do while the stronger control is unavailable
When the passkey step-up cannot be invoked, the safest interim pattern is to raise friction and narrow blast radius. That can mean pausing the action, requiring an alternate proof method with equivalent strength, shortening the elevated window, or routing the request to a lower-risk path until the control is restored.
For identity teams, the implementation choice should be deliberate rather than improvised. NHIMG’s Workforce Identity Security Guide is relevant where the flow protects employee actions, while the Passwordless and Passkeys Guide is useful for understanding how device-bound authentication is expected to support stronger verification at the point of risk.
If the same pattern applies to customer-facing actions, the Customer IAM (CIAM) Guide helps frame how step-up, recovery, and account takeover resistance should be handled without turning every session into a permanently trusted state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Step-up decisions depend on authenticator assurance and reauthentication context. |
| Recommendation — Apply higher-assurance reauthentication when the requested action exceeds the current session assurance. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | Fresh proof at commit time depends on managing stronger authenticators than the base session alone. |
| Recommendation — Require stronger authenticators before allowing high-risk actions to proceed. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Sensitive employee actions need authentication that can be rechecked at the decision point. |
| Recommendation — Reauthenticate users before committing privileged or sensitive actions. | ||
| OWASP ASVS | V6 — Authentication | Authentication strength should match the sensitivity of the action being performed. |
| Recommendation — Enforce step-up authentication when the transaction risk increases. | ||
Practitioner Guidance
What to verify: Confirm whether the requested action has its own approval boundary. If it does, the application should be able to demand a fresh proof at that boundary rather than relying on the existing session.
Decision rule: If the app cannot re-check device-bound assurance at the commit point, treat the action as high risk and slow it down, step it out of band, or block it until a stronger control exists.
What good looks like: Elevated state is short-lived, scoped to one intent, and automatically drops back to ordinary access as soon as the sensitive request finishes or times out.
Common mistake: Using recent login, password re-entry, or a long-lived “trusted device” flag as a substitute for real step-up when the action itself deserves stronger proof.
Practitioner takeaway: The key question is not whether the user is already signed in, it is whether the system can re-establish assurance at the exact moment the action becomes risky.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org