How to read a vendor's encryption claim

What actually goes wrong on a live deal, and where encryption sits in it

The failures that damage a live process are not cipher failures. A bidder is granted a folder built for a different bidder. A file meant to be view only leaves inside a bulk download. Encryption at rest stops neither. It stops an attacker reading raw disks and backups, which nearly every product in this category does with the same algorithm.

So the encryption answer is worth asking for and not worth taking at face value. A vendor who can name the module, the certificate number and where plaintext exists knows their own system. An answer that offers only an adjective is not an answer. A date is also forcing the conversation: on 22 September 2026 every remaining FIPS 140-2 certificate moves to the Historical List, so a vendor leaning on one needs a new answer.

Our own answers are at the end, and two are worth stating first. Every AI feature in our product retrieves documents through a single retrieval path that applies the asking user's own folder permissions before a document is admitted as a source. And each deal is a separate database file on its own subdomain, so one deal's material cannot be reached from another by construction rather than by rule.

What the transition changes, and what Historical status means

NIST and the Canadian Centre for Cyber Security run the Cryptographic Module Validation Program (CMVP), which certifies cryptographic modules against FIPS 140. The current version is FIPS 140-3, and the transition timeline has been public for years. CMVP stopped accepting new FIPS 140-2 submissions on 22 September 2021, closed that route entirely on 1 April 2022, and moves all remaining FIPS 140-2 certificates to the Historical List on 22 September 2026.

Historical is not revocation. CMVP keeps a separate Revoked status for validations that may no longer be referenced to show compliance. Its guidance on Historical is weaker: agencies should not put those modules in new systems, though "CMVP supports the purchase and use of these modules for existing systems."

So a Historical certificate is not evidence that the cryptography is broken, only that it is old and the module has not been through the current scheme. Outside federal procurement it is not a disqualifier by itself, just a reason to ask the questions below.

What a validation certificate actually covers

A certificate covers a cryptographic module, not a product. The module is a boundary around specific code or hardware, at a specific version, tested in a specific operational environment, all of which the CMVP listing states. A different version, a different platform, or the same library called in a non-approved mode falls outside that scope, and the certificate stops describing what you run. FIPS 140-3 also defines four security levels, and Level 1, the common grade for software, says little about physical protection.

So a vendor whose application links against a validated module has not had its application validated. That is a different claim and should be stated as one. CMVP also conditions use of the validation phrases on naming the certificate, so "FIPS 140-3 Validated" is expected to carry a number you can check.

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 protecting national security systems must be reviewed and certified by NSA before use. The weight sits on certification of the implementation, not on the algorithm name, which is available to everyone including to software that uses it badly.

The phrase describes a cipher choice common to nearly every product, and says nothing about key generation, key scope, key custody, where plaintext exists, or who can reach it. An attacker holding a valid session does not need to break AES, and neither does a participant granted a folder they should never have been given.

The gaps that matter more than the cipher

Key scope and custody come first. One key for the whole platform and one key per deal are very different exposures, and the phrase "per-deal keys" is worth testing against the running system rather than accepting from a page. Coverage comes next, because document bytes are the easy part. Metadata, file names, the search index and the audit log may or may not be encrypted at rest, and an audit log is often a table anyone with database access can edit.

Plaintext paths come after that. Every product decrypts content somewhere: previews, watermarked renditions, text extraction, search. In an AI-native product the question is sharper, because document text goes to a model provider for extraction, retrieval and drafting, under retention terms you should read.

Access control matters most, because it is the failure most likely to hurt a live deal. Ask how permissions are resolved, whether the same check governs bulk download and AI answers, and whether view only genuinely prevents export. Ask too whether the compliance evidence you are shown is a self-assessment or an external audit.

The questions to put to a vendor

1. Which cryptographic module, what is its CMVP certificate number, and is it FIPS 140-3 validated or heading to the Historical List?

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

3. Is that module the one in your production build, at the validated version?

4. Is your application itself validated, or does it call a validated module?

5. What is the key hierarchy, what is each key's scope, and who can reach the root material?

6. What is encrypted at rest beyond document bytes, and is the audit trail tamper-evident?

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

Ask again whenever an answer comes back as a phrase rather than a number, a certificate or an architecture.

How we answer the same questions

Document bytes are compressed and then encrypted with AES-256-GCM before they reach disk or object storage, under keys derived with HKDF-SHA256. The mode is authenticated, so altered ciphertext fails to decrypt rather than returning altered content. Coverage runs past the file bytes: each entry's summary and metadata blob is stored encrypted in the deal's own database, so document and folder names are not held in plaintext there. One exception belongs in the answer, because question six asks for it. Audit rows are written as ordinary readable columns rather than as encrypted blobs, so the recorded action and the event detail sit in the deal database in the clear, and the trail carries no hash chain and no signature.

Key scope is the question to press on us. Ask for the hierarchy, each key's scope and who can reach the root material, and check the answer against the running system rather than against a marketing page. /security is the authoritative page here, not this one.

Access control is applied in one place rather than once per feature. The retrieval path behind every AI feature applies the asking user's own folder permissions before a document can become a source, and the separate search endpoint applies the same check. When a draft will be shown to the other side, a document is eligible only if every counterparty organisation that can see the relevant request list may read it, and the logic denies rather than falling back to the deal team's wider access. Export is gated separately from reading, so a view only folder blocks the single file download, the native stream the viewer uses, and the file inside a bulk zip. Watermarks are applied at the moment of serving and cover PDF, Word, images, spreadsheets and presentations, and a file that cannot be watermarked is refused rather than served clean.

The limits are these. Retrieval admits any folder you have some access to, including the view and watermark grades, so an AI answer can quote from a document you may only view watermarked. Defaults are permissive, so folder restrictions are configuration you apply rather than a starting posture. Prompt-level defences against instructions hidden in documents are mitigation rather than a boundary. The boundaries are the per-deal database, the permission check before retrieval, and server-side verification of quoted text. Audit events record the source IP, but the trail is readable by the advising firm's team rather than by counterparties, and it is not cryptographically tamper-evident, so it is a record to treat as operational evidence rather than as forensic proof.

Ask us these questions before you run a process on the platform.