Why do access tokens and refresh flows complicate step-up authentication decisions?

Access tokens are issued before the API sees the request context, so they cannot reflect every risk decision made at runtime. Refresh flows can keep a session alive without a new human authentication, which means auth_time may remain stale even though the client still has valid tokens. That is why freshness and session state must be checked separately.

Why This Matters for Security Teams

Step-up authentication is meant to raise assurance at the moment risk increases, but access tokens and refresh flows make that decision harder because they separate authentication from the request that later needs approval. A token can be valid even when the user or client state has changed, so teams that treat token validity as equivalent to fresh authentication can miss important risk signals. Guidance from the OWASP Non-Human Identity Top 10 and NIST-aligned identity controls both point to the same issue: freshness is a separate control objective, not a side effect of session continuity.

This matters especially when refresh tokens can silently extend a session, because the API may never see the human re-authentication event that security policy expects. In NHI and agentic environments, that gap is amplified when a workload keeps calling tools with long-lived credentials after the original trust moment has faded. NHIMG research shows how often token persistence outlives the intended trust boundary, including the Salesloft OAuth token breach, where token abuse became the access path rather than password theft. In practice, many security teams encounter stale assurance only after a token is already being reused in ways the original step-up event never covered.

How It Works in Practice

The core challenge is that access tokens are usually minted ahead of time, while step-up decisions are often made later at request time. If the application only checks whether the token is valid, it can miss whether the current action requires a newer assurance level, a different device posture, or a stronger session state. Refresh flows complicate this further because they can produce new access tokens without forcing a new interactive authentication, which means the original auth_time may remain acceptable to the token issuer even when the business action has become higher risk.

Security teams usually need to separate three checks:

• Token validity: is the token signed correctly and unexpired?
• Session freshness: was the user or workload recently authenticated at the required assurance level?
• Action sensitivity: does this request require step-up, re-consent, or an entirely new trust decision?

That is why runtime policy matters. Current best practice is to evaluate context at the point of use, using policy-as-code where possible, rather than assuming a pre-issued token can encode every future decision. For workload and agent use cases, this becomes even more important because the identity primitive is often a Non-Human Identity or a delegated workload credential, not an interactive human login. The NIST view of identity assurance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that authentication events, session state, and authorization decisions should be controlled separately rather than blended into one token check. The practical pattern is to make refresh token use conditional, shorten token lifetimes, and require a fresh step-up before sensitive operations such as privilege elevation, key export, or data movement.

These controls tend to break down in legacy SSO stacks and API gateways that cannot evaluate request context at runtime because they only know whether a token is present, not whether the assurance is still sufficient.

Common Variations and Edge Cases

Tighter token freshness often increases user friction and operational overhead, so organisations have to balance stronger assurance against session continuity and automation reliability. There is no universal standard for exactly when step-up must be re-triggered, and current guidance suggests tailoring the policy to the sensitivity of the action rather than the application alone.

One common edge case is service-to-service traffic where a refresh flow exists, but no human is present to re-authenticate. In those cases, step-up logic should usually shift from interactive login to workload assurance: stronger client identity, shorter TTLs, or explicit approval gates for privileged operations. Another edge case is delegated admin access, where a valid access token may still be too weak for the action even though the user is “logged in.” NHIMG’s Guide to the Secret Sprawl Challenge is useful here because it shows how stale credentials and broad token reuse can turn a narrow trust decision into a wide blast radius.

In the real world, refresh-based sessions are most fragile when tokens are copied across tools, cached in CI/CD jobs, or shared through approval workflows that were never designed to preserve auth_time semantics. The more distributed the environment, the more likely it is that token freshness and true step-up state drift apart before anyone notices.

Related resources from NHI Mgmt Group

• What is the difference between risk-based access and traditional step-up authentication?
• Why do consumer banking flows need step-up authentication for high-risk actions?
• Why do OTP-based step-up flows fail for sensitive access?
• What signals should drive step-up authentication decisions?