Why supply chain PQC risk cannot wait

An organisation's post-quantum cryptography migration plan is only as strong as its most cryptographically exposed supplier. Consider a common scenario: an organisation deploys ML-KEM-768 on its own TLS endpoints, but its cloud ERP vendor still terminates those connections with RSA-2048 key exchange. The harvest-now-decrypt-later (HNDL) risk for data processed through that ERP system is entirely unmitigated. The organisation upgraded its front door; the data left through the supplier's back window. Mosca's 2018 analysis in IEEE Security and Privacy established the quantitative framework: once the sum of migration time and data secrecy lifetime exceeds the estimated time to a cryptographically relevant quantum computer, the risk of adversarial capture and future decryption is non-zero. Supply chain PQC risk is an active exposure, not a future planning item.

NIST IR 8547, published November 2024, sets the deprecation clock. RSA, ECDH, ECDSA, DSA, and finite-field Diffie-Hellman/DSA are deprecated for new deployments by 2030 and scheduled for full retirement by 2035. A vendor with no PQC migration roadmap is a vendor whose cryptographic interfaces will be non-compliant with that schedule in fewer than four years. This is not a speculative risk assessment. It is a documented deprecation timeline from the world's primary cryptographic standards authority.

The regulatory obligation to assess vendor readiness is explicit in both NIS2 and DORA. NIS2 Directive (EU) 2022/2555, Article 21(2)(d) [VERIFIED — EUR-Lex CELEX:32022L2555, Yuki consensus 2026-05], requires entities to address supply chain security "including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." DORA Regulation (EU) 2022/2554, Article 28(1), requires financial entities to manage ICT third-party risk as an integral part of the ICT risk management framework. Both instruments create a compliance obligation to assess vendor cryptographic readiness, not simply to accept a vendor's self-certification.

The NIST IR 8547 alignment check: what to ask

The primary quantitative question in any vendor PQC evaluation is: which NIST IR 8547 transition criteria does the vendor's current cryptographic stack meet, and which does it not? The Regulation distinguishes deprecated algorithms (still usable in legacy systems during the transition window but not for new deployments) from disallowed algorithms (removed from use). For key exchange, RSA and ECDH are deprecated; for signatures, RSA and ECDSA are deprecated. The approved post-quantum replacements are ML-KEM (NIST FIPS 203) for key encapsulation, ML-DSA (NIST FIPS 204) for digital signatures, SLH-DSA (NIST FIPS 205) as a hash-based signature alternative, and FN-DSA (NIST FIPS 206) for specific applications.

Ask vendors specifically about key encapsulation. Has the vendor implemented ML-KEM (FIPS 203)? The parameter sets are ML-KEM-512 (Category 1 security), ML-KEM-768 (Category 3, equivalent to 128-bit quantum security), and ML-KEM-1024 (Category 5, required under CNSA 2.0 for national security systems). For most enterprise deployments, ML-KEM-768 is the target. The overhead figures matter for transport layer assessment: ML-KEM-768 public key size is 1,184 bytes; ciphertext size is 1,088 bytes. A vendor whose transport layer cannot accommodate those sizes has not completed the engineering work, regardless of what their roadmap says.

Ask vendors specifically about digital signatures. Has the vendor implemented ML-DSA (FIPS 204)? The parameter sets are ML-DSA-44 (Category 2), ML-DSA-65 (Category 3), and ML-DSA-87 (Category 5, required under CNSA 2.0). ML-DSA-65 produces a signature of 3,309 bytes. For comparison, an ECDSA P-256 signature is 70-72 bytes. That is a 46x increase in signature size. Vendors with signing-intensive workflows such as code signing, certificate issuance, or high-frequency document authentication must have assessed the performance implications before they can credibly claim readiness. If they have not run the numbers, they have not done the work.

FIPS 140-3 validation and the CMVP: the procurement leverage point

