When I talk about security with the people who run an organisation’s systems, one question keeps coming up without a precise answer: how many keys, how many certificates and which algorithms are in use, and where are they? It is rarely a matter of skills. More often, nobody has ever had the mandate, or a concrete reason, to count them. Systems have grown over time, one project after another, and each has brought its own cryptographic choices with it.
Before discussing which post-quantum algorithms to adopt, then, there is a less spectacular piece of work to be done: understanding where the current ones are used. Without this information, any migration plan starts from an incomplete picture.
The problem is not the quantum computer
The topic is almost always framed as a question of dates: when will there be a quantum computer capable of breaking the public-key algorithms we use today, such as RSA and those based on elliptic curves? Nobody knows for certain, and a question framed this way usually leads either to alarm or to postponement.
The guidelines of Italy’s National Cybersecurity Agency (ACN) point to a more useful criterion: plan according to how long today’s data must remain protected, not according to when the machine will appear. Encrypted traffic can be intercepted and stored now, to be decrypted once that becomes possible: this is the strategy known as harvest now, decrypt later. In my work in healthcare, this criterion carries more weight than elsewhere: a medical report transmitted today in a few milliseconds may need to remain confidential for decades.
The risk mainly concerns public-key cryptography, used to exchange keys and to sign. Symmetric algorithms such as AES, with keys of adequate length, remain sound.
The reference framework is now in place. In August 2024 NIST published the first three post-quantum standards: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. At the end of October 2026 it published the final version of IR 8547, which describes the transition path away from vulnerable public-key algorithms. The main milestones are 2030 and 2035, with different deadlines depending on use and security level. In Europe, the coordinated roadmap published in 2025 calls for national plans to be launched by the end of 2026, for high-risk use cases and critical infrastructure to be migrated by 2030, and for the transition to be completed, for as many systems as possible, by 2035.
For systems that stay in service for years, these are tight timescales. And you cannot plan for what you have not inventoried.
Cryptography hidden in software and processes
When an organisation begins mapping its cryptographic dependencies, it usually starts with TLS certificates. It is the most natural choice: they are the most visible point, and mature tools exist to catalogue them. Once the data has been collected from the infrastructure, however, it becomes clear that a significant share of the dependencies is not there. It sits in application code, in the libraries bundled with management software, in connectors to external systems, in the devices that communicate with the central software.
And sometimes it sits in the processes surrounding the technology. Keys and credentials, well protected at source, may pass through a few manual steps before reaching the application that uses them: an email, a shared folder, a copy on a staging server. These are solutions born to meet a real need, often under time pressure, which over time become part of day-to-day operations. Nobody thinks of them as cryptography, yet they are precisely the points that will have to be found and reviewed one by one when algorithms, keys or formats change.
At that point the question changes.
Beyond knowing which algorithms are in use, you need to understand who can change them, which components depend on them and what would stop working after a replacement.
It is a form of technical debt that rarely appears in backlogs: cryptographic debt. Libraries keep working, certificates are renewed, connections stay up. What nobody has often had the chance to check is how complex it would be to replace the cryptographic functions on which all of this rests.
Some clarity on terms is also needed. A certificate contains a public key, RSA or elliptic-curve, and the signature of the authority that issued it, which may use a different algorithm. A TLS connection then uses separate mechanisms for key exchange, which protects confidentiality and is the first to be exposed to harvest now, decrypt later, and for authentication, which protects authenticity and already concerns keys and devices intended to remain in use for a long time. An inventory that mixes these layers does not help in planning a migration.
The cost of an unknown dependency
When the urgency becomes real, those without an inventory have to do three things at once: find out where the dependencies are, understand which ones are critical, and migrate. On the timescales of someone already running late.
The consequences of an emergency migration are first and foremost technical. Priorities are set by instinct rather than by risk. Legacy components that do not support the new algorithms surface once work is already under way. Some libraries cannot be updated without changing the interfaces they expose. Compatibility taken for granted turns out never to have been tested. And systems built at different times must keep talking to each other while the algorithms change.
There is also an aspect that tends to be underestimated: post-quantum keys and signatures are much larger than current ones. An ECDSA signature takes up a few dozen bytes, an ML-DSA signature a few kilobytes. Fixed-size fields, protocols with tight limits and devices with little memory may not cope with the change, and it is worth knowing this in advance.
Then there is the organisational effect: without an inventory, even demonstrating compliance becomes difficult. You can have a reasonable plan and no evidence to show for it.
Designing software that can change
The first step, in my view, is to build a cryptographic inventory. More than a list of algorithms, what is needed is a map that, for each cryptographic function, states:
- what it is for: encryption, key exchange, signing, authentication;
- which algorithm it uses and with which parameters;
- which certificates and keys it involves;
- in which libraries and components it is implemented, and in which version;
- which systems and services depend on it;
- who is technically responsible for it and which supplier manages it, if any;
- what its lifecycle is and how replaceable it really is.
It does not need to be perfect from day one. It needs to exist, stay up to date and make it possible to rank systems by criticality and by the useful life of the data. There are also standard formats for describing it, such as CycloneDX’s Cryptography Bill of Materials (CBOM), which are useful when information has to pass between several suppliers.
How to proceed in practice depends on the context. On many projects we work directly on the code and intervene on the cryptographic libraries: we integrate them, update them and replace them when needed. In ecosystems such as healthcare, on the other hand, many suppliers often work on the same information system, each with their own products. There, our contribution is above all architectural: rather than intervening on an individual library, we help the organisation define boundaries, map services and integrations, and build an architecture in which dependencies are clear and manageable.
In healthcare, and in the public sector more generally, the greatest difficulty is often not technological. Many parties involved, projects that run for years and the natural turnover of people mean that information ends up spread across different documents, systems and areas of expertise. That is simply how long, complex projects evolve. On top of this come constraints specific to the sector: devices that stay in service for many years, integrations with other bodies that cannot be changed overnight, signed documents that must remain verifiable over time. This is why a shared inventory is worth more than anyone’s memory.
Not all dependencies are equally urgent. The signature on a document that must remain valid for decades poses a different problem from the authentication of an internal service that is renewed every year. This is precisely what the inventory is for: deciding where to start, which dependencies to tackle first and which systems require redesign.
The second step concerns the way software is designed. Being able to replace an algorithm depends on the architecture: if cryptographic choices are scattered across libraries, configurations and application code, changing them requires work on many components and a fresh check of how they interact.
Crypto-agility is built before it is needed.
It means isolating cryptographic functions behind well-defined interfaces, avoiding hard-coded algorithms, automating the management of keys and certificates so that manual steps disappear, and designing new developments so that several algorithms can coexist during the transition. It is also the simplest way to prevent a new application from being born with dependencies that are hard to replace.
In some cases this coexistence relies on hybrid schemes, which combine a classical mechanism with a post-quantum one, so that protection holds as long as at least one of the two remains secure. This is not a distant scenario: several browsers already use, by default, a hybrid key exchange that pairs an elliptic curve with ML-KEM. Pairing two algorithms is not enough, however: it takes standardised and verified combinations, appropriate key management and compatibility across all the systems involved. The European roadmap recommends this approach where appropriate.
If tomorrow morning you had to replace a cryptographic algorithm in one of your critical systems, because of a new regulation or a suddenly discovered vulnerability, would you know where to start?
