Cryptographic inventory: where an SME should start

Why now

The argument is counter-intuitive: a quantum computer able to break today's public-key encryption doesn't exist yet, and no one knows whether it will arrive in five years or twenty. So why worry about it?

Because the threat doesn't wait for the machine. It's called "harvest now, decrypt later": capture encrypted communications today, store them, and decrypt them the day the capability exists. Any data that keeps its value in ten years — medical records, trade secrets, personal data, intellectual property, legal archives — is already exposed if it travels under vulnerable cryptography.

The question isn't "when will the quantum computer arrive", but "how long must my data stay secret".

The cryptographer Michele Mosca formalised this intuition. Set three durations:

• X — how many years your data must remain confidential;
• Y — how many years it will take you to migrate your cryptography;
• Z — in how many years a relevant quantum computer will exist.

If X + Y > Z, you're already behind. Most organisations underestimate Y — the migration — far more than Z. And Y begins with something simple and often overlooked: knowing where your cryptography is.

What a cryptographic inventory is — and isn't

A cryptographic inventory is the complete mapping of the cryptographic mechanisms in use across an organisation: which algorithms, which key sizes, which protocols, which certificates, where they are used, what data they protect, and for how long.

It is not a compliance audit, a vulnerability scan, or a migration project. It's the step that makes all of those possible. Without an inventory, a post-quantum roadmap rests on assumptions; with it, it rests on facts.

The minimum scope for an SME

An SME doesn't need — and can't afford — to inventory its entire information system at once. The useful scope, in order of priority:

1. External communications: TLS for sites and APIs, VPNs, email, file transfers.
2. Long-life data at rest: databases, backups, archives, encrypted storage.
3. Secrets and authentication: certificates, SSH keys, code signing, tokens, access management.
4. Third-party dependencies: cryptographic libraries, SaaS providers, hardware (HSMs, cards).

This scope covers most of the real risk for a fraction of the effort of an exhaustive inventory.

The four-pass methodology

We proceed in four successive passes, from broadest to most precise. Each pass produces a usable deliverable even if you stop there.

Pass 1 — Discovery

List the surfaces: domains and subdomains, exposed services, code repositories, certificates, endpoints and servers. We combine documentary sources (registries, configurations, network diagrams) with direct observation (service scanning, reading the negotiated TLS suites). The goal: a list of places where cryptography is likely to live.

Pass 2 — Inventory

For each identified place, record the detail: algorithms (RSA, ECDSA, AES, etc.), key sizes, protocols and versions, certificates and their expiry, and — often forgotten — the lifetime of the data protected. It's this last piece that turns a technical inventory into a decision tool.

Pass 3 — Prioritisation

Cross the inventory with Mosca's model. A brochure-site TLS certificate and an encrypted medical-archive database don't call for the same urgency: the first protects ephemeral, public data; the second, data sensitive for decades. We rank by decreasing X + Y.

Pass 4 — Roadmap

Translate the prioritisation into a plan: what to migrate, in what order, to which algorithms (the NIST standards ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures), and on what milestones. The guiding principle isn't "replace everything" but crypto-agility: making future algorithm changes cheap.

Prioritising fixes: Mosca's logic in practice

The temptation is to start with what's easy to fix. That's a mistake. You start with what has value over time exceeding the migration horizon — even if it's harder. Concretely, three categories:

• Urgent: long-life data, travelling or stored under classical public-key encryption. The first targets of "harvest now".
• Important: authentication and signatures, whose future compromise opens doors — but without retroactively exposing past data.
• Deferrable: ephemeral or public data, where the quantum risk is marginal.

Common mistakes — and how to avoid them

• Confusing inventory and migration. Trying to fix while discovering. Inventory first, decide second; otherwise you optimise details while ignoring the main risk.
• Forgetting data lifetime. Without X, any prioritisation is arbitrary. It's the hardest figure to obtain and the most decisive.
• Ignoring "invisible" cryptography. The kind embedded in dependencies, SaaS, hardware. You don't see it, but it protects — or exposes — your data.
• Migrating without crypto-agility. Replacing one frozen algorithm with another frozen algorithm. The next transition will come; the architecture must absorb it without a new project.

After the inventory

A well-run inventory leaves an organisation with three lasting gains: a clear view of its exposure, a defensible prioritisation, and a sequenced roadmap. The post-quantum migration then becomes an ordinary engineering project — planned, budgeted, measurable — instead of an abstract anxiety.

That's precisely the point of our work: turning a risk few can yet name into a set of concrete steps, within an SME's reach.