Post-quantum cryptography (PQC) migration is not a software update. This is the sentence that most boards have not heard, and it is the sentence that most meaningfully changes the governance picture once it is understood.
A software update has a defined scope — these systems, these versions, this timeline. The team patches them, tests them, deploys them, and closes the project. PQC migration is fundamentally different in three respects: the scope is not fully knowable at the start, the dependencies create cascading complexity that cannot be planned from the outside, and the consequence of discovering mid-migration that your architecture is not crypto-agile is that you have to rebuild the architecture rather than finishing the migration.
I am not describing a worst case. I am describing the experience of organisations that have been through phase one of their PQC migration assessments and discovered that the honest answer to “how complex is this” was substantially different from the answer their CISO had given them when the board first asked.
The reason the CISO’s answer was optimistic is not, in most cases, deliberate misrepresentation. It is structural. The CISO is an expert in the cryptographic architecture and knows how to solve the technical problems. They are less well placed to assess how the migration complexity will interact with the organisation’s broader IT governance, vendor relationships, and board-level risk tolerance. That assessment requires a different vantage point.
What crypto-agility actually means
Crypto-agility is the property of a system or architecture that allows the cryptographic algorithms it uses to be changed without requiring a full system rebuild. An architecture that is crypto-agile can switch from RSA-2048 to ML-KEM (the NIST post-quantum key encapsulation standard) by changing the algorithm configuration rather than re-engineering the system.
An architecture that is not crypto-agile — and many existing enterprise architectures are not — has cryptographic algorithms baked into the system design at a level that cannot be changed without significant re-engineering. This is the “crypto paralysis” problem I have written about in the quantum security space: the moment a PQC migration project discovers that the target system is not crypto-agile, the project scope expands from “change the algorithm” to “redesign the system architecture.”
For a board approving a PQC migration budget and timeline, the governance question is: has the CISO confirmed which of the organisation’s systems are crypto-agile and which are not? If not, the migration timeline is provisional, because the scope of the work cannot be fully defined until that assessment is complete.
This is not an unreasonable governance requirement. It is the migration equivalent of the builder who says “we can give you a price for the renovation once we have opened the walls.” Opening the walls is a necessary step before the accurate estimate. The equivalent in PQC migration is the cryptographic inventory.
The three places where migration complexity concentrates
Complexity concentration 1: Hidden cryptographic dependencies
Enterprise systems use cryptography in more places than the IT team knows. The HTTPS layer is obvious. The end-to-end encryption on the communications platform is known. What is frequently unknown: the cryptographic functions embedded in the software libraries the development team uses, the encryption in the database management system that was configured by a predecessor team eight years ago, and the certificate infrastructure that was implemented by a third-party system integrator and has never been formally inventoried.
When an organisation begins its cryptographic inventory — a necessary first step in any PQC migration — it routinely discovers cryptographic dependencies that nobody in the current IT team knew about. These are not security failures. They are the natural consequence of building complex systems over time. But they are complexity concentrations that the migration plan must account for, and they cannot be accounted for until they are found.
Complexity concentration 2: Third-party and supply chain dependencies
Most organisations cannot complete their PQC migration independently of their vendors. The cloud provider’s encryption service, the payment processor’s cryptographic stack, the HR system vendor’s data encryption — these are not under the organisation’s direct control. The organisation’s migration timeline is partially determined by the migration timeline of its critical vendors.
The governance question for boards: has the CISO produced a list of the organisation’s critical third-party dependencies and their PQC migration status? For UK financial services, where DORA’s third-party ICT risk requirements apply, this is not optional — the board needs to demonstrate oversight of supply chain cyber risk, which includes the PQC readiness of critical ICT suppliers.
Complexity concentration 3: Legacy systems with extended lifespans
Every organisation has systems that are old enough to have been designed before post-quantum cryptography was a consideration. Industrial control systems, legacy financial core systems, older enterprise resource planning platforms — these systems frequently have cryptographic implementations that are embedded in proprietary architectures from vendors who may no longer be in business.
For these systems, the migration option is often not “upgrade the cryptography” but “plan the system replacement on a timeline that accounts for the quantum threat horizon.” This is a capital expenditure question, not a security operations question, and it requires board-level decision-making.
The governance message for boards
I am not suggesting that boards should block PQC migration projects pending a comprehensive architectural review. I am suggesting that boards should ensure the PQC migration programme they are approving has a realistic scope — one that includes the cryptographic inventory, the crypto-agility assessment, and the third-party dependency review as phase one deliverables before phase two timelines and budgets are set.
The CISO who presents a two-year migration timeline at project approval without completing these assessments first is not managing the governance risk. They are managing the budget approval. Those are different goals, and the board’s governance obligation is to require the second before approving the first.
The boards that govern quantum risk well are not the ones with the most aggressive migration timelines. They are the ones with the most accurate picture of where they are starting from.
What NIST’s August 2024 standards change for migration planning
NIST’s finalisation of ML-KEM, ML-DSA, and SLH-DSA in August 2024 removed one source of migration uncertainty: which algorithms to migrate to. Before the finalisation, some organisations were delaying migration planning because the standards were still in draft and they did not want to commit to an algorithm that might be revised.
That uncertainty is now resolved. The board governance message: the “waiting for the standards to be finalised” rationale for delaying migration planning is no longer available. The standards exist. The migration can be planned.
For organisations in scope for NIS2 — essential and important entities in critical infrastructure sectors — the NCSC guidance is explicit: begin migration planning now. Personal liability under NIS2’s Article 20 applies to management bodies. That includes the board.
The specific governance structures, decision sequences, and questions for managing PQC migration complexity at board level are covered in the Quantum Risk: What Directors Need to Know — including a board-level assessment of crypto-agility, third-party dependency risk, and the timeline decisions that boards need to make before delegating migration execution to the CISO.
For quantum security advisory support, visit Quantum Security Defence. For independent board advisory support, contact Steven directly.
