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

Data in Transit

Submit your own example

Practice statement

Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.13.8.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(3)

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

  1. [a]

    cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;

    1 example covers this

  2. [b]

    alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and

    No example covers this objective yet. Submit your own example.

  3. [c]

    either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.

    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.8Data in Transit
    Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.

    • [a]

      cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;

    • [c]

      either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.

    Every CUI transmission path is cryptographically protected; no physical-safeguard alternative claimed

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

    Implementation

    AO coverage. Claims objectives [a] and [c] — identifying the cryptographic mechanisms and implementing them for CUI in transit. Objective [b] (identify alternative physical safeguards) is not claimed: this organization protects every CUI transmission path with cryptography and relies on no physical alternative such as a protected distribution system or hand-carried media, so there is nothing to identify. The SSP records that as an explicit determination rather than leaving the objective ambiguous, and the practice would need to be revisited if a courier path were ever introduced.

    Transmission paths enumerated. Four, and only four, are authorized: (1) email to approved partner domains, (2) the outbound SFTP drop to the prime, (3) browser upload to the government portal, (4) internal transfers between enclave systems. Anything else — consumer file-sharing links, personal email, unencrypted FTP — is blocked rather than discouraged.

    Mechanisms identified [a]. Each path is mapped in the crypto inventory to the mechanism protecting it: TLS 1.2+ with an approved cipher suite list for mail transport and both web paths; message-level encryption for CUI email so protection survives a downstream hop that negotiates poorly; SSH transport with key-based authentication and a pinned host key for SFTP; TLS between enclave services internally. The inventory records the module and version so it stays consistent with the FIPS-validated cryptography practice rather than duplicating it.

    Implementation [c]. The mail platform requires TLS for the partner domains and refuses to fall back to cleartext; a failed TLS negotiation queues and alerts rather than sending in the clear. Labeled CUI mail is auto-encrypted by policy, so the user is not the enforcement point. The SFTP client uses keys held in the secrets vault with no password fallback. TLS 1.0/1.1 and legacy ciphers are disabled on every listener the organization controls.

    Maintenance. Quarterly external TLS scan of the paths under organizational control. Monthly review of TLS-forced mail failures, which usually indicate a partner regression. Annual re-confirmation with contracts that the partner domain list is current.

    Accepted gap. One prime's older SFTP endpoint supports a narrower set of key exchange algorithms than the standard. The strongest mutually supported approved algorithm is pinned, the deviation is on the exception register with the vendor ticket, and the file is additionally encrypted at the archive level before transfer.

    What the evidence looks like

    • Enumerated CUI transmission paths with the mechanism protecting each
    • Crypto inventory entries for mail, web, and SFTP paths
    • Mail connector configuration showing forced TLS to partner domains and auto-encryption of labeled mail
    • External TLS scan output showing legacy protocols disabled
    • Exception register entry for the prime's older SFTP endpoint

    Environment

    OSC exchanging CUI with a prime by email, an SFTP drop, and browser upload to a government portal. No courier or protected-distribution paths.

    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.