SC-23(1): Invalidate Session Identifiers at Logout

To meet the sc-23(1): invalidate session identifiers at logout requirement, your systems must destroy or revoke the session identifier immediately when a user logs out or the session terminates, so the same token/cookie cannot be reused. Operationally, you implement server-side session revocation, client-side cookie clearing, and verifiable tests and logs that prove old session IDs stop working. ¹

Key takeaways:

• Invalidate the session identifier on logout and any termination path, not just the “Log out” button. ¹
• Prefer server-side invalidation (revocation/blacklist/rotation) over relying only on client cookie deletion.
• Keep evidence: design docs, configuration, test results, and logs proving terminated session IDs are rejected.

SC-23(1) is a narrow requirement with outsized blast radius when it fails: if a session identifier remains valid after logout or termination, an attacker (or a malicious insider) who obtains that identifier can replay it and regain access without re-authenticating. This shows up in web apps, APIs, thick clients, admin consoles, and third-party SSO integrations where session state is handled by cookies, bearer tokens, or backend session stores.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SC-23(1) into a small set of non-negotiables: define what counts as “session termination,” pick the technical mechanism that guarantees invalidation, and build repeatable evidence that an assessor can verify without debating implementation details. Your engineering teams can choose the pattern (stateful sessions, token revocation, short-lived tokens plus rotation), but you need the control intent met: terminated sessions must not be reusable.

This page gives requirement-level implementation guidance you can hand to app, IAM, and platform owners, plus the audit artifacts and the common failure modes that slow assessments.

Regulatory text

Requirement: “Invalidate session identifiers upon user logout or other session termination.” ¹

Operator interpretation: You must ensure that any session identifier (for example, an HTTP session cookie value, a server session ID, or an application session token) becomes unusable once the user logs out or the session ends for any reason. “Invalidate” means the system rejects the identifier if it is presented again. ¹

Plain-English interpretation (what assessors mean)

If a user clicks “logout,” closes a session, times out, is forced off due to password reset, gets disabled, or otherwise loses a session, the old session ID must stop granting access. Clearing cookies on the browser is not enough by itself because the identifier can be copied and replayed from another client.

A clean way to phrase this as a testable control objective:

• Given a valid session ID,
• when logout or termination occurs,
• then any subsequent request using that same session ID is denied (401/403) or forced through re-authentication, and the server does not treat it as an active session. ¹

Who it applies to

Entity scope: Federal information systems and contractor systems handling federal data that implement NIST SP 800-53 controls. ²

Operational scope (where it shows up):

• Web applications using cookie-based sessions (server-side session store).
• APIs using bearer tokens that function as “session identifiers.”
• Admin consoles and privileged access paths (highest impact).
• SSO/SAML/OIDC flows where your app issues its own session after identity federation.
• Third-party applications you provide to customers/partners (you own the session lifecycle even if auth is federated).

What you actually need to do (step-by-step)

Use this as an implementation checklist you can assign and track.

1) Define “session identifier” and “session termination” for each system

Create a short inventory per application:

• Session identifier type: server session ID cookie, JWT access token, refresh token, opaque token, etc.
• Storage: browser cookie (HttpOnly/Secure/SameSite), mobile secure storage, local storage (avoid for session tokens), backend session store.
• Termination events you will treat as “must invalidate”:
  • Explicit logout
  • Session timeout/idle timeout
  • Absolute session lifetime reached
  • Password reset / credential change
  • User disabled / role removed / termination
  • Global sign-out (IdP-initiated where applicable)
  • Admin forced logout / incident response action

Output artifact: a one-page per system “Session Lifecycle Spec” that engineering and auditors can both read.

2) Choose an invalidation pattern that is enforceable on the server

Pick one of these patterns per session type:

Pattern A: Stateful server sessions (recommended for simple web apps)

• Store sessions server-side (DB/Redis/session store).
• On logout/termination: delete the session record (or mark it revoked).
• On every request: look up the session ID and confirm it is active.

Pattern B: Opaque tokens with introspection (common for APIs)

• Issue an opaque access token that references server-side state.
• On logout/termination: revoke the token in the authorization server.
• Resource servers validate via introspection or cached revocation status.

Pattern C: Signed self-contained tokens (JWT) with revocation

• JWTs are hard to “invalidate” without state.
• If you use JWTs as a session identifier, you need a server-side revocation strategy (denylist keyed by token ID, or a “session version” claim checked against a server-side user/session record).
• Pair with short token lifetimes and refresh-token rotation if your architecture supports it, but do not rely on expiry alone to satisfy “logout” invalidation.

Decision rule you can enforce as GRC: If the session identifier can be replayed, you need a server-side control that causes replay to fail after termination. ¹

3) Implement logout and termination handlers for all termination paths

Most gaps come from “logout button works, everything else doesn’t.”

Minimum implementation requirements:

• Explicit logout endpoint triggers server-side invalidation and returns a response that clears client cookies (Set-Cookie with Max-Age=0/Expires in past).
• Timeout termination results in server rejecting the session ID and requiring re-authentication.
• Admin actions (disable user, remove access, reset password) trigger immediate invalidation of active sessions for that user (global sign-out for that application).
• SSO edge cases: If the IdP logs the user out, your app’s session must also terminate where applicable. If single logout is not supported, document the limitation and implement compensating controls (short session TTL plus app-level forced reauth) while still meeting SC-23(1) for your app session. ¹

4) Add verification tests that prove invalidation works

Build repeatable tests for each app:

• Log in, capture session ID.
• Call logout.
• Replay the captured session ID against an authenticated endpoint.
• Expected result: denied (and no privileged action succeeds).

Include negative tests:

• Close browser without logging out; session should eventually terminate via timeout and be rejected after termination.
• Disable the user while session is active; replay should fail.

Make these tests runnable in CI for key applications and at least runnable on-demand for others.

5) Instrument logging so you can show evidence and detect abuse

Logging requirements (tune to your environment):

• Log logout events and termination reasons.
• Log session revocation/deletion actions.
• Log rejected requests due to revoked/expired session identifiers (without writing the full token value into logs).
• Retain correlation fields: user ID, session ID hash, timestamp, source IP, app, reason code.

This supports two needs: audit proof and incident response.

6) Assign control ownership and recurring evidence

Operationalize ownership:

• Control owner: AppSec, IAM, or Platform Engineering (pick one primary, then per-app implementers).
• Review cadence: verify configurations and rerun tests when auth/session libraries change, SSO changes, or major releases ship.

Daydream (as your GRC system) fits cleanly here: map SC-23(1) to the owner, link each application’s session lifecycle spec, and schedule recurring evidence collection (test output + sample logs + config snapshots). ¹

Required evidence and artifacts to retain

Keep evidence that demonstrates both design and operating effectiveness:

Design artifacts

• Session Lifecycle Spec per application (what is the session identifier, how it terminates, how invalidation works).
• Architecture diagram for auth/session flows (especially with SSO).
• Configuration snapshots:
  • Session store settings (TTL, invalidation behavior)
  • Cookie flags (HttpOnly/Secure/SameSite where applicable)
  • Token revocation configuration (if using an auth server)

Operating effectiveness artifacts

• Test cases and results showing replay fails after logout/termination (screenshots, CI logs, or test reports).
• Sample application logs showing logout and subsequent rejected replay attempts (token values redacted or hashed).
• Change tickets/PRs implementing invalidation handlers and review approvals.
• Exception register for any legacy systems, with compensating controls and a remediation plan.

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me a terminated session ID being rejected. Can you demo it?”
• “Does this work for admin-forced logout and user disablement?”
• “Are there any apps using JWTs with no revocation story?”
• “Do you rely on client-side cookie clearing only?”
• “How do you prevent session fixation or reuse across devices?”
• “How do you handle SSO logout versus app session logout?” ¹

Hangups that slow audits:

• No written definition of “session termination.”
• Evidence shows logout UI clears cookies, but server still accepts the token.
• Token values appear in logs (privacy/security concern) so teams refuse to provide logs.

Frequent implementation mistakes and how to avoid them

1. Only deleting the cookie on the client

• Fix: always revoke/delete server-side session state. Treat client cookie deletion as hygiene, not the control.

2. Missing non-interactive termination paths

• Fix: add hooks for password reset, user disable, role change, and timeout. Verify with tests.

3. JWT access tokens treated as sessions with no revocation

• Fix: add token revocation (denylist or session-version check) or redesign session handling for apps that need strict logout semantics.

4. Multiple session layers, only one is invalidated

• Example: IdP session ends, but app session remains valid.
• Fix: document session layers and invalidate the app session on logout regardless of IdP behavior.

5. No evidence that old IDs fail

• Fix: add a standard “replay after logout” test and retain outputs per release or per evidence cycle.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific enforcement actions.

Risk framing you can use internally: failure to invalidate session identifiers increases the likelihood of account takeover via token theft, replay, shared devices, compromised proxies, or malicious browser extensions. It also creates persistence after access removal (termination or role change), which is a common root cause in incident postmortems.

Practical 30/60/90-day execution plan

Use phases rather than date promises; delivery speed depends on app count and architecture complexity.

First 30 days (stabilize scope and prove one path)

• Assign a single control owner and named technical owners per application.
• Inventory applications and session mechanisms (cookie sessions, opaque tokens, JWTs).
• Pick one “high-risk” app (admin console or broad user base) and implement:
  • server-side invalidation on logout
  • replay-after-logout test
  • basic logs for logout and rejection
• Create a standard evidence bundle template in Daydream for SC-23(1): spec + test output + config snapshot + sample logs.

Days 31–60 (cover termination paths and SSO edge cases)

• Expand from logout to “other session termination” events: timeout, user disable, password reset.
• Align with IAM team on event triggers (SCIM/user lifecycle events) so access removal forces session invalidation.
• For SSO-integrated apps, document the boundary between IdP session and app session, and implement app-side invalidation regardless.

Days 61–90 (scale and make it repeatable)

• Roll the standard pattern across remaining applications.
• Add CI checks or release gates for critical apps (replay-after-logout test required).
• Formalize recurring evidence collection: on major releases and on a scheduled cadence, store artifacts in Daydream mapped to SC-23(1). ¹

Frequently Asked Questions

Does clearing the session cookie in the browser satisfy SC-23(1)?

By itself, no. You need server-side invalidation so the session identifier cannot be replayed after logout or termination. ¹

We use JWTs. How do we “invalidate” them at logout?

Add a server-side revocation mechanism (denylist by token ID, or a user/session version check) so the server rejects the token after logout. Expiration alone does not demonstrate invalidation on logout. ¹

What counts as “other session termination”?

Treat timeout, forced logout by admins, user disablement, credential changes, and access removal as termination events. Document your list per system and test at least the events that occur in your environment. ¹

Do we need global logout across all apps?

SC-23(1) focuses on invalidating the relevant session identifier for the system in scope when termination occurs. If you cannot do full single logout, document boundaries and ensure the app’s own session cannot be reused after termination. ¹

What evidence is strongest for auditors?

A replay-after-logout test result plus logs showing the old session ID (redacted/hashed) was rejected is usually decisive, backed by a short session lifecycle spec and config snapshots. ¹

How do we handle mobile apps that store tokens locally?

Clear local storage on logout, but also revoke the server-side session/token so a copied token cannot be replayed. Mobile logout must trigger the same invalidation path as web logout. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5