The encryption your organization relies on has a known expiry date.
Governments have dated the migration. Aethyr's platform already runs on the replacement standards.
Public-key cryptography has a known break.
RSA and elliptic-curve cryptography protect almost every key exchange and digital signature in use today. Shor's algorithm, run on a large error-corrected quantum computer, breaks both. Larger keys do not help. The fix is a different kind of mathematics.
No such machine exists yet. The estimate of what it takes to build one keeps falling, and it fell twentyfold for RSA-2048 between 2019 and 2025 on the same hardware assumptions.
- RSA-2048 · Gidney & Ekerå, 2019
- ~20 million physical qubits
- RSA-2048 · Gidney, 2025
- under 1 million physical qubits
- 256-bit elliptic curves · Google, 2026
- under 500,000 physical qubits
- Best machines today
- 48–96 logical qubits
Estimates for machines nobody has built yet. Sources and caveats
Data recorded today can be decrypted later.
An adversary does not need a quantum computer to start. Encrypted traffic recorded today can be stored and decrypted once one exists. Security agencies call this “harvest now, decrypt later.”
Whether your data is exposed is arithmetic. Add how long it must stay secret to how long your migration will take. If the total runs past the arrival of a cryptographically relevant quantum computer, the data is already at risk.
The Global Risk Institute's 2025 survey of 26 experts puts that arrival at 28 to 49 percent likely within ten years, and 51 to 70 percent within fifteen.
Encrypted traffic is recorded and stored.
Whatever was recorded under classical key exchange becomes readable.
Aethyr already runs on the replacement standards.
Every key exchange in an Aethyr deployment uses ML-KEM (FIPS 203), and every identity signs with ML-DSA (FIPS 204). NIST finalized both standards in August 2024. The platform has no classical-only mode to fall back to.
The detail for security teams follows: the deadlines, the algorithms at each assurance level, and the test evidence.
The deadlines are dated.
Each date comes from the primary document. Several bind only government systems or their suppliers, and some are drafts, proposals or recommendations. The status column says which.
- CNSA 2.0 · CNSSP 15New National Security Systems acquisitionsCNSA 2.0 algorithms requiredJan 1, 2027Binding
- CNSA 2.0 · CNSSP 15Fielded NSS equipmentEquipment that cannot support CNSA 2.0 phased outDec 31, 2030Binding
- CNSA 2.0 · CNSSP 15All NSSCNSA 2.0 mandated for full quantum resistanceDec 31, 2031Binding
- OMB M-26-15Federal civilian agenciesPost-quantum migration plan to OMB and the National Cyber DirectorOct 22, 2026Binding
- EO 14412 §4(b)High-value assets and high-impact systemsPost-quantum key establishmentDec 31, 2030Binding via OMB guidance
- EO 14412 §4(b)High-value assets and high-impact systemsPost-quantum digital signaturesDec 31, 2031Binding via OMB guidance
- OMB M-26-15Remaining federal civilian systemsFull migration, based on risk and commercial availability2035Guidance
- EO 14412 §6(c)Covered federal contractorsNIST FIPS compliance, post-quantum standards includedDec 31, 2030Proposed rule due Dec 2026
- NIST IR 8547Systems that follow NIST standards112-bit RSA and ECC deprecated, then every quantum-vulnerable public-key algorithm disallowedAfter 2030 · after 2035Draft
- EU Coordinated RoadmapEU member statesTransition started · high-risk uses migrated · as many systems as feasibleEnd 2026 · end 2030 · 2035Recommended
- NSM-10Federal systemsMitigate as much quantum risk as feasible2035Goal
Sources: NSA CNSA 2.0 FAQ, Ver. 2.2 (October 2026) and CNSSP 15; Executive Order 14412; OMB M-26-15; NIST IR 8547 (draft); EU Coordinated Implementation Roadmap; NSM-10 (May 2022). National Security Systems follow CNSA 2.0, not the OMB schedule.
Two assurance levels. No classical-only mode at either.
Level 3 is the default. Level 5 uses the CNSA 2.0 parameter sets for high-assurance deployments.
- Key establishmentLevel 3: ML-KEM-768, offered with the X-Wing hybrid (ML-KEM-768 + X25519)Level 5: ML-KEM-1024, first in negotiation priority
- Signatures and identityLevel 3: ML-DSA-65Level 5: ML-DSA-87
- Hash-based signaturesFor algorithm diversity. SLH-DSA is not part of CNSA 2.0.Level 3: SLH-DSA-SHA2-192s, selectableLevel 5: SLH-DSA-SHA2-192s, selectable
On hybrids. The Level 3 hybrid keeps a classical X25519 leg, so a future break of the lattice mathematics alone does not expose the session. NSA does not require hybrids for National Security Systems and warns that they add complexity, so at Level 5 the standalone ML-KEM-1024 exchange comes first.
On CNSA 2.0 status. Level 5 is aligned with CNSA 2.0. Compliance also requires validated cryptographic modules, and Aethyr does not hold a CMVP certificate yet.
Break once, forge everywhere.
A signature chain is only as strong as its weakest link. In September 2026, Cloudflare's 1.1.1.1 resolver began validating post-quantum DNSSEC signatures, a real milestone. It is the validating end only: the DNS root, every registry, and every publicly trusted certificate are still signed with classical algorithms, and Cloudflare's own target for a fully post-quantum chain is 2029. Until then, one recovered classical key high in the chain forges every record below it.
A Console deployment does not wait on that chain. Every identity in it, agent, node, and device, derives from a post-quantum commissioner key, and the wire protocol has no classical-only mode. The public internet will get there. Inside your boundary, it is already the design.
Read Cloudflare's announcementTested against NIST's published vectors.
Aethyr's implementation is tested across nine parameter sets of ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), against NIST's official algorithm vectors.
Production uses a narrower set: ML-KEM-768 and ML-KEM-1024, ML-DSA-65 and ML-DSA-87, and SLH-DSA-SHA2-192s. Algorithm testing is not module validation. CAVP and CMVP certification are separate, later steps that Aethyr has not completed yet.
Plan the migration against the dates that apply to you.
We brief security teams and program offices on where their systems stand against CNSA 2.0, EO 14412 and the lifetime of their own data.