The transition to post-quantum cryptography is often described as a future algorithm swap. The operational work starts earlier: an organization has to find where public-key cryptography is used, what it protects, who owns it, and which dependencies can change. Without that inventory, a migration plan becomes a list of products and a guess about risk.
NIST published FIPS 203, FIPS 204, and FIPS 205 in August 2024. They define ML-KEM for key encapsulation and ML-DSA and SLH-DSA for digital signatures. NIST has also published transition guidance that sets deprecation and disallowance timelines for quantum-vulnerable schemes. The dates matter for planning, but the inventory and migration process determine whether a team can meet them.
Inventory cryptography, not just servers
A conventional asset inventory may show a server, database, or application but not the libraries and protocols that carry authentication and key establishment. A cryptographic inventory should capture:
the algorithm and key size used at each point;
the protocol and library that implement it;
what data, identity, or software artifact the key protects;
how long the protection needs to last;
who can update the component;
whether a hardware module, firmware image, or vendor product constrains replacement.
Include code-signing keys, TLS certificates, VPN and identity-provider trust, database connections, backup encryption, package repositories, hardware roots of trust, and machine-to-machine APIs. Also include data at rest and data in transit that may be recorded now and decrypted later, even if the organization does not consider the data sensitive today.
Cryptographic discovery tools can identify some algorithms and libraries, but they may miss embedded cryptography inside a product, a compiled binary, or a protocol that negotiates an algorithm at runtime. Use the tools to create leads, then confirm the result with configuration, source, vendor documentation, or a controlled test.
Separate harvest risk from signature risk
Public-key key establishment is exposed to a future quantum computer because an adversary can record ciphertext today and recover the session key later if the underlying key exchange becomes weak. Digital signatures have a different failure mode: a future attacker may forge a signature or rewrite a trust decision, and historical signatures may need to remain verifiable for a long time.
That distinction affects priority. A long-lived data store protected by a key-exchange protocol may need a migration path before the data's confidentiality period ends. A firmware-signing pipeline may need a longer planning horizon because embedded devices and verification roots are difficult to replace. The organization should record the protection lifetime rather than using a single urgency label for every RSA or elliptic-curve use.
The transition also creates a hybrid period. Some systems will use a classical algorithm and a post-quantum algorithm together, while others will add support for new certificates and protocol versions. Record which mode is active, whether the fallback is intentional, and how a downgrade is detected.
Make agility a testable property
Crypto agility is not a promise that a product can add an algorithm in a future release. It is the ability to change the algorithm, key size, certificate profile, and trust anchor without redesigning the application or losing the ability to verify existing data.
Test the full change path in a lab. Issue a certificate with a new signature algorithm, update the trust store, rotate the corresponding private key, and verify both old and new clients. For key encapsulation, test protocol negotiation and failure behavior when one endpoint does not support the new algorithm. For code signing, test the build, distribution, and verification chain, including offline installers and recovery images.
Monitor the algorithms actually negotiated. A configuration may advertise post-quantum support while most connections still fall back to a classical suite. Inventory the observed state, not just the intended state.
Assign owners and long-lived dependencies
The inventory should connect each cryptographic use to a business owner and a technical owner. The business owner can explain the data lifetime and the consequences of a failed migration. The technical owner can identify the upgrade path and the validation method.
Prioritize dependencies that are hard to change: hardware security modules, embedded devices, operational technology, code-signing infrastructure, and vendor appliances. Ask vendors for their algorithm roadmap, the standards they plan to support, and the evidence they will provide for interoperability. A vendor statement that a product is “quantum ready” is not a substitute for a tested configuration.
Keep a risk register for uses that cannot migrate on the desired schedule. Record the compensating controls, the exposure window, and the decision owner. Review the register when a standard, vendor release, or threat assessment changes.
Validate the migration, not only the algorithm
After a change, verify that the system still authenticates the intended party, rejects the old or revoked credentials, and preserves the required audit evidence. Check certificate path building, clock and validity handling, key rotation, backup restore, and disaster recovery. A migration that works in normal operation but breaks recovery can create a new outage.
Retain enough information to verify historical signatures and decrypt archived data according to policy. Do not destroy the old keys or trust records before the retention requirement has been reviewed. At the same time, remove deprecated algorithms from paths where they are no longer needed rather than leaving them as silent fallback options.
Post-quantum migration is a multi-year engineering program with a clear inventory, owners, dependencies, and tests. The organizations that move fastest will be the ones that can find cryptography in their estate and prove that a change works across the whole chain.