FIPS 140-3 Validated Cryptography for CMMC: A Defense Contractor's Field Guide

Cryptography is the one CMMC control area where the right answer cannot be inferred, negotiated, or talked around. Either your encryption modules appear on the NIST Cryptographic Module Validation Program (CMVP) list under an active certificate, or they do not. There is no partial credit, no "we're working on it," no compensating control that satisfies an assessor.

That clarity should make compliance easy. In practice, it is one of the top failure categories in CMMC Level 2 assessments — not because the rule is hard to understand, but because the products that defense contractors deploy every day are quietly drifting out of compliance as FIPS 140-2 modules age off the Active List. By September 21, 2026, a large share of the cryptographic modules that contractors validated against in 2020 and 2021 will sit on the Historical List, where they no longer satisfy federal procurement requirements for new deployments.

This article is the technical reference I wish more contractors read before their assessments. It walks through what the CMVP actually validates, how NIST 800-171 controls 3.13.8 and 3.13.11 interact with the validation list, where the most common compliance gaps live, and how to verify — not assume — that your environment is using FIPS-validated cryptography to protect CUI.

What FIPS 140-3 Actually Validates

FIPS 140-3 is a federal standard published by NIST that specifies security requirements for cryptographic modules. The "module" is the key word here. The standard does not validate algorithms in the abstract — AES, RSA, SHA-256, and other primitives are validated separately under the Cryptographic Algorithm Validation Program (CAVP). What FIPS 140-3 validates is the implementation: the actual library, hardware chip, firmware, or software component that performs cryptographic operations in a real product.

A module passes FIPS 140-3 validation when an accredited laboratory tests it against the standard and the CMVP issues a certificate. That certificate appears on the public CMVP list with a unique number, a module name, a vendor, an embodiment (software, firmware, hybrid, hardware), and an Approved security functions list.

Three observations about that certificate matter enormously for defense contractors:

1. A vendor product is not validated. A specific module within it is. Microsoft Windows is not on the CMVP list. Specific Windows cryptographic modules — for example, the Cryptographic Primitives Library (BCryptPrimitives.dll) at a specific build number — are on the list. The same is true for Cisco, Juniper, VMware, Red Hat, and every other vendor in your stack. Validation attaches to the module and its version, not the product line.
2. Validation status changes over time. Certificates move through three states: Active, Historical, and Revoked. A module that was Active when you bought the product may now be Historical, even though the product itself has not changed.
3. Approved algorithms inside a validated module can still be misconfigured. A module can hold a valid certificate and still be used in a non-compliant way — for example, by enabling a non-Approved cipher suite or by running the module in a non-Approved operational mode.

A CMMC assessor checking control 3.13.11 will look at all three layers. They want to see the certificate, the module name and version actually deployed, and evidence that the module is running in its Approved mode.

The Controls That Drive This Requirement

Two NIST 800-171 controls reference FIPS-validated cryptography directly, and a handful more depend on it indirectly.

Control 3.13.11 is the headline requirement: Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. This applies to data at rest (full-disk encryption, file-level encryption, database encryption) and data in transit (TLS to cloud services, VPN tunnels, encrypted email). If a cryptographic operation touches CUI, the module performing it must hold an active FIPS validation.

Control 3.13.8 requires that cryptographic mechanisms prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. The mechanism itself must satisfy 3.13.11, so 3.13.8 effectively chains to FIPS validation for any electronic transmission of CUI.

Several other controls inherit the requirement indirectly. 3.5.10 (cryptographically-protected password storage) requires that password hashing functions live inside FIPS-validated modules. 3.8.6 (encryption of CUI on portable media) brings the same requirement to USB drives, removable disks, and backup media. 3.13.16 (encryption of CUI at rest) makes it explicit for storage systems. Even 3.5.3 (multifactor authentication) often touches FIPS validation when the second factor is a smart card, TOTP token, or hardware authenticator using cryptographic operations.

What this means in practice: FIPS validation is not a single checkbox. It threads through about a dozen controls and touches nearly every system that handles CUI. An assessor who finds a gap in 3.13.11 will usually find correlated gaps across this whole cluster.

The Sunset Timeline Every Contractor Should Have on the Wall

CMVP operates on a rolling sunset schedule that catches many contractors by surprise. The relevant milestones:

