up:: The Human & Organizational Side MOC

The Vendor-Claims Checklist

The vendor-claims checklist is a set of three questions to put to any vendor who tells you their product is quantum-safe, and each one converts a marketing sentence into a public fact you can verify yourself: (1) “What is the CMVP certificate number for the module, and can I look it up?” (a real answer is a number) · (2) “Which module carries that certificate, and is the post-quantum algorithm I care about on its approved list?” (frequently it is somewhere else in the codebase) · (3) “When was the module carrying post-quantum validated?” (validation is a snapshot with a date on it).

The checklist works because NIST runs two separate certification programs whose names sound interchangeable, which cost very different amounts to earn, and only one of them tells you anything about the assembled software running in your estate. A vendor can hold the cheap one, describe it in language that implies the expensive one, and be telling the technical truth the entire time. All three answers are public, so the whole check runs against a government registry in roughly 10 minutes with no vendor briefing and no NDA.

The short version:

• Question 1 gets you a certificate number, because CAVP validation confirms one algorithm implementation against test vectors while CMVP validation covers the whole assembled module under FIPS 140-3, and only the second produces the certificate a federal buyer checks.
• Question 2 gets you the module name, because a vendor validates one specific module and the marketing then implies the entire product inherits it, so the algorithm you are buying may sit in code that was never inside the validation boundary.
• Question 3 gets you a date, because post-quantum support is being added to modules continuously, and a certificate issued before that work landed cannot cover the algorithm being sold to you today.
• The worked example is a library almost everyone depends on: Google’s BoringCrypto module holds a current FIPS 140-3 validation whose security policy contains zero post-quantum algorithms, so a product resting a quantum-safe claim on “we use a FIPS-validated BoringSSL” is resting it on something the registry says is absent.
• These are general product-claim questions and they sit apart from the three QKD questions, which test a physics promise rather than a certificate.

Picture buying a building and being handed a genuine, signed safety inspection certificate. The certificate is real, the inspector was qualified, and the seal is authentic. What it covers is one specific stairwell, inspected on one specific date, in the configuration it was in that morning. Nothing on the certificate is false, and nothing on it says anything about the roof you are actually worried about, the extension built afterward, or the wiring behind the walls. The three questions are the three things you would ask before treating that certificate as an answer: what is its number so I can pull the record, what exactly did the inspector walk, and when did they walk it.

The framework

For any quantum-safe product claim, ask three questions in order, each phrased so a real answer is a short public fact:

1. “What is the CMVP certificate number for the module, and can I look it up?” Asking whether a product is FIPS validated invites a yes. Asking for the certificate number invites either a number or a paragraph, and the paragraph is itself the finding. A real answer is a numeral you can type into NIST’s registry before the meeting ends.
2. “Which module carries that certificate, and is the post-quantum algorithm I care about on its approved list?” A validation covers a defined module with a defined boundary. Vendors validate one component and then describe the whole product in validated language, so this question separates the certified thing from the thing you are buying, and the module’s own approved-algorithm list settles it.
3. “When was the module carrying post-quantum validated?” Validation is a point-in-time record. Because post-quantum algorithms are being added to modules continuously, a certificate predating that work cannot cover the algorithm in the pitch, whatever the vendor’s roadmap says.

When the framework applies: any procurement, renewal, or architecture review where a product’s quantum-safe posture is load-bearing, and any moment a vendor answers a cryptography question with a certification instead of a specification. It runs on one product claim and returns a verdict on whether the claim is checkable.

When it does not apply as a rejection: a vendor who answers all three cleanly has passed, and the checklist is designed to let that happen. A validated module carrying ML-KEM with a recent date is exactly the answer you want, and the questions exist to find it rather than to deny it.

Where it stops. The checklist tells you whether one product’s claim survives contact with the public record. Mapping every vendor across your estate, weighting which of their gaps actually touch your sensitive data paths, and turning the answers into contract language and a sequenced remediation plan is estate-specific work that begins where the three questions end.

Question	A real answer	A non-answer	What it protects you from
What is the CMVP certificate number for the module?	A certificate number you can look up in NIST’s registry during the call	”We’re FIPS validated,” “our algorithms are FIPS-tested,” or a paragraph about the compliance program	Buying CAVP algorithm validation while believing you bought CMVP module validation
Which module carries it, and is the PQC algorithm on its approved list?	A named module plus the algorithm’s presence on that module’s published list	”The product is validated” without naming the module, or naming a module whose list you are told not to check	Inheriting a validation boundary that never contained the algorithm you are paying for
When was that module validated?	A specific validation date you can confirm against the registry	”Recently,” “it’s in process,” or a roadmap date offered in place of a validation date	Treating a certificate issued before the post-quantum work as coverage of it

