SC-23: Session Authenticity

Quick-reference card

What this control requires

SC-23 requires you to verify the identity of both endpoints in a communication session and protect the data exchanged from tampering. This control targets session-level protections, not individual packet inspection, and it demands mechanisms that guard against the insertion of false information throughout an active session.

In practice, meeting SC-23 means deploying protections that prevent adversary-in-the-middle attacks, session hijacking, and the injection of unauthorized data into established sessions. You need to ensure that session identifiers are generated with sufficient randomness, that transport channels use mutual authentication where appropriate, and that session tokens can’t be predicted, replayed, or stolen through cross-site scripting or insecure cookie handling.

The control exists because session-layer vulnerabilities create a gap between authenticated access and ongoing trust. A user might authenticate correctly at login, but if the session itself can be hijacked or manipulated after that point, the initial authentication becomes meaningless. SC-23 closes that gap by requiring organizations to treat session integrity as a continuous obligation, not a one-time gate.

Why it matters

Session authenticity failures sit at the intersection of access control and communications integrity, making them a high-severity finding in any NIST SP 800-53 audit. Assessors specifically evaluate whether communication sessions are protected against interception and manipulation, and a gap here can cascade into findings across related controls like non-repudiation and transmission integrity.

Failure to maintain SC-23 introduces audit risk and may result in certification withdrawal or regulatory findings. For organizations operating under FedRAMP moderate or high baselines, a deficiency in session authenticity protections can delay or block an authorization to operate (ATO). The control’s inclusion in both moderate and high baselines reflects how foundational this protection is considered across federal information systems.

Beyond compliance, unprotected sessions expose your organization to a class of attacks that bypass perimeter defenses entirely. An attacker who can intercept or forge session data doesn’t need credentials because they inherit the privileges of an already-authenticated user. Where this risk becomes acute is in environments with long-lived sessions or applications that don’t regenerate tokens after authentication, because the window for exploitation grows with every minute the session remains valid.

The following threat vectors are relevant to session authenticity failures:

• Adversary-in-the-middle attacks allow an attacker to intercept and alter communication between two parties who believe they’re communicating directly, undermining both confidentiality and integrity at the session layer
• Session hijacking occurs when an attacker takes over an active session by stealing or guessing a valid session token, gaining the authenticated user’s privileges without ever providing credentials
• Session fixation forces a user to authenticate using an attacker-controlled session identifier, giving the attacker access to the authenticated session after the user logs in
• Cookie theft through cross-site scripting extracts session tokens from a user’s browser, allowing an attacker to impersonate the victim in any application that relies on cookie-based session management
• Replay attacks capture and retransmit valid session data to impersonate a legitimate user or re-execute transactions, exploiting the absence of nonce-based or time-bound session validation

How to implement

The most common failure mode for SC-23 isn’t the absence of TLS or session tokens. It’s the configuration drift that accumulates over time: cipher suites fall behind current standards, session cookies lack secure flags, and mutual authentication gets deferred indefinitely for internal services.

For your organization

Start by ensuring that all communication sessions use transport layer security (TLS) 1.2 or higher, with TLS 1.3 preferred for new deployments. Configure your TLS implementation to disable weak cipher suites, enforce perfect forward secrecy, and validate certificates against a trusted certificate authority (CA) chain. NIST SP 800-52 provides detailed guidance on TLS configuration for federal systems.

Generate session identifiers using a cryptographically secure pseudorandom number generator (CSPRNG) with at least 128 bits of entropy. Session tokens should be unpredictable, unique per session, and invalidated immediately at logout or after a defined idle timeout. Session termination policies should complement SC-23 by ensuring abandoned sessions don’t remain exploitable.

Set the Secure, HttpOnly, and SameSite flags on all session cookies. The Secure flag prevents transmission over unencrypted channels. HttpOnly blocks client-side scripts from accessing the cookie. SameSite mitigates cross-site request forgery by restricting when the browser sends the cookie.

Implement mutual authentication for high-value or privileged sessions, where both the client and the server present certificates to verify each other’s identity. This approach eliminates the risk of connecting to a spoofed endpoint and is particularly important for machine-to-machine communication and administrative interfaces.

Bind session tokens to additional context such as the client’s IP address or user-agent string to detect session theft. If a session token appears from a different network location or browser fingerprint than the one that originally authenticated, the system should challenge the user to re-authenticate or terminate the session. This technique, sometimes called session binding, adds a layer of detection that complements the prevention mechanisms above.