FIPS 140-3 replaced FIPS 140-2 as the NIST standard for cryptographic module security requirements in 2019 (FIPS 140-2 was deprecated for new submissions in September 2021). For regulated sectors including financial services, government procurement, and healthcare, vendors whose cryptographic modules provide services are expected to have FIPS 140-3 validated products. The NIST Cryptographic Module Validation Programme (CMVP) maintains the list of validated modules.

CMVP validation takes 12 to 24 months to complete. A vendor that has not submitted a FIPS 140-3 validation request for their post-quantum cryptographic module by 2026 or 2027 will not have a validated PQC module before the NIST 2030 new-deployment deprecation deadline. That timeline is the procurement leverage point: when assessing a vendor, do not ask whether they plan to support PQC. Ask whether they have already submitted for FIPS 140-3 validation and what the expected completion date is. A vendor who answers "we're planning to start the process" in 2026 has missed the practical deadline for validated modules by 2030. For library and module-level evaluation detail, see the companion piece on PQC vendor selection for cryptographic library providers.

Hardware Security Modules deserve specific scrutiny. HSMs hold private keys and perform cryptographic operations for PKI, code signing, TLS termination, and payment processing. The HSM is the root of trust. If the HSM does not support ML-KEM or ML-DSA, PQC deployment on the services it protects cannot be completed, regardless of what the application layer does. Leading HSM vendors including Thales (Luna), Entrust (nShield), and the cloud hyperscaler HSM services have published post-quantum roadmaps at varying levels of specificity. Verify current status directly with each vendor, because roadmaps in this space change frequently and published documentation lags actual product capability.

The five-question vendor evaluation framework

The five questions below are written so they can be lifted directly into a vendor questionnaire. For each, a good answer is described alongside what a poor answer looks like. Vague answers are poor answers.

Question 1: Algorithm inventory. "Can you provide a cryptographic algorithm inventory listing every algorithm used in key exchange, signatures, symmetric encryption, and hashing in your product or service, along with key sizes?" A good answer is a document that names specific algorithms and key sizes, not a general statement about security practices. A poor answer is "we use industry-standard encryption." Vendors who cannot answer this question are at the earliest stage of PQC readiness. NIST NCCoE SP 1800-38B (2024) calls this ICT product discovery and treats it as the prerequisite for any migration planning. Regulatory basis: DORA Article 8 / NIS2 Article 21(1).

Question 2: NIST IR 8547 alignment timeline. "By what date will RSA and ECDH key exchange be replaced by ML-KEM-768 in new deployments? By what date will ECDSA and RSA signatures be replaced by ML-DSA or SLH-DSA?" A good answer gives specific dates before 2030. A poor answer says "we are monitoring the situation" or gives a post-2030 date. Vendors without a specific date are not positioned to meet the NIST new-deployment deprecation deadline. Regulatory basis: NIST IR 8547 (November 2024).

Question 3: FIPS 140-3 validation status. "Has your post-quantum cryptographic module been submitted for FIPS 140-3 validation via the CMVP? What is the current status and expected validation date?" A good answer names a specific CMVP submission with a status update. A poor answer references a planned submission without a date or describes FIPS 140-2 certification as equivalent (it is not; FIPS 140-2 modules are deprecated for new submissions). Regulatory basis: FIPS 140-3 / CMVP.

Question 4: Hybrid mode support. "Does your product support hybrid key exchange combining X25519 with ML-KEM-768 in TLS 1.3?" Hybrid mode allows HNDL protection on current traffic without requiring complete migration. IETF RFC 9496 (X-Wing hybrid KEM) and the IETF TLS hybrid design draft specify the mechanisms. A vendor supporting hybrid mode is operationally ready for the transition period; a vendor requiring a complete PQC cutover presents higher migration risk and timeline uncertainty. Regulatory basis: NIST IR 8547 transition guidance / IETF RFC 9496.

Question 5: Crypto-agility architecture. "Is your cryptographic architecture crypto-agile? Can algorithm selection be changed by configuration without full product re-engineering?" NIST NCCoE SP 1800-38B identifies crypto-agility as the design principle that determines how rapidly a vendor can respond to algorithm changes, including deprecations and newly discovered vulnerabilities. A vendor with hardcoded RSA requires full re-engineering to migrate. A vendor with a configurable cryptographic abstraction layer can respond in weeks. The difference in migration risk is material. Regulatory basis: NIST NCCoE SP 1800-38B crypto-agility guidance.

Tiering vendor readiness: a scoring model

The four-tier model below is derived from NIST NCCoE guidance and CMVP criteria. It is a practitioner instrument, not a regulatory standard. No regulator endorses this specific tiering. Use it as an internal risk prioritisation tool.

The action threshold varies by data sensitivity. A Tier D vendor handling data whose confidentiality requirements extend beyond 2030 is a material risk requiring immediate escalation. A Tier D vendor handling short-lived operational data with no long-term confidentiality requirement is lower priority. Map vendor tier against data confidentiality lifetime, derived from your cryptographic bill of materials (CBOM), to determine urgency. The prerequisite step before applying this framework to your supply chain is completing a CBOM for your own estate, so you know which vendors are handling which cryptographic assets. That methodology is covered in the cryptographic asset register build guide.

Contractual levers and the regulatory audit trail

For organisations subject to NIS2 Article 21(2)(d) or DORA Article 28, this evaluation framework is a compliance instrument, not optional best practice. Both articles require entities to manage the security practices of direct suppliers. The evaluation output, whether a vendor tier assignment, a remediation plan, or a replacement decision, must be documented in the ICT risk management framework as evidence of supplier assessment. If a regulator asks how you assessed supply chain quantum readiness, this documentation is the answer.

At contract renewal, four specific levers are available under DORA RTS (EU) 2024/1773: require the vendor to provide a cryptographic algorithm inventory as a contract deliverable; require the vendor to commit to ML-KEM and ML-DSA support by a specified date; include a right-to-audit cryptographic controls; include a notification requirement if the vendor's cryptographic architecture changes materially. RTS (EU) 2024/1773 requires financial entities to include audit rights and security standard maintenance obligations in third-party contracts [ASSUMED: verify exact RTS 2024/1773 clause detail against EUR-Lex text before publication]. For contracts not yet due for renewal, Article 28(1)'s risk management obligation provides a basis for requesting voluntary PQC roadmap disclosure. Frame the request as a regulatory requirement, not a preference, and document the response or non-response.

In the UK, the NCSC's supplier assurance framework and its "questions to ask your suppliers" guidance are directly applicable to PQC vendor evaluation, even for organisations not subject to NIS2. UK organisations should treat NCSC guidance as the national authority reference. EU organisations outside financial services should refer to ENISA's supply chain security guidance and their competent authority, whether BSI, ANSSI, NCSC-NL, or another national body.

Two critical vendor categories and where the field stands

Cloud hyperscalers are the easiest vendor category to assess and the hardest to replace. AWS, Azure, and GCP have all published PQC roadmaps and have begun deploying hybrid key exchange on specific services. AWS KMS has supported ML-KEM-768 hybrid key exchange on certain API connections. The question for organisations relying on these providers is not whether they will migrate but which specific services support PQC today, whether hybrid mode is available for those services now, and what the timeline is for services that do not yet support it. Hyperscaler PQC deployment is evolving rapidly; verify current service-level status directly with each provider before publication or procurement decisions, because blog posts and capability announcements from 2024 may not reflect current production capability.

Open-source TLS libraries are the less visible but equally important category for organisations that build their own stacks or use open-source infrastructure. OpenSSL 3.x supports experimental ML-KEM and ML-DSA implementations via the Open Quantum Safe (OQS) provider. BoringSSL, used in Chrome and Android, has experimental PQC support. The critical distinction here is between experimental implementation and FIPS 140-3 validated production module. The OQS provider is not FIPS 140-3 validated as of the knowledge cutoff for this article; verify current CMVP status before treating OQS-based implementations as meeting regulated sector requirements. Organisations building on open-source libraries should track the OQS project at openquantumsafe.org and the OpenSSL OQS provider repository for FIPS 140-3 submission status updates.