Why Vendor Assessment Matters for PQC
Your organization’s ability to transition to post-quantum cryptography depends heavily on your technology vendors. Every encryption library, HSM, cloud service, TLS termination point, VPN appliance, and certificate authority in your stack must support PQC algorithms — and the transition requires coordinated effort across your entire supply chain.
The challenge is that vendor PQC readiness varies dramatically. Some vendors have been shipping ML-KEM support since 2024. Others have no public roadmap. Procurement teams and security architects need structured evaluation frameworks to separate vendors who are genuinely PQC-ready from those who are marketing vaporware.
This guide provides the questions to ask, the answers to expect, and a scoring methodology that procurement teams can use immediately.
The PQC Vendor Readiness Landscape
Current Market Reality (2026)
The PQC vendor landscape falls into distinct tiers:
| Tier | Description | Examples |
|---|---|---|
| Tier 1: Shipping | PQC algorithms available in production | Google (BoringSSL), Cloudflare, AWS, Apple |
| Tier 2: Beta/Preview | PQC implementations available for testing | Microsoft (CNG), Entrust, DigiCert |
| Tier 3: Roadmapped | Public commitment with timeline | Thales, Fortinet, Palo Alto Networks |
| Tier 4: Silent | No public PQC commitment or roadmap | Many enterprise software vendors |
Organizations relying heavily on Tier 4 vendors face significant transition risk. These vendors may delay your migration beyond regulatory deadlines.
Why This Assessment Cannot Wait
- CNSA 2.0 mandates ML-KEM for key exchange in national security systems by 2030 and pure PQC by 2033
- PCI DSS 4.0 requires organizations to inventory cryptographic assets and plan for quantum threats
- Contract cycles mean vendor switches take 12-24 months — you need answers now for migrations happening in 2027-2028
- HNDL exposure means every day without PQC key exchange adds data to adversary collection pools
Core Assessment Areas
Area 1: Algorithm Support
This is the foundation. A vendor cannot be PQC-ready without implementing the standardized algorithms.
Questions to Ask:
-
Which NIST PQC algorithms do you currently support?
- Expected answer: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205)
- Red flag: Only supporting deprecated/non-standard algorithms (e.g., Round 3 Kyber without final FIPS 203 compliance)
-
Which parameter sets are supported?
- Expected answer: At minimum ML-KEM-768, ML-DSA-65; ideally all parameter sets
- Red flag: Only supporting Level 1/lowest parameter sets
-
What is your timeline for supporting the NIST standards (not draft, but final FIPS)?
- Expected answer: Already done, or specific quarter/year commitment
- Red flag: “We’re watching the space” or “when customer demand materializes”
-
Do you support HQC or FrodoKEM (post-Round 4 candidates) as alternatives?
- Good-to-have: Shows awareness of algorithm diversity and backup options
Scoring:
| Answer | Score |
|---|---|
| All three FIPS standards in production | 5/5 |
| ML-KEM + ML-DSA in production, SLH-DSA planned | 4/5 |
| ML-KEM in production, ML-DSA in beta | 3/5 |
| Algorithms in beta/preview only | 2/5 |
| Roadmap commitment only | 1/5 |
| No commitment | 0/5 |
Area 2: Hybrid Mode Capability
Hybrid cryptography — combining classical and PQC algorithms — is the recommended transition strategy. Vendors must support it.
Questions to Ask:
-
Do you support hybrid key exchange (e.g., X25519+ML-KEM-768)?
- Expected answer: Yes, as default or configurable option
- Red flag: PQC-only without hybrid option
-
Do you support hybrid signatures (e.g., ECDSA+ML-DSA composite certificates)?
- Expected answer: Yes, following draft IETF composite signatures standards
- Note: This is newer and less mature than hybrid key exchange
-
Can hybrid mode be enabled/disabled per connection, per service, or globally?
- Expected answer: Granular control at multiple levels
- Red flag: All-or-nothing toggle only
-
What happens if a peer doesn’t support the PQC component of hybrid negotiation?
- Expected answer: Graceful fallback to classical-only with logging/alerting
- Red flag: Connection failure or silent downgrade without notification
-
What is the performance overhead of hybrid vs. classical-only?
- Expected answer: Specific benchmarks (typically 5-15% latency increase for TLS handshake)
- Red flag: “No measurable impact” (unrealistic) or no data available
Scoring:
| Answer | Score |
|---|---|
| Hybrid key exchange + hybrid signatures in production | 5/5 |
| Hybrid key exchange in production, signatures planned | 4/5 |
| Hybrid key exchange in beta | 3/5 |
| Hybrid support planned with timeline | 2/5 |
| No hybrid support | 0/5 |
Area 3: FIPS 140-3 Validation
For regulated industries, FIPS validation is non-negotiable.
Questions to Ask:
-
Is your PQC implementation included in a FIPS 140-3 validated module?
- Expected answer: Yes, or “in CMVP queue with expected validation date”
- Context: Very few modules were validated for PQC before mid-2026
-
What is your FIPS 140-3 validation timeline for PQC algorithms?
- Expected answer: Specific quarter/year, referencing CMVP submission status
- Red flag: “After NIST finalizes everything” (they already have)
-
Which specific algorithms and parameter sets will be in scope for validation?
- Expected answer: At minimum ML-KEM-768/1024 and ML-DSA-65/87
- Red flag: Only Level 1 parameter sets in validation scope
-
Will validation cover both software and hardware (HSM) implementations?
- Expected answer: Both, potentially on different timelines
- Red flag: Software only with no HSM plan
Scoring:
| Answer | Score |
|---|---|
| FIPS 140-3 validated with PQC algorithms | 5/5 |
| In CMVP queue, expected validation within 6 months | 4/5 |
| Submission planned within 12 months | 3/5 |
| Will pursue validation, no timeline | 1/5 |
| Not pursuing FIPS validation | 0/5 |
Area 4: Key Management
PQC introduces significant changes to key management: larger keys, different lifecycle requirements, and new encapsulation mechanisms.
Questions to Ask:
-
How do you handle the larger key sizes for PQC algorithms?
- Expected answer: Updated storage, specific accommodations for ML-DSA keys (2.5-5 KB) and ML-KEM public keys (1.2-1.6 KB)
- Red flag: “Same as before” (suggests they haven’t actually tested)
-
Do your HSMs support PQC key generation and operations?
- Expected answer: Yes, specific HSM models and firmware versions cited
- Context: Thales Luna, Entrust nShield, AWS CloudHSM have varying PQC support
-
How does your key lifecycle management handle PQC key rotation?
- Expected answer: Automated rotation with PQC-specific considerations (e.g., ML-DSA key generation is slower)
- Red flag: No changes to key lifecycle processes
-
Do you support key encapsulation (KEM) natively, or only key agreement (DH-style)?
- Expected answer: Native KEM support — ML-KEM is a KEM, not a key agreement scheme
- Red flag: Trying to use ML-KEM as a drop-in DH replacement (misunderstanding of the primitive)
-
Can you manage hybrid key pairs (classical + PQC) as a single logical entity?
- Expected answer: Yes, composite key management
- Nice-to-have: Integrated with existing PKI/KMS workflows
Scoring:
| Answer | Score |
|---|---|
| Full PQC key lifecycle management with HSM support | 5/5 |
| PQC key management in software, HSM planned | 4/5 |
| Basic PQC key storage and generation | 3/5 |
| PQC keys treated as opaque blobs only | 2/5 |
| No PQC key management | 0/5 |
Area 5: Upgrade Path and Crypto-Agility
How easily can the vendor adapt as standards evolve or new algorithms are introduced?
Questions to Ask:
-
Can algorithms be updated without replacing hardware or requiring downtime?
- Expected answer: Software-configurable algorithm selection; firmware updates for hardware
- Red flag: Algorithm changes require hardware replacement
-
How do you handle algorithm deprecation?
- Expected answer: Configurable policy enforcement, deprecation warnings, graceful migration paths
- Red flag: No deprecation framework
-
Can customers run multiple algorithm versions simultaneously during transition?
- Expected answer: Yes, with per-connection or per-service algorithm selection
- Red flag: Single algorithm globally
-
What is your process when NIST releases updated standards or new algorithms?
- Expected answer: Regular update cadence (quarterly or faster), early access programs
- Red flag: Major version upgrades only (annual or longer)
-
Do you support algorithm negotiation that allows automatic selection of the strongest mutually supported algorithm?
- Expected answer: Yes, via standard protocol negotiation (TLS cipher suite negotiation, SSH kex algorithms)
- Red flag: Manual, static algorithm configuration only
Scoring:
| Answer | Score |
|---|---|
| Full crypto-agility: hot-swappable algorithms, automated negotiation | 5/5 |
| Algorithm updates via software/firmware with minimal disruption | 4/5 |
| Algorithm updates require planned maintenance window | 3/5 |
| Algorithm updates require major version upgrade | 2/5 |
| Hardware replacement needed for algorithm changes | 1/5 |
Area 6: Performance and Testing
PQC algorithms have different performance characteristics. Vendors must demonstrate they’ve tested at scale.
Questions to Ask:
-
What is the measured performance impact of PQC (hybrid or pure) on your product?
- Expected answer: Specific benchmarks — latency, throughput, CPU/memory usage
- Red flag: “Minimal impact” without data
-
Have you tested PQC at production scale (not just single-connection benchmarks)?
- Expected answer: Yes, with specific load testing results (connections/second, p99 latency)
- Red flag: Only micro-benchmarks or lab testing
-
What is the impact on certificate-related operations (issuance, validation, revocation)?
- Expected answer: Quantified impact of larger certificates on chain validation, OCSP, CRL
- Red flag: “We haven’t measured that yet”
-
How does PQC affect your product’s memory and storage requirements?
- Expected answer: Specific increases quantified (larger key stores, session caches)
- Red flag: Unquantified or “no impact”
-
Do you provide PQC-specific testing tools or sandboxes for customer evaluation?
- Expected answer: Test environments, integration test suites, performance benchmarking tools
- Nice-to-have: PQC interoperability testing with other vendors
Scoring:
| Answer | Score |
|---|---|
| Published benchmarks + customer testing sandbox + production validation | 5/5 |
| Published benchmarks + testing environment | 4/5 |
| Internal benchmarks shared on request | 3/5 |
| ”Minimal impact” without data | 1/5 |
| No performance testing done | 0/5 |
Area 7: Standards Compliance and Interoperability
Questions to Ask:
-
Which IETF drafts and RFCs do you implement for PQC protocol integration?
- Expected answer: Specific draft numbers for hybrid TLS, composite signatures, PQC in IKEv2
- Red flag: Proprietary PQC protocol extensions
-
Have you participated in PQC interoperability testing?
- Expected answer: Yes — NIST PQC interop events, IETF hackathons, or vendor-to-vendor testing
- Red flag: Isolated implementation with no interop validation
-
Do you align with CNSA 2.0 timelines and requirements?
- Expected answer: Explicit mapping of product capabilities to CNSA 2.0 phases
- Critical for: Government/defense vendors, FedRAMP-certified products
-
How do you handle the transition period where some peers support PQC and others don’t?
- Expected answer: Negotiation-based algorithm selection, fallback policies, compatibility modes
- Red flag: Requires all parties to upgrade simultaneously
Scoring:
| Answer | Score |
|---|---|
| Full standards compliance + interop tested + CNSA 2.0 aligned | 5/5 |
| Standards-compliant implementation + some interop testing | 4/5 |
| Following standards but limited interop validation | 3/5 |
| Proprietary implementation with standard alignment planned | 2/5 |
| No standards alignment | 0/5 |
Vendor Qualification Checklist
Summary Scorecard
| Assessment Area | Weight | Max Score | Vendor Score | Weighted |
|---|---|---|---|---|
| Algorithm Support | 25% | 5 | ___ | ___ |
| Hybrid Mode | 20% | 5 | ___ | ___ |
| FIPS 140-3 Validation | 15% | 5 | ___ | ___ |
| Key Management | 15% | 5 | ___ | ___ |
| Upgrade Path / Crypto-Agility | 10% | 5 | ___ | ___ |
| Performance & Testing | 10% | 5 | ___ | ___ |
| Standards & Interoperability | 5% | 5 | ___ | ___ |
| Total | 100% | 5.0 | ___ |
Interpretation
| Total Weighted Score | Assessment | Action |
|---|---|---|
| 4.5 - 5.0 | PQC Leader | Proceed with confidence; potential migration partner |
| 3.5 - 4.4 | PQC Ready | Suitable for near-term deployment; validate specific gaps |
| 2.5 - 3.4 | PQC In Progress | May be suitable for 2027+ timeline; get written commitments |
| 1.5 - 2.4 | PQC Lagging | Significant risk; begin evaluating alternatives |
| 0 - 1.4 | PQC Not Ready | Do not depend on this vendor for PQC timeline; switch vendors |
Procurement Contract Language
Required Contract Provisions
When renewing or signing vendor contracts, include these PQC-specific requirements:
1. Algorithm Support Commitment
“Vendor shall support NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) algorithms at Security Level 3 or higher within [X months] of contract execution.”
2. Hybrid Mode Requirement
“Vendor shall provide hybrid cryptographic mode combining classical (ECDH/ECDSA) and post-quantum (ML-KEM/ML-DSA) algorithms, deployable without service interruption.”
3. FIPS Validation Timeline
“Vendor shall submit PQC algorithms for FIPS 140-3 validation within [X months] and provide CMVP queue status updates quarterly.”
4. Crypto-Agility Clause
“Vendor shall support algorithm updates via software/firmware deployment without hardware replacement, with new algorithm support available within 90 days of NIST standard publication.”
5. Performance SLA
“PQC-enabled operations shall maintain [X]% of baseline throughput and add no more than [Y] ms to p99 latency.”
6. Migration Support
“Vendor shall provide migration tooling, documentation, and professional services support for transitioning from classical to post-quantum cryptography without service disruption.”
Category-Specific Assessment Considerations
HSM Vendors (Thales, Entrust, Utimaco, Marvell)
Additional questions:
- Which PQC algorithms are supported in hardware (not software emulation)?
- What is the key generation rate for ML-DSA and ML-KEM?
- Can PQC keys be stored alongside classical keys?
- What is the firmware update process for adding new algorithms?
- Is the HSM’s internal RNG suitable for PQC key generation requirements?
Cloud Providers (AWS, Azure, GCP)
Additional questions:
- Which managed services support PQC (KMS, Certificate Manager, TLS termination)?
- Is PQC available in all regions or limited geographic availability?
- What is the pricing impact of PQC operations?
- Do managed databases support PQC for encryption at rest key wrapping?
- Is PQC available for VPC/VPN connectivity between regions?
Certificate Authorities (DigiCert, Entrust, Sectigo, Let’s Encrypt)
Additional questions:
- When will you issue ML-DSA certificates?
- Do you support hybrid/composite certificates?
- What is your timeline for PQC-signed root certificates?
- How do you handle the larger certificate sizes in OCSP/CRL?
- Do your validation systems support PQC signatures?
Network Security (Fortinet, Palo Alto, Cisco, Juniper)
Additional questions:
- Which product lines support PQC VPN (IPsec with ML-KEM)?
- Is PQC offloaded to hardware or software-only?
- What is the throughput impact for PQC-enabled VPN tunnels?
- Do firewalls support inspection of PQC-encrypted TLS traffic?
- What firmware version introduces PQC support?
Using QCecuring CBOM for Vendor Assessment
QCecuring CBOM plays a critical role in vendor assessment by providing visibility into which vendors’ products exist in your cryptographic infrastructure:
- Vendor dependency mapping: Identifies which vendor products implement cryptography in your environment
- Algorithm usage by vendor: Shows which classical algorithms each vendor’s product uses — quantifying the migration scope per vendor
- Risk prioritization: Highlights which vendor relationships have the highest HNDL exposure based on the algorithms their products use
- Progress tracking: Monitors as vendors ship PQC updates, verifying that deployments actually achieve PQC protection
- Contract compliance verification: Validates that vendor PQC commitments translate to actual deployed cryptographic protection
Organizations use QCecuring CBOM to generate vendor-specific migration reports: “Vendor X’s product currently uses RSA-2048 for Y connections — when will ML-KEM be available to replace this?”
Key Takeaways
- Vendor PQC readiness varies dramatically — from production-deployed to no roadmap at all
- Assessment must cover seven key areas: algorithm support, hybrid mode, FIPS validation, key management, crypto-agility, performance testing, and standards compliance
- Use the weighted scorecard to compare vendors objectively and identify migration risks
- Include PQC contract language in all vendor agreements now — even if deployment is 1-2 years away
- Tier 4 vendors (no commitment) represent critical risk — begin evaluating alternatives immediately
- FIPS 140-3 validation is the gating factor for regulated industries — ask for CMVP submission timelines
- Crypto-agility is more important than current algorithm support — vendors that can update quickly are safer bets than those with current support but rigid architectures
- QCecuring CBOM identifies which vendors matter most by mapping cryptographic usage to vendor products in your environment
- Don’t accept “we’re watching the space” — NIST standards are final, implementations exist, there is nothing left to watch
- Start assessments now — contract cycles mean switching vendors takes 12-24 months