Continuous Authentication vs Step-Up Authentication: When Each Fits

A strong sign-in at nine in the morning says little about who is holding the session at three in the afternoon, and that gap is where session theft, insider misuse and over-trusted agent sessions live. Two families of control try to close it. Step-up authentication asks for a stronger or fresher authentication at the moment a sensitive action is requested. Continuous authentication keeps re-evaluating the session in the background, using signals about the user, device, network and behaviour, and acts when something changes, including revoking tokens through standards such as the OpenID Continuous Access Evaluation Profile (CAEP). This guide compares the two as design choices: threat model, architecture, signals, triggers, user experience cost, token revocation, coverage against session hijacking, and how each applies to AI agent and workload sessions. It is for identity architects, zero trust leads and application owners. Protocol detail lives in the OAuth Step-Up Authentication Challenge Guide and the CAEP and Continuous Access Evaluation guide, which this page links rather than repeats.

Key takeaways

• Short answer: step-up protects actions, continuous authentication protects sessions. Use step-up where a specific operation needs proof of a strong, recent authentication; use continuous evaluation where the risk is that a valid session is later misused or stolen. Most mature programmes need both.
• Step-up is explicit and standardised for APIs. RFC 9470 (September 2023, Standards Track) lets a resource server reject a token with insufficient_user_authentication and ask for specific acr_values or a max_age.
• Continuous evaluation needs a revocation path. Detecting risk mid-session is useless unless the relying party can act; CAEP 1.0 (published 29 August 2025) defines eight event types, including session-revoked, credential-change and assurance-level-change.
• Neither is enough against a stolen session on its own. Step-up only fires on sensitive actions, and behavioural signals can be noisy; binding sessions and tokens to the device closes the replay gap that both leave.
• Agents change the calculus. An AI agent cannot answer a step-up prompt itself, so step-up for agents becomes human approval, while continuous evaluation of agent tokens and behaviour becomes the main runtime control.

Definitions and the comparison at a glance

Step-up authentication is a request, triggered by a policy decision at the time of an action, for the user to authenticate again with a stronger method, or more recently, before the action proceeds. Continuous authentication is used for two related ideas: passive, ongoing verification that the same person is still present (behavioural biometrics, device posture), and continuous access evaluation, where identity providers and applications exchange events so that access is re-evaluated whenever risk or state changes. NIST SP 800-63B-4 calls the first idea session monitoring, "the ongoing evaluation of session characteristics to detect possible fraud during a session".

Threat model for each approach

What step-up defends against

• Weakly authenticated sessions reaching high-impact actions: a user who signed in with a password should not approve a payment or change MFA methods without a phishing-resistant factor.
• Stale authentication: a session that is hours old, possibly on an unattended device. RFC 9470 measures freshness from the last "active authentication event", not from token issuance, and notes that auth_time and acr do not change when an access token is renewed.
• Some stolen sessions: if a hijacked session hits a step-up gate, the attacker must defeat the stronger factor. They may try MFA fatigue (ATT&CK T1621) or interception (T1111), which is why the step-up method should be phishing resistant.

What continuous evaluation defends against

• Revocation lag: an account is disabled or a password reset, but access tokens and application sessions stay valid until they expire. CAEP events such as session-revoked and credential-change let relying parties act straight away.
• Session theft and replay: a stolen cookie or token (T1539, T1550.004) used from a different device or network may show up as a change in IP, device or behaviour.
• Posture drift: a device falling out of compliance mid-session, signalled by device-compliance-change.
• Risk accumulation: several weak signals that together raise risk, signalled by risk-level-change with values LOW, MEDIUM or HIGH.

Architecture in words

Step-up has three moving parts. The resource server holds a policy that maps operations to required authentication context (acr) and maximum age. When a token falls short it returns HTTP 401 with error="insufficient_user_authentication" and the required values. The client sends the user back to the authorisation server with those parameters, and the authorisation server performs the stronger authentication and issues a new token whose acr and auth_time satisfy the policy. The architecture is stateless apart from the policy table: no continuous data flow is needed.

Continuous evaluation is a signal pipeline. Transmitters (the identity provider, endpoint management, UEBA, other SaaS applications) emit security events; receivers (applications, gateways, other identity providers) subscribe through the Shared Signals Framework and map each event to an action: end sessions, revoke refresh tokens, re-evaluate authorisation, or demand step-up. Inside the identity provider, a risk engine scores sign-ins and sessions from signals NIST lists for session monitoring: usage patterns, velocity and timing, behavioural biometrics such as typing cadence, device and browser characteristics, geolocation and IP address reputation. The transport is covered in the Shared Signals Framework Guide.

