Post-quantum migration starts with a dependency inventory
NIST’s August 2024 standards gave migration concrete targets. Map data lifetimes and supplier dependencies before replacing algorithms across business systems.
By 
Paul. Architecture and infrastructure
A business cannot plan a cryptographic migration from a list of algorithms alone. It needs to know where those algorithms protect data, who controls their implementation and how long the protection must last. The first finalized NIST post-quantum standards made that inventory more actionable. They justified beginning the transition, with priorities based on exposure and dependencies rather than a universal countdown.
This November 2026 retrospective concerns the NIST announcement of 13 August 2024. NIST encouraged administrators to begin transitioning as soon as possible. That recommendation deserves action, but the announcement did not give every private company the same mandatory migration date. A deadline applicable to a particular organization needs its own authority and scope.
Three standards, different jobs
FIPS 203, published on 13 August 2024, specifies ML-KEM, a key-encapsulation mechanism. Its job is to help establish a shared secret over a public channel. That secret can then be used with symmetric cryptography. Describing ML-KEM as an algorithm that directly replaces all stored-data encryption would confuse two different roles.
FIPS 204 specifies ML-DSA for digital signatures. FIPS 205 specifies SLH-DSA, a stateless hash-based signature algorithm. Both standards also state 13 August 2024 as their publication date. Signing software updates and establishing secrets for a connection belong to different parts of a system, even when both require migration planning.
That distinction has a business consequence. A supplier's statement that it supports one post-quantum algorithm cannot establish that every relevant function is covered. Ask which protocol, product version and use case the statement describes. A supported library primitive, a negotiated network connection and a certificate accepted by counterparties are separate pieces of evidence.
Follow the protected information
An initial inventory should connect each use of cryptography to a business task. Record the system, the kind of protection, its technical owner and the supplier that controls upgrades. Include the expected lifetime of confidential information or signed artifacts. A list of package names without those relationships will be difficult to prioritize.
Consider an illustrative comparison. A business holds documents whose confidentiality must survive for many years, while another service exposes public information and retains little sensitive material. The same technology headline should not automatically produce the same order of work. The consequences of later disclosure differ, as do the dependencies that have to change first.
NIST’s current explainer, consulted in November 2026, describes the long-lived-data concern: an adversary may retain encrypted traffic and attempt decryption later. NIST's August announcement discusses the threat to existing public-key cryptography from a sufficiently capable quantum computer. That supports planning for the risk; it does not establish that such a machine was available in August 2024 or assign a reliable arrival date.
Avoid turning uncertainty into either panic or permission to wait indefinitely. If migration requires replacement hardware, supplier coordination or changes across several systems, preparation itself can take time. Discovering those constraints is useful work even before the final production configuration has been chosen.
Ask suppliers a question they can answer
A useful supplier request names the function: how will this service establish keys, verify signed updates or handle certificates during transition? Ask which supported versions implement the relevant change and what must happen on your side. Request a documented compatibility path rather than accepting a general statement about future readiness.
Distinguish a roadmap from a released capability. A roadmap can inform scheduling, but it cannot demonstrate that your counterparties will accept a new handshake or signature today. If a dependency is outside your control, record that dependency and the next date or event at which you will revisit it.
For an implementation assessment, proposed checks might cover client compatibility, message sizes and failure behavior when negotiation does not succeed. Those are questions to investigate in the actual environment. This article supplies no performance measurements and does not recommend writing custom cryptographic primitives to avoid waiting for maintained implementations.
Replacing an algorithm can also leave the old path active for compatibility. Document what is still accepted and why. Otherwise the project may report a new capability while the business assumes a stronger, broader protection than the configuration actually provides.
Waiting has a serious argument
The strongest objection to immediate replacement is operational: protocols, libraries, devices and counterparties may not all be ready together. A rushed change can interrupt a service that customers rely on. For a small team, a speculative rewrite can also consume the time needed for current security maintenance.
That objection supports staging the work. It does not explain why the business should remain unable to identify its cryptographic dependencies. Keep routine security work moving, identify long-lived exposure first and use supported upgrades where they address the required function. Escalate an unsupported or unowned dependency before it becomes the last obstacle in a larger migration.
The standards pages retrieved in November 2026 include later planning material, including notices on FIPS 203 and 204. Those notices are later context, not part of the August launch. Any implementation selected now should check the applicable revisions and corrections instead of treating the original announcement as a permanent implementation guide.
The practical outcome is a transition record with named owners and evidence: which protection matters, which supplier must change it, what remains incompatible and what action comes next. That turns the August standards into scheduled engineering work without inventing a quantum-computer deadline or promising that one library upgrade completes the migration.