Post-quantum cryptography is often introduced as an algorithm replacement project: identify legacy cryptography, select approved alternatives, and begin upgrading. That makes sense, but it skips the hardest question: Where, exactly, is vulnerable cryptography being used—and what depends on it?
An organization cannot plan a migration around an algorithm name alone. It needs to reconcile cryptographic observations to assets, applications, endpoints, certificates, protocols, owners, vendors, and business services. Until those relationships are visible, a post-quantum roadmap is mostly a list of intentions.
Begin with what is actually deployed
Most environments contain more cryptography than their teams can readily describe. Certificates are issued through several channels. Application teams bundle libraries into software. Network devices negotiate protocols with settings that have accumulated over years. Cloud services and third-party products introduce cryptographic dependencies outside the direct control of the security team.
A useful inventory therefore cannot be a one-time questionnaire. It must combine evidence from the discovery channels an organization can operate: passive observation, selected-asset interrogation, supported cloud integrations, existing records, and deliberately scoped uploads. Each channel sees a different portion of the estate. None should be mistaken for proof that an unobserved surface is clean.
The immediate objective is not perfect coverage. It is a canonical inventory that preserves what was observed, where it was observed, when it was observed, and how confidently it maps to a durable asset or service. That foundation turns a broad concern about quantum risk into a set of concrete records that can be evaluated and governed.
Inventory makes prioritization possible
Two uses of the same algorithm may require completely different treatment. A short-lived internal connection on a replaceable service is not the same migration problem as a long-lived certificate protecting a critical external interface. Data with a multi-decade confidentiality requirement is not equivalent to information that loses sensitivity after a few days. A vendor-managed appliance with no published upgrade path is not equivalent to an application your own team can rebuild next sprint.
Prioritization requires context. At minimum, teams need to understand the affected service, business criticality, data lifetime, exposure, ownership, replacement constraints, vendor dependency, and available remediation path. Cryptographic strength matters, but it is one input into the decision—not the entire decision.
This is also where “harvest now, decrypt later” becomes operational rather than rhetorical. If information must remain confidential beyond the expected useful life of its current cryptographic protection, the organization can identify the systems handling that information and move them earlier in the plan. Without asset and data context, the phrase produces urgency but little direction.
Migration is a governed change program
Post-quantum readiness is not a single cutover. It is a program of discovery, evaluation, planning, testing, remediation, exception handling, and proof. Some systems will adopt new standards quickly. Others will depend on operating-system support, hardware refreshes, protocol changes, vendor releases, or coordinated changes across organizational boundaries.
A credible plan should distinguish among several states: vulnerable usage that is confirmed, usage that requires further evidence, migration work that has an accountable owner, dependencies waiting on an external party, approved exceptions, and changes that have been completed and re-observed. Those states allow leadership to see whether exposure is actually declining rather than merely whether assessments have been performed.
Crypto agility matters here, but it should be treated as an engineering property rather than a slogan. Can an application change algorithms or providers without a major redesign? Can certificates and keys be rotated through controlled workflows? Can teams test interoperability before deployment? Can the organization observe the new state after a change? Inventory reveals where those capabilities are missing.
Proof closes the loop
A migration task is not complete because a ticket was closed. The changed environment should be observed again, evaluated against the intended policy, and linked to evidence that shows what changed. That may include a fresh observation, a configuration record, a test result, an approved exception, or a cryptographic bill of materials with traceable scope.
This creates an operating loop: discover cryptographic evidence, reconcile it into a canonical inventory, evaluate the resulting state, take accountable action, and preserve proof. The same loop supports today’s compliance and cryptographic hygiene work while preparing the organization for longer-term post-quantum migration.
A practical first move
Choose one business-critical domain and define its boundaries. Identify the discovery channels you can connect, the owners who can validate results, and the questions the inventory must answer. Establish a baseline, document known gaps, and select a small number of high-value records for remediation or deeper investigation.
The result will not be a complete enterprise migration plan—and it should not pretend to be. It will be something more useful: an evidence-backed model of a real part of the estate, an accountable way to improve it, and a repeatable foundation for expanding coverage. Post-quantum migration becomes manageable when it begins with that kind of inventory.