Marin Ivezic
NIST published the first three post-quantum cryptography standards on August 13, 2024: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures. Suppliers began shipping support almost immediately. Cloud key management services, TLS libraries, VPN appliances and hardware security modules now carry post-quantum algorithms on their roadmaps, and a comfortable conclusion follows from that. If the suppliers are building it in, the enterprise job reduces to installing updates as they arrive.
That conclusion is where post-quantum programs quietly stall. Suppliers will do a large share of the work. None of them can do the part that determines whether the migration finishes on time.
A patch cannot reach what nobody has mapped
Two risks drive the timeline, and they behave differently. The first is harvest now, decrypt later: an adversary records encrypted traffic today, stores it, and decrypts it once a cryptographically relevant quantum computer (CRQC) exists. Any data with a confidentiality requirement longer than the time remaining until a CRQC is already exposed. The second risk concerns signatures and long-lived roots of trust. A firmware signing key burned into a device shipping today may still be verifying updates in 2040, and it cannot be swapped by a software patch.
Neither risk is solved by a vendor release note, because the algorithms are not drop-in replacements. An X25519 public key is 32 bytes. An ML-KEM-768 encapsulation key is 1,184 bytes. An Ed25519 signature is 64 bytes; an ML-DSA-65 signature is 3,309. Those numbers break fixed-width database columns, smartcard buffers, single-packet handshake assumptions and certificate size limits written into protocol implementations a decade ago. The cryptography changes, and the systems around it change with it.
The scope also runs wider than most inventories assume. A single industrial sensor may use symmetric encryption for local storage, TLS for its uplink and a digital signature scheme for firmware verification. Three layers, three different migration paths, and one of them may require replacing the hardware. Multiply that across an estate of servers, applications, databases, network devices, operational technology and cloud services, and the work stops looking like patching.
Accountability does not transfer with the contract
Regulators have started to treat cryptographic transition as a governance matter rather than a technical backlog item. In the United States, the Quantum Computing Cybersecurity Preparedness Act of 2022 obliged federal agencies to prepare for migration, and OMB memorandum M-23-02 required them to produce prioritised inventories of cryptographic systems. NIST IR 8547 exists at present only as an initial public draft, and it proposes that RSA-2048 and ECC-256 be deprecated after 2030 and disallowed after 2035. That is a proposal rather than a rule in force, and NSA’s CNSA 2.0 timelines bind only national security systems, so no universal deprecation date applies to a commercial estate today. Named instruments are nonetheless converging on the same window. The EU’s NIS Cooperation Group published a coordinated post-quantum migration roadmap in June 2025 that asks member states to begin the transition by the end of 2026 and to protect their highest-risk use cases by the end of 2030, and a commercial estate that sells into the public sector on either side of the Atlantic inherits those dates through procurement rather than through regulation.
The practical effect is that a board can be asked what its exposure is, and “our suppliers are handling it” isn’t an answer that survives a follow-up question. Four questions worth being able to answer at the next risk committee:
- How long must our most sensitive data remain confidential, and does that period end before or after 2035?
- Which of our cryptographic dependencies are ours to fix, and which belong to a supplier?
- For the supplier-owned ones, what has each supplier committed to in writing, and by when?
- What happens to the programme if a critical supplier misses that date?
The third and fourth questions are the ones that separate a real programme from a stated intention. A roadmap slide is not a commitment, and a supplier who misses a date does not absorb the resulting risk on your behalf.
The inventory is the one deliverable no supplier can hand over
Every serious migration methodology starts in the same place: find out where cryptography is actually used. The output is a cryptographic bill of materials (CBOM), an inventory of the algorithms, key lengths, certificates, protocols and libraries in the estate together with the systems that depend on each one. It extends the idea of a software bill of materials (SBOM), which lists components, to record what those components do cryptographically. The CycloneDX format added support for cryptographic assets in version 1.6, so the inventory can live alongside the SBOM rather than in a separate spreadsheet.
Building one is a discovery exercise with three parts. Automated scanners find certificates, TLS endpoints and known library versions, and they will miss a great deal. Code review and configuration review find the hardcoded calls, the pinned parameters and the bespoke key derivation someone wrote in 2014. Supplier disclosure covers the rest, because closed products will not yield their internals to a scanner.
Tag each entry as internally controlled or supplier-controlled from the beginning. The two categories are managed with entirely different instruments, and a programme that discovers the distinction late finds itself renegotiating contracts under deadline pressure. Then prioritise by data lifetime rather than by system criticality alone. A low-traffic archive holding records with a thirty-year confidentiality requirement outranks a busy service whose data is worthless in a week.
Engaging suppliers without transferring accountability
Supplier engagement gets better results when it starts before the renewal conversation. Ask for a written post-quantum transition plan naming the specific algorithms and parameter sets, not a statement of intent to follow NIST. Ask which products will support hybrid modes, where a classical and a post-quantum algorithm are used together so that the connection stays secure if either one fails. Ask what happens to devices already deployed in the field, and ask which of them cannot be upgraded at all. That last answer identifies the population that has to be replaced rather than upgraded, which is the line item most likely to be missing from the budget.
Then write the answers into the commercial relationship. Contracts and tender documents can require crypto-agility, meaning the product can switch algorithms through configuration or a signed update rather than a redesign. They can require disclosure of the cryptographic inventory for the supplied product, notification when algorithms change, and a committed support date for the FIPS 203 and FIPS 204 families. Where a supplier will not commit, the finding belongs in the risk register with a named owner and a review date, and in some cases the correct response is to plan the replacement.
The business case is already written
Two arguments tend to win budget faster than the threat narrative does. The first is that the proposed deprecation dates are published, which lets migration be scheduled against a fixed end date rather than argued for annually as a discretionary security project. The second is that cryptographic discovery reliably surfaces problems that have nothing to do with quantum computing: expired certificates nobody owns, deprecated cipher suites still enabled, systems using key material that was supposed to be retired years ago. The inventory pays for itself on those findings before a single algorithm is swapped.
There is a negotiating benefit too. An organisation that knows exactly which supplier-controlled cryptography it depends on asks better questions during procurement and gets firmer commitments in return.
Where the capability comes from
None of this is exotic work, and most of it is unfamiliar. Building a CBOM, reading a supplier’s transition plan critically, writing crypto-agility into a contract and defending a prioritisation to a risk committee are learnable skills, and they sit across security architecture, procurement and governance rather than in one team.
That is the gap our post-quantum training addresses. Quantum Academy programmes are built for the people who will run these programmes rather than for the people who will implement the mathematics, and they work through inventory, prioritisation and supplier engagement as practical exercises. The current certification paths are listed at quantumacademy.com/. For the migration methodology itself, pqcframework.org is the open reference, and PostQuantum.com carries the deeper technical analysis behind most of the points above.