• September 22, 2020: CMVP began accepting FIPS 140-3 submissions.
• September 21, 2021: CMVP stopped accepting new FIPS 140-2 submissions. Vendors who wanted to remain validated had to begin transitioning their modules to 140-3.
• April 1, 2022: Last FIPS 140-2 testing reports could be submitted to CMVP from the labs.
• September 21, 2026: Approximately the five-year mark for the final batch of FIPS 140-2 certificates issued in 2021. Modules whose five-year sunset clock expires move to the Historical List on this rolling basis.

The Historical List is the part most contractors misunderstand. A module on the Historical List has not been broken or revoked. Existing federal deployments may continue to use it. However, federal agencies should not procure new instances of a Historical module to satisfy compliance requirements. For defense contractors, that means a Historical module is acceptable for systems already in production at the time it moved, but it is not acceptable for new deployments, refreshed systems, or replacement hardware procured after the transition.

The practical effect across mid-2026: a defense contractor who refreshed a firewall, deployed a new laptop fleet, or migrated to a new cloud service in the last 12 months may be running modules whose certificates have moved to Historical since the procurement decision was made. The product still works. The vendor still supports it. The CMMC assessor will still write it up.

How to Verify Your Environment

The verification process is mechanical, but it requires discipline. For each system that handles CUI, you need to answer five questions:

1. What cryptographic operations does this system perform on CUI? Data-at-rest encryption, TLS termination, VPN tunneling, file signing, key wrapping, password hashing — list them.
2. Which module performs each operation? Not the product name. The module. Vendors publish security policy documents that name the validated module and tell you which build or version is covered.
3. What is the certificate number, and what is its current status? Look it up on the CMVP Module Validation List. Confirm Active, Historical, or Revoked.
4. Is the module running in its Approved mode? Security policy documents list the configuration steps required to operate in Approved mode. Many products require an explicit setting — Windows requires the "System cryptography: Use FIPS-compliant algorithms" policy enabled, Red Hat requires fips=1 at boot, network appliances require a "FIPS mode" command at the CLI.
5. What evidence proves it? Screenshots, configuration exports, command output, and vendor documentation that ties the deployed version to the certificate.

The output of this exercise is a Cryptographic Module Inventory — a single spreadsheet listing each CUI-handling system, the operations it performs, the modules in use, certificate numbers, statuses, and the evidence link. This document, more than any policy, is what a competent assessor wants to see.

The Pitfalls That Show Up in Real Assessments

After reviewing dozens of contractor environments, the same compliance gaps repeat in almost every one.

Self-signed TLS with non-FIPS libraries. Internal applications often terminate TLS using libraries that have never been validated — OpenSSL builds that ship without FIPS providers enabled, Node.js processes using built-in crypto, Python services with ssl defaults. Any of these in the CUI path is a finding.

Cloud storage encryption without verifying the underlying module. Marketing pages claim "encryption at rest with AES-256" without specifying whether the keys are managed by a FIPS-validated HSM. The contractor assumes coverage; the assessor asks for the certificate; the answer is "we don't have one."

Email encryption that defaults to opportunistic TLS. Microsoft 365, Google Workspace, and similar platforms use TLS in transit, but the default configuration permits fallback to unencrypted SMTP when the receiving server does not support TLS. CUI sent under that configuration may transmit in cleartext. The technical control needs to be configured to enforce TLS, not to attempt it.

VPN clients that negotiate non-Approved cipher suites. A VPN concentrator may be FIPS-validated, but if the client policy permits negotiation of older suites (AES-128-CBC with SHA-1, IKEv1 with DH Group 2), the deployment is not running in Approved mode. Assessors check actual negotiated cipher suites, not vendor claims.

Full-disk encryption with consumer-grade BitLocker or FileVault settings. BitLocker is FIPS-validatable, but only when configured to use the Approved cryptographic provider. The default configuration on many laptops does not enable this. Same story for FileVault on macOS.

Backup encryption handled outside the validated module. A primary storage system may use validated cryptography, but the backup workflow exports data through a separate tool that re-encrypts using a different (often unvalidated) library. The data is encrypted; it is not encrypted under a FIPS-validated module.

Historical-list modules in new deployments. This is the rising-tide problem of 2026. A module that was Active 18 months ago is now Historical. The contractor purchased the product expecting compliance and is now in a documentation scramble.

Each of these is preventable. None of them are obvious until someone reads the security policy documents and verifies the actual deployed configuration.

A 60-Day Remediation Plan

If you have not done a cryptographic module inventory in the last 12 months, here is the sprint plan I recommend to contractors heading into a CMMC Level 2 assessment.

Weeks 1–2: Inventory and lookup. Build the spreadsheet. List every system that handles CUI. For each, identify cryptographic operations, modules, and certificate numbers. Look them up on the CMVP list and record current status.

