CISA’s new product-category lists mark a practical turning point in how organizations — and especially federal agencies — must buy, architect, and test for post-quantum cryptography (PQC) readiness, requiring acquisition plans that favor PQC-capable products in specified categories and calling for rapid operational planning to avoid “harvest now, decrypt later” exposures.
Background / Overview
The June 6, 2025 Executive Order (EO 14306) tasked CISA, working with NSA and other partners, to identify product categories where
products supporting post-quantum cryptography standards are widely available and to update that list regularly. The resulting guidance organizes categories into (1) those with widely available PQC-capable products that federal buyers should now prefer, and (2) categories that are still transitionansitioning and where manufacturers are explicitly encouraged to implement and test PQC capabilities.
Two cryptographic functions are central to the CISA lists:
key establishment (how keys for encryption are securely created and shared) and
digital signatures (authentication, integrity, and non‑repudiation). The guidance follows NIST’s transition framing (notably NIST IR 8547) that maps quantum‑vulnerable primitives to quantum‑resistant replacements and emphasizes staged migration and crypto‑agility. Organizations should treat the lists as procurement guardrails: when a product category is listed as PQC‑capable and widely available, plan to procure only PQC‑capable products in that category.
What CISA’s Tables Say (Plain English)
Table 2 — Widely available PQC-capable categories (buy PQC-only)
- Cloud services (IaaS, PaaS)
- Collaboration software (chat, messaging)
- Web software (browsers, web servers)
- Endpoint security (data‑at‑rest encryption, full‑disk encryption)
CISA notes many of these categories have implemented PQC for
key encapsulation and key agreement (key establishment) more commonly than for digital signatures, so they are not
fully quantum‑resistant yet; they are included because their
principal security service already uses quantum‑resistant KEMs or KEX schemes. Agencies must still check for PQC across all relevant functions (including software updates and firmware signing).
Table 3 — Categories transitioning to PQC (encouraged to implement & test)
- Networking hardware and software (routers, firewalls, DNS, SDN)
- Cloud SaaS
- Telecommunications hardware (VoIP, radios)
- Operating systems, hypervisors, containers
- ICAM (PKI, identity providers, HSMs)
- Storage systems, databases, enterprise security tooling
CISA treats Table 3 as a “watch list”: these categories must aggressively adopt PQC for both core and secondary features (updates, attestation, firmware signing). As they mature, they will be moved into Table 2.
Why This Matters Now: The Security Rationale
- Harvest now, decrypt later is the single most important driver. Adversaries can capture encrypted traffic and wait until a cryptographically relevant quantum computer (CRQC) appears to decrypt it. PQC adoption mitigates that risk for long‑lived secrets.
- Federal procurement scale: Government buying rules and large enterprise contracts shape the marketplace; federal preference for PQC-capable products will accelerate vendor implementation timelines and ecosystem interoperability.
- Standards are already actionable: NIST’s PQC program has produced candidate standards for key‑encapsulation and signature schemes and has published transition guidance (for example, NIST IR 8547). Vendors and platform providers are shipping initial support; the policy task is to convert that to operational procurement and testing.
Category-by-Category Analysis and What IT Buyers Need to Know
Cloud Services (IaaS / PaaS)
Cloud providers were early movers on PQC experimentation and early production rollouts for KEMs and, in some managed KMS/HSM offerings, PQC signatures. Expect:
- Hybrid TLS and key‑wrap options to let customers test PQC without breaking interop.
- HSM and KMS services that either support PQC in software (for testing) or add hardware‑backed PQC primitives in premium tiers.
Strengths:
- Cloud providers can roll out PQC at scale more rapidly than edge vendors.
- Managed HSMs can abstract complexity and provide vetted PQC endpoints for customers.
Risks and caveats:
- Performance and ciphertext size impacts vary by algorithm; bench before production. Vendor performance claims for PQC ops are algorithm‑ and workload‑dependent and require independent validation. Procurement teams should request algorithm‑specific throughput and latency figures measured with representative workloads.
Action checklist:
- Prioritize cloud offerings with documented PQC KEM support and upgrade paths for PQC signatures.
- Require vendor test results for your typical crypto workloads.
- Ensure your PKI and certificate lifecycle tooling support hybrid certificates and crypto‑agility.
Web Software (Browsers and Servers) and Collaboration Software
Browsers, web servers, and messaging platforms are moving to support PQC hybrids for TLS and signed artifacts. The practical path is hybrid TLS (classical + PQC) to reduce risk while maintaining interop.
Procurement implications:
- Require support for hybrid TLS and proof of interoperability with mainstream PKI/CA architectures.
- Confirm that user‑facing clients (browsers, mobile apps) are updated to accept PQC‑strengthened server certificates.
Vendors are already providing preview PQC APIs and SDKs for these categories; agencies must run integration tests on real application stacks.
Endpoint Security (DAR, FDE, BitLocker)
Endpoint encryption vendors and OS vendors are introducing PQC primitives into platform crypto stacks (for example, PQC APIs in OS crypto libraries and silicon‑level key wrapping). This is a crucial area because endpoints store long‑lived secrets and disk images.
Key points:
- BitLocker-style disk encryption and full‑disk encryption workflows are beginning to expose PQC APIs so organizations can adopt hybrid or PQC‑first signing and key establishment. However, wide hardware support (SoC, TPM, secure enclave) is still in rollout phases.
Risks:
- Offloading keys to firmware or silicon reduces attack surface but increases reliance on vendor firmware security, patch cadence, and supply‑chain integrity.
- Recovery semantics (key escrow, enterprise recovery workflows) are not always fully detailed in early vendor announcements; treat GA dates and compatibility claims cautiously.
Identity, Credential, and Access Management (ICAM) and HSMs
ICAM and HSMs are mission‑critical: PKI roots, certificate authorities, signing services, and hardware key custody must become PQC‑capable.
What vendors are doing:
- Cloud HSM vendors are integrating PQC KEMs and planning signature support; some premium HSM offerings advertise PQC roadmap and certification (FIPS / Common Criteria / eIDAS) alignment.
Procurement checks:
- Request formal certification artifacts and scope statements (FIPS 140‑3, Common Criteria, eIDAS QSCD) rather than press claims.
- Verify whether the HSM supports PQC algorithms natively (hardware‑accelerated) or via firmware/software updates, and whether updates are in‑field and auditable.
Networking Hardware and Software (Routers, Switches, DNS, SDN)
Networking stacks remain a transition locus: TLS termination on load balancers, router control plane authentication, and DNSSEC are all places PQC must appear.
Why this is hard:
- Network devices often run long‑lived firmware and have constrained CPU/memory budgets; PQC algorithms can increase key and packet sizes and CPU costs.
- Many network stacks still rely on legacy crypto in boot and management channels — those vectors must be upgraded to PQC for true end‑to‑end quantum resilience.
Immediate procurement guidance:
- For new purchases, require vendor PQC roadmaps and timelines for firmware updates.
- For existing fleets, plan segmentation, compensating controls, and replacement timelines for devices that cannot be updated.
Storage Systems, Databases, and Enterprise Security Tooling
Databases and storage appliances that protect long‑lived data need PQC for key establishment and for signing update/replication flows.
Key points:
- PQC adoption must include not only encryption payloads but also ancillary flows: snapshot signing, replication authentication, software/firmware updates, and backup vaulting.
- Endpoint backup keys and tape vaults are classic high-value targets for harvest‑now strategies; prioritize PQC in backup key‑wrap and key management.
Cross‑Reference: Vendor Activity & Independent Signals
- Major cloud providers and OS vendors are publicly adding PQC primitives to their key management and crypto stacks, typically as hybrid-mode previews or APIs for testing. These vendor moves corroborate the CISA procurement direction and show real product momentum.
- Hardware HSM and silicon vendors are packaging PQC support into premium (often PCIe) adapters and cloud HSM services with compliance roadmaps (FIPS 140‑3, Common Criteria, eIDAS). But the exact performance claims and certification artifacts must be audited and validated before being relied upon for compliance.
- Platform vendors (OS and endpoint) have introduced PQC APIs and experimental BitLocker/TPM flows in preview channels; these are essential early wins but do not yet constitute universal production readiness. Expect staged rollouts and continued refinement.
Strengths and Strategic Benefits of CISA’s Approach
- Procurement leverage: By declaring categories “PQC‑capable and widely available,” CISA uses federal procurement influence to accelerate vendor adoption and raise the market floor for quantum resistance.
- Practicality: The guidance recognizes realistic migration constraints (hybrid algorithms, staged rollout, interop) and focuses on the highest‑impact areas first: key establishment, KMS/HSM, cloud services, and endpoint disk encryption.
- Ecosystem nudging: Moving categories from “transitioning” to “widely available” will create a visible procurement bar that vendors must meet, reducing long‑tail compatibility issues later.
Risks, Gaps, and Where the Guidance Needs Careful Operationalization
- Incomplete signature coverage: Many categories have PQC for key establishment but not yet for digital signatures; full quantum resistance requires both. Buyers must confirm which algorithms are implemented for both functions.
- Performance and payload tradeoffs: PQC algorithms generally increase key and ciphertext sizes and, in some cases, CPU cost. These tradeoffs can affect latency-sensitive systems (e.g., network appliances, real‑time comms) and storage/backup capacity planning. Vendor performance claims vary widely; request empirical benchmarks.
- Firmware and supply‑chain risk: Moving keys into firmware or SoC (hardware wrapping) reduces some risks but centralizes trust in vendor firmware and supply chains. Firmware bugs or slow patching cycles can become systemic failures; require patch SLAs and attestation mechanisms.
- Unverifiable vendor roadmaps and dates: Many vendor announcements (press posts or previews) contain optimistic GA timelines or throughput claims. Treat these as provisional until validated by documentation, independent testing, or formal certification. Flaged claims should be explicitly validated during procurement.
Practical Procurement and Migration Playbook (Actionable Steps)
- Inventory and classify crypto assets by lifetime and function (key establishment vs signatures).
- Prioritize assets that protect long‑lived secrets (backups, archives, PKI root keys, FDE keys).
- When procuring from categories listed as PQC-capable, require:
- Explicit PQC algorithm support matrix (which KEMs and signature algorithms supported).
- Hybrid operation modes and interop test results.
- Performance benchmarks for your representative workloads.
- Firmware update, attestations, and patch SLAs.
- For Table 3 categories, require vendor PQC implementation roadmaps, test plans, and timelines for moving core and secondary functionality (including update signing) to PQC.
- Run integration tests:
- Hybrid TLS and certificate validation across your application stack.
- HSM/KMS PQC signing and key‑import/export semantics.
- Endpoint recovery and key escrow scenarios with PQC-wrapped keys.
- Document exception paths and compensating controls for devices that cannot be upgraded (segmentation, isolated networks, limited lifetimes).
- Maintain crypto‑agility: design systems to allow algorithm negotiation, key rotation, and multi‑algorithm trust anchors.
Technical Verification and Cross‑Checks (What to Demand from Vendors)
- Formal certification artifacts (FIPS 140‑3 module certificates, Common Criteria evaluation reports, eIDAS QSCD confirmation) rather than marketing statements. Validate certificate numbers, evaluated firmware versions, and scope.
- Reproducible performance tests: algorithm‑specific metrics for KEM/key‑agreement, signature generation/verification, and key‑management operations under realistic concurrency.
- Interoperability evidence: test matrices that demonstrate hybrid TLS and signature verification across common libraries and clients (OpenSSL, Windows CryptoAPI / CNG, mainstream browsers).
Flagged and Unverifiable Claims — Red Flags to Watch
- Vendor press release GA dates for PQC features without product documentation or release notes are provisional and should be treated as marketing claims until validated. Request timelines and test artifacts.
- Peak performance numbers for PQC operations are sometimes mixed with differing cryptographic workloads; ensure vendors label metrics by algorithm, key size, and test configuration. Treat headline ops/sec figures as directional.
- Claims that firmware-wrapped keys remove need for enterprise recovery or escrow are misleading; recovery semantics (escrow, migration, backups) remain essential and must be operationally tested.
Long‑Term View: What IT Leaders Should Budget For
- Multi‑year migration programs: PQC is not a single change but an architectural transition that touches PKI, HSMs, network stacks, endpoints, and update mechanisms.
- Testing and integration costs: Expect non-trivial testing effort for hybrid TLS, PKI migration, and firmware/driver compatibility.
- Hardware refresh cycles: Some devices (network appliances, embedded devices) may require replacement if vendors cannot deliver PQC firmware updates.
- Training and governance: Crypto‑agility exercises, policy updates, and procurement language changes require investment in up‑skilling teams.
Conclusion — A Practical, Risk‑Managed Roadmap
CISA’s product‑category lists turn abstract cryptographic policy into practical procurement guidance: where PQC‑capable products are widely available, buyers should
buy PQC. The guidance strikes a balance between urgency (mitigating harvest‑now risk) and realism (hybrid modes, staged rollout). For IT leaders this means three concurrent tracks:
- Short term (0–12 months): inventory, require PQC in new purchases for listed categories, run hybrid testing with cloud/KMS/HSM vendors.
- Medium term (1–3 years): migrate PKI roots, adopt PQC for backup and long‑term storage, refresh non‑updatable hardware.
- Long term (3+ years): complete transitions to PQC for signatures and key establishment across the enterprise, bake crypto‑agility into architecture and vendor contracts.
Treat vendor roadmaps and headline performance numbers as starting points for technical validation rather than proof of readiness; demand explicit algorithm support matrices, certification artifacts, and representative benchmarking during procurement. This is a transitional window where smart procurement and robust testing will convert policy pressure into tangible quantum‑resilient security.
Postscript: The guidance is intentionally pragmatic — it recognizes standards and product maturity vary by category and calls for procurement and testing discipline rather than blind faith in vendor timelines. Organizations that start now, with prioritized inventories and measurable tests, will minimize downstream risk and avoid becoming sources of long‑term decryptable archives.
Source: CISA
Product Categories for Technologies That Use Post-Quantum Cryptography Standards | CISA