Post-quantum: before migrating, do you know where your information system really uses cryptography?

The transition to post-quantum cryptography can easily be approached as an algorithm problem: which standards should be adopted, which libraries should be replaced, and which products should be purchased?

For many organisations, however, that is not the first problem to solve.

Before choosing a post-quantum technology, an organisation needs to answer a more basic question: where is cryptography actually used across the information system, what does it protect, for how long, and with which dependencies?

ANSSI now recommends that both public and private organisations begin inventorying their cryptographic uses. Its 2026-2027 roadmap also includes initial inventory steps for French government administrations, with a transition that needs to be anticipated over several years.12

The post-quantum issue therefore starts less with technical migration than with a visibility problem across the information system.

The first inventory is not a list of algorithms

Searching configuration files for RSA, ECC or AES can be useful. But a list of algorithms alone does not tell an organisation what should be migrated first.

Preparing for a transition requires understanding the use case behind each cryptographic mechanism.

A TLS certificate exposed on a public website, an electronic signature that legally commits a company, a VPN link with an industrial partner, or a key protecting confidential archives for fifteen years do not carry the same consequences.

ANSSI recommends, in particular, identifying products and business uses that incorporate cryptography, the algorithms they use, and the data whose confidentiality or authenticity must remain guaranteed beyond 2030.1

This means turning a technical inventory into a map of relationships.

| Element to know | Example question | |---|---| | Business use | Why is cryptography used here? | | Protected data | Which information must remain confidential or authentic? | | Protection duration | Until when must that protection remain effective? | | Application or service | Which system relies on this mechanism? | | Protocol | TLS, IPsec, SSH, S/MIME, signature…? | | Algorithm / mechanism | Which cryptographic mechanisms are actually used? | | Product or equipment | Which component implements them? | | Supplier | Who controls its migration roadmap? | | Dependencies | Which other services use the same component? | | Renewal cycle | When can it realistically be replaced? |

The value of the inventory therefore does not lie in the number of rows collected. It lies in the relationships between those rows.

An application rarely “does” cryptography on its own

Consider a business application exposed to the Internet.

Its team may think it simply uses HTTPS. In practice, several layers of the information system can participate in that protection: a reverse proxy terminates TLS, a certificate manager renews keys, an internal certificate authority issues some certificates, a network appliance secures inter-site exchanges, and an application library signs certain documents.

A single application can therefore depend on several cryptographic mechanisms with different owners and life cycles.

Conversely, the same cryptographic component may be shared by dozens of applications.

That is what makes an application-by-application migration difficult to manage.

A useful representation might follow a chain such as:

business process → application → flow → protocol → cryptographic component → product or equipment → supplier → migration strategy

This is not a regulatory model or an ANSSI-mandated method. It is an operational way to turn the inventory into a decision-making tool.

Above all, it helps answer an important question: if this component must be replaced, what is the real blast radius?

Data lifetime may matter more than server criticality

The post-quantum transition introduces an unusual dimension into prioritisation: time.

A system can be perfectly protected today while still exposing information that will need to remain confidential when cryptographic capabilities that are currently out of reach become available.

ANSSI therefore asks organisations to include the quantum threat in their risk analysis and identify data and use cases whose protection must persist over time.13

This changes how the inventory should be prioritised.

A platform that is not highly critical for availability may, for example, process information whose confidentiality must be maintained for twenty years. That platform may become a priority in a post-quantum strategy.

Conversely, a highly critical service handling only public and short-lived data may present a different type of risk.

The question is therefore not only:

“Which system is the most critical today?”

It also becomes:

“Which information must still be protected after the cryptographic context has changed?”

Constructed case: five cryptographic uses behind one service

Consider a fictional company operating a portal through which industrial customers exchange technical files.

The application appears in the information-system catalogue as a single service.

By examining its dependencies, the team discovers five distinct cryptographic uses:

• TLS is terminated by a cloud load balancer;
• internal users authenticate through an identity federation;
• some uploaded documents are digitally signed;
• archived data is encrypted through a key-management service;
• exchanges with a long-standing partner use a VPN running on a physical appliance.

The technical documents must remain confidential for fifteen years.

