Sign in Subscribe
migration

PQC Vendor Landscape: An Independent Framework for CISOs and Procurement Teams

PQC Vendor Landscape: An Independent Framework for CISOs and Procurement Teams

The phrase "quantum-ready" has been appearing on vendor datasheets since at least 2021 - long before NIST finalized a single post-quantum standard. Now that the regulatory floor has shifted, that marketing language is no longer a differentiator; it is a liability screen. Federal agencies and government contractors operating under Executive Order 14306, signed June 6, 2025, are facing a procurement environment where the difference between a vendor that has implemented ML-KEM across production infrastructure and one that has added "PQC roadmap" to its website carries real compliance consequences.[Source] The January 2026 CISA publication of its PQC product category list made that distinction enforceable.[Source] If your next RFP cycle does not include a structured cryptographic compliance questionnaire, you are selecting vendors on obsolete criteria.

How CISA's Product Category Framework Should Drive Your Vendor Shortlist

On January 26-27, 2026, CISA published its official list of product categories for technologies that use post-quantum cryptography standards - a document that operationalizes Executive Order 14306's mandate into procurement-actionable categories.[Source] The framework introduces a two-tier taxonomy that every procurement team must internalize before issuing a single RFP.

The first tier is "widely available" - product categories in which NIST-standardized PQC algorithms are already implemented and commercially available at scale. CISA has designated four categories here: cloud services (IaaS and PaaS), web software, collaboration tools, and endpoint security.[Source] The policy implication is direct: procuring a product in one of these categories that does not support ML-KEM or the applicable signature algorithms is no longer a defensible gap - it is a procurement failure in the context of federal solicitations.

The second tier is "transitioning" - categories where implementation is underway but not yet broadly available. These include networking hardware, SaaS platforms, telecommunications infrastructure, identity and credential access management (ICAM) hardware, password managers, antivirus software, storage solutions, and operational technology (OT)/IoT devices.[Source] For procurement teams, transitioning does not mean exempt - it means you must ask harder roadmap questions now, because the window to negotiate contractual PQC commitments into multi-year agreements is closing.

The 90-day implementation guidance embedded in EO 14306 and CISA's January 2026 publication means federal agencies had approximately until April 2026 to begin requiring PQC support in solicitations for widely available categories.[Source] For government contractors, the downstream effect is equally concrete: prime contractors will be required to flow these standards down into subcontractor agreements. If you are a regulated entity in financial services, healthcare, or critical infrastructure, treating this federal timeline as a leading indicator for your own procurement standards is the appropriate posture.

What NIST Standardization Actually Requires - And How to Verify Vendor Claims

NIST finalized three post-quantum cryptographic standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SPHINCS+, a hash-based signature scheme).[Source] A vendor claiming PQC compliance must be measured against these specific standards - not against experimental implementations, pre-standardization drafts, or proprietary "quantum-resistant" schemes. Understanding the technical distinctions between ML-KEM, ML-DSA, and HQC (selected in March 2025 as a backup algorithm) is essential for any procurement team that intends to write enforceable compliance language into contracts.

The most common and consequential gap in vendor implementations is the signature algorithm problem. Many vendors - particularly those serving TLS and VPN use cases - have prioritized key encapsulation (ML-KEM) because it maps cleanly onto existing key exchange mechanisms. Digital signature migration is harder: it requires changes to certificate infrastructure, code signing pipelines, firmware authentication, and identity verification workflows. As a result, a vendor may legitimately claim FIPS 203 compliance for key establishment while having no production roadmap for FIPS 204 or FIPS 205.[Source] Procurement teams that do not ask explicitly about signature algorithm coverage will systematically undercount their cryptographic exposure.

