Post-quantum migration programmes often start in the wrong place. Teams compare ML-KEM parameter sets, debate hybrid modes, and ask which library is fastest. Those questions matter, but they are not the first dependency. The first dependency is knowing where cryptography actually lives.
Start with externally exposed paths
Public TLS endpoints are the easiest place to begin because they can be scanned repeatedly and independently verified. Capture protocol versions, certificate algorithms, chain lengths, load balancer ownership, renewal automation, and any legacy clients that still require older cipher suites. This produces an early risk map and gives engineering teams a clear pilot surface for hybrid TLS tests.
Map libraries and embedded dependencies
The harder work is inside applications and appliances. OpenSSL, BoringSSL, wolfSSL, mbedTLS, Java security providers, HSM firmware, VPN concentrators, service meshes, S/MIME tooling, code-signing pipelines, and backup products can each carry independent algorithm policies. A useful inventory records the library, version, owner, update path, and the business process that would break if the component changed.
Prioritise by data lifetime
Harvest-now/decrypt-later risk is not uniform. Session data that loses sensitivity in hours is less urgent than identity records, export-controlled material, citizen records, long-term contracts, healthcare data, or classified operational information. The inventory should therefore attach data-retention and sensitivity horizons to cryptographic paths, not only algorithm names.
Make the inventory operational
A static spreadsheet becomes stale quickly. The durable version is an operating model: scheduled scans, owner attestations, certificate transparency checks, SBOM enrichment, and change-management hooks that flag newly introduced RSA, ECDH, or legacy protocol dependencies. The inventory is not the migration deliverable; it is the control that keeps the migration from drifting after the first rollout wave.