SC-23 Session Authenticity

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Moderate, High	System	3 (0 in a baseline)

Related controls: AU-10, SC-8, SC-10, SC-11

Control statement

Protect the authenticity of communications sessions.

NIST discussion

Protecting session authenticity addresses communications protection at the session level, not at the packet level. Such protection establishes grounds for confidence at both ends of communications sessions in the ongoing identities of other parties and the validity of transmitted information. Authenticity protection includes protecting against “man-in-the-middle” attacks, session hijacking, and the insertion of false information into sessions.

Control enhancements

SC-23(1) Invalidate Session Identifiers at Logout

Baselines: Not in a baseline

Invalidate session identifiers upon user logout or other session termination.

Discussion and assessment objectives for SC-23(1)

Invalidating session identifiers at logout curtails the ability of adversaries to capture and continue to employ previously valid session IDs.

Determine if session identifiers are invalidated upon user logout or other session termination.

Examine: System and communications protection policy; procedures addressing session authenticity; system design documentation; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities.

Test: Mechanisms supporting and/or implementing session identifier invalidation upon session termination.

SC-23(3) Unique System-generated Session Identifiers

Baselines: Not in a baseline

Generate a unique session identifier for each session with [Assignment: organization-defined randomness requirements] and recognize only session identifiers that are system-generated.

Discussion and assessment objectives for SC-23(3)

Generating unique session identifiers curtails the ability of adversaries to reuse previously valid session IDs. Employing the concept of randomness in the generation of unique session identifiers protects against brute-force attacks to determine future session identifiers.

Determine if:

• SC-23(03)[01] a unique session identifier is generated for each session with [Assignment: organization-defined randomness requirements];
• SC-23(03)[02] only system-generated session identifiers are recognized.

Examine: System and communications protection policy; procedures addressing session authenticity; system design documentation; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities.

Test: Mechanisms supporting, implementing, generating, and monitoring unique session identifiers; mechanisms supporting and/or implementing randomness requirements.

SC-23(5) Allowed Certificate Authorities

Baselines: Not in a baseline

Only allow the use of [Assignment: organization-defined certificated authorities] for verification of the establishment of protected sessions.

Discussion and assessment objectives for SC-23(5)

Reliance on certificate authorities for the establishment of secure sessions includes the use of Transport Layer Security (TLS) certificates. These certificates, after verification by their respective certificate authorities, facilitate the establishment of protected sessions between web clients and web servers.

Determine if only the use of [Assignment: organization-defined certificated authorities] for verification of the establishment of protected sessions is allowed.

Examine: System and communications protection policy; procedures addressing session authenticity; system design documentation; system configuration settings and associated documentation; list of certificate authorities allowed for verification of the establishment of protected sessions; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities.

Test: Mechanisms supporting and/or implementing the management of certificate authorities.

Withdrawn enhancements: SC-23(2), SC-23(4).

Assessment objectives (SP 800-53A)

Objectives and methods for SC-23

Determine if the authenticity of communication sessions is protected.

Examine: System and communications protection policy; procedures addressing session authenticity; system design documentation; system configuration settings and associated documentation; system audit records; system security plan; other relevant documents or records.

Interview: System/network administrators; organizational personnel with information security responsibilities.

Test: Mechanisms supporting and/or implementing session authenticity.

Policy statement

• The System owner shall ensure the system protects the authenticity of communications sessions. (SC-23)

From the System and Communications Protection Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

SC-23 asks you to protect communications sessions as a whole, so that both ends can trust, for the whole session, who is on the other end and that what arrives is what was sent. NIST’s discussion says it works at the session level, not the packet level, and protects against machine-in-the-middle attacks, session hijacking and the insertion of false information into sessions. In practice it has two parts: an authenticated, protected channel, and a session identifier that an attacker cannot guess, steal or reuse. SC-23 is in the Moderate and High baselines, not Low.

Common implementations.

• TLS for every session, with the server’s certificate validated by the client against approved trust anchors (SC-17), and mutual TLS where services call each other. The encryption and key management standard sets the approved protocols for each kind of connection and requires clients to validate certificates; it cites NIST SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (August 2019), for TLS settings. NIST’s planning note of May 7, 2026 says the publication is being reviewed (as of October 2026).
• Session management in web applications and APIs built on the application framework’s tested session handling rather than custom code.

NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (July 2025), section 5, is NIST’s most specific guidance on sessions that follow authentication. Its section 5.1 requires session secrets that are:

• Generated by the session host in direct response to an authentication event, so a new secret at login rather than one carried over from before it, from an approved random bit generator, and at least 64 bits long
• Erased or invalidated when the user logs out, and not accepted after the session’s time limits
• Sent only over an authenticated protected channel and unavailable to intermediaries, with no fall back from HTTPS to HTTP after authentication

It also requires a session identifier in POST and PUT content, which the relying party verifies, against cross-site request forgery. Session cookies must be marked Secure, scoped to the fewest host names and paths, and should be HttpOnly, SameSite Lax or Strict, and hold only an opaque identifier (section 5.1.1). Session secrets should not be kept in browser local storage, where cross-site scripting can reach them. Set inactivity and overall time limits by assurance level from SP 800-63B-4 and keep them in step with AC-12 and SC-10.

Organization-defined parameters. SC-23 has no parameters. In the System and Communications Protection policy, the system owner ensures the system protects the authenticity of communications sessions.

Evidence assessors ask for.

• A TLS scan of the system’s endpoints, internal as well as external, showing approved protocols and valid certificates
• The application’s session management design or configuration: how identifiers are generated, their length, cookie attributes, timeouts and what happens at logout
• A demonstration: after logout, replaying the old session cookie fails
• Penetration test or application scan results covering session handling, such as fixation, cross-site request forgery and cookie flags
• The system security plan’s description of session timeouts, which SP 800-63B-4 section 5.2 asks agencies to record

Inheritance. TLS at a load balancer, content delivery network or API gateway is often provided by a platform team or cloud provider, and single sign-on sessions by the identity provider; record what is inherited in the system security plan. Each application owns its own session handling, so SC-23 is almost always a hybrid control.

Common findings.

• Session cookies without the Secure or HttpOnly attribute.
• Logout that clears the cookie in the browser but leaves the session valid on the server.
• The same session identifier before and after login.
• Internal service-to-service traffic over plain HTTP, or clients that skip certificate validation.

Enhancements in the Moderate baseline. SC-23 has no enhancements in any baseline. SC-23(1) invalidating session identifiers at logout, SC-23(3) unique system-generated session identifiers and SC-23(5) allowed certificate authorities are in no baseline; SP 800-63B-4 section 5.1 already requires the first two for sessions that follow authentication, so a system that meets it meets them in practice. SC-23(2) and SC-23(4) are withdrawn.

Federal systems (as of October 2026). CISA Binding Operational Directive 18-01, Enhance Email and Web Security (October 16, 2017), requires publicly accessible federal websites and web services to provide service only over HTTPS with HTTP Strict Transport Security; CISA’s page does not mark it revoked. OMB M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles (January 26, 2022), Section III.C, extends this inside the agency: agencies must enforce HTTPS for all web and application programming interface traffic in their environment. The encryption and key management standard’s federal block carries BOD 18-01 but not yet M-22-09.

Artifacts

• System and Communications Protection Decision Worksheet
• System and Communications Protection Policy