Weeks 3–4: Gap classification. Categorize each finding into one of four buckets: (a) Active certificate, Approved mode confirmed; (b) Active certificate, Approved mode not confirmed; (c) Historical certificate, in production before sunset; (d) No FIPS validation in the cryptographic path. Bucket (d) requires the most urgent attention; (b) is the next priority.

Weeks 5–6: Configuration remediation. For bucket (b), enable Approved mode operation across all affected systems. This often means group policy updates, kernel parameter changes, configuration file edits, and rebooting affected machines. Document the changes and capture before/after evidence.

Weeks 7–8: Vendor and procurement conversations. For bucket (c) and (d), engage the vendors. Ask explicitly: "What is the certificate number of the module currently deployed, and what is the upgrade path to an Active certificate?" Many vendors offer drop-in modules with active certificates; some require version upgrades; some require product replacement. Capture vendor responses in writing — assessors love a vendor letter that states the certificate situation explicitly.

Continuous: Establish a quarterly cryptographic module review on the controls calendar. Modules drift. New systems get deployed. Vendor versions get patched. A quarterly check keeps the inventory current and catches Historical-list transitions before an assessor does.

What Assessors Actually Ask For

When an assessor reaches the cryptography section of a CMMC Level 2 assessment, the conversation typically follows a predictable pattern.

They will start with the System Security Plan and look for a written description of how FIPS-validated cryptography is implemented across the CUI boundary. A generic statement that "the company uses FIPS-validated encryption" satisfies nothing. The SSP needs to name the systems, the modules, and the certificate numbers.

They will then ask for the cryptographic module inventory. The format does not matter; the content does. If you can hand them a spreadsheet that lists every CUI system, every module, every certificate, and the date of the last verification, you have answered most of the question before they ask.

They will spot-check configuration evidence. Expect screenshots from Windows GPO showing FIPS policy enabled. Expect output from cat /proc/sys/crypto/fips_enabled on Linux servers. Expect VPN configuration exports showing the negotiated cipher suites. Expect the BitLocker manage-bde -status output. Expect the BCrypt provider version on Windows endpoints.

They will check vendor documentation. Be prepared to produce the security policy documents from CMVP that match the modules you have inventoried. This is a public document for every validated module — print the relevant ones to a binder section or organize them in your evidence repository.

They will probe historical transitions. If any module on the inventory shows as Historical, they will ask when it transitioned and when the contractor became aware. A documented transition with a remediation plan is acceptable; an undocumented transition with no plan is a finding.

The contractors who pass this section are not necessarily the ones with the cleanest infrastructure. They are the ones who can produce the inventory, the certificates, and the configuration evidence on demand. The contractors who fail are usually running the same products — they just cannot answer the questions.

Where Policy Foundations Fit

FIPS-validated cryptography is enforced through configuration and verified through evidence, but the assessor also expects to see a written policy that documents the requirement and assigns ownership. A policy without the operational discipline behind it is hollow; operational discipline without a policy fails the documentation test.

The TalonPoint PolicyPack includes a dedicated Cryptographic Controls Policy aligned to NIST 800-171 controls 3.13.8, 3.13.10, 3.13.11, and 3.13.16, plus the supporting controls in the 3.5 and 3.8 families. The policy specifies the cryptographic module inventory requirement, the quarterly review cadence, the Approved-mode verification standard, and the vendor diligence expectations described in this article. Pair it with the operational sprint above and you have both halves of what an assessor needs to see.

The Bottom Line

FIPS-validated cryptography is one of the few CMMC requirements where the answer is binary, verifiable in public records, and impossible to fake. Contractors who fail this control area are not failing because the requirement is unclear. They are failing because nobody on the team has walked through the systems, looked up the certificate numbers, and confirmed that the modules in actual production hold Active validations and are running in Approved mode.

That work takes a few weeks if you start now. It takes considerably longer if you start the week before your assessment, because vendor responses, procurement cycles, and configuration changes all introduce delays you cannot compress.

With the September 21, 2026 sunset wave moving more modules to the Historical List every month, the inventory you built two years ago is no longer current. Rebuild it. Verify it. Put it on a quarterly cadence. Then walk into your C3PAO assessment knowing that the one control area with no room for interpretation is the one you can prove without hesitation.

---

TalonPoint Security helps defense contractors prepare for CMMC Level 2 assessments through ready-to-deploy policy frameworks, audit-readiness tools, and gap remediation guidance. Explore the PolicyPack to see how we accelerate compliance for small and mid-sized contractors.