SC.L2-3.13.11CUI Encryption
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
[a]
FIPS-validated cryptography is employed to protect the confidentiality of CUI.
Org-approved crypto module list; BitLocker and TLS configured to approved modes
Implementation
AO coverage. Addresses all FIPS-validated cryptography objectives claimed for in-scope systems in this pattern.
Approved modules. Maintain an inventory of cryptographic modules in use (OS FDE, TLS libraries on reverse proxies, VPN) with FIPS 140-2/140-3 validation references where the org asserts FIPS mode. Engaging a new crypto product requires security review against this list.
Endpoint. BitLocker with XTS-AES; group policy / MDM sets encryption method and requires TPM+PIN or TPM+password for boot where policy demands. FIPS mode enabled for CUI devices when required by contract; test pack validates that banned algorithms are refused.
In transit. External TLS terminators require TLS 1.2+ with an approved cipher suite list; TLS 1.0/1.1 disabled. VPN uses approved IPsec/IKE suites only.
Maintenance. Quarterly check that module versions still match CMVP certificates (or plan upgrade). After OS feature updates, re-run the crypto test pack on a canary ring before broad rollout.
Accepted gap. One vendor SaaS used for proposals does not offer a customer-controlled FIPS mode. CUI is not stored there; contracts language and DLP block CUI upload to that tenant.
What the evidence looks like
- Crypto module inventory with validation refs / config baselines
- BitLocker / MDM encryption settings export
- TLS configuration scan output (cipher suites)
- VPN crypto proposal config
- SaaS exception with compensating control
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.