Post-Quantum Cryptography Inventory: Prioritize Before You Migrate

Post-quantum migration begins with knowing where public-key cryptography is used and how long protected data must remain confidential or authentic. Buying one “quantum-safe” product does not address certificates, firmware signing, identity, VPNs, code signing, backups, embedded devices, partner protocols, or archived data.

The practical problem

A company inventories TLS endpoints but initially misses document signatures and firmware update keys. The team expands discovery to certificate services, HSMs, CI systems, mobile apps, appliances, vendors, and long-lived archives. It ranks high-value data with ten-year confidentiality above short-lived public content, records which vendors support hybrid modes, and identifies an old device fleet whose firmware cannot accept larger signatures.

This scenario defines the boundary for post quantum cryptography inventory: the system of record, the component that enforces the decision, the asset or money at risk, and the condition that ends an exception. If one of those is unknown, discover it before changing production or presenting the number.

A step-by-step workflow

1. Scope the system. Define cryptographic categories and business data lifetime.
2. Establish the baseline. Discover certificates, key stores, libraries, protocols, hardware, signing systems, and vendor services.
3. Apply the control. Record algorithm, key size, purpose, owner, location, expiry, rotation method, dependency, and upgrade path.
4. Test failure paths. Identify harvest-now-decrypt-later exposure.
5. Verify the result. Map trust chains and interoperability.
6. Record ownership. Test standardized post-quantum or hybrid options in representative environments.
7. Close the loop. Prioritize by consequence, lifetime, replaceability, and ecosystem readiness.
8. Review the change. Plan rollback and coexistence..

Prove the failure paths

Start with a healthy case based on “Define cryptographic categories and business data lifetime”, then repeat the exercise while deliberately violating the assumption behind “identify harvest-now-decrypt-later exposure”. Capture the observable result, the alert that should fire, and the person who decides whether to stop or continue. Next, simulate the most credible failure in this guide: scanning certificates alone misses application-layer and signing use. The test passes only when the team detects the condition, limits its impact, and restores service or the decision model without relying on undocumented knowledge. A final replay should cover proprietary “quantum-safe” claims may not map to standards; this is the check most likely to reveal that a control works in a diagram but not at the actual boundary.

Evidence worth keeping

• Maintain inventory coverage
• Unknown owners
• Data-lifetime classification
• Vendor roadmaps
• Algorithm and protocol support
• Blocked devices
• Test results
• Performance changes
• Certificate-chain size
• Migration wave
• Exception expiry
• And decommission evidence.

Attach each record to the concrete object under review: the relevant asset, release, customer, contract, key, query, or configuration. Preserve timestamps and version identifiers so another reviewer can reconstruct the sequence. The evidence list above should answer three questions: what was true before the change, what changed, and what proves the intended outcome. For this topic, the most useful cross-check is “map trust chains and interoperability”. Keep sensitive fields out of screenshots and tickets; retain structured exports or signed records when they provide stronger provenance. Set retention according to incident, audit, privacy, and contractual needs rather than keeping everything indefinitely.

Common mistakes

• Scanning certificates alone misses application-layer and signing use.
• replacing algorithms without checking message size can break protocols.
• proprietary “quantum-safe” claims may not map to standards.
• hard deadlines without vendor and device dependencies create false confidence.
• removing classical algorithms too early can reduce interoperability..

A focused operating checklist

• Name the owner of the system and the owner of the decision.
• Verify “discover certificates, key stores, libraries, protocols, hardware, signing systems, and vendor services” from the actual production or financial source.
• Exercise the failure described by “Scanning certificates alone misses application-layer and signing use”.
• Reconcile the observed result with the evidence list above.
• Put an expiry and rollback condition on every exception.
• Monitor the user, security, reliability, or cash outcome—not only activity.
• Revisit dependencies when the underlying product, contract, or standard changes.

Make this control sustainable

Assign the owner closest to the enforcement point described in “record algorithm, key size, purpose, owner, location, expiry, rotation method, dependency, and upgrade path”, plus a backup who can execute the rollback. Review the control after a material release, supplier change, incident, financing event, or policy change that affects its assumptions. An alert is useful only when it names an action: inspect, throttle, revoke, reconcile, fail over, or escalate. Use the evidence measurements above to set thresholds from observed workload or financial behavior. Treat replacing algorithms without checking message size can break protocols as a specific review trigger. Close temporary exceptions with an owner, expiry, compensating control, and proof that the normal path was restored.

Primary references and further verification

Use NIST post-quantum standards and national guidance as primary references, while tracking browser, CA, HSM, operating-system, and protocol support.

For a current post quantum cryptography inventory decision, record the publication or effective date of the primary material and the version actually deployed or executed. Recheck vendor, standards-body, regulator, or accounting guidance when the product, protocol, vulnerability, or contract changes. Discovery summaries can point to an issue, but the decision record should link to the authoritative source and the organization’s own reproducible evidence.

Conclusion

The practical outcome is a control the team can explain and test: define cryptographic categories and business data lifetime, then plan rollback and coexistence.. Keep the assumptions and exception path visible. That is more useful than a generic checklist because the next reviewer can reproduce the decision, see where it can fail, and reverse it safely.