Marin Ivezic
Discovery that never finishes
Every serious post-quantum migration guide opens with the same instruction: inventory your cryptography, then migrate it. The UK’s National Cyber Security Centre puts discovery and a costed plan at 2028, first migrations at 2031, and completion at 2035, in its PQC migration timelines. US federal agencies have been submitting and updating cryptographic inventories since 2023. The instruction is sound. In a large estate it also stalls, and it stalls in the same three places almost every time.
A cryptographic inventory is a record of where an organization uses encryption, digital signatures, key exchange, and hashing. A complete entry names the algorithm and key length, the library or hardware module that implements it, the system it protects, the person who owns that system, and what else depends on it. Written out like that, the ambition is obvious, and so is the difficulty.
The first stall is tooling. Network discovery sees the TLS sessions your systems negotiate. Code scanning sees the cryptographic calls in the source you control. Certificate management sees what your certificate authorities issued. None of them sees a signing key baked into the firmware of a vendor appliance, and no single product stitches the three views into one asset list without a lot of manual reconciliation.
The second stall is other people’s software. A large share of the cryptography in your estate belongs to suppliers, and you can’t scan what you can’t open. Asking a vendor which algorithms their product uses is a procurement conversation with a response time measured in weeks, and it multiplies by the number of suppliers you have.
The third stall is arithmetic. A discovery project that runs eighteen months delivers an eighteen-month-old picture. Certificates rotate, applications get replaced, and teams stand up new services while the scan is still working through the old ones. Teams that chase completeness end up reporting a coverage percentage that never quite reaches the number they promised the steering group.
The problem is not the attempt, it is the deliverable. Coverage is a progress metric, and the program needs decisions.
What the inventory is actually for
Before scoping any discovery work, we ask architects to write down what the inventory is going to decide. In practice it feeds four decisions, and each one needs a different depth of evidence.
Sequence. Which systems migrate first, and in which release. This decision needs the data the system holds, how long that data stays sensitive, and where the system sits relative to untrusted networks. It rarely needs the cipher suite.
Containment. Which systems cannot be migrated on the required timetable and therefore need compensating controls around them. This needs the network position, the protocols in use, and the identity of whoever operates the enforcement point in front of the system.
Retirement. Which systems should be switched off rather than migrated. Every large estate carries applications whose migration cost exceeds their remaining value, and discovery is a good moment to find them. This needs usage data and an owner willing to sign the decommissioning ticket.
Contract. Which cryptography belongs to a supplier and therefore needs a clause and a date rather than an engineering task. This needs the vendor, the product, the version, and the renewal date.
Only the first of these eventually turns into detailed engineering work, and only that work needs the algorithm-by-algorithm depth that the guidance describes. Three of the four decisions can be made from information most organizations already hold in a configuration management database, a data classification scheme, and a contract register.
That reframing is what makes a partial inventory legitimate rather than an admission of defeat. You’re not sampling the estate and hoping. You are collecting the evidence each decision requires, at the depth that decision requires, and recording where you stopped.
Two dates, and which one binds
Two dates govern the sequence, and architects should know which of the two is driving each system.
The first comes from the physics and the engineering. A cryptographically relevant quantum computer (CRQC) is one large and stable enough to run Shor’s algorithm against the key sizes in production use, which would break RSA, Diffie-Hellman, and elliptic-curve cryptography. Nobody has built one. Resource estimates have been falling: a 2025 estimate from Craig Gidney at Google Quantum AI puts factoring a 2048-bit RSA modulus at fewer than one million noisy physical qubits running for under a week (arXiv:2505.15917), well below the twenty-million figure that circulated from his 2019 analysis with Martin Ekerå. That is an estimate on paper, not a demonstration, and the gap between announced hardware and demonstrated logical qubits remains large. It’s still the direction of travel, and it is the number a board will ask about.
Michele Mosca of the University of Waterloo turned this into a relation architects can use. Take x, the number of years your data must stay confidential. Take y, the number of years your migration will take. Take z, the number of years until a CRQC exists. If x plus y is greater than z, data you are protecting today is already exposed. The relation does not require you to know z precisely. It requires you to pick a planning value, defend it, and notice that a thirty-year retention obligation plus a five-year migration leaves very little room under any plausible estimate.
The second date comes from regulators, and for most commercial systems it binds first. NIST’s draft IR 8547 proposes that RSA-2048 and ECDSA P-256 be deprecated after 2030 and disallowed after 2035. The NCSC roadmap lands on the same 2035 endpoint. The US National Security Agency’s CNSA 2.0 suite requires AES-256, SHA-384, ML-KEM-1024 (formerly CRYSTALS-Kyber) for key establishment, and ML-DSA-87 (formerly CRYSTALS-Dilithium) for signatures on national security systems, and that transition is staged rather than complete. If your organization sells into any of those markets, a customer or an auditor will ask for a migration plan well before a quantum computer exists.
Sequencing by the regulatory date is the pragmatic default. Sequencing by Mosca’s relation is what you do for the small set of systems where the retention obligation is long enough to override it.
Four filters for the first pass
With the decisions and the dates fixed, a first pass over the estate can be done in weeks rather than quarters. Four filters do most of the work.
Confidentiality lifetime. How long does the data this system protects need to stay secret? This is the filter that catches harvest now, decrypt later (HNDL), where an adversary copies encrypted traffic or encrypted archives today and stores them until a CRQC can open them. Data with a short shelf life is largely out of scope for that attack. Clinical records, insurance claim files, source code, merger documentation, and long-lived personal data are not.
Signature and trust-anchor lifetime. Signatures have the mirror-image problem, sometimes called trust now, forge later (TNFL). A quantum adversary who can forge signatures can issue certificates your systems accept, sign firmware your devices install, and produce contracts your archives will validate. The systems to flag here are the ones whose trust decisions outlive the algorithm: a root certificate authority with a 2040 expiry, a code-signing key that authenticates firmware for a fifteen-year field asset, a device identity burned in at manufacture. Signatures get less attention than encryption in most inventory projects, and they are frequently harder to change.
Exposure. Which cryptographic traffic crosses a network you do not control? Internet-facing services, site-to-site links over carrier circuits, remote access, partner integrations, and anything traversing a shared facility all rank above a protocol confined to one rack. Exposure is what turns a theoretical HNDL risk into a plausible one, because the adversary has to record the traffic before they can store it.
Brittleness. This is the filter architects most often skip, and it changes the plan more than the other three. The question is not only which algorithm a system uses, it is how hard that algorithm will be to change. A service running a current TLS library behind a load balancer can be moved in a sprint. A payment terminal with a hardcoded key, an appliance whose vendor is out of business, an industrial protocol with no negotiation step at all, or an application that calls its cryptography from eleven different places in the code base will take years. Brittle systems belong in the plan early even when their data is unremarkable, because their lead time is the constraint.
Score each significant system group against the four filters, record the score, and stop. That’s the first pass. Detailed discovery then goes only to the systems the filters lifted to the top, and to the trust anchors those systems depend on.
Record what you did not look at
The unexamined remainder gets written down, and that’s what turns a partial inventory from a shortcut into an auditable position.
Most partial inventories fail their first serious review not because they covered too little, but because they were silent about what they left out. A reviewer cannot tell the difference between a scope decision and an oversight, so they treat both as an oversight. A residual-scope register removes that ambiguity. It sits alongside the inventory, it has a named owner, and it carries one row per group of systems you chose not to examine.
| Field | What it records |
|---|---|
| System group | The set of assets, named specifically enough to be counted |
| Reason not examined | Tooling limitation, vendor opacity, operational risk, cost, or timing |
| Assumed cryptographic posture | The conservative assumption you are working from |
| Exposure assessment | Where this group sits relative to untrusted networks |
| Compensating control | What reduces the risk while the group stays unexamined |
| Review trigger and date | The event or date that reopens the question |
| Risk owner | The person who has accepted the residual risk in writing |
A filled row reads something like this. System group: 340 building management controllers across eleven sites. Reason not examined: no read access to firmware, vendor unresponsive on algorithm disclosure. Assumed posture: RSA-1024 or weaker for management sessions, no signature verification on configuration updates. Exposure: management VLAN, reachable from the corporate network via two jump hosts. Compensating control: management VLAN moved behind an enforcement proxy in Q3, jump host access restricted to a named group with hardware authentication, egress from the VLAN blocked. Review trigger: next controller refresh cycle, or vendor disclosure, whichever comes first. Owner: Head of Facilities Technology.
That row is more useful to a migration program than a scan result would have been, and it took an afternoon. It states the worst case, it states what has been done about the worst case, and it names the person who agreed. When the assumption turns out to be wrong, the register shows what the organization believed and when, which is the difference between a defensible decision and an embarrassment.
We would rather see an inventory covering thirty percent of an estate with a complete residual register than one covering eighty percent with no account of the other twenty.
A worked example
Consider a regional electricity distributor with roughly 2,000 employees, running a customer billing portal, a corporate identity platform, an internal certificate authority, a control centre, and several hundred substations. The enterprise-wide discovery quote came back at fourteen months and a price the board wouldn’t approve.
The first pass took three weeks and produced four groups.
Group one, scanned in full. The billing portal, the public API, the corporate certificate authority, and the remote access gateway. All internet-facing, all running software the team can read, all with owners in the room. Discovery here was straightforward: TLS versions and negotiated groups from the load balancers, library versions from the build pipelines, certificate details and expiry dates from the certificate authority. The result was a concrete engineering backlog, including a certificate authority whose root expires in 2039 and signs with RSA-2048, which is the single most consequential finding in the estate.
Group two, scanned selectively. Around forty internal business applications. Rather than scan all of them, the team pulled the cryptographic dependencies from the five shared libraries that most of them call, and scanned only the applications that do not use those libraries. Coverage of the group’s cryptography turned out to be far better than coverage of the group’s applications, because the cryptography is concentrated where the libraries are.
Group three, vendor questions instead of scanning. Payroll, the geographic information system, and the outage management platform, all supplier-hosted. No scanning is possible and none would be permitted. The team sent one standard question set to each supplier, asking which key establishment and signature algorithms the product uses, whether the vendor has published a post-quantum migration plan, and what date they commit to. Two answered. The third became a residual register row with a contract renewal date as the review trigger.
Group four, residual by design. The substation protection and automation equipment, including several hundred intelligent electronic devices, which are the microprocessor-based relays and controllers that protect and switch the network. These devices have fifteen to twenty-five year service lives, several models predate any practical cryptographic agility, and scanning them in service carries an operational risk the control room would not accept. The team wrote three residual rows covering the equipment by generation, assumed the worst plausible posture for each, and put the compensating controls in the same rows.
The distributor’s plan then wrote itself. The certificate authority is the first migration, because it is the trust anchor everything else inherits from and its own key outlives the deprecation date by four years. The internet-facing services follow, because they are exposed and easy to change. The substations get containment now and a cryptographic requirement written into the next procurement cycle, because that cycle is the only realistic opportunity to change them.
Controls for what you cannot migrate yet
Compensating controls buy time. They are worth deploying, and they are worth understanding precisely, because two of them are routinely credited with protection they don’t provide.
Reduce exposure first. Segmentation, restricted access paths, and terminating external connections at a boundary you control all shrink the set of adversaries who can record your traffic in the first place. Disabling static RSA key exchange and old TLS versions is worth doing on its own merits. Perfect forward secrecy, which uses an ephemeral key per session so a stolen server key cannot decrypt past traffic, doesn’t defeat harvest now, decrypt later. A CRQC can solve the ephemeral Diffie-Hellman exchange from the recorded handshake. Forward secrecy protects you against server key theft, and that is a different attack.
Wrap what you cannot change. A post-quantum outer tunnel around a legacy inner protocol is a real mitigation for data in transit. The standard mechanism is hybrid key exchange, where a classical algorithm and a post-quantum one both contribute to the session key, so the session stays secure unless both are broken. The hybrid group combining X25519 with ML-KEM-768, the NIST-standardized lattice key encapsulation mechanism, has been widely tested rather than widely defaulted. Chrome offers it to servers that support it and turned it on for Google origins, Firefox support is experimental or opt-in, and providers including Cloudflare terminate hybrid key exchange at the edge. Adoption is growing, and it is not yet the default across the web. Equivalent extensions are being standardized for IPsec. Where a device cannot speak the new protocol, a gateway can terminate the hybrid connection and hand off over a short, controlled internal link. Two honest limits apply. The inner leg stays as weak as it was, so the control is only as good as the containment around that leg. And an overlay appliance becomes a trust anchor of its own, with its own key management, its own patch cycle, and its own supplier. Some vendors sell these as making an estate quantum-safe. They make a link quantum-safe, which is a smaller and more useful claim.
Raise symmetric margins. Grover’s algorithm gives a quadratic speedup on brute-force search, which is usually described as halving the effective strength of a symmetric key. That halving is a conservative upper bound rather than an operational forecast, because the search is inherently serial and does not parallelize the way classical cracking does. Moving to AES-256 and SHA-384 is still the right move, it is cheap in most places, and it is what CNSA 2.0 requires.
Watch for the harvest. The decryption phase of an HNDL attack is invisible to you by definition, because it happens on someone else’s hardware, years later. The collection phase is not. Bulk transfers of encrypted archives, unusual database exports, and sustained taps on high-value links are all detectable with controls most security operations teams already run. Tuning existing data-loss and anomaly detection toward large encrypted egress is a low-cost addition, and it is the only stage of the attack where intervention is possible.
Making a partial inventory defensible
Three habits turn the partial inventory into something that survives an audit and keeps its value between refreshes.
Express what you found in a portable format. A cryptography bill of materials (CBOM) is a machine-readable list of the cryptographic assets a piece of software contains, including algorithms, key lengths, certificates, and the protocols they support. The CycloneDX specification supports it, and NIST’s National Cybersecurity Center of Excellence has published example implementations through its post-quantum migration project. Producing a CBOM for the systems you did scan gives you something you can diff at the next refresh, and something you can ask suppliers to produce rather than answering a bespoke questionnaire.
Push the boundary into procurement. Vendor cryptography is not going to become visible through better scanning. It becomes visible through contract language: a disclosure requirement at onboarding, a CBOM at each major release, and a committed migration date. Every residual row whose reason is vendor opacity should have a matching clause in the next renewal.
Build agility while you wait. Crypto-agility is the ability to change a cryptographic algorithm without rewriting the application that depends on it, usually achieved by routing cryptographic operations through a shared service or library rather than scattering calls through the code. It is the reason the second migration costs a fraction of the first. Centralizing cryptographic calls, upgrading libraries to versions that already support the new algorithms, and standing up a test environment for hybrid modes are all work you can start before the inventory is finished, and none of it is wasted if the plan changes.
None of this removes the eventual obligation. Regulators expect complete migration, and complete migration will eventually require complete knowledge. What a risk-driven inventory changes is the order of operations and the honesty of the reporting. You protect the assets that would hurt most, you contain the ones you cannot reach, you write down what you haven’t examined, and you name the person who accepted that. A program built that way can report progress every quarter instead of reporting a coverage percentage that keeps not arriving.
Where to build this skill
Scoping decisions of this kind sit awkwardly between architecture and governance. They need enough cryptographic depth to judge what a scan result actually means, and enough program discipline to write a residual register that a risk committee will sign. Quantum Academy’s post-quantum training is built for exactly that pairing, with the assessment work drawn from the same kinds of estate problems described here rather than from textbook scenarios. You can see the current programs and enrollment options at quantumacademy.com/.
For the migration methodology that sits underneath these decisions, including phase structure and governance artifacts, see pqcframework.org. For deeper technical treatment of the algorithms, resource estimates, and standards timelines referenced above, PostQuantum.com carries the long-form analysis.