What is the difference between CAVP and CMVP?

CAVP is the Cryptographic Algorithm Validation Program, and it confirms that a vendor’s implementation of a specific algorithm produces the correct outputs against a set of known-answer test vectors. It is useful and it is narrow: it tells you the mathematics was implemented correctly, in isolation, on the tested platform.

CMVP is the Cryptographic Module Validation Program, and it validates the entire cryptographic module against FIPS 140-3, covering how the module manages keys, how it is constructed, how it authenticates operators, and how it resists tampering. That is the certificate a federal buyer checks, because it speaks to the assembled thing rather than to one routine inside it.

The relationship between them is the part that makes the marketing possible, and NIST states it plainly: algorithm validation is a prerequisite of module validation. Passing CAVP is a step on the way to CMVP rather than a smaller version of it, so a product can hold CAVP validation forever without ever entering module validation at all.

Source: NIST, “Cryptographic Algorithm Validation Program,” csrc.nist.gov, stating that cryptographic algorithm validation is a prerequisite of cryptographic module validation.

Source: NIST, FIPS 140-3, Security Requirements for Cryptographic Modules, csrc.nist.gov.

The move worth watching for is a vendor earning the cheap, narrow validation and then marketing in language that implies the expensive, rigorous one. Phrases like “NIST-validated” and “FIPS-tested algorithms” are technically accurate descriptions of CAVP and deliberately blurry about which program produced them. Question 1 exists because a certificate number cannot be blurry.

Why does asking for the number work better than asking whether they are validated?

Because the two questions have different failure modes, and only one of them produces evidence. “Are you FIPS validated?” is answerable with a confident yes by a vendor holding an algorithm validation, a vendor holding a module validation, and a vendor whose partner holds one. All three sound identical across a conference table.

“What is the certificate number?” has one shape of correct answer. Either a numeral arrives, in which case you have a public record to read, or it does not, in which case you have learned something specific and dated about how this vendor handles verification requests. The question converts a claim into either evidence or a finding, and both outcomes are useful.

This is the same discipline that runs through discovery generally: read the artifact rather than the description of the artifact. A certificate is a signed, dated, machine-readable public record, and unlike a datasheet it cannot misremember what it covers.

How do you check the answer yourself?

NIST publishes every validated module in a public database, the CMVP validated-modules registry, and the check needs the module name and a browser. Look up the module, open its certificate, and read its approved-algorithm list. Whatever is absent from that list is absent from the validation, regardless of what the surrounding product does.

Source: NIST, “Cryptographic Module Validation Program: Validated Modules,” csrc.nist.gov.

The worked example is worth running because it touches an enormous share of the market. A great many products get their cryptography from BoringSSL, and the reasoning “we use BoringSSL, so we are post-quantum” is common enough to be a genre. The validated module behind it is Google’s BoringCrypto. Pull its FIPS 140-3 non-proprietary security policy and read Table 5, the approved-algorithm list, and what appears there is AES, SHA-1, the SHA-2 family, HMAC, RSA, ECDSA, key-agreement schemes, a DRBG, and key-derivation functions. The document contains zero occurrences of ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS, or the phrase “post-quantum.”

Source: Google LLC, “BoringCrypto FIPS 140-3 Non-Proprietary Security Policy,” CMVP certificate 5296, 41 pages, document dated 24 February 2026, csrc.nist.gov. Full text retrieved and searched 2026-08-06.

So a product resting its quantum-safe claim on a FIPS-validated BoringSSL module is resting it on something that, per NIST’s own registry, the validation does not cover. The open-source code may well include post-quantum algorithms, and the validated module is a narrower thing than the codebase around it. Both facts are true at once, and only one of them is on a certificate.

The registry is live, which is the reason question 3 exists and the reason this section carries a verification date. Re-run the lookup at decision time rather than trusting any write-up of it, including this one.

What question goes one layer past the certificate?

A certificate tells you an accredited lab tested something and NIST issued a record. It does not tell you what the vendor’s own engineering team has run, on which corpus, or what their implementation could not execute. There is a fourth question available for the vendors who clear the first three, and it separates a team that ran the vectors from a team that quoted someone who did.

Ask it in this shape: against which pinned ACVP corpus revision did you evaluate, and what did your unsupported-operation column look like?

Both halves do work. The corpus revision is a commit and a date, so an answer is either specific or it is not. The unsupported-operation column is the more revealing half, because every real implementation cannot execute some part of the vector set, and a team that has genuinely run the corpus will say so immediately and without embarrassment.

