Service 02
Migration to quantum-safe algorithms
From “we think we use TLS everywhere” to a documented, prioritised and tested transition to the NIST post-quantum standards — with crypto-agility built in, so the next algorithm change is a configuration exercise rather than another five-year programme.
Harvest now, decrypt later
The threat does not wait for a working quantum computer. An adversary with patience and storage can capture encrypted traffic today and decrypt it once a cryptographically relevant quantum computer exists. Any data whose confidentiality must outlive the 2030s — patient records, legal files, source code, long-lived credentials, state secrets, intellectual property — is exposed the moment it crosses a network protected only by RSA or elliptic-curve key exchange.
Signatures have a different but equally awkward problem. Firmware signing keys, code-signing chains, certificate authorities and long-lived device identities have replacement cycles measured in years. Starting when the deadline arrives is starting too late.
The standards are settled enough to act on
In August 2024 NIST published the first three post-quantum standards as final FIPS. In March 2025 it selected HQC as a backup key-encapsulation mechanism built on different mathematics, so a future break in lattice assumptions would not be a single point of failure. A standard for FALCON (FIPS 206) is still in preparation.
| Standard | Algorithm | Purpose |
|---|---|---|
| FIPS 203 | ML-KEM (CRYSTALS-Kyber) | Key encapsulation — protects data in transit |
| FIPS 204 | ML-DSA (CRYSTALS-Dilithium) | General-purpose digital signatures |
| FIPS 205 | SLH-DSA (SPHINCS+) | Hash-based signatures — conservative fallback |
| Selected 2025 | HQC | Backup key encapsulation on different mathematics |
| FIPS 206 (draft) | FN-DSA (FALCON) | Compact signatures for constrained contexts |
The schedule is equally concrete. NIST’s draft transition guidance (IR 8547) deprecates RSA and elliptic-curve cryptography after 2030 and disallows them after 2035. The EU’s coordinated roadmap, published by the NIS Cooperation Group in June 2025 following the Commission’s 2024 Recommendation, expects Member States to have national strategies and first migration steps under way by the end of 2026, high-risk use cases protected no later than 2030, and the transition as complete as practically feasible by 2035.
IR 8547 remains an initial public draft; the dates are directional planning guidance rather than a binding mandate, and may shift in the final version. We plan against them anyway, because the EU milestones do not depend on them.
How a migration actually runs
Phase 1 — Cryptographic inventory
You cannot migrate what you cannot see. We build a cryptographic bill of materials: where keys and certificates live, which algorithms and key sizes are in use, which libraries and hardware modules provide them, which are hard-coded in applications, and which belong to suppliers rather than to you. Sources include certificate stores, TLS scanning, code and dependency analysis, HSM and PKI configuration, and structured supplier questionnaires.
Phase 2 — Risk ranking
Every finding is scored on three axes: how long the data must remain confidential, how exposed the channel is, and how hard the migration will be. A public API terminating TLS at a modern load balancer is a configuration change. A twelve-year-old device fleet with hard-coded certificates is a capital plan. Treating them the same is how programmes stall.
Phase 3 — Target architecture and crypto-agility
We design the destination: which standards apply where, whether hybrid key exchange is appropriate during the transition, what happens to your PKI and certificate lifecycle, how key sizes and performance affect constrained systems, and — most importantly — how to stop cryptography being hard-coded again. The goal is that the next algorithm change is a policy update, not an archaeology project.
Phase 4 — Supplier assurance
Much of your cryptography is somebody else’s product. We give you the questions to ask, the roadmap commitments to demand, and the contract language that makes post-quantum support an obligation rather than an aspiration — for new procurement and for renewals of what you already run.
Phase 5 — Pilot, rollout and evidence
A pilot on a representative system establishes real performance and interoperability data instead of vendor claims. From there, a wave plan with rollback paths, monitoring, and an evidence trail aligned to the EU roadmap milestones — so when a regulator or a customer asks what you have done, the answer is a document rather than a meeting.
What you receive
- A cryptographic inventory and CBOM you can maintain, not a one-off spreadsheet
- A risk-ranked migration backlog with effort estimates and dependencies
- Target-state cryptographic architecture and crypto-agility standard
- Supplier questionnaire, scoring model and procurement clauses
- Pilot results with measured performance and interoperability findings
- A board-level briefing and a regulator-ready evidence pack mapped to the EU milestones
Common questions
Is it too early to start?
Not for the inventory, which is the long pole and is useful regardless — it improves certificate management, incident response and audit evidence immediately. Whether to begin replacing algorithms depends on your data lifetime: if something you transmit today must still be secret in 2040, the exposure already exists.
Should we deploy hybrid or pure post-quantum?
For key establishment during the transition, hybrid modes that combine a classical and a post-quantum algorithm are widely recommended, because they fail safe if either component is broken. The right answer depends on your protocol support, performance envelope and regulatory context, and it is a design decision we make explicitly rather than by default.
Do we need new hardware?
Sometimes. HSMs, smartcards and embedded devices are the usual constraints, since post-quantum keys and signatures are larger than what some hardware was designed to hold. Identifying those cases early is exactly why the inventory comes first — hardware replacement has a procurement cycle that a software change does not.
How does this connect to NIS2 and DORA?
Both require risk-appropriate cryptographic controls and the ability to demonstrate them. Neither names post-quantum algorithms today, but a documented cryptographic inventory and a transition plan are increasingly what “appropriate” looks like for entities with long-lived confidentiality requirements — and both make the eventual conversation with a supervisor considerably shorter.
Start with the inventory.
A scoped cryptographic discovery is the cheapest useful step, and it is the one every later decision depends on.