1Overview
SC.L2-3.13.15 protects communications sessions from being hijacked or forged. It requires that the authenticity of communications sessions be protected, so that a session between systems or users cannot be impersonated, injected into, or taken over by an attacker. It is a five-point requirement that cannot be deferred on a plan of action.
Encrypting a session protects its confidentiality, but authenticity is a distinct property: the assurance that the session is genuinely with the intended party and has not been hijacked or tampered with mid-stream. Attacks such as session hijacking and man-in-the-middle exploit weak session authenticity. This control requires protecting that authenticity, typically through mechanisms that establish and verify the identity of session endpoints and protect the integrity of the session, so a session cannot be forged or taken over. Its five-point weight reflects that a hijacked session can bypass the protections around it. The single assessment objective is that the authenticity of communications sessions is protected.
Protect the authenticity of communications sessions.
The requirement is to protect the authenticity of communications sessions. In practice this is achieved through session authentication and integrity mechanisms, such as authenticated and integrity-protected protocols like TLS with proper certificate validation, that ensure a session is with the genuine party and cannot be hijacked or injected into. The single assessment objective is that this authenticity is protected.
2The Assessment Objective
NIST SP 800-171A frames 3.13.15 as a single objective: protect the authenticity of communications sessions.
The authenticity of communications sessions is protected. Sessions cannot be forged, hijacked, or injected into.
The single objective is protecting session authenticity. The common gap is reliance on protocols or configurations that encrypt but do not adequately authenticate the session or protect its integrity. The assessor looks for mechanisms that protect the authenticity of sessions, not just their confidentiality.
3Failure Patterns
The failures are about sessions that can be forged or taken over.
No session authentication
Sessions without endpoint authentication can be impersonated. Authenticating the session parties protects its authenticity.
Weak certificate validation
Encrypted sessions that do not properly validate certificates are open to man-in-the-middle attacks. Proper validation protects authenticity.
Session integrity not protected
Sessions whose integrity is not protected can be injected into mid-stream. Integrity protection keeps the session genuine throughout.
4Ownership
This is an IT and network-owned technical control.
| Role | Responsibility for this control |
|---|---|
| IT and network | Implements session authentication and integrity protection. Owns the configuration evidence. |
| System architects | Select protocols and configurations that protect session authenticity. |
| Security or compliance lead | Confirms session authenticity is protected across communications. |
5Tooling
The control is delivered by authenticated, integrity-protected session protocols.
| Objective | Tooling | What it provides |
|---|---|---|
| authenticate | TLS with certificate validation, mutual authentication | Verified session endpoints. |
| protect integrity | Integrity-protected session protocols | Sessions that cannot be injected into or hijacked. |
The caveat is that the mechanisms have to protect authenticity, not merely confidentiality. Encrypted sessions with weak authentication or certificate validation remain open to hijacking. The assessor examines whether session authenticity is protected, so the authentication and integrity mechanisms have to hold.
6Evidence
The satisfied version of 3.13.15 shows protected session authenticity.
| Evidence | What it demonstrates |
|---|---|
| Session protocol configuration | The objective. Sessions authenticated and integrity-protected. |
| Certificate validation settings | The objective. Session endpoints verified. |
The evidence should show communications sessions protected through authentication and integrity mechanisms. The session protocol configuration together with certificate validation settings is the clearest demonstration, and because this control cannot sit on a plan of action, the protection has to be real at the time of assessment.
A private session can still be a forged one
Encryption hides a session's contents but does not prove who is on the other end, so this five-point control asks that session authenticity be protected against hijacking and impersonation. Implementing authenticated, integrity-protected sessions is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.13.15. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objective 3.13.15. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing SC.L2-3.13.15 among the five-point derived security requirements. ecfr.gov