Crypto Inventory and Crypto-Agility: You Don't Migrate What You Don't Know You Have

Every conversation about post-quantum migration comes up against an unanswered question: where, exactly, does the organization use cryptography. Most leaders don't know how to respond, and those who respond quickly are often mistaken.

This lack of knowledge is the biggest obstacle to the project. You can't migrate, prioritize or estimate deadlines on a blank map. Before choosing ML-KEM, ML-DSA or any algorithm, you need to see the lay of the land.

This article addresses the two capabilities that underpin any serious cryptographic transition: inventory, which shows what you have, and crypto-agility, which allows you to change algorithms without rewriting the entire system. Without them, post-quantum migration becomes an eternal and expensive project.

Why inventory comes before everything

Encryption spreads throughout an organization silently. It is in network traffic, in certificates, in software signatures, in tokens, in databases, in integrations with third parties, in devices, in libraries that came embedded in dependencies that no one consciously chose.

This scattering creates dangerous blind spots. A forgotten certificate, an old library embedded three levels down the dependency chain, a legacy service that no one wants to touch: any of these could be exactly the point that uses RSA or ECC critically. You don't migrate what you don't know you have, and what you don't know you have is what hurts the most.

Inventory is also what makes prioritization possible. Without knowing where the encryption is and what data it protects, you can't tell what to migrate first. With the map, the conversation changes from "we need to do something about quantum" to "these twenty streams protect long-term data and rely on vulnerable algorithms, let's start with them."

And there's the compliance angle. Demonstrating to a regulator, an auditor, or a client that you know where you use encryption and have a plan is very different from admitting you have no idea. Under LGPD, knowing and protecting the path of personal data is part of the obligation, not an extra.

What to map, specifically

A useful cryptographic inventory goes beyond listing certificates. He answers operational questions.

Map cryptographic assets: keys, certificates, secrets, their locations, owners and expiration dates. Map the algorithms in use, distinguishing what is vulnerable to quantum computing, such as RSA and ECC, from what is more resilient, such as strong symmetric cryptography. Map out the libraries and versions that each application uses, including those built into dependencies, because that's where most of the encryption lives that no one consciously chose.

Map the protocols of your connections, internal and external, because it is in their key exchange that the risk of early capture is concentrated. And map the data that each use of encryption protects, with special attention to the validity of confidentiality: data that needs to remain secret for many years is the most exposed to "harvest now, decrypt later", the capture of data encrypted today for decryption in the future with quantum computing.

Finally, map the suppliers. Much of your encryption runs within cloud providers, SaaS and partners. Knowing which of them have a post-quantum transition plan is part of your inventory, because their risk is yours.

How to conduct the survey without crashing

The reaction of many teams to this list is discouragement: it seems too big. The solution is not to try to inventory everything perfectly at once.

Combine fonts. Automated discovery tools scan network, code, and certificates and find much of what is hidden. But they don't replace people's knowledge: architects and product teams know dependencies and contexts that no scan captures. Use both fronts.

Start with what matters. Instead of a universal inventory before taking any action, prioritize systems that touch long-validity, high-exposure data. Inventory these first, start acting on them, and expand the survey in waves. A partial and actionable inventory is worth more than a complete and delayed one.

And treat inventory as alive. It is not a document that you write once and file away. Systems change, certificates are born and die, dependencies increase in version. An inventory that is not updated ages quickly and becomes a blank map again. Integrate cryptographic discovery into your change and deployment processes.

Crypto-agility: exchange without rewriting

Inventory answers "what I have." Crypto-agility answers “how fast can I trade”. The two complement each other.

Crypto-agility is the ability to change a system's cryptographic algorithm without completely rewriting it. It is an architectural property. Systems that have tied a specific algorithm into the code, spreading direct calls to a cipher far and wide, pay dearly to change: each change becomes a months-long project, with risk at every point.

The difference is in the coupling. When encryption is isolated behind a well-defined layer, a clear boundary that the rest of the system uses without knowing the internal details, switching the algorithm beneath that boundary is a contained change. The rest of the system doesn't even notice.

This matters especially now because post-quantum cryptography will evolve. Parameters will be adjusted, new algorithms may emerge, recommendations will change. Without crypto-agility, you repeat the entire migration project with every move. With it, the next exchange is incremental. Post-quantum migration is the first major proof of this capacity, not the last.

Building the ability to exchange

Crypto-agility cannot be bought ready-made, it is built with conscious design decisions.

Centralize access to encryption. Instead of having each part of the system directly call a specific cipher, have them pass through a common point that decides which algorithm to use. Changing the algorithm means changing this central decision, not hunting for calls scattered throughout the code.

Outsource algorithm configuration. Which cipher to use, with which parameters, must be a configuration, not a constant embedded in the code. This allows you to adjust, and even roll back, without rewriting and redeploying everything, which is vital when a post-quantum upgrade causes problems in production and you need a way back.

Design to work with more than one algorithm at the same time. During the transition, clients and servers will be at different stages, and the hybrid approach combines classical and post-quantum algorithms. Your system needs to negotiate and support multiple algorithms in parallel without breaking legitimate connections. Anyone who assumed a single algorithm in the design suffers exactly here.

And accommodate the new sizes. Post-quantum keys and signatures are bigger. Structures, fields, and boundaries that have assumed small sizes need clearance. Building this slack now avoids redoing the work later.