How do I demonstrate FIPS 140-2 (or 140-3) validated cryptography to an assessor?

FIPS demonstration is one of the most evidence-heavy controls because the assessor must verify both the validation status of the module and that the module is actually operating in its validated configuration on the assessed environment.

The practice (SC.L2-3.13.11)

"Employ FIPS-validated cryptography when used to protect the confidentiality of CUI."

SC.L2-3.13.11 cannot generally be on a POA&M. Non-FIPS cryptography in a CUI environment must be remediated before assessment. There is one carve-out in 32 CFR 170.21(a)(2)(ii): if encryption is employed for CUI but the cryptographic module is not FIPS-validated, SC.L2-3.13.11 may be on a POA&M at point value 3. The carve-out does not apply if no encryption is in use.

The four evidence layers

Building the FIPS module inventory

List every cryptographic module that protects CUI:

• Operating system cryptographic providers (Windows BCRYPT, Linux OpenSSL FIPS Object Module, etc.).
• Application-layer crypto (SQL Server TDE, BitLocker, FileVault).
• Network crypto (TLS implementations, IPsec, SSH).
• Cloud service crypto (Azure Storage encryption, AWS KMS).
• Device crypto (mobile device encryption, hardware security modules).

For each, capture: vendor, module name, CMVP certificate number, validated version, validated operating environment, and the OSA's current operating environment.

Verifying CMVP certificates

Each certificate has an active status, an effective date, and a sunset date. Visit csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules and look up each certificate. Verify:

• Status is "Active." "Historical" or "Revoked" status doesn't satisfy the practice.
• Validated configuration matches your operating environment (OS, version, application).
• Validated version matches the version you're running.

Configuration evidence

The module being CMVP-validated is not enough. It must operate in its validated configuration. Examples:

• Windows: Local Security Policy → Local Policies → Security Options → "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" set to Enabled. Confirmed via screenshot or via PowerShell Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy'.
• Linux: Kernel boot parameter fips=1 set, FIPS mode active confirmed via cat /proc/sys/crypto/fips_enabled.
• Application services: Per-service FIPS configuration (e.g., SQL Server, IIS, web servers) documented and screenshot-evidenced.

Operational evidence

• BitLocker on a CUI workstation: manage-bde -status output showing encryption method (e.g., XTS-AES 256) and the FIPS-validated provider.
• TLS in transit: network capture or SSL Labs-style report showing the cipher suite negotiated and the validated module on each side.
• VPN: configuration screenshots and validated module references for the IPsec or TLS-based VPN.

Common errors

• FIPS mode disabled despite a validated module being installed. Validation requires the module to operate in FIPS mode. Merely having the module is not enough.
• Validated version mismatched against running version. If the certificate validates v3.0 and you're running v3.1, the validation may not apply.
• Certificate sunset. Many older FIPS 140-2 certificates have sunset; check the post-validation status.
• No inventory. Without a comprehensive module inventory, the assessor can't verify coverage.
• Application-level crypto bypassed by user-level operations. If users can copy CUI into apps that don't enforce FIPS, the inventory is incomplete.