For procurement professionals without a deep cryptographic background, here is a plain-language verification checklist:

  • Algorithm specificity: Can the vendor name the exact FIPS standard - FIPS 203, 204, or 205 - rather than generically referencing "NIST PQC standards"? Vague references are a yellow flag.
  • Implementation scope: Does the claim cover production systems or only a beta/preview feature? Ask for release notes or changelog documentation showing general availability.
  • CMVP status: Has the vendor submitted their cryptographic module for NIST Cryptographic Module Validation Program (CMVP) testing? As of early 2026, no FIPS 140-3 validated PQC module exists - but vendors should at minimum be able to describe their submission timeline.[Source]
  • Hybrid mode support: Does the implementation support hybrid classical/PQC operation during the migration window, or does it require a hard cutover?
  • Third-party audit: Has an independent security firm audited the PQC implementation? Self-attestation is insufficient for high-assurance procurement.

Widely Available Categories - What Leading Vendors Are (and Aren't) Delivering

CISA's four widely available categories map to the highest-volume procurement decisions most enterprises make annually. Here is what independent assessment of the market shows across each category as of early 2026.

Cloud Services (IaaS and PaaS)

Major hyperscale cloud providers have been the most aggressive early adopters of ML-KEM. AWS, Google Cloud, and Microsoft Azure have all published technical documentation or blog posts describing ML-KEM support in their TLS implementations, typically in hybrid mode alongside ECDHE.[Source] However, "supported in TLS" is not equivalent to "fully deployed across all services." Key management services (KMS), secrets managers, and certificate authorities within these platforms vary significantly in their PQC readiness. Procurement teams should request a service-level PQC matrix from cloud vendors - not a single platform-level attestation - and verify whether ML-DSA is in scope for code signing and API authentication.

Web Software

Web server software and content delivery layers present a more fragmented picture. Open-source server software including recent versions of nginx and Apache have community-level PQC integrations available, but production-grade, FIPS-aligned builds require additional configuration and are not default deployments. Commercial web application firewall and CDN vendors have been faster - several major CDN providers have announced ML-KEM hybrid support in TLS 1.3 handshakes.[Source] The gap to watch here is certificate issuance: no major public Certificate Authority had issued production ML-DSA certificates at scale as of early 2026, meaning web software PQC claims are currently limited to key exchange and do not extend to the full authentication chain.

Collaboration Tools

Enterprise collaboration platforms - video conferencing, messaging, and file sharing - have been inconsistent. Signal Protocol-based implementations have been the furthest along, with Signal itself announcing PQXDH (an ML-KEM hybrid key agreement protocol) in production.[Source] Enterprise-grade platforms targeting federal and regulated industry customers have prioritized compliance alignment, though implementations differ between in-transit encryption (where ML-KEM is more common) and at-rest encryption (where PQC adoption remains sparse). For federal procurement specifically, collaboration tools must be evaluated against both NSA CNSA 2.0 requirements and the CISA product list framework simultaneously - understanding the CNSA 2.0 deadline matrix for different system types is essential context for any defense or IC contractor evaluating collaboration platforms.

Endpoint Security

Endpoint detection and response (EDR) and endpoint encryption vendors are perhaps the most uneven of the four widely available categories. The core challenge is that endpoint security products sit at the intersection of cryptographic operations (disk encryption, certificate validation, secure boot) and behavioral analytics - two architecturally distinct functions with different PQC migration timelines. Full-disk encryption vendors have made limited progress on PQC key wrapping for recovery keys. Code signing for endpoint agent updates - a critical attack surface - remains almost entirely on RSA or ECDSA as of early 2026, meaning adversaries who compromise a vendor's signing infrastructure face a much lower bar than the PQC marketing language suggests.[Source]

Transitioning Categories: Realistic Timelines and What to Ask Vendors Today

For categories CISA has designated as transitioning, the procurement challenge shifts from compliance verification to roadmap negotiation. Eight-plus categories fall into this tier, including networking hardware, SaaS platforms, telecommunications, ICAM hardware, password managers, antivirus, storage, and OT/IoT. OT and IoT devices are explicitly excluded from current mandates due to the hardware constraints and operational risk involved in firmware updates at scale - a critical caveat for readers in critical infrastructure, utilities, and manufacturing.[Source]

Networking hardware deserves special attention for its combination of long procurement cycles and deep cryptographic dependencies. Routers, switches, and VPN concentrators performing IPsec and IKEv2 key exchange are primary ML-KEM migration targets. Major networking vendors have published CNSA 2.0 compliance roadmaps with timelines ranging from 2026 to 2030 depending on platform generation - but these roadmaps are frequently tied to hardware refresh cycles rather than software updates, meaning organizations running older generation hardware may face capital expenditure timelines that outpace regulatory deadlines. The capital and operational cost structure of PQC migration is a planning input that must be included in any multi-year vendor contract negotiation for transitioning categories.

For transitioning vendors, send this minimum set of questions with every RFP or contract renewal:

  1. What is your committed general availability date for ML-KEM (FIPS 203) in [specific product]?
  2. Does your roadmap include ML-DSA or SLH-DSA for digital signature operations - and on what timeline?
  3. Will PQC functionality require a hardware upgrade, or is it available via software/firmware update to existing deployments?
  4. What is your CMVP submission timeline for PQC-enabled cryptographic modules?
  5. What contractual remedies exist if your stated PQC roadmap dates slip?

The Hidden Complexity - Hybrid Cryptography, Interoperability, and Supply Chain Validation

The most underappreciated procurement risk in the current PQC transition is not which vendors have implemented PQC - it is whether your multi-vendor environment will achieve interoperable PQC operations during the hybrid migration window. Every major standards body, including NIST and ETSI, recommends hybrid classical/PQC operation during transition to protect against both classical and quantum threats simultaneously.[Source] In practice, this means your TLS-terminating load balancer, your API gateway, your PKI infrastructure, and your VPN concentrator must all support hybrid key encapsulation with compatible algorithm selections - across vendors who may implement hybrid modes differently.

The threat context reinforces why this interoperability work is not optional. Orange Cyberdefense's Security Navigator 2026 documented 139,373 security incidents in a single reporting period - a threat environment in which the harvest-now-decrypt-later attack model means that encrypted data being captured today will be retroactively decryptable once sufficiently capable quantum systems become available.[Source] The adversarial calculus around harvest-now-decrypt-later and why each month of delay creates irreversible exposure applies directly to procurement decisions: a two-year vendor contract signed without PQC commitments today is a two-year window of unprotected data accumulation.

Supply chain validation adds another layer. A vendor's own PQC implementation may be sound, but if their product relies on third-party cryptographic libraries - OpenSSL, BoringSSL, or proprietary modules - the compliance chain extends to those dependencies. Procurement teams should require vendors to identify all cryptographic library dependencies and confirm PQC support through the full stack, not just at the API surface. The institutional momentum behind this requirement is significant: the Year of Quantum Security 2026 (YQS2026) initiative, launched January 12, 2026 with backing from the FBI, CISA, and NIST, has explicitly called on vendors to disclose PQC implementation status across their full product stack.[Source]

Building an Independent Vendor Evaluation Scorecard for PQC Readiness

The following scoring framework is designed for use in formal RFP processes and existing vendor reviews. It is deliberately algorithm-neutral in structure - adaptable across CISA's widely available and transitioning categories - and maps to verifiable evidence rather than vendor assertions. CISOs building a crypto-agile vendor evaluation process should treat this scorecard as the cryptographic compliance component of a broader agility assessment.

Dimension 1: Algorithm Compliance (0-25 points)

  • 25 points: Full implementation of FIPS 203 (ML-KEM) and at least one signature standard (FIPS 204 or FIPS 205) in production, documented in release notes or technical documentation referencing specific FIPS designations.
  • 15 points: FIPS 203 in production; FIPS 204/205 in beta or committed roadmap with stated GA date within 12 months.
  • 5 points: Pre-standardization or draft-based PQC implementation with stated FIPS alignment roadmap.
  • 0 points: Generic "quantum-resistant" claim with no FIPS citation or roadmap.

Dimension 2: Implementation Scope (0-20 points)

  • 20 points: PQC implemented across all relevant cryptographic operations in the product (key exchange, signatures, certificate validation, at-rest encryption where applicable).
  • 10 points: PQC implemented for key exchange only; signature and certificate operations remain classical.
  • 5 points: PQC available as optional configuration; not default deployment.
  • 0 points: PQC not yet in any production component.

Dimension 3: Third-Party Validation (0-20 points)

  • 20 points: CMVP submission filed or validation in progress; independent security audit of PQC implementation completed.
  • 10 points: CMVP submission planned with stated timeline; internal security review documented.
  • 5 points: Third-party audit planned; no CMVP engagement.
  • 0 points: Self-attestation only; no third-party validation.

Dimension 4: Roadmap Transparency (0-20 points)

  • 20 points: Publicly published PQC roadmap with specific version numbers, dates, and hardware/software upgrade requirements clearly stated.
  • 10 points: Roadmap available under NDA with specific dates; not publicly disclosed.
  • 5 points: General timeline statements without version or date specificity.
  • 0 points: No roadmap available.

Dimension 5: Hybrid and Interoperability Support (0-15 points)

  • 15 points: Hybrid classical/PQC mode supported per NIST or ETSI guidance; interoperability tested with major ecosystem partners documented.
  • 8 points: Hybrid mode supported; interoperability testing not documented.
  • 3 points: Hybrid mode on roadmap.
  • 0 points: Hard PQC-only cutover required; no hybrid mode.

Scoring interpretation: 80-100: Vendor meets current procurement standards for widely available categories. 60-79: Acceptable for transitioning categories with contractual roadmap commitments. 40-59: Require escalation and contractual remedies before renewal. Below 40: Treat as non-compliant for any federal or regulated procurement context.

Key Takeaways

  • CISA's January 2026 PQC product category publication is the operative procurement document - it creates a "widely available" standard that makes non-compliant cloud, web, collaboration, and endpoint products actively non-compliant in federal solicitations from approximately April 2026 onward.
  • The signature algorithm gap is the most commonly overlooked compliance failure: vendors may have implemented ML-KEM (FIPS 203) for key encapsulation while having no production roadmap for ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) - always ask about both functions explicitly.
  • No FIPS 140-3 validated PQC cryptographic module exists as of early 2026; CMVP submission status is the correct question to ask, not CMVP certification.
  • For transitioning categories - networking hardware, SaaS, ICAM, telecom, password managers - negotiate PQC roadmap commitments and contractual remedies into multi-year agreements now, before renewal leverage is lost.
  • Hybrid classical/PQC interoperability across multi-vendor environments is the primary technical risk during the migration window; validate compatibility across your full cryptographic stack, not per-vendor in isolation.
  • OT and IoT devices are explicitly excluded from current PQC mandates - but critical infrastructure operators should begin inventory and risk assessment now given hardware refresh constraints.
  • Use the five-dimension vendor scorecard in this article as the cryptographic compliance layer in your RFP process; scores below 60 should trigger contractual escalation before renewal.

This article draws on primary documentation from CISA (Post-Quantum Cryptography product category list, January 2026), NIST (FIPS 203, FIPS 204, FIPS 205, and the CMVP program documentation at csrc.nist.gov), the White House (Executive Order 14306, June 6, 2025), ETSI (Quantum Safe Cryptography standards and migration guidance), and Orange Cyberdefense (Security Navigator 2026, February 2026). All claims verified against official sources as of March 2026.

Disclaimer: This content is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Consult a qualified professional before making compliance decisions. pqcinformation.com is independent and not affiliated with any vendor or standards body.

Read next