What comes back	What it tells you
A commit or release date, plus a straightforward account of what their build does not implement	They ran it. This is the answer you want, and the omissions are ordinary
A certificate number restated	They answered the earlier question again. Their validation is real and this one is still open
”Everything passed” with no unsupported cases	Worth gently probing. A complete pass across every operation and parameter set is unusual, and the likeliest explanation is that unsupported cases were dropped rather than recorded
Confusion about what the corpus is	The testing sits with a supplier further up the chain, which is worth knowing and is not by itself a problem

Be precise about what this does not imply. A vendor who cannot answer this still holds a valid certificate, and a validated module remains a validated module. This question reaches past validation into engineering practice, and it is a useful discriminator among vendors who have already cleared the bar rather than a way to knock anyone below it.

The reason the second half is diagnostic comes from the reproducibility work behind it: a conformance run produces false assurance when unsupported cases are dropped, when harness errors are recorded as failed verdicts, when only favorable fields are compared, or when the denominator changes between products. A vendor who volunteers their unsupported column is a vendor whose numbers have a denominator you can see.

Source: Christopher M. Frost, HEOSSI (Pte.) Ltd., “A Reproducibility Protocol for Cross-Implementation Evaluation of Post-Quantum ACVP Test Vectors,” arXiv:2608.13784, 2026, arxiv.org/abs/2608.13784. Single-author preprint from a commercial entity, not peer-reviewed. Background on the evidence tiers is in ACVP and PQC Validation.

Why does the module boundary matter more than the product name?

Because a validation applies to a defined module with a defined cryptographic boundary, and the product you buy is almost always larger than that boundary. Everything inside the boundary was examined. Everything outside it was not, and the certificate makes no claim either way.

This is where question 2 earns its place. A vendor can hold a genuine, current, module-level validation and still ship the post-quantum feature you are buying in code that sits outside the validated boundary, because adding an algorithm to a validated module means re-entering validation while adding it to the surrounding product does not. The gap is a normal consequence of how the programs work rather than evidence of bad faith, and it is invisible unless someone asks which module carries the certificate.

The practical form of the question names the algorithm out loud. “Is ML-KEM on the approved-algorithm list of the module carrying that certificate?” cannot be answered by describing the product, and the module’s published list settles it in the open. For a federal system the stakes are explicit, because the validated module is what compliance rests on rather than the algorithm standard the product implements.

Why is “FIPS 203 compliant” a different claim from “FIPS 140-3 validated”?

Because the two documents do different jobs, and the similarity of their numbers does a great deal of unearned work in vendor copy. FIPS 203 is the algorithm standard that specifies ML-KEM. FIPS 140-3 is the standard that specifies security requirements for the module that implements algorithms, and validation against it is what CMVP performs.

A product can implement FIPS 203 correctly and hold no module validation at all. A module can hold a current FIPS 140-3 validation whose approved-algorithm list contains no post-quantum algorithm whatsoever, which is precisely the BoringCrypto case above. “Compliant with the algorithm standard” and “validated as a module” are separate facts, and for a federal system only the second one carries.

Sources: NIST, FIPS 140-3, Security Requirements for Cryptographic Modules, csrc.nist.gov, for what module validation covers; NIST Cryptographic Module Validation Program, csrc.nist.gov, for the certificate and the approved-algorithm list, and for the federal rule that settles the second half of this section: “Non-validated cryptography is viewed as providing no protection to the information or data… In essence, if cryptography is required, then it must be validated.”; NIST, FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, §1.1, csrc.nist.gov, for the algorithm standard’s own scope, which aims “to provide sufficient information to implement ML-KEM in a manner that can pass validation.” FIPS 203 never mentions FIPS 140-3 and draws no compliance distinction of its own.

The clean way to hold this in a meeting is to treat “compliant” as a statement about intent and “validated” as a statement about evidence. Only one of the two produces a certificate number, which is what question 1 asks for.

Has this happened before?

Certification frameworks have carried this exact shape since the field had certification frameworks at all. The Trusted Computer System Evaluation Criteria, the Orange Book, was published in 1983 and became the standard framework for evaluating computer security through the 1990s, descending directly from the 1972 Anderson Report’s argument that security required dedicated evaluation rather than assurances. The institutional infrastructure that emerged from it continues to shape contemporary security evaluation frameworks, CMVP among them.

Source: Nicole Perlroth, This Is How They Tell Me the World Ends, reading ledger session 1, on the Anderson Report’s lineage into TCSEC (1983) and onward into modern evaluation frameworks.

