Skip to content
ControlVerdict
Sign in
SC.L2-3.13.15CMMC Level 2Level 2

Communications Authenticity

Submit your own example

Practice statement

Protect the authenticity of communications sessions.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.13.15.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(1)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    the authenticity of communications sessions is protected.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    SC.L2-3.13.15Communications Authenticity
    Protect the authenticity of communications sessions.

    • [a]

      the authenticity of communications sessions is protected.

    Both ends prove who they are: validated TLS for people, mutual TLS and pinned keys for machines

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses the single Communications Authenticity objective for the session types in scope: user-to-application, application-to-application, and administrative.

    User-to-application. Sessions ride TLS 1.2+ with full certificate validation; clients do not have validation-disabling flags, and no internal tool ships with a “skip certificate check” default. Federated sign-in uses signed SAML assertions or OIDC tokens with audience and issuer validation, short token lifetimes, and rejection of unsigned or algorithm-downgraded assertions. Session cookies are issued with Secure, HttpOnly, and SameSite attributes, and a new session identifier is issued on authentication so a pre-login identifier cannot be fixated.

    Application-to-application. The B2B API uses mutual TLS: the prime validates our client certificate and we validate theirs against a pinned issuer, so possession of a bearer token alone is not sufficient to impersonate either side. The client certificate lives in the HSM-backed vault. Webhook callbacks are signature-verified rather than trusted by source address, and requests carry a timestamp and nonce so a captured call cannot be replayed.

    Scheduled file transfer. SFTP jobs pin the supplier host keys; an unexpected host key fails the job and pages rather than prompting for acceptance. Authentication is key-based, so there is no password to phish or replay.

    Administrative and network sessions. Administrative access uses phishing-resistant authentication, which is replay-resistant by construction. The site-to-site tunnel authenticates peers with certificates rather than a pre-shared key. DNSSEC validation is enabled on resolvers where the zones support it, and SPF, DKIM, and DMARC are enforced so mail claiming to be from the organization can be authenticated by recipients.

    Maintenance. Quarterly external TLS scan confirming certificate chains and protocol versions. Pinned issuer and host-key values are reviewed before any counterparty certificate renewal, coordinated through the integration contact list. Annual review of token lifetimes and assertion validation settings after IdP feature changes.

    Accepted gap. One supplier's SFTP endpoint rotates host keys without notice. That job pins the key but treats a change as a hold-and-verify event: the transfer stops, an operator confirms the new fingerprint with the supplier out of band, and only then is the pin updated. This trades some availability for authenticity and is documented as a deliberate choice.

    What the evidence looks like

    • TLS configuration and scan output for each session type under organizational control
    • Mutual TLS configuration for the B2B API, including the pinned issuer
    • SFTP job configuration showing pinned host keys and key-based authentication
    • IdP assertion and token validation settings (signing, audience, lifetime)
    • Hold-and-verify record from a supplier host-key change

    Environment

    CUI applications behind SSO, one B2B API integration with a prime, and scheduled SFTP jobs to two suppliers.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.