SC-23(2): User-initiated Logouts and Message Displays

SC-23(2): User-initiated Logouts and Message Displays requires you to provide a user-driven logout capability and present clear logout-related messages so users can reliably end sessions and understand session state. Operationalize it by standardizing logout UX, invalidating tokens on logout, and retaining test evidence that logout actions terminate authenticated access as designed. ¹

Key takeaways:

• Define “logout” as a security event: terminate session state, revoke tokens where feasible, and clear client-side auth artifacts.
• Make logout visible and unambiguous: users should see an explicit confirmation and be guided on next steps (e.g., close browser on shared devices).
• Evidence wins audits: keep UI screenshots, config snippets, and test results proving logout works across web, mobile, and SSO flows.

A “logout” button that only redirects to a landing page is a common control gap. SC-23(2): user-initiated logouts and message displays is aimed at the real operational risk: users think they ended access, but sessions, tokens, or cached credentials still grant entry, especially on shared workstations, kiosks, VDI, and mobile devices. Your job is to make logout both technically effective and operationally clear to the user.

This requirement shows up most often during federal assessments and contractor due diligence because it’s easy to test, easy to misunderstand, and often inconsistent across applications. Web apps may implement logout differently than mobile apps; SSO adds complexity; API tokens can outlive browser sessions; and “Remember me” features can undermine user expectations.

This page gives you requirement-level implementation guidance you can hand to engineering and IAM teams: scope what systems are in-bounds, define what “user-initiated logout” means in your environment, implement consistent UI and message patterns, validate session termination in the real flows auditors test, and retain the artifacts assessors ask for. ²

Requirement: sc-23(2): user-initiated logouts and message displays requirement (plain-English)

SC-23(2) expects two things to work together:

1. Users can initiate a logout without needing admin help or obscure steps.
2. The system displays messages related to logout/session state so the user can tell what happened (for example, “You have been signed out,” and guidance appropriate to the context). ¹

In practice, treat this as a combined UX + security state control: the user must be able to end their authenticated session, and the system must communicate the outcome clearly enough to prevent mistaken assumptions.

Regulatory text

The source requirement is defined as “NIST SP 800-53 control SC-23.2.” ¹

Operator translation (what you must do):

• Provide an explicit, user-accessible logout function for in-scope systems.
• On logout, display a clear message indicating the user is logged out (and any additional steps if needed for shared devices or federated sign-out).
• Make logout actually terminate access by removing or invalidating session artifacts in your architecture (server sessions, cookies, refresh tokens, device tokens, or SSO sessions as applicable). Map the requirement to an owner and recurring evidence so you can prove it repeatedly, not once. ¹

Who it applies to (entity + operational context)

Entities:

• Federal information systems and contractors handling federal data commonly scope to NIST SP 800-53 controls. ²

Systems and contexts to include:

• Web applications with authenticated sessions (including admin portals).
• Mobile applications that store tokens locally and support biometric re-auth.
• SSO/federated apps (SAML/OIDC) where “logout” can mean local app sign-out, IdP sign-out, or both.
• VDI, kiosks, shared workstations, and call-center terminals where user confusion about logout creates direct exposure.
• APIs and CLIs if you provide long-lived tokens tied to interactive users.

Typical control owners: IAM lead, application security, platform engineering, and the product owner for authentication UX. Compliance/GRC owns the requirement mapping and evidence cadence.

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

Step 1: Define “logout” for each authentication pattern

Create a short standard that engineers can follow per pattern:

Pattern	Minimum “logout” behavior	Message display requirement
Server-side session (traditional web)	Destroy server session; expire session cookie	“Signed out” confirmation page
SPA + access/refresh tokens	Clear tokens in memory/storage; revoke refresh token if supported; rotate session identifiers	“Signed out” plus warning if other tabs remain
Mobile app	Clear tokens/secure storage entries; disable offline access if tied to auth; require re-auth	“Signed out” plus next-step (close app on shared device)
SSO (OIDC/SAML)	End app session; initiate IdP logout where feasible; document limitations	Message clarifying local vs federated sign-out

Keep it opinionated. Auditors test the common case and the edge case (“back button,” second tab, cached API calls).

Step 2: Standardize the UI placement and wording

Implementation expectations become messy when each app invents its own logout experience.

Minimum UX standards you can require:

• Logout is reachable from every authenticated page (header/menu).
• Logout label is explicit (“Sign out” / “Log out”), not buried under “Account settings.”
• After logout, landing page is non-authenticated and cannot display sensitive user data from cache.
• Message text is consistent and plain: “You’re signed out.” Add context-specific guidance for shared devices.

Capture these standards in your secure SDLC requirements so they land in backlog templates and acceptance criteria.

Step 3: Implement real session termination (don’t stop at redirect)

Engineers should implement a logout handler that:

• Invalidates server-side sessions (delete session record; rotate session key).
• Expires cookies (set Max-Age=0/Expires in past; correct path/domain).
• Revokes refresh tokens when your IdP or auth server supports it.
• Clears local storage/secure storage for SPA/mobile tokens.
• Prevents replay: if a token is presented after logout, the backend rejects it.

If you cannot revoke certain token types (for example, stateless JWT access tokens), document the residual risk and mitigate by shortening token lifetimes and limiting scopes. Keep the explanation in your system security plan or control narrative so assessors see you understand the tradeoff.

Step 4: Cover the flows auditors actually test

Build test cases (manual or automated) that reflect real usage:

