What Does "FIPS 140-3 Compliant" Actually Mean, and How Do You Verify It?

Every encryption vendor claims FIPS 140-3 compliance. Datasheets say it. Sales decks say it. Procurement questionnaires get checked. Then the assessor shows up.

The phrase "FIPS 140-3 compliant" has no legal definition. It is not a certification. Anyone can write it. What matters is whether the cryptographic module a vendor uses has been validated by NIST's Cryptographic Module Validation Program (CMVP), and that is something you can verify independently, in a public database, before you sign anything.

The gap between a vendor's self-declaration and a searchable CMVP certificate is exactly where audit findings happen. For defense contractors navigating CMMC Level 2, for federal agencies running procurement pilots, and for any organization handling CUI, that gap carries real contractual and regulatory risk. This post explains why it matters under specific compliance frameworks and how to verify a vendor's status in under five minutes.

What Is FIPS 140-3, and Why Does the CMVP Exist?

FIPS 140-3 is the current NIST standard for cryptographic module security requirements. It defines security levels from 1 through 4 for hardware, software, and firmware modules that implement cryptography. The standard replaced FIPS 140-2 as the active framework. Modules validated under 140-2 remain operational under legacy status, and some procurement contracts still accept them, but new federal procurements are increasingly specifying 140-3.

The Cryptographic Module Validation Program is the joint NIST/CCCS effort that certifies whether a specific module meets the standard. Validation is conducted by accredited testing laboratories, not by vendors themselves. The result is a certificate assigned to a specific module, at a specific security level, running in a defined operational environment.

That certificate is public. It is searchable at csrc.nist.gov/projects/cryptographic-module-validation-program. You can search by vendor name and see the module name, certificate number, validation date, and the exact conditions under which the module is valid.

The CMVP exists because cryptography is easy to implement incorrectly. AES-256 is a strong algorithm. A weak implementation of AES-256 is not. Testing a module for proper key generation, entropy sources, self-tests, and boundary protection is the point. The algorithm alone tells you nothing about the quality of the implementation around it.

What Is the Difference Between "FIPS 140-3 Validated" and "FIPS 140-3 Compatible"?

"Validated" means a specific cryptographic module has completed CMVP testing and holds an active certificate. The vendor can provide the certificate number. You can look it up.

"Compatible," or softer variants like "compliant," "aligned," and "based on FIPS 140-3 algorithms," means the vendor uses an algorithm that appears in FIPS-approved algorithm lists. AES-256 appears on those lists. SHA-256 appears on those lists. Using them does not constitute validation.

Think of it this way: a vehicle can use components that appear in a safety-certified design without the assembled vehicle ever having passed that certification. The similarity of components does not mean the assembled product meets the standard.

A vendor who runs AES-256 inside a non-validated library has not met FIPS 140-3. They have used an algorithm that, when implemented inside a validated module, would satisfy the requirement. The module itself must be validated, not just the algorithm within it.

This is not a technical nuance for specialists. It is the exact difference that CMMC assessors and federal contracting officers apply when they review supplier documentation during audits and procurement reviews.

Why Does This Distinction Matter for CMMC Level 2 and Federal Procurement?

CMMC Level 2 practice SC.L2-3.13.10 requires organizations to "employ FIPS-validated cryptography when used to protect the confidentiality of CUI." The word in that control is "FIPS-validated," not "FIPS-aligned" or "FIPS-grade." Validated. As in, a CMVP certificate must exist.

SC.L2-3.13.16 addresses the protection of CUI at rest. Taken together, these two controls mean that if your encryption vendor cannot provide a CMVP certificate number, and if you cannot independently verify that certificate at csrc.nist.gov, then you do not have FIPS-validated cryptography covering your CUI. You have AES-256 with marketing copy around it. That will not satisfy a C3PAO conducting a CMMC Level 2 assessment, and it will not survive a DoD procurement review.

ITAR adds a related consideration. When you store or transmit technical data subject to the International Traffic in Arms Regulations or the Export Administration Regulations, the adequacy of your encryption controls is not self-certified. Reviewers will ask for documentation. "We use AES-256" is not documentation.

For a plain-language breakdown of how encryption requirements map across CMMC practices, the Theodosian CMMC Level 2 encryption guide covers SC.L2-3.13.10 and related controls in detail. For organizations comparing encryption platforms for CMMC and ITAR, the 2026 CMMC and ITAR file encryption guide covers the landscape with specific control mapping.

The practical implication: build your vendor due diligence checklist around the CMVP search, not around sales claims. If the module is validated, the certificate is there. If the certificate is not there, the validation does not exist.

