How to read a vendor's encryption claim

What the FIPS 140-3 transition changes

NIST and the Canadian Centre for Cyber Security run the Cryptographic Module Validation Program (CMVP), which tests and certifies cryptographic modules against the FIPS 140 standard. The current version is FIPS 140-3, which incorporates ISO/IEC 19790:2012 and ISO/IEC 24759:2017.

The transition timeline has been public for years. FIPS 140-3 was approved on 22 March 2019 and became effective on 22 September 2019. CMVP began accepting FIPS 140-3 submissions on 22 September 2020. It stopped accepting new FIPS 140-2 validation submissions on 22 September 2021, with limited exceptions for work already under contract, and stopped accepting them for new certificates entirely on 1 April 2022. On 22 September 2026, all remaining FIPS 140-2 certificates are placed on the Historical List.

The practical point for a buyer is simple. Any FIPS 140-2 certificate a vendor holds was issued from a queue that closed to new work several years ago. It is aging out on a schedule that was published in advance, so a vendor should not be surprised by it.

What Historical status does and does not mean

Historical is not revocation. CMVP maintains a separate Revoked status, and a revoked module validation "is no longer valid and may not be referenced to demonstrate compliance to the 140 standards." Historical is weaker than that. CMVP's guidance is that federal agencies should not include Historical modules in new systems but may procure them for legacy systems, and that even on the Historical list "CMVP supports the purchase and use of these modules for existing systems." Agencies decide their own migration timing, based on their own risk assessment.

So a Historical certificate is not evidence that the cryptography is broken. It is evidence that the certificate is old and that the module has not been through the current scheme. If you are a bank, a fund, or a corporate development team with no federal procurement mandate, Historical status is not a disqualifier by itself. It is a prompt to ask three follow-up questions: which module, is a FIPS 140-3 validation in progress or complete, and what is the certificate number.

What a validation certificate actually covers

A certificate covers a cryptographic module, not a product. The module is a defined boundary around specific code or hardware, at a specific version, tested in a specific operational environment. The CMVP listing states which version, part number, or release was validated, and the operational environment where one applies. Move outside that boundary and the certificate no longer describes what you are running. A different version, a different platform, or the same library called in a non-approved mode all fall outside the tested scope.

FIPS 140-3 defines four increasing security levels and covers requirement areas including module specification, interfaces, roles and services and authentication, software and firmware security, operating environment, physical security, sensitive security parameter management, self-tests, and life-cycle assurance. Level 1 is the common grade for a software module and says very little about physical protection. A certificate number without a level tells you less than it appears to.

Two things follow. First, a vendor whose application links against a validated module has not had its application validated. That may still be a reasonable answer for your risk profile, but it is a different claim, and it should be stated as the different claim it is. Second, CMVP conditions use of the validation phrases on naming the certificate, so a claim written as "FIPS 140-3 Validated" is expected to carry a certificate number you can look up. CMVP also states that validation "in no way constitutes or implies product endorsement by NIST or CCCS." A validated module is a tested component, not a seal of approval on the software around it.

Why "military-grade encryption" is a meaningless phrase

AES is a public standard. NIST published it as FIPS 197 and anyone can implement it, correctly or badly. CNSS Policy No. 15 states that all AES key lengths are sufficient to protect classified information up to SECRET, that TOP SECRET requires the 192 or 256 bit key lengths, and that implementations used to protect national security systems must be reviewed and certified by NSA before acquisition and use. The part of that policy which carries weight is the certification of the implementation. The algorithm name is available to everyone, including to software that uses it wrongly.

So "military-grade encryption" describes a cipher choice that is common to nearly every product in the category. It says nothing about key generation, key scope, key custody, where plaintext exists in the system, or who can reach it. Those are where real systems fail. An attacker with a valid session does not need to break AES. Neither does a participant who was granted a folder they should not have been given.

The gaps that matter more than the cipher

For a data room, the questions worth spending time on sit next to the encryption claim rather than inside it.

Start with key scope and custody. One key for the whole platform and one key per deal are very different exposures, and the phrase "per-deal keys" is worth testing rather than accepting. Ask who can access the master key material, how it is stored, and whether operations staff can decrypt customer content.

Coverage. Document bytes are usually the easy part. Ask whether metadata, folder and file names, the search index, and the audit log are encrypted at rest, and whether the audit log is tamper-evident or simply a table someone with database access can edit.

Plaintext paths. Every product decrypts content somewhere. Previews, watermarked renditions, text extraction, and full text search all handle plaintext. In an AI-native product this question is sharper, because document text is sent to a model provider for extraction, retrieval, and drafting. Ask which providers receive that text, under what retention and training terms, and what enforces that one deal's material cannot appear in another deal's answers.

Access control. Encryption at rest does not address the failure most likely to hurt a live deal, which is a participant seeing a folder they should not see. Ask how folder permissions are resolved, whether the same check governs bulk download and AI answers, and whether view-only really prevents export.

Evidence type. A self-assessment against a control framework and an external audit of that framework are different artefacts. Ask which one you are being shown, and who signed it.

The questions to put to a vendor

1. Which cryptographic module do you use, and what is its CMVP certificate number and status?

2. Is the module validated under FIPS 140-3, or under FIPS 140-2 and therefore heading to the Historical List?

3. At which security level, and in which tested operational environment?

4. Is the validated module the thing running in your production build, at the validated version?

5. Is your application itself validated, or does it call a validated module? Say which.

6. What is the key hierarchy, what is the scope of each key, and who can access the root key material?

7. Which data is encrypted at rest beyond document bytes, and is the audit trail tamper-evident?

8. Where does plaintext exist during processing, and which third parties receive document content?

If a vendor answers these with a phrase rather than a number, a certificate or an architecture description, ask again for the number, the certificate or the description before accepting the answer.

Where to check our answers

We would rather be asked these questions than not. Our own posture, including what is encrypted, how folder permissions are enforced, and how AI features access document content, is documented on /security, and that page is the authoritative one rather than anything summarised here. Ask us directly about key hierarchy and key scope and we will give you the specifics. If a statement there is not specific enough to verify, ask us for the specifics. We apply the same standard to ourselves.