When should organisations re-authenticate an SSO session?

When re-authentication should be triggered by risk, not the clock

Re-authentication is most defensible when the session’s risk profile changes. A user or agent who authenticated for one purpose should not automatically carry that assurance into a materially different action, data set, or system boundary. For OpenID Connect Core 1.0, that means treating the original sign-in as a starting point, not a blanket approval for every later step.

Fixed timers are a weak proxy for trust because they ignore context. If the task remains low impact, a session can continue with lighter friction; if the task escalates into payment, export, admin, or sensitive-data access, the control should step up immediately. That is why high-value workflows need event-driven re-authentication, not a generic “every X minutes” rule.

For SSO, the practical test is whether the authenticated context still matches the purpose that justified it. If the device, network posture, privilege level, app, or transaction scope has changed, the old session may still be technically valid while no longer being security-appropriate. The decision is therefore about session purpose, not just session age. See also the Identity Provider and SSO Security Guide for the surrounding session and federation controls.

Where SSO sessions become too long-lived

The failure mode is simple: a session outlasts the access decision that created it. Once that happens, the session can be reused after the original context has drifted, which increases the window for misuse if the browser, token, or device is compromised. This is especially important where SSO is fronting many apps and the IdP becomes the enforcement point for far more than just login.

Operationally, the highest-risk boundaries are where a routine working session turns into a high-consequence action. Examples include approving a payout, changing identity or recovery settings, accessing production secrets, or allowing an AI agent to continue with tool access after the task scope has changed. In those cases, step-up authentication should occur at the boundary, before the sensitive action proceeds.

Attackers benefit when organisations treat a valid session as equivalent to continuing trust. Token theft, session hijacking, and replay let an intruder inherit the user’s authenticated state without knowing the password. The CitrixBleed exploitation 2023 and CircleCI breach 2023 are useful reminders that session validity can survive long after the original login moment.

Practical triggers for re-authentication in SSO and agent workflows

Use re-authentication when one of four things changes: the risk of the action, the sensitivity of the data, the trustworthiness of the device or network, or the scope of authority being exercised. That applies to human users and to AI agents that continue operating under delegated access. For agents, the boundary should be tied to task completion, new tool use, or a shift in the permitted action set, not to an arbitrary time slice.

What to verify: confirm that the re-auth trigger is attached to a material boundary, such as privilege escalation, recovery changes, payment release, production access, or cross-tenant access. If the trigger cannot be explained in terms of changed risk, it is probably the wrong control.

What changes at scale: the more apps and tools an SSO session reaches, the more likely one stale session becomes a wide blast-radius event. At scale, re-authentication policy should be consistent enough to automate, but specific enough to avoid forcing users through friction for low-risk continuation.

For identity assurance guidance, NIST SP 800-63 Digital Identity Guidelines is useful for thinking about assurance level, while Workforce Identity Security Guide gives a broader operational view of SSO, federation, and step-up authentication.

Risk and Threat Considerations

Overly long SSO sessions create a replay window for token theft, session fixation, and post-compromise persistence. They also make lateral movement easier when one authenticated context can be reused across multiple downstream systems without a fresh challenge.

Failure mechanism: a session remains valid after the original risk conditions have changed, so a stolen cookie, token, or active browser session can still authorize sensitive actions that should have required a new trust decision.

Impact: attackers gain durable access, defenders lose a clean re-authentication boundary, and incident response becomes harder because the session itself may look legitimate even after the user’s intent has changed.

Practitioner Guidance

Decision rule: re-authenticate at the point where the task’s consequence changes, not when an arbitrary timer expires. If the next action could change money, identity, secrets, production state, or AI agent authority, require a fresh trust decision first.

What to prioritise: start with recovery paths, admin actions, payment actions, and privileged self-service flows, because those are the places where a stale SSO session causes the most damage. Then extend the same logic to agentic workflows that can call tools or act on behalf of a user.

Common mistake: teams often tune session length globally and assume the problem is solved. A better design is to keep ordinary navigation low-friction while forcing step-up at meaningful operational boundaries.

Practitioner takeaway: the question is not “how long should SSO last?”, it is “what action still deserves the original authentication?” When the answer changes, the session should end or step up.

Related resources from NHI Mgmt Group

• How should security teams authenticate AI agents in enterprise environments?
• When should organisations pair SSO with MFA and session controls?
• When should organisations re-evaluate their NHI governance model?
• When should organisations treat an SSO issue as a federation-wide incident?