NIST IR 8547, finalized on October 27, 2026, changes an important detail in the timetable for replacing quantum-vulnerable cryptography. In the 2024 draft, stronger classical public-key algorithms generally avoided the 2030 deprecation step and faced disallowance after 2035. The final report puts those stronger algorithms on the same two-stage schedule as weaker ones: deprecated after 2030, disallowed under NIST standards and guidelines after 2035. That is a meaningful change for organizations still buying systems that depend on RSA, elliptic-curve signatures or classical key exchange.
The finding comes from comparing Tables 2 and 4 in NIST's November 2024 draft with Tables 2 and 4 in the final report. It is not evidence that existing internet encryption has suddenly failed, nor a claim that every private company must abandon RSA on January 1, 2031. The practical change is in migration planning: stronger classical keys no longer offer a way to postpone the formal deprecation stage in NIST's roadmap.
What changed in the final NIST IR 8547
The original draft separated quantum-vulnerable digital signatures by classical security strength. For ECDSA and RSA signatures at the 112-bit security level, the draft listed deprecation after 2030 and disallowance after 2035. For those algorithms at 128 bits or higher, it listed disallowance after 2035 without the earlier deprecation step. EdDSA, listed at 128 bits or higher, also had only the 2035 disallowance date.
The final report removes that distinction. Its Table 2 applies deprecation after 2030 and disallowance after 2035 to ECDSA and RSA signatures at 112 bits or more of classical security strength, and to EdDSA at 128 bits or more. Table 4 makes the parallel change for finite-field and elliptic-curve Diffie-Hellman and MQV schemes and RSA-based key establishment. These are two families of cryptographic functions, but the same two-stage transition now applies to both.
That comparison is the article's central independently checked finding. The 2024 document was a public draft, not binding final guidance; the 2026 document is the final report. A comparison between them shows a change in NIST's stated transition plan, not evidence that a product was secure yesterday and insecure today. NIST's October 27 announcement describes the report as a roadmap for federal agencies and a planning resource for vendors and other organizations.
Deprecation after 2030 is not the same as disallowance after 2035
In NIST's transition terminology, a deprecated algorithm may still be used subject to acceptance of the associated security risk and applicable restrictions. Disallowed means it is no longer permitted for the specified use under the relevant NIST standards and guidelines. The difference matters because a team cannot simply read the year 2030 as a universal prohibition on all classical public-key cryptography.
Nor can every federal system assume that the general 2035 disallowance date is its deadline. The final report explicitly says earlier federal requirements constrain continued use for high-value assets, high-impact systems and other prioritized systems. Organizations also need to distinguish the scope of a federal directive from a contractual or regulatory requirement affecting their own operations.
A practical way to read the schedule is as three separate milestones: federal high-priority systems must adopt post-quantum key establishment by December 31, 2030; those systems must adopt post-quantum digital signatures by December 31, 2031; and NIST's broader algorithm transition moves quantum-vulnerable public-key techniques to disallowed status after 2035. The first two dates come from Executive Order 14412 and OMB Memorandum M-26-15, as described in the final report. They do not mean every consumer website faces identical statutory obligations.
Why key establishment and digital signatures have different clocks
Key establishment helps two parties agree on or transport the secret material used to protect a connection. Digital signatures help establish authenticity and integrity—for example, whether software or a certificate came from the expected signer and has not been altered. Both use public-key techniques, but they protect different things and often sit in different parts of an organization's technology stack.
The distinction explains why the federal high-priority deadline for key establishment comes one year before the corresponding signature deadline. NIST emphasizes the risk sometimes called “harvest now, decrypt later”: an adversary may capture encrypted communications now and attempt to decrypt them if sufficiently capable quantum computers emerge later. That creates urgency for information that must remain confidential for many years. A signature migration also matters, especially for software integrity and long-lived devices, but the operational dependencies and threat models are not identical.
Nothing in the report establishes a date when a cryptanalytically relevant quantum computer will exist. NIST says no such machine currently threatens today's specified security levels. The reason to begin migration is the time needed to inventory dependencies, update protocols and hardware, test interoperability and protect long-lived information—not a verified prediction that quantum decryption will become practical in 2030.
The final roadmap leaves familiar symmetric encryption in a different category
A common misunderstanding is that NIST has scheduled all encryption for retirement. It has not. The final report distinguishes quantum-vulnerable public-key algorithms from symmetric cryptography, including widely used AES block ciphers and approved hash functions. NIST says the existing symmetric standards are substantially less vulnerable to known quantum attacks and does not expect a general replacement of those standards as part of this migration.
For many systems, the work therefore concerns how keys are established, how identities and updates are signed, and which libraries and devices implement those functions. Replacing a public-key exchange mechanism does not automatically require discarding every encrypted database or changing every AES key. Conversely, an application using strong symmetric encryption may still depend on quantum-vulnerable public-key operations when it opens a secure session or validates a signature.
Unhyd's earlier guide to quantum-safe encryption deployment explains the basic technology and adoption challenge. The newly finalized NIST report adds the narrower but consequential issue of exactly when the agency plans to deprecate classical public-key algorithms at different strengths.
Why the real bottleneck may be the supplier, not the algorithm
NIST's report describes a chain of dependencies: network protocols such as TLS, SSH and IPsec; cryptographic software libraries; hardware security modules and trusted platform modules; certificate authorities and public-key infrastructure; and the applications built on top. A team might update its own application while discovering that a device, certificate service or external partner cannot yet use the new scheme. That makes migration a procurement and interoperability problem as much as a cryptographic one.
It also changes how organizations should question vendors. “Supports post-quantum cryptography” is too vague to prove readiness. Buyers need to know which standardized algorithms and parameter sets are implemented, which protocols negotiate them, whether support is enabled in production, what certificate and signature paths remain classical, what validation applies, and how failures or fallback are handled. NIST recommends ML-KEM-768 as a default parameter set for post-quantum key establishment, but that recommendation does not certify a particular vendor's deployment.
For a small organization, the first useful action may be a documented inventory of its certificate services, VPNs, externally exposed systems, code-signing tools, cloud providers and long-lived devices. A spreadsheet of where cryptography is used can expose a dependency that would otherwise appear only when a replacement product fails to interoperate. The report's guidance is not a claim that every small business must engineer new cryptographic algorithms itself.
Hybrid migration is an option, not an automatic safety guarantee
NIST discusses hybrid key-establishment techniques that combine a conventional component with a post-quantum one. Properly designed, the resulting protection can remain sound if at least one component remains secure, but the report cautions that implementation complexity, performance costs and independent security review matter. Simply advertising two algorithms does not establish that a particular combination is correct.
The agency also distinguishes true hybrid key establishment from a transitional environment where some sessions use classical algorithms and others use post-quantum algorithms. Running both types of session across an organization is not the same as combining both components within one session. That distinction is important when reading product marketing or a vendor's compatibility statement.
For organizations that operate their own websites, it is worth separating a browser's visible padlock from the cryptographic properties negotiated in an individual connection. A padlock is not a public audit of an entire service's post-quantum readiness. Similarly, a software update can add an algorithm without proving that all devices, users and counterparties have successfully migrated.
What an honest readiness assessment would report
Rather than declaring itself “quantum-safe,” an organization can report a more auditable set of facts: the share of inventoried public-key uses with identified owners; which systems handle information requiring long confidentiality; which suppliers have a tested migration path; which key-establishment and signature functions have been replaced; and which legacy dependencies remain. These are proposed reporting categories, not measured industry adoption statistics.
A meaningful readiness claim should also identify the denominator. Saying “80% migrated” without specifying whether that means certificates, connections, applications, devices or suppliers can mislead. The final NIST report supplies a transition framework, not a national census of completed deployments. No percentage of U.S. organizations meeting the 2030 or 2035 milestones can be calculated from its tables alone.
For consumers, the sensible response is to keep devices and browsers updated and rely on trustworthy service providers rather than purchase an unverified “quantum-proof” product. Unhyd's quantum computing explainer distinguishes today's machines from the future fault-tolerant systems relevant to cryptographic risk. There is no evidence in the NIST report that an ordinary person's encrypted accounts have already become readable to a quantum attacker.
The significance of the 2026 revision
The final NIST IR 8547 does more than repeat that quantum-resistant standards exist. Its revised tables remove a planning distinction that could have let stronger classical public-key implementations appear to avoid the 2030 deprecation stage. At the same time, the report preserves the difference between deprecation and disallowance and acknowledges that federal high-priority systems have earlier, more specific deadlines.
The defensible conclusion is operational: organizations should stop treating longer classical keys as a substitute for a post-quantum migration plan, and they should ask suppliers for testable evidence rather than a broad promise. Whether any particular organization can meet the schedule remains unknown without its system inventory, dependencies, procurement timeline and actual migration results.