The two meet in the middle: a continuous signal such as a CAEP assurance-level-change or a raised risk level is often best answered not by terminating the session but by forcing step-up at the next request. Designing that hand-off is most of the work.

Signals and triggers compared

NIST SP 800-63B-4 is careful about one point: fraud indicators "MAY be used to lower the risk of misauthentication", but they do not change the authenticator assurance level or substitute for an authentication factor. Continuous signals can trigger reauthentication; they cannot replace it.

Reauthentication baselines from NIST SP 800-63B-4

Both approaches sit on top of plain session timeouts, which SP 800-63B-4 sets per assurance level. When either timeout expires the session "SHALL be terminated".

Step-up and continuous evaluation should tighten these baselines where risk is higher, never loosen them. For the full assurance model see the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.

Token revocation and the session hijack gap

Session hijacking is the clearest test of the difference. The attacker holds a valid session cookie or token, so the original authentication was genuine. In the 2023 CitrixBleed exploitation, attackers read valid session cookies from appliance memory and replayed them, which bypassed passwords and MFA entirely, and patching did not invalidate cookies already stolen. See CitrixBleed 2023.

• Step-up coverage: partial. The attacker is stopped only when they try a protected action, and only if the step-up method resists phishing and fatigue. Anything below the threshold, such as reading mail or files, proceeds.
• Continuous evaluation coverage: partial, and dependent on signals. Replay from a new IP or device can raise risk, but an attacker who replays from a similar network may not stand out. Once detected, revocation only works where receivers are wired up: an application that issues its own session cookie must end that session itself.
• Closing the gap: bind sessions and tokens to the client so a copied secret cannot be replayed elsewhere. NIST notes that browser cookies are acceptable only as short-term secrets for session maintenance, not as authenticators. See the Device-Bound Session Credentials (DBSC) Guide, the DPoP Guide and the Session Hijacking and Cookie Theft Guide.

User experience cost

• Step-up friction is predictable: users learn which actions prompt and why. The cost rises if thresholds are too broad or max_age too short, so that users are challenged repeatedly within one task. Reuse a recent strong authentication across related actions within the freshness window.
• Continuous evaluation friction is unpredictable: a session ended because a laptop changed Wi-Fi networks feels arbitrary. Prefer graduated responses: log, then require step-up at the next sensitive request, then terminate only on high-confidence events such as session-revoked.
• Accessibility: behavioural biometrics can misjudge users with disabilities or assistive technology, and step-up methods must have accessible alternatives. Test with real user groups before enforcing.
• Privacy: NIST notes that most session monitoring characteristics have privacy implications that fall under its privacy risk assessment. Document what is collected, retention and purpose.

Agent and workload sessions

AI agents and workloads hold tokens for long periods and act at machine speed, which stresses both models differently.

• Step-up becomes human approval: an agent cannot complete a passkey prompt on behalf of a person, and should not. For high-impact agent actions, route the step-up to the accountable human through a decoupled flow such as OpenID CIBA, and record the approval. See CIBA vs OAuth Device Flow and the Human-in-the-Loop for AI Agents Guide.
• Freshness of the delegating user: when an agent acts on a user's behalf through token exchange, the user's auth_time and acr still matter; a resource server can require that the delegating user authenticated strongly and recently. See the OAuth Token Exchange and Delegation Guide.
• Continuous evaluation is the main runtime control: watch agent token use for new destinations, unusual tool calls, volume and timing, and revoke agent tokens when the delegating user's session is revoked or their credentials change. CAEP events about the human subject should propagate to agent sessions created from it.
• Workload identities: service accounts have no interactive step-up at all; rely on short-lived, sender-constrained credentials, conditional access for workload identities where available, and anomaly detection. See the Zero Trust for AI Agents Guide.

Worked scenarios

Scenario 1: finance portal

Users sign in with a passkey (AAL2 or higher). Adding a new payee requires an acr mapped to phishing-resistant authentication within the last five minutes, enforced through RFC 9470 at the payments API. Continuous evaluation runs alongside: a credential-change event from the identity provider ends all other sessions, and a jump in risk level forces step-up on the next request rather than ending the session outright. Step-up protects the money movement; continuous evaluation protects everything else.

