You cannot migrate cryptography you cannot find
Every post-quantum migration plan begins with an inventory, and most inventories stall because the team looks for algorithms instead of looking for the places algorithms are decided.
Why inventories stall
Ask a large organisation to inventory its cryptography and a predictable sequence follows. A tool is procured, it scans source repositories, it produces a list of several thousand library calls, and the list is unusable: it does not say what each call protects, most entries are in dependencies rather than in code the organisation writes, and the entries that matter most are absent because they are not in source code at all.
Six months later the exercise is described as ongoing. The migration plan that was supposed to follow does not exist, because the input to it never arrived.
The failure is one of framing. Cryptography is not a property of code; it is a property of systems, and it is decided in several places—in code, yes, but also in appliance configuration, in firmware, in protocol negotiation with a counterparty, in a certificate hierarchy, in the format of data written years ago. An inventory built from one of those sources will be confidently incomplete.
Look for decision points, not algorithms
A more productive framing is to enumerate the places where a cryptographic choice is made, and then ask what each one chose. There are far fewer decision points than library calls, and every one of them belongs to someone.
For each decision point, the questions are the same: what scheme and parameters, protecting what, for how long, changeable by whom, and blocked by what. An inventory of two hundred decision points with those six fields is a migration plan. An inventory of four thousand library calls is a report.
This is the structure that the joint quantum-readiness guidance recommends: begin with an inventory that connects cryptographic use to the systems and data it supports, and use it to prioritise. The connection to data is the part that makes prioritisation possible.
Eight places to look
Discovery has to be multi-source. In rough order of how often the important findings appear:
| Source | Method | What it finds |
|---|---|---|
| Network observation | Passive capture and active scanning of internal and external endpoints | What is actually negotiated, including systems nobody documented |
| Certificate inventory | Private CA records, transparency logs, endpoint scanning | Key algorithms and sizes across the estate, expiry dates |
| Key management services | Enumerate keys in modules and key services | Keys in active use, their algorithms and purposes |
| Appliance and platform configuration | Configuration export from load balancers, VPNs, databases, storage | Long-lived choices nobody revisits |
| Source and dependency analysis | Code scanning plus the component inventory | Application-level use and library versions |
| Stored data formats | Schema and format review | Whether ciphertexts and signatures record their scheme |
| Firmware and device images | Image analysis, vendor documentation | Embedded roots of trust and signature schemes |
| Counterparty integrations | Contract and interface review | Protocol choices you cannot change unilaterally |
The first source is the most efficient starting point and the most often skipped, because it requires network access rather than repository access. It is also the only method that finds systems the organisation has forgotten it operates.
The component inventory is worth using here rather than building something parallel. If the build already emits a bill of materials, the cryptographic libraries and versions in each release are already recorded, and the marginal work is mapping library versions to the schemes they are configured to use.
Record the fields that make it a plan
An inventory entry should be short and should contain the fields a plan needs:
- Asset. The specific system, endpoint, key or data store.
- Scheme and parameters. Algorithm, mode, key size, and where applicable the certificate chain.
- Purpose. Confidentiality, integrity, authentication, signing—and of what.
- Protection lifetime. How long the data or assertion must remain secure. This is a business input, not a technical one.
- Change owner. The named team that would perform the change.
- Blocker. What prevents the change today: a vendor release, a counterparty, a hardware limit, a data migration, nothing.
The last two fields are what most inventories omit and what makes the difference between a list and a work plan. An asset with no named owner will not migrate, and identifying the blocker is usually what reveals that the work is a two-year vendor conversation rather than a configuration change.
NIST SP 800-57 supplies the vocabulary for the scheme and lifetime fields, and it is worth using its distinctions rather than inventing local ones—the difference between a key-encryption key and a data key, or between a signing key and an authentication key, determines migration order.
Rank by difficulty and by data lifetime
Two rankings matter, and they are different.
The first is migration difficulty: how long the change would take once decided. Configuration changes are days. Application releases are weeks. Counterparty protocol changes are quarters. Deployed device firmware and embedded roots of trust are years, or never. Ranking by difficulty tells you what to start now, because the slowest items determine the end date regardless of when you begin the easy ones.
The second is data lifetime against harvest risk. Confidentiality protected by a public-key key exchange today can be broken retrospectively by an adversary who records traffic now and decrypts later. Any data whose confidentiality must outlast the arrival of a capable quantum computer is therefore already at risk, and ranking by required protection lifetime identifies it.
The UK’s migration timelines set out a schedule against which both rankings can be read: discovery and planning first, high-priority migration completed by 2031, and the remainder by 2035. Working backwards from those dates, an asset with a three-year change cycle needs its decision made well before the end.
The assets that will hurt
Across assessments, the entries that dominate a migration plan are consistent, and none of them are application code:
- Deployed devices with a signature verification root in immutable storage, where the algorithm cannot be changed for units already shipped.
- Counterparty protocols in payments, industrial control and government interfaces, where the message format is specified by someone else on their timetable.
- Hardware security modules whose firmware must support the new schemes, which depends on a vendor release and often on a hardware refresh.
- Long-retention stored data encrypted in a format with no algorithm identifier, so re-encryption requires inferring the scheme.
- Embedded and licensing systems where a public key is compiled into a client that customers control.
- Document and archive signatures that must remain verifiable for decades, which needs a long-term validation strategy rather than a re-signing.
Finding these early is the entire point of the inventory. They are the reason NIST’s transition guidance sets deprecation dates years ahead: the schedule is long because the slowest assets are slow.
Keep it current without a programme
An inventory assembled once and never updated is worth less each quarter. Keeping it current as a standing programme is expensive and tends to be cancelled.
The sustainable arrangement attaches inventory updates to events that already happen. A new external interface, a new appliance, a new vendor integration, a change to a data format, or a new hardware revision each generate one inventory entry as part of the existing design review. Certificate and key inventories update themselves from the issuing systems. Network discovery re-runs quarterly and reports differences rather than a full list.
The output to maintain deliberately is small: the ranked list of assets that would take more than a release cycle to change, with owners and blockers. Twenty to fifty lines. That artefact is what a migration decision actually consumes, and it is short enough that someone will keep it accurate.