- Current TLS everywhere with legacy protocol versions and weak ciphers disabled covers the transport half; session-token handling — secure cookies, short lifetimes, sound binding — covers the application half.
- Watch internal and legacy paths: session authenticity tends to hold at the browser edge and fail on the ten-year-old internal application.
03.13.15 — Session Authenticity
03.13 System and Communications Protection · NIST SP 800-171 Rev. 3
Requires protecting the authenticity of communications sessions — confidence that a session, once established, remains with the same parties and has not been hijacked or had traffic inserted into it.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗What this requirement is after
A session that starts authenticated must stay the same conversation: protection against hijacking, replayed tokens, and machine-in-the-middle insertion, so that 'still logged in' continues to mean 'still the same party.' Modern TLS and well-configured federation carry most of this; the real work is turning off the degraded modes that undercut them.
Brilliant at the Basics practices that support this requirement
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Implementation considerations and evidence
- TLS configuration baselines with weak versions and ciphers disabled
- Application session-management settings for in-scope systems
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
Where this came from in Rev. 2
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |