Most PQC migration programmes are designed as internal IT projects. Define the cryptographic estate, select algorithms, sequence the workstreams, migrate. The implicit assumption is that the perimeter of the problem is the perimeter of the organisation. It is not. Every supplier, service provider, and component vendor that exchanges encrypted data with your organisation, authenticates to your systems, or ships signed firmware into your infrastructure is a cryptographic dependency you do not control. When a cryptographically relevant quantum computer (CRQC) arrives, that dependency becomes a vulnerability.
Supply chain attacks as a class are well documented. The SolarWinds compromise of 2020, analysed in CISA Alert AA20-352A, demonstrated what every security architect already understood in principle: an adversary who cannot breach an organisation's perimeter directly will target a trusted supplier instead. The quantum layer adds a dimension to that established attack pattern. The attack surface is not just software delivery pipelines. It is the cryptographic authentication mechanisms running throughout the supply chain (signed firmware, PKI-issued certificates, mutual TLS between organisations), all of which are built on RSA or elliptic-curve cryptography (ECC) that Shor's algorithm breaks.
NIST IR 8547 (initial public draft, November 2024) and the CISA/NSA/NIST joint advisory on quantum readiness from August 2023 are explicit: an organisation cannot assess its own PQC readiness without understanding the cryptographic posture of its key suppliers. Supply chain quantum security risk is not a future planning item. It is a current gap in most migration programmes.
HNDL Does Not Stop at Your Perimeter
Harvest Now, Decrypt Later (HNDL) is the practice of capturing and archiving encrypted data today for decryption once a CRQC is available. The HNDL threat applies to data in motion between organisations as readily as it applies to data at rest inside them. Encrypted inter-company transfers (M&A documents shared under NDA, financial settlements, shared engineering files, EDI transaction data) all carry some period of confidentiality requirement. For any transfer with a confidentiality window of ten or more years, the Mosca inequality (documented by Michele Mosca in IEEE Security & Privacy, Vol. 16 No. 5, 2018) already flags an active risk.
An organisation that has migrated its own infrastructure to post-quantum algorithms but continues to exchange sensitive long-lived data with suppliers over quantum-vulnerable channels has not closed the HNDL exposure. The encryption protecting the channel is only as strong as the weakest algorithm in the handshake. If your supplier's TLS termination still uses RSA key exchange, the session is harvestable regardless of what is running on your end.
Code Signing Is the Less-Understood Risk
Confidentiality risks get most of the attention in supply chain quantum discussions. The integrity risk is, in some ways, harder to address and less well understood.
Digital signatures authenticate software, firmware, and hardware components throughout procurement, delivery, and update lifecycles. Code-signing certificates based on RSA or ECC are vulnerable to Shor's algorithm on a CRQC. A quantum-capable adversary with the ability to forge RSA or ECC signatures could produce an apparently authentic firmware update, a signed software package, or a configuration file that passes classical verification systems without triggering any alert. The payload would be trusted.
NIST standardised ML-DSA (FIPS 204, August 2024) and SLH-DSA (FIPS 205, August 2024) as the post-quantum migration targets for digital signature infrastructure. Both are final published standards, not draft recommendations. An organisation whose suppliers have not migrated their signing chains to ML-DSA or SLH-DSA remains exposed to signature-forging attacks even after completing its own confidentiality migration. These are separate workstreams with separate infrastructure dependencies and separate compliance timelines.
PKI Chains Break at the Weakest Link
PKI (Public Key Infrastructure) underpins most supply chain authentication mechanisms. TLS sessions between organisations, API authentication tokens, certificate-based device identity, procurement portal credentials. Every PKI hierarchy built on RSA or ECC is quantum-vulnerable, and the chain is only as quantum-safe as its quantum-weakest certificate.
ETSI TR 103 744 (V1.1.1, December 2020) provides the quantum-safe threat assessment framework for PKI migration. ETSI TS 119 312 (V1.4.1, 2023) addresses certificate and PKI lifecycle management specifically in the quantum transition context, including hybrid classical/PQC certificate schemes for the migration period. The relevant point for supply chain planning: if a supplier's intermediate CA is still RSA-based, the certificate chain rooting in that CA is quantum-vulnerable regardless of what the leaf certificates say. A supplier that has partially migrated its PKI creates a false assurance for any organisation relying on that chain for authentication.
Long-Lived Hardware Is a Procurement Problem
Industrial sensors, VPN appliances, programmable logic controllers, embedded controllers: assets procured today across industrial and operational technology supply chains carry operational lifetimes of ten to twenty years. CISA ICS-CERT advisories document 15-to-25-year asset lifetimes as standard in OT environments, a figure aligned with NCSC operational technology guidance from 2023.
Hardware components that use hardwired RSA or ECC for authentication cannot be updated to post-quantum algorithms through a software patch. If a device's cryptographic identity is baked into silicon at manufacture, the migration option is replacement, not upgrade. An organisation purchasing such components today is making a security decision for the duration of the CRQC threat window. Procurement specifications written now that do not include cryptographic agility requirements and post-quantum algorithm support will produce assets that are quantum-vulnerable from day one of their operational life.
Regulatory Pressure Is Propagating Down Through Supply Chains
NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, September 2022) specifies ML-KEM, ML-DSA, and SLH-DSA as required algorithms for national security systems, with 2030 as the migration deadline for prioritised systems. CNSA 2.0 is mandatory for national security systems. For commercial organisations, it creates compliance pressure rather than a legal mandate. That pressure propagates. Companies providing products or services to the US national security community (including allied-nation defence contractors, critical infrastructure operators, and commercial technology vendors) face downstream obligations even if they are not US government entities.
The US DoD Cybersecurity Maturity Model Certification (CMMC 2.0, November 2021) creates explicit audit chains through defence supply tiers. A Tier 3 component supplier that has not migrated its PKI infrastructure faces disqualification from the supply chain before a CRQC exists. The compliance pressure does not wait for the hardware.
The EU Cyber Resilience Act (Regulation 2024/2847, October 2024), with phased enforcement beginning in 2027, creates new requirements for digital product security across the EU market. Germany's BSI TR-02102-1 (2024) and the UK NCSC's guidance on quantum-safe cryptography (2024) provide aligned national-level direction. The CISA/NSA/NIST joint advisory from August 2023 specifically identified water, energy, and transport sectors as having supply chain cryptographic dependencies requiring prioritised assessment because of long asset lifecycles and OT protocol vulnerabilities. None of this is speculative regulatory drafting. These are published, operative frameworks.
The SBOM Gap: What CBOM Addresses
US Executive Order 14028 (May 2021) mandated Software Bills of Materials for software sold to the federal government. An SBOM is a formal record of software components. It does not enumerate cryptographic algorithms or certificate dependencies. An organisation that has achieved SBOM compliance has demonstrated component transparency. It has not demonstrated cryptographic transparency.
A Cryptographic Bill of Materials (CBOM) is an emerging complement to SBOM that enumerates cryptographic dependencies specifically. NIST IR 8547 references CBOM as a component of supply chain cryptographic transparency. IBM has published CBOM tooling based on the CycloneDX schema extension. As of mid-2025, CBOM is not a mandated standard in any major jurisdiction, but it represents the clear direction of regulatory travel for supply chain contexts. Organisations waiting for CBOM to become mandatory before beginning the underlying cryptographic discovery work are building in a compulsory lag.
Four Misconceptions Worth Addressing Now
Small suppliers are not below the targeting threshold. Supply chain attacks disproportionately target smaller suppliers to reach larger downstream organisations via trusted certificate relationships or software update channels. A Tier 3 component supplier may carry no sensitive data itself and still provide an entry point into a Tier 1 prime's environment.
Cloud infrastructure does not transfer supply chain cryptographic responsibility. Cloud providers are migrating their platform-level cryptography on their own timelines. Inter-company communications that route through or between cloud environments still carry cryptographic dependencies at the application layer. The application layer is the customer's responsibility.
Completing your own migration does not close supplier exposure. An organisation that has migrated its own estate but continues to operate with quantum-vulnerable suppliers inherits residual risk. Supplier API endpoints using classical TLS with RSA key exchange, supplier-issued certificates for mutual authentication, and firmware updates signed with classical algorithms all remain exploitable against a quantum adversary after the purchasing organisation has completed its own programme.
Procurement leverage is real and it can be used now. Including PQC readiness criteria in supplier contracts, requesting supplier PQC roadmaps, and building cryptographic agility requirements into new procurement are documented practices in the NIST and CISA supply chain guidance. Waiting for suppliers to act independently is not the only option.
Where to Start
The supply chain quantum problem cannot be addressed before the internal problem is understood. You cannot assess your suppliers' cryptographic posture usefully if you have not mapped your own. The prerequisite is a cryptographic inventory: a complete record of every algorithm, certificate, protocol, and dependency in your own estate, including the third-party services and components your systems rely on. NCSC's 2024 guidance on quantum-safe migration makes this explicit: the inventory must include dependencies on third-party services and products, not just internal infrastructure.
QSECDEF's PQC Readiness Checklist asks about vendor dependencies as one of its ten input dimensions. If your organisation has significant reliance on third-party cryptographic services or components, the checklist output will include supply chain-specific actions alongside your internal programme priorities. It is a starting point for understanding where third-party cryptographic risk sits in your programme, not a substitute for the supplier assessment work that follows.
QSECDEF members have access to the practitioner methodology documentation and template supplier questionnaires developed from that assessment work. The membership resources cover the supply chain workstream as a distinct module within the PQC migration programme.
