System & communications protection.
Boundary protection and cryptography for CUI in motion and at rest.
System & Communications Protection is 16 of Level 2’s 110 requirements — the second-largest family, after Access Control. It covers the boundary between a network and the outside world, how internal systems are segmented, and how CUI itself is protected by cryptography, whether it’s crossing a network or sitting on a drive. This page covers what SC specifically requires, including its one built-in POA&M exception.
This page explains the family. It does not replace the requirement text or assessment objectives.
01What this family protects
SC protects two related things: the boundary a system sits behind, and the confidentiality of CUI itself as it moves across networks or rests on storage. Where Access Control (AC) governs who may open a connection, SC governs what happens to the traffic and the data once that connection exists — whether it’s segmented from the rest of the network, encrypted, and protected against interception or tampering.
02The rule says
All 16 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.13 has the full text and discussion for each.
| § | Requirement |
|---|---|
| 3.13.1 | Monitor, control, and protect communications at the external boundaries and key internal boundaries of organizational systems. |
| 3.13.2 | Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. |
| 3.13.3 | Separate user functionality from system management functionality. |
| 3.13.4 | Prevent unauthorized and unintended information transfer via shared system resources. |
| 3.13.5 | Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. |
| 3.13.6 | Deny network communications traffic by default and allow network communications traffic by exception (deny all, permit by exception). |
| 3.13.7 | Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to external resources (split tunneling). |
| 3.13.8 | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission, unless otherwise protected by alternative physical safeguards. |
| 3.13.9 | Terminate network connections associated with communications sessions at the end of the session or after a defined period of inactivity. |
| 3.13.10 | Establish and manage cryptographic keys for cryptography employed in organizational systems. |
| 3.13.11 | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. |
| 3.13.12 | Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device. |
| 3.13.13 | Control and monitor the use of mobile code. |
| 3.13.14 | Control and monitor the use of Voice over Internet Protocol (VoIP) technologies. |
| 3.13.15 | Protect the authenticity of communications sessions. |
| 3.13.16 | Protect the confidentiality of CUI at rest. |
Level 2 POA&M items are normally limited to 1-point requirements, with exactly one named exception: SC.L2-3.13.11 may sit on a POA&M at its 3-point value when encryption is employed but is not yet FIPS-validated. If no encryption is employed at all, the point value is 5 and the requirement is not POA&M-eligible. 32 CFR 170.21(a)(2)(ii). See The Levels for the full POA&M mechanics.
03In practice
Boundary and segmentation (3.13.1, 3.13.3, 3.13.5, 3.13.6). A firewall at the network edge, a deny-all default posture with specific approved exceptions, publicly accessible systems (a web server, a customer-facing portal) isolated in their own segment, and administrative interfaces kept separate from ordinary user access.
Session and connection controls (3.13.7, 3.13.9, 3.13.12, 3.13.15). No split tunneling on remote-access devices, sessions that terminate after inactivity, no remotely-activated cameras or microphones without a visible indicator, and protection against man-in-the-middle interference on communications sessions.
Cryptography (3.13.8, 3.13.10, 3.13.11, 3.13.16). CUI gets encrypted in transit (3.13.8) and at rest (3.13.16) unless an equivalent physical safeguard is in place instead; keys get managed under a defined process (3.13.10); and where encryption is the chosen protection for CUI’s confidentiality, it has to be FIPS-validated (3.13.11) — not merely strong-looking, but validated against the specific NIST cryptographic module standard.
Code and application controls (3.13.2, 3.13.4, 3.13.13, 3.13.14). Secure design principles applied to systems built or substantially modified in-house; no information leaking between users through shared system resources; mobile code (browser scripts, similar technologies) and VoIP use both controlled and monitored rather than left to default settings.
04Where it fails
The usual stumble is calling something “encrypted” without knowing whether the specific implementation is FIPS-validated. Full-disk encryption is on, a cloud provider says data is encrypted at rest, a VPN uses a well-known protocol — and none of that answers 3.13.11’s actual question, which is about the validation status of the cryptographic module doing the work, not simply whether encryption exists in some form.
A second recurring gap is a flat network where a public-facing system (a marketing website, a customer portal) shares the same segment as internal systems that touch CUI, with no subnetwork separating the two — the kind of boundary mistake the Scope & Boundary page covers from the scoping side.
05What evidence may look like
Firewall and network-segmentation diagrams matching the actual environment; a FIPS validation certificate number or vendor documentation for the specific encryption module in use; VPN and remote-access configuration showing split tunneling disabled; a key-management procedure, even a short one; and configuration settings or policy documents for mobile-code and VoIP controls where those technologies are in use.
06At the shop
Blanchard Tool & Machining is the desk’s fictional composite (any resemblance to an actual company is coincidental). Blanchard found, during its internal review, that its file-share encryption used a strong cipher but hadn’t been validated against a specific FIPS 140 module — a gap the MSP hadn’t flagged because the encryption itself worked fine. Blanchard documented the gap in its SSP, opened a POA&M item at the 3-point value under the 3.13.11 exception, and moved to a FIPS-validated encryption product on a defined timeline, closing the item well inside the 180-day window.
07Commonly confused with
Access Control (AC). AC decides who may open a remote connection; SC decides how that connection and the data on it are protected once opened. See Access Control.
Identification & Authentication (IA). IA’s password-protection requirement (3.5.10) and SC’s cryptography requirements look similar but protect different things: IA protects credentials; SC protects CUI itself and the sessions carrying it. See Identification & Authentication.
“Encrypted” vs. “FIPS-validated.” The two are not the same claim. Strong, modern encryption that has not gone through FIPS validation does not satisfy 3.13.11 as implemented; it may still qualify for the requirement’s narrow POA&M exception while validation is pursued.
08Cross-desk links
Long-lived CUI — a technical drawing for a part with a decades-long service life, for example — raises a planning question beyond what 3.13.11 requires today: data encrypted now could be harvested and decrypted later if a future adversary gains sufficiently capable quantum computing. The lab’s Quantum program covers this “Harvest Now, Decrypt Later” (HNDL) awareness in depth. This is planning background, not a CMMC requirement — nothing in 32 CFR Part 170 or NIST SP 800-171 Revision 2 calls for post-quantum cryptography, and 3.13.11’s FIPS-validation bar is unaffected by it. See also The Data, section 06.
09Sources
| Document | What it’s for |
|---|---|
| NIST SP 800-171 Rev. 2, §3.13 | Full requirement text and discussion for all 16 SC requirements. |
| NIST SP 800-171A | Assessment objectives for each SC requirement. |
| 32 CFR 170.21(a)(2) | The Level 2 POA&M rule, including the SC.L2-3.13.11 exception at 3 points. |
| NIST Cryptographic Module Validation Program (CMVP) | Looking up whether a specific cryptographic module is FIPS-validated. |
| 32 CFR 170.4 | Defines “CMMC Level 2 security requirement” and ties the 800-171 R2 families to the CMMC Program. |