The market is filling with PQC claims. Some are legitimate. Many are marketing. A few are actively misleading. This lesson gives you a systematic framework for evaluating any vendor's PQC claim, identifying red flags, asking the right questions, and scoring claims by evidentiary strength. This is a skill you will use on Monday morning.
Unit 2 progress
By the end of this lesson you will be able to
Identify the seven red flags that signal a weak or misleading PQC claim
Apply a five-question due diligence framework to any vendor's PQC materials
Score a vendor's claim using the three-tier evidentiary framework from Lesson 2.1
Write three precise due-diligence questions for a specific vendor scenario
Explain why "quantum-safe" without specifics is not a technical claim
Part 1 — Why vendor claims require scrutiny
PQC is a compliance and marketing opportunity for vendors. Every security vendor, cloud provider, hardware manufacturer, and software platform has a commercial incentive to claim quantum readiness. Most of them mean well. Some of them understand what they are claiming. Fewer of them can substantiate it under scrutiny.
The problem is not usually outright deception, it is imprecision. "Quantum-safe" has no standardized technical definition. "Post-quantum ready" does not specify which algorithm, which parameter set, or whether any validation has occurred. "NIST-aligned" could mean anything from "we read the FIPS 203 specification" to "we hold CMVP certificate #4821 for ML-KEM-768 on three platforms." Those are not equivalent claims.
Your job as an evaluator is to translate a vendor's marketing language into a specific, checkable technical claim, and then check it. The seven red flags below are the patterns that consistently signal a claim that cannot be substantiated.
Part 2 — The seven red flags: scan this vendor statement
The vendor statement below contains all seven red flags. Click each flagged phrase, or click the items in the legend, to see why it is a problem and what you should ask instead.
Vendor claim scanner
"ArmorQ Enterprise Security Suite is fully quantum-safe and future-proof against all emerging threats. Our proprietary QuantumShield™ encryption engine exceeds NIST guidelines and provides military-grade protection. ArmorQ has been independently tested by leading cybersecurity experts and meets the highest standards of quantum resistance. Our team closely follows the NIST PQC process and will be releasing quantum-safe updates in our upcoming roadmap."
BFor SMB decision-makers: the statement above is the type of language you will encounter in sales calls, procurement documents, and vendor security questionnaires. None of the seven phrases contain a verifiable technical claim. Before your next vendor renewal or new purchase involving security infrastructure, run any PQC claim through this red flag checklist. A vendor who cannot replace these phrases with specific FIPS references and CMVP certificate numbers is not ready to substantiate their claim.
Part 3 — The five-question due diligence framework
Once you have identified red flags, the next step is structured questioning. These five questions work for any vendor in any context: TLS library, certificate management platform, VPN appliance, HSM, or cloud service. Open each question to see why it matters and what good and bad answers look like.
CFor IT professionals: these five questions map directly to your procurement process. Add them to your vendor security questionnaire template. For existing contracts, schedule a vendor call specifically on PQC readiness and work through all five. Document the answers, they become part of your CBOM and migration planning record. A vendor who scores 4/5 or 5/5 is a credible migration partner. A vendor who scores 0/5 is a migration liability that needs a remediation plan or a replacement decision.
AFor motivated learners: being able to conduct this framework in a vendor meeting is a career-ready skill. Practice it by picking a real security vendor you know, a TLS library, a certificate platform, a VPN product, looking up their public PQC documentation, and scoring them against all five questions. The result will show you immediately whether their claim is substantiated. This kind of vendor analysis is exactly what security consultants and procurement teams need and struggle to do systematically.
Part 4 — Scoring a claim: the evaluation scorecard
After gathering answers to the five questions, you have enough information to score the vendor's overall PQC claim. The scorecard below maps your findings to a defensible assessment.
Vendor PQC claim evaluation scorecard
Criterion
Strong evidence
Gap / concern
Algorithm specificity
Named: ML-KEM / FIPS 203, ML-DSA / FIPS 204, or SLH-DSA / FIPS 205
Only "quantum-safe," "post-quantum," or proprietary name used
FIPS validation status
CMVP certificate number provided and verifiable at csrc.nist.gov
In CMVP pipeline — lab name and submission date provided
Platform coverage
Certificate covers the specific platform you are deploying
Certificate exists but does not cover your OS / hardware / version
Migration timeline
Published roadmap with specific dates and currently supported FIPS algorithms
General commitment to PQC with no specific dates
Hybrid / transition support
Hybrid mode supported — classical + PQC simultaneously during transition
PQC-only, no hybrid — forces you to cut over entirely before ecosystem is ready
A vendor who scores strong evidence on all five criteria is a credible PQC migration partner. A vendor who scores gaps on algorithm specificity and FIPS validation, regardless of how confident their marketing language sounds, cannot substantiate their claim. Document your scorecard for every critical vendor in your environment. It becomes your procurement record and your migration risk register.
A sixth due diligence question: for high-assurance deployments
The five-question framework covers algorithm specificity, FIPS validation, platform coverage, migration timeline, and hybrid mode. For deployments where the cryptographic implementation will protect high-value or regulated data (financial transactions, healthcare records, government communications, classified information), add a sixth question:
"How do you guarantee your implementation resists side-channel attacks, specifically timing attacks?"
A PQC algorithm can be mathematically unbreakable and still leak key material through its implementation if the code takes different amounts of time to execute depending on secret key values. This is a software problem, not just a hardware one, and it is remotely exploitable over a network. The correct answer involves constant-time implementation: code that executes identically regardless of key values. A vendor who cannot explain how they achieve this, or who says "we use a standard library" without naming the library and its constant-time guarantees, has not addressed it.
One shortcut: a vendor with CMVP validation under FIPS 140-3 has had their module boundary, self-tests, and physical security evaluated by an accredited laboratory. This provides evidence of implementation quality beyond algorithm correctness, another concrete reason why the aligned/validated distinction from Lesson 2.1 matters in practice.
Note: This question is most relevant for organizations implementing PQC at the library or module level (financial institutions, government agencies, and defense contractors in particular). For most SMBs deploying commercial software or cloud services, the vendor's CMVP validation status is the practical proxy for this question.
Part 5 — Two real-world claim scenarios
Apply the framework to these two contrasting vendor scenarios before the comprehension check.
Vendor A — Credible claim
"Our TLS library implements ML-KEM-768 (FIPS 203) for key exchange, deployed in hybrid mode as X25519MLKEM768. We submitted for CMVP validation in January 2025 with UL's testing laboratory. Certificate issuance is expected Q3 2025. Certificate #xxxx will be publicly searchable at csrc.nist.gov. ML-DSA (FIPS 204) certificate migration is on our roadmap for Q1 2026 pending CA ecosystem readiness."
✓ Specific algorithm named (ML-KEM-768, FIPS 203)
✓ CMVP submission in progress with named lab and date
✓ Certificate migration roadmap with specific dates
⚠ Not yet validated — follow up when certificate #xxxx is issued
Vendor B — Unsubstantiated claim
"SecureVault Pro now includes post-quantum encryption powered by our advanced QuantumGuard technology. Our security team has implemented next-generation cryptographic algorithms that exceed current NIST requirements and provide comprehensive protection against quantum threats. SecureVault Pro is quantum-ready for the challenges ahead."
✗ No algorithm named — "QuantumGuard technology" is not a standard
✗ No FIPS reference — "exceeds NIST requirements" is unverifiable
✗ No CMVP certificate or submission reference
✗ No migration timeline or hybrid mode information
✗ Every phrase is marketing language with no technical content
Comprehension check
Question 1 of 3
A vendor says their product is "NIST-aligned for post-quantum security." What is the most important follow-up question?
Question 2 of 3
A vendor provides CMVP certificate #4892 for their product. You look it up and find it covers AES-256, SHA-384, and HMAC-SHA-256 on Linux x86-64. They claim this proves their product is "FIPS-validated for quantum-safe communications." What is wrong?
Question 3 of 3
Why is "independently tested by leading cybersecurity experts" a red flag rather than a credible claim?