What carries forward is the structural fact rather than the specific criteria: an evaluation covers a defined system in a defined configuration, evaluated on a date, and the marketing pressure has always been to describe the evaluated thing and ship something larger. The three questions are the durable countermeasure, because they ask for the identifier, the scope, and the date, which are the three variables every evaluation regime has ever had.

What does the checklist look like run against a real pitch?

Take a claim of the kind that reaches a board through a deck: “Our platform is quantum-safe today. We’re NIST-validated, we use industry-standard post-quantum cryptography, and our underlying crypto library is FIPS certified, so you’re covered ahead of the mandates.”

Question 1, the certificate. “What is the CMVP certificate number for the module, and can I look it up?” If the answer describes a compliance program rather than producing a numeral, the claim has already failed to be checkable, and that is a dated finding for the risk record. If a number arrives, you have a public record and the conversation improves immediately.

Question 2, the module. “Which module carries that certificate, and is ML-KEM on its approved list?” Here the deck’s phrase “our underlying crypto library is FIPS certified” meets the registry. If the module is BoringCrypto, its approved-algorithm list settles the matter in the open, and the answer today is that no post-quantum algorithm appears on it. The platform may still implement ML-KEM somewhere. The validation does not reach it.

Question 3, the date. “When was the module carrying post-quantum validated?” A roadmap date offered in place of a validation date is the answer to a different question, and worth recording as such. A real validation date lets you confirm the certificate postdates the post-quantum work rather than preceding it.

The output, in one meeting: three public facts, or a documented gap where each fact should be. The claim moves out of the trust column and into the verify column, and every downstream decision about that product inherits a record rather than an impression.

Common misconceptions

• “NIST-validated means the whole product was validated.” Validation attaches to a module with a defined boundary, and the product is almost always larger than the module. The certificate describes exactly what was examined, and everything outside the boundary is outside the claim.
• “CAVP and CMVP are two names for the same certification.” They are separate programs at different depths and different costs, where algorithm validation is a prerequisite step inside module validation. A product holding only CAVP has had one algorithm implementation checked against test vectors and has had its key management, construction, and tamper resistance checked by nobody.
• “If the open-source library supports post-quantum, the validated module does too.” The codebase and the validated module are different artifacts with different contents. BoringSSL and BoringCrypto are the standing example, where the library moves faster than the validation boundary around it.
• “A vendor who says this is lying to me.” Most of them are describing a real certification accurately and relying on the two program names sounding alike. Treating it as deception makes the conversation adversarial and gets you less. Treating it as a question of scope gets you a certificate number.
• “FIPS 203 compliant covers the compliance requirement.” Implementing the algorithm standard and holding a validated module containing that algorithm are separate facts, and for a federal system the validated module is what counts.
• “A certificate is a permanent property of the product.” Validation is dated, modules get revalidated as they change, and post-quantum support arrives on a schedule. A certificate that predates the algorithm in the pitch cannot cover it.

Pro tips

1. Ask for the number before you ask anything else. Questions 2 and 3 both assume a certificate exists, and question 1 establishes whether it does. Leading with it also sets the register for the rest of the conversation, because a buyer who opens by asking for a public identifier is understood to be someone who will check.
2. Send all three in writing, ahead of the meeting. A written question produces a written answer, and a written answer is an artifact you can attach to the risk record and to the contract. It also removes the live-meeting dynamic where a confident verbal yes ends the topic.
3. Name the specific algorithm in question 2. “Is your product post-quantum?” and “Is ML-KEM on the approved-algorithm list of the module carrying certificate 5296?” invite completely different answers. The second one is checkable by both parties in the same minute.
4. Record a non-answer as a dated finding rather than an open item. “Vendor asked for CMVP certificate number on 2026-08-06; response described the compliance program without providing a number” is something a board can act on. “Still waiting on the vendor” is something that sits in a spreadsheet for a year.
5. Re-run the lookup at contract signature as well as at evaluation. The registry is live and modules get revalidated. A gap found in evaluation may genuinely have closed by signature, and a claim that was accurate in evaluation may be about a module that has since changed.
6. Use the answers to write the contract clause. The three facts map directly onto procurement language: the module by name, the algorithm on its approved list, and a validation date the vendor commits to maintaining. This is where the checklist stops being a filter and starts being leverage, and it composes with the broader procurement language work.
7. Run the checklist on the products you already own, in the order the two-lens rule produced. The questions are usually framed around new purchases, and the installed estate is where the unexamined claims have been accumulating.

Where does the checklist break?

The framework has honest limits, and naming them keeps it from becoming a reflex:

