Data in Transit

Official Source Material

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

Determine if:

[a] cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified;
[b] alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified; and
[c] either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.

Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024

Practitioner Guidance

How to meet it

Inventory the paths CUI travels, then name the mechanism on each.

Objective [a] is a list of the ways CUI (Controlled Unclassified Information) moves: email, file transfer, cloud sync, remote access, site-to-site links, scanner-to-server traffic. Give every path a cryptographic mechanism. TLS, the standard encryption protocol for internet connections, at version 1.2 or newer covers nearly all of them, and [c] becomes the configuration evidence per path. The path you never identified is the one the assessor finds.

The module must be validated, not just the algorithm.

CUI in transit outside your protected environment needs FIPS-validated cryptography: encryption tested and certified under the government's FIPS 140 program. Validation attaches to the cryptographic module, the software or hardware running the algorithm, not to the algorithm itself. On Windows, enable FIPS mode so TLS rides the operating system's validated modules, and verify each module's certificate on the NIST Cryptographic Module Validation Program list. SC.L2-3.13.11 carries the full validation story. This requirement is where transmission inherits it.

Email is the path that fails quietly.

Ordinary email negotiates opportunistic TLS, encryption used only when the receiving server supports it, and delivers anyway when the far end cannot. So you cannot show [c] for CUI sent to arbitrary recipients. Force TLS to the partner domains you exchange CUI with. Or encrypt the file itself with a FIPS-validated tool before attaching it. Or move the exchange to a controlled channel such as a secure file transfer service. Pick one answer per counterparty and write it down.

Physical safeguards are the narrow alternative, and radio is never one.

Objective [b] exists for the protected distribution system case: cabling protected against interception inside a controlled facility. It shelters unencrypted traffic on a wired segment inside your physical boundary. It never covers wireless, because the signal leaves the building no matter what the walls do.

What falls short

Opportunistic TLS on email offered as the mechanism for CUI sent to arbitrary recipients. Delivery falls back to unprotected transmission when the receiving server fails the handshake, so implementation under [c] cannot be shown for that path.
Office WiFi carrying CUI without FIPS-validated wireless encryption, justified as being inside the building. Wireless transmission is not protected by physical safeguards, and access points running unvalidated encryption leave the path uncovered.

Edge cases

The assessment guide allows compensating safeguards or an explicit acceptance of risk where commodity carrier links, such as carrier-separated MPLS, cannot offer cryptographic assurance. Encrypt the link anyway when you can: the exception is narrow, software-defined WAN products do not inherit it, and an encrypted tunnel ends the argument.
Legacy equipment that cannot speak modern protocols, such as older CNC machines, belongs on an isolated wired segment inside your physical boundary, where the alternative physical safeguard genuinely applies. Move CUI to and from that equipment under controlled procedures.