You cannot refactor what you cannot find
NIST finalised the first three post-quantum standards in August 2024. That gives migration programmes stable starting points.
The harder task is finding where quantum-vulnerable cryptography sits in the estate you already run.
Where cryptography actually sits in a long-lived control system
In a tunnel supervisory platform, a tolling back office or a roadside management system, cryptography is rarely a clean module sitting behind a swappable interface.
An RSA key size is a constant in a header file. The certificate parser assumes one structure and falls over on anything else. A library version is pinned because upgrading it broke an integration years ago, and nobody has had a reason to revisit it since. Key material lives in a configuration file older than the current deployment process. Whoever made each of those calls has moved on, and the reasoning went with them.
None of that is negligence. It is what twenty years of delivery pressure looks like in a codebase that stayed in service the whole time.
The dates already exist
Two public roadmaps provide useful planning reference points, although their jurisdiction and status differ.
The EU Member States published the Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography in June 2025, following Recommendation (EU) 2024/1101. It recommends national transition strategies by the end of 2026, transitioning high-risk use cases by the end of 2030, and completing the transition by 2035 for as many systems as practically feasible.
The roadmap also addresses long-lived products directly. Products with an expected lifetime beyond 2030 should be upgradable to PQC, and their software and firmware update mechanisms should incorporate post-quantum signatures for integrity and authenticity. Many tunnel control platforms, roadside assets and tolling systems in service today will still be operating beyond 2030.
The UK NCSC guidance sets separate indicative milestones: discovery and an initial migration plan by 2028, highest-priority migration by 2031 and full migration targeted for 2035. It expects large organisations and organisations running their own infrastructure to spend two to three years on discovery, assessment, strategy and the initial migration plan.
Migration effort raises the risk score
The EU roadmap builds a quantum risk level for each use case from three factors: the quantum weakness of the cryptography in use, the expected impact if it is broken, and the estimated time and effort required to migrate to PQC.
That third factor changes the planning logic. If cryptographic dependencies buried across an application materially increase migration time and effort, they raise one of the three factors used in the roadmap’s risk assessment. Migration difficulty therefore belongs in prioritisation from the start. Deferring an awkward legacy system because it is awkward can increase schedule risk rather than reduce it.
What crypto agility actually requires
NIST’s crypto agility guidance (CSWP 39) defines crypto agility as the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructures while preserving security and ongoing operations.
Very little of that list is the algorithm. The final clause is the one that bites: preserving ongoing operations. For a control system, that is the engineering problem.
The refactoring discipline is ordinary
Nothing about the work is exotic, which is part of why it gets deferred.
Find every call site. Put an abstraction between the application logic and the cryptographic implementation, so the algorithm becomes a decision the system makes rather than a fact about the code. Get test coverage around the behaviour before changing it. Migrate incrementally where the architecture allows it, with an interoperability strategy defined for each protocol and dependency. Fit the work to the availability and maintenance regime of the live system.
The schedule risk still sits here. The NCSC expects discovery, assessment, strategy and the initial plan alone to take large organisations two to three years. Nothing downstream can be scoped properly until the inventory exists.
Why a control system makes this harder
The NCSC identifies two areas where post-quantum protocol development will be harder than swapping one algorithm for another. One is the WebPKI. The other is ICS protocols, where legacy protocols in use have never been brought up to modern cryptographic standards, so architectures will have to evolve around the new algorithms rather than simply adopt them.
The operational constraints compound that. A web service can often shift traffic across instances as a migration progresses. A tunnel supervisory platform has a much tighter operational envelope.
Every change needs a maintenance window agreed with the operator, a tested rollback path and evidence an auditor can follow afterwards. We have written about that discipline in the context of configuration verification and change records. On safety-relevant control systems, cryptographic migration inherits the same validation, rollback, authorisation and audit constraints as other protected software or configuration changes.
The NCSC makes the same point for operational technology and extensive physical infrastructure: pay particular attention to the constraints that infrequent replacement cycles impose, and align changes with other infrastructure maintenance where possible. So count the maintenance windows available between now and 2030. The number of available windows can become a binding schedule constraint alongside developer capacity, and we can know it today.
Lillyneir builds and maintains long-lived control and supervisory systems for road authorities and motorway operators, which is where cryptographic migration work actually lands. If you are scoping a cryptographic inventory across a transport estate, we are happy to talk about how to bound it.
