Where a CISO should start a post-quantum migration: the cryptographic inventory

When a board asks a CISO about post-quantum cryptography, the conversation usually jumps straight to vendors and algorithms.

I understand why. They’re concrete. But every serious migration plan I know of starts somewhere less exciting: an inventory of where cryptography is actually used.

The European Union’s coordinated roadmap for the transition makes the same point. Its first milestones, due by the end of 2026, are about understanding exposure and planning, not about replacing algorithms.

Why the inventory is harder than it sounds

Cryptography is everywhere and nowhere. It’s inside protocols, libraries, hardware modules, cloud services, embedded devices and third-party products. Very few organisations have ever needed a complete list.

A spreadsheet of certificates is a start. It won’t tell you:

• which applications negotiate which key-exchange algorithms;
• which libraries, in which versions, implement them;
• which devices verify firmware with which signature scheme;
• which data protected by those mechanisms must stay confidential for a long time;
• which supplier you depend on to change any of it.

That’s why the term CBOM, cryptographic bill of materials, is gaining ground: a structured description of cryptographic assets, in the same spirit as an SBOM for software components. CycloneDX, for example, supports it.

What a useful inventory contains

For each cryptographic use, I’d want to capture at least:

1. Where it is: system, application, device or service.
2. What it does: key exchange, encryption, signature, identity, integrity.
3. Which algorithm and key size, and whether it is quantum-vulnerable.
4. Who implements it: in-house code, an open-source library, a hardware module, a supplier.
5. What it protects, and for how long that protection must last.
6. How it can change: configuration, software update, firmware update, hardware replacement, or not at all.
7. Who owns it.

The last two fields are the ones most inventories skip, and the ones that turn a list into a plan.

Relationships matter more than items

An inventory is a list of things. A migration is a sequence of changes to things that depend on each other.

If a certificate authority changes its signature algorithm, which devices will fail to validate new certificates? If a library is upgraded, which products embed it? If a device can’t verify a new signature, which update has to come first?

These questions can’t be answered from a flat list. They need a model of the relationships. That’s the core of what we’re building at Shorium, and the reason I think of it as a design problem as much as a security one: people need to see the consequences of a decision before they make it. More in Why I’m building Shorium.

A pragmatic sequence

You don’t need perfect coverage to start. A sequence that works:

1. Start with the long-lived data and the long-lived products. Anything that must stay confidential beyond 2035, and any device that will still be in the field then. See harvest now, decrypt later.
2. Use what you already have. Certificate managers, network scans, code repositories, SBOMs and procurement records each reveal part of the picture.
3. Ask suppliers early. Their post-quantum roadmaps will constrain yours. Put the question into contracts and renewals now.
4. Classify by changeability. Separate what can be changed by configuration from what needs a release, and from what needs new hardware. The last group sets your real timeline.
5. Keep it alive. An inventory that’s updated once a year will be wrong when you need it. Connect it to the processes that change systems.

What to tell the board

The board doesn’t need algorithm names. It needs three things: how exposed the organisation is, how long a migration will realistically take, and what decisions are needed now to avoid making it longer.

A good inventory answers all three. That’s why it comes first.