Ensure your application regenerates session identifiers after any privilege escalation event, including login, role changes, and transitions from anonymous to authenticated states. Failing to regenerate tokens at these boundaries leaves the door open for session fixation attacks. Concurrent session limits should also be enforced to prevent an attacker from silently maintaining a hijacked session while the legitimate user continues working.

Common mistakes include allowing TLS fallback to older protocol versions, using default session timeout values that are too long, and neglecting to review session cookie configurations after application updates. Document your session management configuration and review it quarterly against current NIST guidance.

For your vendors

When evaluating a vendor’s compliance with SC-23, you need to verify that their systems protect session authenticity for any communication channel that touches your data. A vendor risk management platform can help you track this evidence systematically across your vendor portfolio.

Include the following questions in your security questionnaire:

• Do your systems enforce TLS 1.2 or higher for all sessions that process, store, or transmit our data?
• How are session identifiers generated, and what is the minimum entropy used?
• Are session cookies configured with Secure, HttpOnly, and SameSite flags?
• What is your session timeout policy, and do you regenerate session tokens after authentication events?
• Do you perform regular TLS configuration audits, and can you share the most recent results?

Request copies of their TLS configuration audit reports, session management policies, and any third-party penetration test results that specifically cover session-layer vulnerabilities. Look for evidence that the vendor monitors for certificate expiration and revocation. An attack surface management tool can help you verify externally visible TLS configurations across your vendor ecosystem without relying solely on self-reported evidence.

Red flags include vendors who can’t articulate their session management practices, those still supporting TLS 1.0 or 1.1, or organizations whose penetration test findings show unresolved session fixation or session hijacking vulnerabilities. Vendors who defer to “we use HTTPS” without demonstrating deeper session-level protections haven’t met the intent of SC-23. Also watch for vendors who can’t demonstrate session identifier invalidation at logout, as this gap directly contradicts the ongoing authenticity requirement of SC-23.

Evidence examples

Cross-framework mapping

Related controls

• AU-10 — Non-repudiation: provides evidence that communication actions occurred and can’t be denied, complementing session authenticity by ensuring accountability for data exchanged within authenticated sessions
• SC-08 — Transmission Confidentiality and Integrity: protects the content of communications during transmission, working alongside SC-23 to ensure that sessions are both authentic and encrypted
• SC-10 — Network Disconnect: terminates network connections at the end of a session or after a defined period of inactivity, reducing the window during which a session could be hijacked
• SC-11 — Trusted Path: establishes a protected communication channel between the user and the system for security-critical functions, providing a higher assurance path that builds on session authenticity protections

Frequently asked questions

What is NIST SP 800-53 SC-23

SC-23 is the NIST SP 800-53 control that requires organizations to protect the authenticity of communication sessions against interception, hijacking, and the insertion of false information. It applies to systems at both moderate and high baselines and focuses on session-level protections rather than individual packet integrity. Organizations meet this control by implementing mechanisms like TLS, cryptographically random session identifiers, and mutual authentication.

What happens if SC-23 is not implemented

Without SC-23 protections, communication sessions are vulnerable to adversary-in-the-middle attacks, session hijacking, and session fixation, all of which allow an attacker to impersonate an authenticated user. Assessors evaluating concurrent session controls and related requirements will flag the absence of session authenticity protections as a high-severity finding. For organizations pursuing FedRAMP authorization, an unresolved SC-23 deficiency can delay or prevent an authorization to operate.

How do you audit SC-23

Auditing SC-23 requires verifying that the organization’s TLS configuration, session identifier generation, and cookie security settings match documented policy. Assessors review session management policy documents, TLS audit records, and system design documentation that describes how session authenticity protections are implemented. They also look for penetration test results that specifically test for session hijacking, session fixation, and replay attack vectors to confirm that protections work under adversarial conditions.

How does TLS protect session authenticity

TLS protects session authenticity by encrypting the communication channel and verifying the server’s identity through certificate validation, preventing an attacker from intercepting or altering session data in transit. When configured with mutual authentication, TLS also verifies the client’s identity, establishing bidirectional trust for the session. Proper TLS implementation, including the use of current protocol versions and strong cipher suites, addresses the adversary-in-the-middle and session hijacking vectors that SC-23 is designed to mitigate.