FIPS-Validated Encryption for CUI: Why Enabled Is Not Enough

Somewhere in your SSP there is probably a sentence like “CUI at rest is protected with FIPS-validated FileVault encryption.” If an assessor asks three follow-up questions, that sentence has to survive them: which cryptographic module, which certificate number, and does that certificate cover the macOS version this fleet actually runs? “FileVault is enabled” answers none of those, and under the scoring rules the difference is worth real points.

What the requirement actually says

NIST SP 800-171 Rev 2 requirement 3.13.11 reads: “Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.” The 800-171A assessment objective is blunt: the assessor determines whether FIPS-validated cryptography is employed, not whether it is planned. Two sibling requirements define where crypto shows up: 3.13.8 (confidentiality of CUI in transit) and 3.13.16 (CUI at rest), plus 3.1.19 (encrypt CUI on mobile devices and platforms, and the CMMC guide explicitly treats laptops with full-disk encryption as in scope). Neither 3.13.8 nor 3.13.16 says “FIPS”; 3.13.11 is the requirement that upgrades whatever crypto you use for them to validated crypto.

The scoring makes this concrete. Under the DoD Assessment Methodology, 3.13.11 is a 5-point requirement, with a specific carve-out: if encryption is employed but is not FIPS-validated, 3 points are subtracted instead of 5. And CMVP’s own position is unambiguous: non-validated cryptography is viewed as providing no protection; the data is treated as unprotected plaintext.

Validated, compliant, enabled: three different claims

Validated means a specific cryptographic module, at a specific version, holds an active certificate on the CMVP validated modules list. Compliant is vendor language that usually means approved algorithms without a validated module; the CMMC assessment guide is explicit that using an approved algorithm is not sufficient, because the module implementing it must be separately validated. Enabled is a checkbox, and a checkbox proves nothing about which code performed the cryptography. CMVP validates modules, not products, so the question is never “is FileVault FIPS?” but “which validated module executes FileVault’s cryptography on this OS version?”

One deadline makes this newly urgent: CMVP moves all remaining FIPS 140-2 certificates to the Historical list in September 2026 per the 140-3 transition schedule. Historical status means fine for existing systems, not acceptable for new procurements. If your SSP leans on a 140-2 certificate, its shelf life is measured in weeks.

Where Apple actually stands

Apple validates its corecrypto modules OS release by OS release, and the good news is that the pipeline is current. As of July 2026, the CMVP active list includes FIPS 140-3 certificates for corecrypto on macOS 15 Sequoia (Apple silicon User Space #5184; Intel User and Kernel #5217/#5218; Secure Key Store hardware #5305/#5306), macOS 14 Sonoma (#5216, #5263, #5201/#5202 among others), and macOS 13 Ventura (#5065/#5050, #4948/#4919). Apple tracks the OS-to-module mapping on its security certifications page, and each newer OS typically sits “in review” until its certificates land.

Three practical consequences. First, pin your macOS versions to certificate coverage and check CMVP before your fleet rides an OS upgrade past your documented claim; at this writing at least one Sequoia module variant was still working through the process, which is exactly the kind of detail your SSP should date-stamp. Second, macOS has no FIPS mode to configure. Apple’s validated modules are designed to run in their approved mode automatically, which removes a whole class of Windows-style misconfiguration, with one current exception: Apple ships an optional installer to constrain OpenSSH to FIPS 140-3 algorithms. Third, a certificate for corecrypto is not a certificate for every byte of crypto on the machine, which is where the gotchas live.

The FileVault claim chain

FileVault encrypts the volume with AES-XTS, and on Apple silicon all key handling happens inside the Secure Enclave; encryption keys are never exposed to the CPU, and the key hierarchy chains the user password to a hardware UID (Apple Platform Security). The defensible SSP claim is therefore a chain: this macOS version runs these validated modules (cert numbers), FileVault’s cryptography executes in those modules, our MDM proves the fleet runs that OS version with FileVault on and recovery keys escrowed. Each link is evidence you can produce: a CMVP certificate page, an Apple certifications page reference, and an MDM compliance export.

Where the claim quietly breaks

CUI in transit is the usual first break. Your VPN client and your browser terminate TLS with their own crypto libraries, not necessarily Apple’s validated modules, so each transit path needs its own module answer under 3.13.8 plus 3.13.11. Third-party apps that bundle OpenSSL or BoringSSL use the build they shipped with, and a generic OpenSSL build is not a validated module. Removable media is its own problem: encrypted external drives do not get Secure Enclave key handling, and media transport drags in 3.8.6 besides. And anything that syncs CUI to a cloud service (iCloud drive being the classic accidental case on a Mac) moves the question from your endpoint’s modules to your cloud provider’s FedRAMP posture entirely.

What documenting it correctly looks like

For each place CUI is encrypted, the SSP implementation statement should name five things: the data flow (at rest on managed Macs, in transit over VPN), the product feature (FileVault, per-app TLS), the executing module with version, the CMVP certificate number and its status, and the macOS versions in scope with the MDM report that proves it. That is one disciplined paragraph per flow, and it converts 3.13.11 from a hope into an examinable fact. It is also precisely the structure a 3-point deduction turns on.

Educational content, not legal or assessment advice. Certificate statuses change; verify against the CMVP validated modules list and Apple’s certifications page before you publish an SSP claim. Facts here were checked July 2026.