CMMC NUGGET #18

Data Encryption Requirements

Let’s clear this up immediately: SHA-256 is not an encryption standard. It’s a hashing algorithm. Encryption is reversible with the right key; hashing is not reversible at all, and that’s by design. SHA-256 exists to verify that data hasn’t been tampered with (integrity) and to support digital signatures, it has nothing to do with protecting confidentiality. If SHA-256 is doing your “encryption,” your CUI has no cover at all, its true identity is fully readable, just fingerprint-stamped so you’d know if someone altered it. Useful tool, wrong job description.

SC.L2-3.13.11: The Master Clearance – Employ FIPS-validated cryptography to protect the confidentiality of CUI

This is the control that governs every other encryption requirement in this nugget. Think of it as the background check every cryptographic implementation has to pass before it’s allowed anywhere near CUI.

Here’s the distinction that catches almost everyone: FIPS-compliant is not the same as FIPS-validated.

• FIPS-compliant means your implementation uses an algorithm defined in a FIPS standard, like AES-256, defined in FIPS 197.
• FIPS-validated means the specific cryptographic module implementing that algorithm has been tested and certified under FIPS 140-2 or FIPS 140-3 by an accredited lab, and appears on NIST’s Cryptographic Module Validation Program (CMVP) list.

An organization can run textbook AES-256 and still fail this control if the software module doing the encrypting was never validated. That’s the equivalent of carrying a badge that looks official but was never actually issued by headquarters.

Before your assessment, check every encryption implementation in your environment against the CMVP database: csrc.nist.gov/projects/cryptographic-module-validation-program. Commonly validated implementations include Windows CNG, certain OpenSSL builds running in FIPS mode, and hardware security modules from major vendors, but validation is version-specific, so verify your exact product version, not just the product family.

SC.L2-3.13.8: Cover for Data on the Move -Implement Cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards

Data in transit is data exposed. Every network hop is a chance for interception, so if it travels encrypted or isn’t otherwise physically protected, it doesn’t travel through your CUI environment.

• TLS 1.2 minimum, TLS 1.3 preferred, for all network communications involving CUI. TLS 1.2 is acceptable only when configured with FIPS-approved cipher suites (no RC4, DES, 3DES, or export-grade ciphers), and the underlying TLS module performing the encryption must itself be FIPS-validated per SC.L2-3.13.11, cipher suite selection and module validation are two separate checks, and both are required.
• VPNs used for remote access to CUI systems need strong encryption, IKEv2 with AES-256 is the current standard for IPsec implementations (see Nugget #12 for the full remote access picture).

SC.L2-3.13.16: The Safehouse – Protect the confidentiality of CUI at rest

Data sitting still is still a target. This control requires encryption for CUI wherever it’s parked, on servers, endpoints, or storage systems.

• AES-256 applied consistently and transparently across storage solutions
• Full-disk encryption on any device storing CUI, especially mobile and removable devices, since a lost or stolen laptop with unencrypted storage is a full breach, not a close call
• Cloud storage needs its own briefing here. FedRAMP Moderate authorization for the underlying platform is necessary but not sufficient. You also need clarity on who controls the encryption keys, customer-managed keys (CMK) give you direct control and audit visibility; provider-managed keys leave that control with the vendor. Document which model your environment uses and make sure it matches what your SSP claims.

SC.L2-3.13.10: Key Management, or, Who Gets to Know the Combination – Establish and manage cryptographic keys for cryptography employed in organizational systems

Encryption is only as strong as the discipline around who holds the keys.

• Implement a Key Management System aligned with NIST SP 800-57, covering key generation, storage, rotation, and access
• Store keys securely and rotate them on a defined schedule, not “whenever someone remembers”
• Separate the roles. The people who manage keys shouldn’t be the same people who can unilaterally use them without oversight. This is the same separation-of-duties principle from AC.L2-3.1.4 (Nugget #16), applied to your cryptographic vault instead of your access list.

RSA with a 2048-bit minimum key length is still the accepted floor for digital signatures and key exchange under current NIST guidance. Treat it as a floor, not a destination.

Post-quantum cryptography is not a current CMMC Level 2 assessment requirement under NIST SP 800-171 Rev 2. However, NIST SP 800-171 Rev 3 updates the cryptographic requirements to align with current NIST standards, and the finalization of FIPS 203, 204, and 205 in 2024 signals the direction. Organizations should track NIST’s post-quantum guidance as part of their cryptographic planning, particularly as DoD provides transition timelines from Rev 2 to Rev 3

Two encryption-adjacent controls got full treatment elsewhere and don’t need repeating, just a pointer:

• MP.L2-3.8.6 (encrypting CUI on digital media during transport) – Nugget #17
• MP.L2-3.8.9 (protecting backup CUI confidentiality) – also in Nugget #17. One addition worth noting here for cloud backups specifically. Apply the same customer-managed vs. provider-managed key question raised above under SC.L2-3.13.16.

SC.L2-3.13.11 Strong algorithm in use, but the cryptographic module itself was never FIPS-validated
SC.L2-3.13.8 TLS 1.2 enabled but configured with deprecated or weak cipher suites
SC.L2-3.13.16 Cloud storage encrypted, but no documentation of who controls the keys
SC.L2-3.13.10 No formal key rotation schedule; key management and key use not separated by role

SC.L2-3.13.11 should be documented first in your SSP’s encryption section as the governing requirement, with 3.13.8, 3.13.10, and 3.13.16 following as its operational expressions. Cross-reference MP.L2-3.8.6 and MP.L2-3.8.9 rather than duplicating them.

For each control your SSP should document:

• The specific cryptographic module and its CMVP validation status
• The policy governing key management, rotation schedule, and role separation
• Who owns encryption implementation and verification
• How compliance is verified, including how often CMVP status is rechecked against product version updates

Every good cover story falls apart under questioning, and “we use AES” is not a complete answer when an assessor asks for your CMVP validation record. If you want your encryption story to actually hold up, DTC’s C3PAO team is happy to help you close the gaps before someone else finds them first.