2030 and 2035: the NIST PQC timeline.
NIST has set draft dates for retiring RSA and elliptic-curve cryptography and published the standards that replace it. Here is what the documents say, and how to start a migration from what your code actually uses.
NIST's draft transition plan, NIST IR 8547 (initial public draft, November 2024), deprecates quantum-vulnerable public-key algorithms at the 112-bit security level after 2030 and disallows all of them after 2035. The replacements are already final: ML-KEM in FIPS 203 for key establishment and ML-DSA in FIPS 204 for signatures, both published on August 13, 2024. Because the dates are still in draft, start with an inventory you can re-run as the guidance changes.
From new standards to the cutoff
The standards and drafts that set the dates, and where a migration should be today.
-
August 2024
FIPS 203 and FIPS 204 final
ML-KEM and ML-DSA become NIST standards.
-
October 2024
SP 800-131A Rev. 3 draft
Proposes retiring SHA-1, 224-bit hashes and ECB for encryption.
-
November 2024
NIST IR 8547 draft
Sets the transition dates for quantum-vulnerable algorithms.
-
Today
Inventory and prioritize
Find every quantum-vulnerable use, starting with key establishment.
-
After 2030
Deprecated
Quantum-vulnerable algorithms at 112 bits of security. SHA-224 and HMAC-SHA-1 under the SP 800-131A draft.
-
After 2035
Disallowed
All quantum-vulnerable public-key algorithms, at any security strength.
Four documents set the dates
Two are final standards. Two are initial public drafts, which is why the dates may still move.
Module-Lattice-Based Key-Encapsulation Mechanism Standard
Published August 13, 2024. Defines ML-KEM, the replacement for RSA encryption and Diffie-Hellman style key agreement.
Module-Lattice-Based Digital Signature Standard
Published August 13, 2024. Defines ML-DSA, the replacement for RSA, DSA, ECDSA and EdDSA signatures.
Transition to Post-Quantum Cryptography Standards
Released November 12, 2024. Lists the quantum-vulnerable standards and schedules them: deprecated after 2030 at 112 bits of security, disallowed after 2035.
Transitioning the Use of Cryptographic Algorithms and Key Lengths
Released October 21, 2024. The classical side: a retirement schedule for SHA-1 and 224-bit hashes, ECB retired as a mode for encryption, and a move from 112-bit to 128-bit security.
Deprecated and disallowed mean different things
NIST IR 8547 uses precise terms. A deprecated algorithm may still be used, but there is some security risk, and the data owner must decide whether to accept it. A disallowed algorithm is no longer allowed for the stated purpose.
So 2030 is the year quantum-vulnerable algorithms at 112 bits of security become a documented risk you have to own, and 2035 is the year none of them are allowed. The draft also notes that systems with long-term confidentiality needs may have to move earlier.
2035 is the deadline, not the start date
Traffic encrypted under RSA or Diffie-Hellman style key exchange can be recorded today and decrypted once a large quantum computer exists. Every month a system runs before it moves to ML-KEM adds to what an attacker can harvest.
Migrations are also slow because cryptography is chosen in many places at once: library calls, framework settings, token configuration, committed keys and certificates, server TLS settings and dependencies. You cannot schedule the replacement of a choice you have not found, and the inventory does not depend on which way the drafts settle.
Built for guidance that will move
Each NightVision finding carries the years after which NIST deprecates and disallows its choice, where NIST has scheduled them, and each report records the catalogVersion of the classification that assessed it.
The catalog version is raised whenever the weakness, severity, reference or dates for the same choice change, and not for a reworded explanation. Compare two reports and you can tell a finding the guidance reclassified from one the code changed.
How to start a migration
Each step uses something the NightVision report already gives you.
- 1
Run the inventory on every repository
Add
--weak-cryptotonightvision openapi extract, on a laptop or in CI. Add--credentialsto link committed keys to their credential findings. - 2
Confirm the report is complete
Read
completeand its gaps before you call a repository clean. A run that stopped early says so. - 3
Fix what is broken today
High findings, such as MD5 on a password or verification turned off, do not wait for 2030.
- 4
Prioritize key establishment and encryption
Quantum-vulnerable encryption and key exchange are rated medium because recorded traffic is exposed now. Plan ML-KEM there first.
- 5
Plan signatures and tokens next
RS256 and ES256 tokens, signing keys and certificates are rated low. Plan ML-DSA with the owner of each.
- 6
Assign by location
Each finding names its file, line and function, so it goes straight to the team that owns that code.
- 7
Track by fingerprint across runs
A finding's fingerprint stays the same when code elsewhere in the file moves, so comparing runs shows what was fixed, what is new and what remains. It fits SARIF's partial fingerprints.
- 8
Re-check when the catalog changes
A new
catalogVersionmeans the guidance moved. Review the findings it reclassified.
The report is written beside the API spec that source intelligence generates. Viewing and tracking these findings in the NightVision platform is in development.
Where the inventory looks
Code and framework settings are read in Python today, from hashlib and pyca/cryptography to PyJWT, Django and Flask settings. Committed private and public keys, certificates, SSH keys, nginx, Apache and OpenSSL TLS settings and cryptography dependencies are read in any language. For what Shor's algorithm breaks and what replaces it, see what quantum breaks; for committed files, see keys, certificates and TLS.
Questions about the NIST PQC timeline.
When do quantum-vulnerable algorithms have to be replaced?
Under NIST IR 8547, an initial public draft, quantum-vulnerable algorithms at the 112-bit security level are deprecated after 2030, and all quantum-vulnerable algorithms are disallowed after 2035.
Are the NIST post-quantum standards final?
Yes. FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) were published as final standards on August 13, 2024. The transition guidance that sets the 2030 and 2035 dates, NIST IR 8547, is still an initial public draft.
What is the difference between deprecated and disallowed?
In NIST IR 8547, a deprecated algorithm may still be used, but there is some security risk that the data owner must examine and accept. A disallowed algorithm is no longer allowed for the stated purpose.
What happens to NightVision findings if the draft dates change?
Each report records the catalogVersion of the classification that assessed it. The version is raised whenever the weakness, severity, reference or dates for the same choice change, so you can tell a finding the guidance reclassified from one the code changed.
Where should a migration start?
With an inventory of where your applications use public-key cryptography. Then fix what is broken today, move key establishment and encryption first, since traffic recorded today can be decrypted later, and plan signatures and tokens next.
Where does this run today?
It runs in the NightVision CLI today: add the --weak-crypto flag to nightvision openapi extract and the report is written beside the API spec that source intelligence generates. The --no-upload flag sends nothing to NightVision. Viewing and tracking these findings in the NightVision platform is in development.
Start the inventory before the deadlines.
See every quantum-vulnerable and weak cryptographic choice in your code and committed files, with NIST's years beside each. Start from the quantum readiness overview.