How Can You Verify a Vendor's FIPS 140-3 Validation Before Signing a Contract?

Go to csrc.nist.gov/projects/cryptographic-module-validation-program and use the module search. Enter the vendor's company name or the module name they reference in their documentation.

You are looking for three things. First, the validation status: "Active" for 140-3, or "Historical" for 140-2 legacy modules still in operational use. Second, the security level: most enterprise software products are validated at Level 1 or Level 2, while hardware security modules can reach Level 3 or 4. Third, the operational environment: the certificate specifies the exact platform, operating system version, and configuration under which the module is valid. If the vendor's deployment differs from the certificate's defined environment, the validation may not apply to your deployment.

Ask the vendor directly for their CMVP certificate number. If they cannot provide one, ask why. A legitimate answer is that they rely on a validated third-party cryptographic library such as OpenSSL's FIPS module. In that case, you need to understand whether their product is deployed in a way that uses the validated module's approved operating mode. That is a technical question worth asking before contract signature, not after an audit finding.

One additional timing consideration: FIPS 140-2 modules entering "Historical" status do not immediately invalidate existing deployments, but they introduce renewal risk. If a platform you are onboarding today relies on a 140-2 certificate that will move to Historical status during your contract term, plan for a re-evaluation. New procurements are better anchored on 140-3 from the start.

Why Is Self-Custody Key Management a Separate Requirement, and Why Do Most FIPS-Validated Platforms Still Fail It?

FIPS 140-3 validation addresses the cryptographic module. It says nothing about who holds the decryption keys after the module generates them.

Most cloud-based encryption platforms, including many with legitimate CMVP certificates, operate on a model where the vendor manages encryption keys on your behalf. Your data is encrypted, files are protected in transit and at rest, and the module is validated. But the vendor can decrypt your files. So can anyone who compromises the vendor's key management infrastructure, or anyone who serves the vendor with a legal order.

For federal agency pilots, defense subcontractors handling ITAR-controlled technical data, and organizations subject to export control regulations, that exposure is not theoretical. The adversary model includes supply chain compromise, insider threats at the SaaS provider, and legal compulsion across foreign jurisdictions. Key custody is where those risks converge.

Self-custody key management means the encryption vendor has no access to decryption keys. Keys are generated on your infrastructure, under your control, and never transmitted to the vendor in recoverable form. This is architecturally distinct from FIPS 140-3 validation. Most FIPS-validated platforms do not provide it.

A useful way to frame the two requirements: FIPS 140-3 validation tells you the cryptographic module is sound. Self-custody tells you that access to what the module produced belongs solely to you. Both matter. Satisfying one while leaving the other open is not a complete compliance posture.

For a detailed technical and compliance walkthrough of zero-knowledge key architecture, the Theodosian zero-knowledge encryption guide covers the architecture and its implications. For a direct comparison of how key custody decisions affect compliance outcomes, see the zero-knowledge vs. standard enterprise encryption breakdown.

What Does a Fully Compliant Architecture Look Like?

The standard that procurement officers and CMMC assessors are increasingly applying combines three things: FIPS 140-3 validated cryptography, self-custody key management, and underlying infrastructure that meets federal baseline security requirements.

Theodosian is built to satisfy all three. For FIPS 140-3 validated cryptography, Theodosian relies on AWS's CMVP-validated cryptographic module — the same approach this post's verification section describes as a legitimate and standard model for cloud-native platforms. Per-file FIPS 140-3 AES-256 encryption assigns a unique cryptographic key to each individual file rather than applying a single key to an entire data store. This limits the blast radius of any key compromise to a single document, not a repository. The platform runs on FedRAMP Moderate infrastructure. The patent-pending zero-knowledge architecture means Theodosian cannot access customer files, cannot be compelled to produce decryption keys it does not hold, and does not operate a central key escrow.

Context-aware access controls layer identity, device posture, geolocation, time of access, network context, and behavioral anomaly signals into access decisions. When anomalies are detected, the Drop the Gate feature triggers an autonomous freeze and step-up multi-factor authentication without waiting for manual intervention.

For organizations comparing Theodosian's file-level encryption model against container-based security approaches, the Theodosian vs. Microsoft Purview comparison shows where per-file encryption and container security diverge on control granularity and audit defensibility.

The two-week proof of concept covers FIPS 140-3 validation, self-custody key architecture, and deployment on FedRAMP Moderate infrastructure, so you have the documentation before your assessor asks for it.

FAQs: FIPS 140-3 Validation & CMVP Compliance