The team cannot simply create one row labelled “customer portal — cryptography to migrate” and consider the inventory complete.

It must identify several owners, technologies and suppliers.

The load balancer depends on the cloud provider’s roadmap. The VPN depends on equipment scheduled for replacement in four years. The signature function relies on a library embedded in internally developed software. The key-management service follows yet another evolution cycle.

The migration problem is already no longer an algorithm problem.

It is an architecture and dependency problem.

The supplier belongs in the inventory

A significant share of cryptographic mechanisms is not directly controlled by the organisation.

Algorithms may be implemented in a firewall, VPN appliance, HSM, cloud platform, SaaS product, external PKI or third-party library.

ANSSI explicitly recommends identifying equipment that will need to evolve and contacting suppliers to understand their post-quantum roadmap.1

For each structural dependency, several pieces of information therefore become useful:

• product and version in use;
• cryptographic mechanism concerned;
• support status;
• planned end-of-support date;
• announced ability to support post-quantum mechanisms;
• expected availability date;
• information-system dependencies using the product;
• whether the component can be replaced independently from the rest of the system.

A supplier roadmap should not, however, be confused with an internal migration strategy.

Knowing that a vendor plans to release a post-quantum-compatible version in 2028 does not say when the organisation will actually be able to deploy it, or which applications will be affected by the upgrade.

The inventory should prepare cryptographic agility

The G7 Cybersecurity Working Group also recommends structuring the transition around several dimensions: governance, identification of cryptographic use cases, risk management, cryptographic agility and transformation management.4

Cryptographic agility means, among other things, avoiding situations where a mechanism is so deeply embedded in an architecture that replacing it becomes extremely difficult.

An inventory can reveal these situations.

Two applications using the same algorithm do not necessarily have the same migration capability.

In the first, cryptography is supplied by a maintained library, abstracted behind an interface and easy to upgrade.

In the second, the mechanism is embedded in a proprietary protocol used by several partners and implemented by equipment approaching end of support.

Technically, both rows in the inventory may show the same algorithm.

Architecturally, they are completely different.

A useful map should therefore also expose the expected difficulty of replacement.

The goal is not to inventory everything at the same level of detail

Trying from day one to discover every certificate, key and cryptographic primitive in the information system can turn into an endless project.

ANSSI also notes that automated cryptographic-inventory tools can complement the approach, but do not replace a broader process for identifying needs and use cases.1

A progressive approach can begin with uses that meet at least one of the following characteristics:

1. data whose confidentiality must be preserved for a long time;
2. important signature or authentication functions;
3. equipment with a long renewal cycle;
4. products shared widely across the information system;
5. supplier dependencies that are difficult to substitute;
6. inter-organisational protocols requiring coordinated migration.

Once these scopes are identified, the inventory can be refined to the technical level required.

This avoids confusing two different objectives: discovering every cryptographic object and knowing where to begin the transition.

The information-system renewal calendar becomes a post-quantum variable

The transition will not happen in a single operation.

ANSSI expects it to span more than a decade and recommends integrating it into normal system-renewal cycles. The agency also states that from 2030 onward it would not be reasonable to purchase new products that do not take post-quantum cryptography into account.13

This makes decisions taken today important.

Equipment purchased in 2027 and expected to remain in production for eight years may span a substantial part of the transition period.

Post-quantum considerations can therefore appear long before the migration project itself, in procurement, supplier requirements and architecture decisions.

The cryptographic inventory then also becomes a way to answer another question:

which investments made today risk creating tomorrow’s cryptographic debt?

A simple exercise to get started

An organisation can test its level of visibility without immediately launching a full transformation programme.

Choose a piece of data whose confidentiality must be preserved for at least ten years.

Then try to reconstruct its entire protection chain:

data → business process → applications → flows → protocols → equipment or services → cryptographic mechanisms → suppliers → renewal cycles.

If this chain can be obtained quickly, the organisation already has a usable foundation.

If it requires several days of interviews, configuration research and reconciliation between separate inventories, the first post-quantum workstream has probably been identified.

The objective is not yet to replace existing cryptography.

It is to know precisely what will one day need to be replaced, in what order, and why.