Post-Quantum Migration Starts With a Cryptographic Inventory

Post-quantum cryptography is often introduced with a dramatic future event: a sufficiently capable quantum computer arrives and today's public-key systems fail. That framing can make migration sound both urgent and strangely abstract.

The practical problem is already here. Organizations depend on cryptography they cannot fully locate, supplied by products they do not control, connected through certificates and protocols with long replacement cycles. NIST has finalized its first post-quantum standards and says migration should begin now. The sensible first step is not replacing every algorithm. It is discovering what would have to change.

What quantum computers threaten

A cryptanalytically relevant quantum computer could use Shor's algorithm to undermine the mathematical problems behind widely deployed RSA and elliptic-curve cryptography. Those algorithms protect key establishment and digital signatures across TLS, VPNs, PKI, software signing, identity systems, secure messaging, and device firmware.

The risk is not limited to the day such a computer exists. An adversary can collect encrypted traffic now and retain it for later decryption. That “harvest now, decrypt later” model matters when data must remain confidential for years.

What they do not threaten in the same way

Quantum computing does not make every cryptographic primitive useless. Symmetric encryption and hash functions are affected differently, and larger key or output sizes can preserve useful security margins. The migration focus is therefore not “remove all existing cryptography.” It is to identify quantum-vulnerable public-key use, understand the required protection lifetime, and choose supported replacements.

This distinction prevents a quantum-readiness program from becoming a vague security rebranding exercise.

The finalized NIST algorithms

NIST's first finalized post-quantum standards include ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. They are designed to resist attacks from both classical and quantum computers and can run on conventional systems.

Standardization is a major milestone, not an instant ecosystem migration. Protocols, libraries, hardware, certificate formats, management platforms, interoperability profiles, and vendor products must all implement and test the algorithms. Some deployments will use hybrid approaches during transition so that classical and post-quantum mechanisms both contribute to the result.

Why cryptographic inventory comes first

NIST's migration project treats cryptographic visibility and risk management as a core workstream. The reason is simple: an organization cannot prioritize cryptography it has not identified.

A useful inventory describes more than algorithm names. It records:

• the system, application, service, or device;
• protocol and cryptographic function;
• certificate and key type, without storing private key material;
• library, provider, firmware, or managed service responsible;
• data protected and required confidentiality period;
• owner and business dependency;
• external integrations;
• current upgrade path and vendor support; and
• evidence source and last verification date.

The inventory will never be perfectly complete. It becomes valuable when it is maintained, connected to ownership, and good enough to drive decisions.

Where public-key cryptography hides

The obvious certificates on public web servers are only one layer. Quantum-vulnerable dependencies may appear in:

• internal TLS and service meshes;
• SSH access and automation;
• site-to-site and remote-access VPNs;
• S/MIME and encrypted email;
• code, package, and container signing;
• document signatures;
• device identity and 802.1X;
• firmware verification and secure boot;
• API client credentials;
• backup encryption key wrapping;
• cloud key-management integrations; and
• long-lived industrial or embedded equipment.

Dependencies can also be indirect. A SaaS product may terminate TLS, issue certificates, sign exports, or embed a third-party identity provider. The customer does not control its crypto implementation, but still depends on its migration timetable.

Prioritize by exposure and lifetime

Not every discovered item has equal urgency. A useful priority model considers:

1. Confidentiality lifetime: Must the protected data remain secret for ten or twenty years?
2. Exposure: Can an adversary collect the encrypted material today?
3. Criticality: Would signature forgery or failed authentication affect a high-value process?
4. Replacement time: Is the component a browser update or a device expected to remain installed for fifteen years?
5. Control: Can the organization change it, or is a vendor roadmap required?

Long-lived sensitive data and slow-moving infrastructure rise to the top even if a cryptographically relevant quantum computer is not imminent.

Crypto-agility is the durable goal

Post-quantum migration will not be the last cryptographic change. Algorithms can be weakened, implementations can fail, standards can evolve, and compliance requirements can change. Crypto-agility is the ability to locate, replace, configure, and verify cryptography without redesigning the entire system.

That means avoiding hard-coded algorithm assumptions, separating cryptographic policy from application logic, maintaining upgradeable libraries, testing certificate and handshake size effects, and knowing which dependencies cannot change quickly.

Agility is not a product checkbox. It is an architectural and operational capability supported by inventory.

A realistic migration sequence

Discover. Combine configuration data, certificate scanning, software inventories, architecture records, code analysis, procurement information, and vendor questionnaires.

Classify. Identify the cryptographic purpose, protected data, system owner, exposure, and required lifetime.

Prioritize. Focus first on long-lived confidentiality, critical signatures, exposed traffic, and assets with slow replacement cycles.

Plan. Map each dependency to a standards-based product or protocol roadmap. Record where no supported path exists.

Test. Validate performance, message sizes, certificate chains, hardware constraints, interoperability, rollback, monitoring, and failure behavior.

Migrate. Roll out in controlled stages, using hybrid mechanisms where the relevant standard and implementation call for them.

Monitor. Keep the inventory current and detect systems that reintroduce deprecated algorithms.

Start with visibility, not panic

The case for beginning now does not depend on predicting the exact year a powerful quantum computer will arrive. Large environments take years to discover and change, while some of the information they protect must remain confidential well beyond that.

The strongest first deliverable is therefore modest and operational: a cryptographic inventory with ownership, evidence, and priorities. It turns a distant-sounding threat into a migration program that can be measured, tested, and improved.