On 27 October 2026 NIST published NIST IR 8547, Transition to Post-Quantum Cryptography Standards, as a final report. Until then it existed only as an initial public draft from November 2024, which is why a great deal of vendor material described its dates as expected rather than settled. Ours did too, and that has now been corrected.
The publication is less dramatic than the headlines and more consequential than they suggest. The general dates did not move. What changed is their status, and the fact that the document now says, in its own words, that a shorter set of deadlines sits underneath them.
The 2030 and 2035 dates held
NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035. That sentence is now a published position rather than a draft expectation. NSM-10 still sets 2035 as the overall target for completing the federal migration.
The two words carry specific meanings, and they are not interchangeable. Deprecated means the algorithm may still be used while an organisation migrates, under the constraints NIST sets for legacy use. Disallowed means NIST standards and guidelines no longer permit it. The window between the two exists to accommodate lower-risk systems and legacy constraints while the rest of the estate completes its migration.
The shorter clock underneath them
The part of the final report that deserves more attention than it has received is the relationship between the 2030-2035 window and the federal deadlines that run alongside it. The report is unambiguous about it.
- High value assets and high impact systems, defined as systems where at least one FIPS 199 security objective carries a potential impact of high, must adopt PQC key establishment by 31 December 2030.
- The same systems must adopt PQC digital signatures by 31 December 2031.
- TLS 1.3 support is required no later than 2 January 2030 under EO 14306 and OMB M-26-15.
- The priority also extends to other systems holding highly sensitive data, or protecting data expected to remain mission-sensitive in 2030.
- Systems that cannot support post-quantum cryptography should be identified and prioritised for replacement or decommissioning.
What that means in practice
Two schedules now run in parallel, and an organisation subject to both cannot plan to a single date. The 2035 window is the outer boundary for the general estate. The 2030 and 2031 dates are the boundary for the systems where compromise matters most, and they arrive five years earlier. A migration plan that sequences everything by 2035 satisfies the general schedule and misses the one that applies to high impact systems.
The practical consequence is that classification has to happen before sequencing. Inventory by algorithm is not enough. The useful cut is by impact and by data lifetime: which systems carry a FIPS 199 high impact rating, which hold data that must remain confidential past 2030, and which have no credible path to post-quantum support at all. That last group is a decommissioning decision, not a migration one, and the report says so directly.
Three details that change architecture decisions
Beyond the dates, the final report settles several technical questions that vendors have been answering loosely.
- ML-KEM is the only approved post-quantum key-establishment scheme based on public-key cryptography today. NIST recommends ML-KEM-768 as the default parameter set, because it provides a large security margin at reasonable cost. Other parameter sets remain available where that is impractical or where higher security is required.
- HQC was selected as an alternative to ML-KEM and will be approved once a FIPS specifying it is published. Until then it is a selection, not an available standard. Any product presenting HQC as currently approved is ahead of NIST.
- Composite and hybrid key establishment can be FIPS 140-validated as long as at least one input comes from an approved key-establishment scheme, even where other inputs are disallowed. SP 800-227 provides the guidance on combiners. This is what makes the hybrid TLS path that agencies are being pushed toward by 2030 validatable rather than a special case outside the standards.
A detail in the symmetric section worth noticing
Most of the transition conversation is about public-key cryptography, because that is what a quantum computer breaks. The report also notes that a small number of NIST symmetric standards sit at the 112-bit security level, and those will be disallowed in 2030. It is a narrow point, but it is a reminder that a migration scoped only to RSA, ECDSA and ECDH will leave residue behind.
What the report does not say
It offers no date for a cryptographically relevant quantum computer. The schedule is a migration target, not a forecast, and treating 2030 or 2035 as a prediction of when the machine arrives misreads it in both directions.
It does not certify any product. Conformance vectors, CMVP validations and agency authorisations are separate processes with separate evidence, and a product that cites IR 8547 as though it were an approval is borrowing authority it does not have.
It does not create a safe harbour for deprecated algorithms after 2035, and it does not allow an organisation to trade the earlier federal deadlines against the later general window. The report exists to prevent exactly that reading.
How QNSI maps to it, and where the boundary is
QNSI operates ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) as tenant-policy-governed key operations, with four enforced tiers that restrict the permitted algorithm set. Those tiers reject weaker and classical parameter sets at the operation boundary, so a downgrade is a policy violation rather than a configuration choice. Cryptographic inventory and CBOM export exist to answer the classification question the report depends on, and the audit chain exists to retain evidence that an approved change actually happened.
The boundary matters as much as the mapping. QNSI holds neither CAVP algorithm certificates nor CMVP module validation, and neither is a prerequisite for post-quantum cryptography: no product acquires either by association with a NIST publication. There are no plans to pursue validation as of now; if a client requires it, it will be considered at that stage. Production effectiveness for a specific deployment remains a qualification exercise, not a claim inherited from a standard. Adopting QNSI does not make an organisation compliant with IR 8547; it gives the migration a governed place to happen and evidence that it did.
Our own standards registry now encodes the two schedules separately: the 2030 and 2035 dates, and the earlier federal deadlines, so that one cannot be quoted in place of the other.
A sequence that satisfies both clocks
- Now: build the inventory and classify every system by FIPS 199 impact and by how long its data must stay confidential. Identify systems with no path to PQC and start replacement decisions.
- Now: move transport to TLS 1.3 with hybrid key exchange, which is the earliest dated milestone and the one that protects data in transit against collection today.
- 2027 to 2029: migrate key establishment for high impact systems, then signatures. Signatures are the later half of the federal deadline because re-signing an estate takes longer than re-keying it, not because it matters less.
- 2029: prove the evidence path works before it is needed. Approval records, cutover confirmation, reconciliation and signed audit checkpoints are easier to build while the pressure is low.
- 2030 to 2035: complete the general estate against the outer window, with deprecated algorithms used only under the constraints NIST permits.