FIPS 140-3 Validated Encryption: A Federal Buyer's Guide

A validation certificate says that an accredited third-party laboratory tested a named cryptographic module, at a stated version and in a stated operational configuration, against the requirements of FIPS 140-3, and that CMVP reviewed and accepted that testing. The certificate names the module, the vendor, the validated version or firmware level, the security level achieved, and the approved algorithms the module implements. It is evidence about that module — nothing wider.

Three distinctions save buyers the most trouble. First, validated is not the same as compliant: "FIPS-compliant" and "uses FIPS-approved algorithms" are vendor phrasings that carry no certificate behind them, while "validated" points at a numbered CMVP entry you can look up. Second, a module ships in more than one mode — many products are only operating within the boundary of their certificate when FIPS mode is explicitly enabled during setup, which is a configuration step your administrators have to perform and document. Third, the boundary is the module, not the box: a switch, a laptop, or a storage array may embed a validated module while large parts of the product sit outside the tested boundary entirely.

None of this makes the standard less useful. It just means the useful artifact is the certificate, and the useful question to a vendor is "which certificate number, at which version, and what has to be configured to stay inside it?"

FIPS 140-3 replaced FIPS 140-2 as the standard new modules are tested against. CMVP began accepting FIPS 140-3 submissions on September 22, 2020, and stopped accepting new FIPS 140-2 submissions on April 1, 2022. Since then the population of 140-2 certificates has been fixed and shrinking in relevance, while the 140-3 population has been growing.

The date most federal buyers are tracking is September 21, 2026. CMVP states that modules validated to FIPS 140-2 can continue to be accepted by U.S. and Canadian federal agencies for the protection of controlled unclassified information (Designated Information in Canada) through that date. After September 21, 2026, CMVP will move FIPS 140-2 validated modules to the Historical list, which — in CMVP's own framing — allows agencies to continue using those modules for existing systems only. At the time this guide was written, that move had not yet happened.

Historical is not revoked. Certificates issued before the move are not retroactively invalidated, and deployed systems do not stop working or stop being lawful to operate. What changes is the posture for new work: agencies are expected to stop specifying Historical-list modules into new procurements and new systems, and CMVP's guidance is to keep using an existing FIPS 140-2 module until a replacement FIPS 140-3 module is available. In practice that makes "is there a 140-3 certificate for the version we would actually deploy, and if not, when?" the right question to put to a manufacturer this year — laboratory and CMVP queues under 140-3 have generally run longer than they did under 140-2, so a current, well-regarded product with no 140-3 certificate yet is a common and not necessarily alarming situation.

FIPS 140-3 defines four security levels. They are cumulative — each builds on the one below — and they describe how hard the module is to physically attack, not how strong its encryption is. The approved algorithms are the same across all four.

Level 1 requires approved algorithms implemented in production-grade equipment, with no physical security requirements beyond production-quality components. This is where most software cryptographic modules, operating-system crypto libraries, and general-purpose implementations land. Level 2 adds tamper evidence — seals, coatings, or pick-resistant enclosures that show visible signs of entry — together with role-based authentication, so a later inspection can tell whether a device was opened.

Level 3 adds tamper resistance and active response: the module is designed to detect intrusion and automatically zeroize its keys when it happens, with identity-based authentication and stronger separation between interfaces and critical security parameters. Hardware security modules and many purpose-built secure network devices target this level. Level 4 is the highest, requiring robust protection against physical and environmental attack — including side-channel and fault-injection techniques — with active tamper response across the entire module envelope. It is rare and appears in specialized, high-assurance equipment.

Most federal requirements are written to Level 1 or Level 2 unless the system handles keys whose compromise would be catastrophic, in which case Level 3 is the usual bar. Specifying a higher level than the requirement calls for narrows the field of available products sharply and rarely buys the mission anything.

Verification is a public, free lookup and it takes a couple of minutes. Go to the Cryptographic Module Validation Program on csrc.nist.gov and open the validated modules search. Search by certificate number if the vendor gave you one, or by module name and vendor name if they did not. Never treat a marketing claim as the verification — the certificate is the verification.

When you find the entry, read four fields before anything else. The module name and version: confirm it matches the firmware or software release you would actually deploy, because a certificate for version 3.2 says nothing about version 4.0. The standard: 140-2 or 140-3. The security level. And the status: Active or Historical, which after September 21, 2026 is the field that tells you whether the module belongs in a new system or only in an existing one.

Then read the module's security policy, which is published alongside the certificate. It states the cryptographic boundary and the approved mode of operation, and it is where you will find the configuration steps required to run the module inside its validation. That document, not the datasheet, is what your security team should be handed. If a vendor cannot produce a certificate number, the honest reading is that the product has not been validated — which may still be acceptable, but it should be a decision your organization makes deliberately rather than one it discovers during an audit.

Self-encrypting drives and storage arrays are the most common encounter. Self-encrypting SSDs and hard drives implement full-disk encryption in the drive controller, and the controller's cryptographic module is what gets validated; the certificate typically names the drive family and a specific firmware level, which is why firmware version control matters as much as the model number on a storage buy.

Hardware security modules and smart cards sit at the other end of the range, since a validated module is essentially the entire product proposition. Network security devices — VPN concentrators, firewalls, and routers terminating encrypted tunnels — commonly carry validated modules for their IPsec and TLS implementations, and usually require an explicit FIPS mode that disables non-approved algorithms and older protocol versions. Operating systems and platforms contribute their own validated crypto libraries, which is the layer most application software inherits rather than validating separately. Multifunction printers and copiers appear more often than buyers expect, because they hold scanned documents on internal storage.

Two purchasing habits follow from this. Put the certificate requirement in the requirement document rather than the evaluation notes, phrased against the module and version rather than the product family. And confirm at delivery that FIPS mode is part of the build configuration, because a validated module running in a non-approved mode gives you the procurement paperwork without the property it was bought for.

FIPS validation is one input among several, and it answers a question none of the others answer. FedRAMP authorization is about a cloud service offering's security posture as a whole and reaches down to require FIPS-validated cryptography where the service protects federal data. CMMC assessments for the defense industrial base likewise expect FIPS-validated cryptography to be the mechanism protecting controlled unclassified information, rather than accepting encryption generically. DISA STIGs specify configuration hardening and frequently require FIPS mode to be enabled on systems that support it.

Two questions that often get conflated with FIPS are genuinely separate. The Trade Agreements Act asks where an item was made or substantially transformed — a country-of-origin question. Section 889 of the FY2019 NDAA asks who made the equipment, naming specific covered entities, and it applies at every dollar value. A module can hold a current FIPS 140-3 certificate and still fail either of those tests, and a product from a designated country with no §889 exposure may hold no certificate at all. Treat them as three independent checks on the same line item.

For the origin question on quoted line items, Uniqcli performs TAA country-of-origin screening before the quote. Cryptographic validation status remains the manufacturer's published certificate and the CMVP listing, and should always be confirmed there.