Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
3.13.15OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.13.15 — Session authenticity

3.13 System and Communications Protection · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Protect the authenticity of communications sessions.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Communications sessions must be authentic end to end: each side stays confident about who it is talking to for the life of the session, defeating hijacking, replay, and man-in-the-middle insertion. In practice this is TLS done properly, plus session handling that cannot be stolen cheaply.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: The modern federated protocols the MFA rollout standardizes on — OIDC and SAML over TLS, with signed, time-limited assertions — protect the authenticity of the authentication sessions they establish, resisting hijacking and assertion replay on the paths the rollout converts.

What this does not claim: May partially address the requirement. Session authenticity spans every communications session in the boundary — TLS configuration, certificate validation, and session handling for applications, services, and infrastructure the identity rollout never touches — and post-authentication token theft remains a live attack the base protocols do not stop; token protection and session policy are separate work.

Practice-side activities
  • Standardize applications on federated SSO with signed assertions
  • Shorten token lifetimes and apply conditional session policies for sensitive applications
Evidence this produces
  • Identity-provider session and token policy exports
  • SSO protocol configuration showing assertion signing

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Run current TLS with valid certificates on every in-scope service — including internal ones, where self-signed sprawl quietly trains users to click through warnings.
  • Session management is the second half: signed tokens, short lifetimes, and invalidation on logout for the applications the organization operates.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • TLS configuration and certificate inventory for in-scope services
  • Application or identity-provider session policy exports

Suggested owners, derived from the mapped practices and artifacts: Identity administrator. Ownership is a named person in your organization, not a role on a website.

Artifacts

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.

The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated