PQC Migration Is an Asset Discovery Problem Before It Is a Cryptography Problem.

Most post-quantum conversations start in the same place: which algorithm. ML-KEM instead of a classical key exchange, ML-DSA instead of RSA or ECDSA, and an argument over which hybrid scheme to run during the transition. It's a real decision, and it matters. It is also not the hard part.

The hard part is that most organizations don't know where their own cryptography lives. Algorithm selection quietly assumes an inventory that, in almost every environment we walk into, doesn't exist yet.

Why the inventory doesn't exist

Cryptography is invisible by design, which is exactly what makes it easy to lose track of. It's buried in TLS configuration nobody has touched since it was first set up. It's hardcoded into firmware with a ten-to-fifteen-year deployment lifespan, running on hardware nobody plans to revisit before it ages out. It's wrapped inside third-party libraries and SDKs, several dependencies deep, where the team that shipped it may not even know which primitives are in use underneath. And it's embedded in long-lived signed artifacts — code-signing certificates, document signatures — that have to keep verifying correctly years after the algorithms behind them are formally deprecated.

On top of that, almost nobody owns "cryptography" as a system the way they own identity or network. Identity has an IAM team. Network has a network team. Cryptographic usage is scattered across every team that happened to need it, with no single owner accountable for knowing where it all is — which means the inventory doesn't just not exist, there's no one whose job it was to build it.

And even where someone does take a snapshot, it goes stale almost immediately. Cryptography is added continuously — every new service, dependency, certificate and integration brings more of it — so a one-time scan is out of date by the time it's written up. A usable inventory is not a document produced once; it's a capability that keeps running, which is a very different thing to ask an organization to stand up, and a large part of why the honest answer to "where is all your cryptography" is so often a shrug.

What discovery actually has to cover

Discovery that earns the name has to reach past the systems a team already suspects, because the cryptography that breaks a migration is precisely the cryptography nobody remembered was there. It is less a scan than a hunt, and what it has to find falls into four categories — breadth across the whole estate, a structured bill of materials that assigns ownership, sequencing that reflects genuine exposure rather than convenience, and a reckoning with the data that is already at risk today:

• Discovery across the full estate — application code, infrastructure, firmware, and third-party dependencies, not just the systems a team already knows use cryptography.
• A cryptographic bill of materials that turns raw findings into something a program can actually run against: algorithms, key sizes, protocols and ownership, mapped to real systems rather than left as a scan output.
• Sequencing by actual exposure and data lifetime — a system protecting data that must stay confidential for twenty years is not the same priority as an artifact that's signed once and consumed immediately.
• A plan for what's already at risk today — "harvest now, decrypt later" applies to sensitive data in transit right now, independent of when the migration itself finishes.

The move that matters here is the one from the first bullet to the second: a scan produces findings, but a bill of materials produces accountability. A list of algorithms nobody owns is just a longer version of the problem. A cryptographic bill of materials that ties each use to a system, a protocol and a named owner is the artifact a migration program can actually be run against — the difference between knowing you have a problem and being able to assign it. Ownership is the operative word. Every other column in the inventory describes the cryptography; the owner column is the only one that names who will actually do the migrating, and it is the column raw tooling almost never fills in on its own.

Harvest now, decrypt later changes the clock

There is a tempting way to defer all of this: a cryptographically relevant quantum computer doesn't exist yet, so the migration can wait until one is closer. That reasoning holds for data with a short shelf life. It fails completely for data that has to stay confidential for a decade or two, because an adversary does not need a quantum computer today to benefit from one later. They need only to capture the encrypted traffic now and store it. The decryption happens whenever the capability arrives; the exposure is already underway.

That reframes the whole exercise. The deadline is not the arrival of quantum hardware — it's the confidentiality horizon of the data you are transmitting today, counted backward. Anything that must remain secret past the point such hardware is plausible is, for practical purposes, at risk right now. And you cannot triage by that horizon until you know which systems carry long-lived secrets and which don't, which is to say: you cannot even measure the urgency without the inventory. Discovery is not a prerequisite you get to postpone; it's the thing that tells you how much time you actually have.

An algorithm you haven't inventoried the need for is not a migration plan. It's a guess with better math behind it.

The algorithm decision doesn't go away — it gets sequenced correctly

None of this makes the algorithm choice unimportant. It makes it the second decision instead of the first — made system by system, against a real inventory, in the order actual exposure demands rather than the order systems happen to get noticed. And algorithms will change again after this migration — they always do, which is exactly why crypto-agility has to be built into the architecture from the start rather than treated as a one-time swap.

That's the sequence behind 6QURE's post-quantum methodology: discovery and CBOM before hybrid architecture, so the migration is built on an inventory that's actually complete rather than one bounded by whatever was already easy to find. Get the order right and the algorithm decision becomes almost mechanical. Get it wrong and you spend years migrating the systems you could see, while the ones you couldn't keep protecting your longest-lived secrets with exactly the cryptography you set out to replace.