Scenario 2: administrator console in a SaaS estate

The concern is a stolen administrator session. Step-up on every privileged change provides a gate, but the stronger control is continuous: when the administrator's device falls out of compliance or the account is disabled, the SaaS application receives a CAEP event and ends the session within minutes instead of at token expiry. Device-bound sessions remove most of the replay risk.

Scenario 3: coding agent with repository access

An agent opens pull requests on a developer's behalf. Merging to a protected branch requires the developer's approval through a decoupled request, which is the agent equivalent of step-up. Continuous evaluation watches the agent's token for access to repositories outside its task and revokes it if the developer leaves the organisation or their session is revoked.

Decision guidance

Small organisations get most value from step-up configured in their identity provider and from short session lifetimes, because these need no application changes. Large organisations should treat continuous evaluation as a programme: inventory which applications can receive revocation events, close the gaps, and measure revocation latency. For the policy side see the Risk-Based and Adaptive Authentication Guide.

How to implement

1. Classify operations and sessions. List high-impact actions (step-up candidates) and high-value long sessions (continuous evaluation candidates).
2. Define authentication levels. Map acr values to methods and set max_age per operation class.
3. Start step-up in report-only mode. Log when a request would have been challenged, tune thresholds, then enforce on one application.
4. Wire revocation first, risk second. Make applications act on session-revoked and credential-change before consuming risk scores; these are high confidence and low noise.
5. Add risk-driven responses gradually. Map medium risk to step-up at the next request and high risk to termination; review false positives weekly during the pilot.
6. Bind sessions. Introduce device-bound sessions or sender-constrained tokens for the highest-value applications.
7. Extend to agents. Propagate user session events to agent tokens and add human approval for high-impact agent actions.
8. Keep rollback simple. Each enforcement rule should have a switch back to report-only, owned by the identity team, for outages caused by bad signals.

Detection and measurement

• Revocation latency: time from account disable or credential change to session end in each application; the core continuous evaluation metric.
• Receiver coverage: percentage of applications that act on revocation events.
• Step-up challenge and failure rates: per operation; a rise in failures can indicate attack, a high challenge rate indicates friction.
• Risk-driven termination false positive rate: terminations later judged legitimate.
• Agent token revocation propagation: percentage of agent sessions ended within target after the delegating user's session is revoked.

Log every step-up challenge with the required and presented acr, every received security event and the action taken, and every risk-driven termination with its signals, so that analysts can reconstruct why access was allowed or ended.

Framework mapping

Common failure patterns

• Step-up only at sign-in: calling a single MFA prompt at login "step-up" leaves every later action covered by the original authentication.
• Risk detected, nothing revoked: the identity provider flags the session but applications keep their own cookies for hours because they never subscribed to revocation events.
• Step-up with a phishable factor: push approval or SMS as the stronger method invites fatigue and interception.
• Freshness ignored: checking acr but not auth_time, so a strong authentication from yesterday satisfies a payment approval today.
• Agents inheriting human sessions without propagation: the user is offboarded but the agent's tokens remain valid.
• Behavioural signals enforced without tuning: lockouts for legitimate users that lead to exemptions, which then become the attacker's way in.

Practitioner checklist

• List high-impact operations and assign each a required acr and max_age.
• Use phishing-resistant methods for step-up.
• Apply SP 800-63B-4 timeouts as the baseline for each assurance level.
• Make every application act on session revocation and credential change events, or shorten its sessions.
• Map risk levels to graduated responses, with report-only first.
• Bind sessions or tokens to devices for the highest-value applications.
• Propagate user revocation to agent tokens and require human approval for high-impact agent actions.
• Measure revocation latency and receiver coverage monthly.
• Complete a privacy assessment for behavioural and location signals.

Standards and references

• IETF: RFC 9470 OAuth 2.0 Step Up Authentication Challenge Protocol
• OpenID Foundation: Continuous Access Evaluation Profile 1.0
• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• MITRE ATT&CK: T1539 Steal Web Session Cookie
• MITRE ATT&CK: T1621 Multi-Factor Authentication Request Generation
• MITRE ATT&CK: T1550.004 Web Session Cookie

Related NHI Mgmt Group resources: Zero Trust Identity Guide · OAuth Step-Up Authentication Challenge Guide · CAEP and Continuous Access Evaluation · Agent Identity and Access Guide