1. A missing validation is sometimes the correct engineering state. Module validation takes time and money, and a vendor shipping a genuinely good post-quantum implementation may be mid-process or may serve a market where FIPS validation is irrelevant. The questions surface the fact rather than the verdict, and the verdict depends on whether your environment requires validated modules at all.
2. Non-federal buyers have a different bar. For a federal system the validated module is the compliance object, and the checklist maps onto a requirement. For a commercial buyer with no FIPS obligation, the answers are still the best available evidence of engineering seriousness, and they are evidence rather than a rule.
3. The questions cover the cryptographic module and stop there. A product can hold an impeccable validation covering exactly the right algorithms and still deploy them badly, negotiate weak parameters, or leave the post-quantum path switched off in your configuration. Reading what actually gets negotiated is a separate check, and the checklist does not replace it.
4. Question 3’s answer moves. Post-quantum support is being added to modules continuously, so a gap documented today may close next quarter. The questions are durable and the answers are dated, which is why the finding format includes the date.
5. Hardware and cloud services complicate the module boundary. Where the cryptography runs inside a vendor-operated service, the module carrying the validation may belong to a provider several layers down, and tracing it is genuinely harder than reading one certificate. The questions still apply and the answer arrives more slowly.

How do you use this in a procurement conversation?

Deploy it as a request for public facts rather than as a challenge, because the register determines what you get back. A vendor asked to defend a claim becomes defensive. A vendor asked for a certificate number, a module name, and a date is being asked for three things a competent team has to hand, and the ones who have them produce them quickly.

Carry three one-line landings. For the certificate: “before we go further, I’d like the CMVP certificate number so I can pull the record.” For the module: “which module does that certificate cover, and is ML-KEM on its approved list?” For the date: “when was that module validated with post-quantum in it?” Each is short, each is neutral, and each has one shape of correct answer.

Then let the answers sort the market for you. Vendors who answer all three in a sentence each have demonstrated something no deck can demonstrate, and they are the ones worth spending evaluation time on. Vendors who cannot have handed you a finding with today’s date on it, which is more than the meeting was ever going to produce otherwise.

The result is a procurement record built from public facts rather than impressions, at a cost of about 10 minutes per product, in a market where “quantum-safe” currently sells better than it verifies.

Questions people ask

How long does this actually take? Roughly 10 minutes per product once you have the module name, because the whole check runs against NIST’s public registry with no vendor briefing and no NDA. The waiting time is in getting the certificate number out of the vendor rather than in the lookup itself.

What if the vendor refuses to give me a certificate number? Record it as a dated finding and proceed accordingly. A refusal is information: either no module validation exists, or the person you are talking to cannot reach the people who would know, and both facts matter to a buying decision. The finding belongs in the risk record with the date and the exact wording of the request.

Does a product need CMVP validation to be secure? No. Validation is evidence of a specific kind of examination, and plenty of well-engineered cryptography has never entered the program. What validation gives you is an independent, dated, public record, which is why federal systems require it and why it is the strongest artifact a commercial buyer can ask for.

Is BoringCrypto a bad module? No, and that is what makes it the useful example. It is a current, genuine FIPS 140-3 validation from a serious engineering organization. The point is that its approved-algorithm list contains no post-quantum algorithm, so a quantum-safe claim resting on it is resting on something the certificate does not cover. Check the live registry rather than this note, because the situation can change.

Which of the three questions matters most? Question 2, the module, because it is where genuine certificates and unvalidated features most often coexist. Question 1 is asked first because everything else depends on a certificate existing, and question 3 catches the case where the certificate exists and predates the thing you are buying.

Do these replace the questions I would ask a QKD vendor? No. The three QKD questions test a physics promise and its engineering consequences, which no certificate speaks to. These three test a certification claim about a software module. A QKD pitch can warrant both sets, and they cover different ground.

What do I do with a vendor who is mid-validation? Get the module name, the algorithms in scope, and the submission date in writing, then treat the roadmap date as a roadmap date. A vendor in process can usually produce all three, and the written answer is what turns a promise into something you can hold them to at renewal.

Where does this fit relative to building an inventory? After it. You need to know which vendor products carry cryptography in your estate before you know whose claims to check, and that is discovery work. The checklist then runs against the products that matter, in the order the two-lens rule ranked them.

Can I put these in an RFP? Yes, and that is where they do the most good, because a requirement stated before selection costs nothing and the same requirement discovered after signature costs a renegotiation. The three facts translate directly into contract language covering the named module, its approved-algorithm list, and a maintained validation date.

---

Everything here is the map, given freely, and the three questions are yours to run on the next quantum-safe claim that reaches your desk. The version scaled across your whole vendor estate, with the answers weighted against where your sensitive data actually flows and written into contract language, is the work I do. Request the workshop.

Last verified 2026-08-19 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.