• Basic: login → navigate → logout → attempt to access authenticated URL directly.
• Back button: logout → browser back → ensure content does not reappear (or reauth required).
• Multi-tab: open two tabs → logout in one → refresh the other → confirm signed-out state.
• SSO: logout from app → confirm app session ended; if IdP logout is not global, confirm messaging clarifies what ended.
• Mobile: logout → force-close app → reopen → confirm reauth required.

Document expected results. Run them per release for high-risk apps, and at a defined cadence for others.

Step 5: Operationalize ownership, evidence, and recurring checks

SC-23(2) often fails in audits because teams can’t prove consistency across systems.

Do these two governance tasks:

• Create an application inventory field: “Logout implemented per standard (Y/N), pattern type, last tested date.”
• Assign a control operator who collects evidence per cycle and follows up on drift (new apps, new auth flows, IdP migrations).

Daydream (or your GRC system) fits here as the system of record: map SC-23(2) to control owners, store standard test scripts, attach screenshots/configs, and generate a recurring evidence task that aligns with your release cadence. ¹

Required evidence and artifacts to retain

Keep evidence that demonstrates both capability and operation:

1. Policy/standard

• Secure SDLC requirement or auth standard defining logout behavior and required messages.
• UX copy guidelines for logout message text.

2. System-level implementation

• Screenshots of logout UI placement and logout confirmation page.
• Configuration snippets: session management settings, token revocation endpoints, IdP logout configuration.
• Architecture note showing where sessions/tokens are invalidated.

3. Testing/operation

• Test cases + dated results (manual QA checklist, automated test output, or security test report).
• Defect tickets for failures and proof of remediation.
• Change records when auth/SSO components are updated.

4. Scope clarity

• Inventory of in-scope applications and their auth pattern classification.

Common exam/audit questions and hangups

Expect these questions:

• “Show me how a user logs out, and what message they see.” (Have screenshots ready.)
• “After logout, can I revisit a deep link and still see data?” (Demonstrate with a live test or recorded runbook.)
• “What happens to refresh tokens and active sessions?” (Explain revocation/invalidation strategy.)
• “How do you handle SSO logout?” (Clarify local app logout vs IdP global logout; show message copy.)
• “How do you ensure consistency across applications?” (Point to standards, inventory, and recurring evidence tasks.)

Hangup to anticipate: assessors may treat “logout” as a control that must terminate all sessions across devices. If your architecture cannot support that globally, document what you do support ¹ and how you communicate it to users.

Frequent implementation mistakes and how to avoid them

1. Redirect-only logout
   Fix: ensure server-side session/token invalidation happens before redirect.

2. Clearing cookies but leaving refresh tokens valid
   Fix: revoke refresh tokens on logout when feasible; otherwise reduce refresh token persistence and document.

3. Logout works in one tab but not another
   Fix: implement session checks on each request; for SPAs, add a “session invalidated” handler that forces reauth.

4. Misleading message displays (“You are logged out” while SSO session persists)
   Fix: adjust copy to reflect reality: “Signed out of this application” plus “Close your browser on shared devices.”

5. No evidence trail
   Fix: make logout testing a recurring control activity with stored artifacts and change linkage.

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this specific enhancement, so treat this as an assessment and breach-exposure issue rather than a control with named case law in this packet. ¹

Risk implications to explain internally:

• Shared-device exposure if a session remains valid after a user believes they logged out.
• Account takeover blast radius if refresh tokens remain active after sign-out.
• Audit findings for inconsistent logout behavior across in-scope systems.

Practical 30/60/90-day execution plan

First 30 days (stabilize + scope)

• Name a control owner for SC-23(2) and define in-scope systems (apps, mobile, SSO flows).
• Publish a one-page logout standard by auth pattern (web session, SPA tokens, mobile, SSO).
• Collect baseline evidence for your top-risk apps: screenshots, config, and one test run per flow.

Day 31–60 (implement + test)

• Fix the highest-risk gaps: redirect-only logouts, stale refresh tokens, cached sensitive pages post-logout.
• Add QA test cases for back button, multi-tab, and deep-link access after logout.
• Standardize logout message text and placement across your main apps.

Day 61–90 (operationalize + prevent drift)

• Add logout checks to SDLC acceptance criteria and security review checklists.
• Build an evidence cadence ¹ and store artifacts centrally.
• Update your application inventory with logout pattern type and last validated date; track exceptions with compensating controls and documented rationale.

Frequently Asked Questions

Do we need “global logout” across all devices for SC-23(2)?

Implement user-initiated logout that reliably ends the session in the system being used, and clearly message what was ended. If you cannot invalidate all device sessions, document the limitation and ensure the message display does not imply global sign-out. ¹

For SSO, is logging out of the app enough?

Often yes for the application session, but users can misinterpret it as logging out of the identity provider. Add message text that clarifies whether the IdP session remains active and, where feasible, implement IdP logout flows. ²

How do we handle stateless JWT access tokens that can’t be revoked?

Treat logout as revoking the refresh token and ending the app session, then mitigate JWT replay risk through shorter token lifetimes and tighter scopes. Record this design choice in your control narrative and architecture documentation. ²

What evidence is usually enough to pass an assessment?

Provide the logout standard, UI screenshots, configuration proof of session/token invalidation, and dated test results showing post-logout access is blocked. Tie the evidence to the in-scope system inventory so assessors can see coverage. ¹

Does an “idle timeout” satisfy SC-23(2)?

No. Idle timeout supports session management, but SC-23(2) is about a user-initiated logout action and the related message display. Implement both if your risk profile includes unattended sessions. ¹

We have multiple products; how do we keep logout consistent?

Set a baseline logout pattern per auth type, publish approved message text, and require product teams to attach logout test evidence at release. Track compliance in a central system so new apps do not drift from the standard. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5