For thirty years, RSA and elliptic curve cryptography have protected everything from your banking sessions to national security communications. That era is ending. NIST finalized the first post-quantum cryptography (PQC) standards in 2024, the White House issued M-26-15 in June 2026 mandating federal agencies to complete migration by 2035, and the cryptography world is now in the middle of the largest infrastructure transition in the history of computing. Every TLS connection, every SSH key, every code-signing certificate, every VPN tunnel, and every hardware security module on the planet needs to be replaced or augmented with quantum-resistant algorithms. This is not a drill, and the threat is not theoretical.
Here is what has changed in 2026, why the deadline is tighter than it looks, and what your organization should be doing right now.
The Threat Is Already Here: Harvest Now, Decrypt Later
The most dangerous misconception about quantum computing is that it does not matter until a quantum computer actually exists. That is wrong. Adversaries — primarily nation-state intelligence agencies — are already executing harvest-now-decrypt-later (HNDL) attacks. They are intercepting and storing encrypted TLS traffic today, knowing that within five to ten years a cryptographically relevant quantum computer (CRQC) will be able to break RSA-2048 and ECC-256 in hours. Every piece of encrypted data with a long shelf life — classified government communications, intellectual property, trade secrets, health records, diplomatic cables — is already being collected with the intent to decrypt it retroactively.
The math is unforgiving. Data that needs to remain confidential for 10 years (medical records, state secrets, long-term financial data) must be encrypted with quantum-resistant algorithms today, because the encrypted traffic captured today will be broken when the quantum computer arrives. If your data has a confidentiality lifespan longer than the estimated time to a CRQC, you are already exposed. For defense, healthcare, and financial sectors, that means the window has already closed for anything transmitted in the last five years.
This is why the White House M-26-15 memorandum, published in June 2026, is so aggressive. It does not ask agencies to prepare. It mandates a full inventory of cryptographic systems by fiscal year 2027, pilot migrations of high-priority systems by 2028, and completion of all migration efforts by 2035. The Office of Management and Budget is tracking compliance quarterly. CISA is providing technical guidance through its Post-Quantum Cryptography Initiative. And the 2035 deadline is the outer boundary — agencies handling classified data face significantly shorter timelines.
The NIST Standards: What Actually Ships
NIST's PQC standardization process ran for eight years, evaluated over 80 candidate algorithms, and produced three finalized standards published as Federal Information Processing Standards (FIPS). These are the algorithms your infrastructure needs to support:
FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation)
Formerly known as CRYSTALS-Kyber, ML-KEM is the standard for key establishment — the quantum-resistant replacement for RSA key exchange and ECDH in TLS. It produces shared symmetric keys that two parties can use to encrypt communications, and it is the algorithm that will be patched into virtually every TLS implementation on earth. ML-KEM is fast (comparable to ECDH in latency), has small keys (1,536 bytes for the public key at security level 3), and is the primary algorithm browsers, servers, and VPN clients will adopt. Major libraries including OpenSSL 3.4+, BoringSSL, and AWS LC already ship ML-KEM implementations. Cloudflare has been running ML-KEM in production TLS for over a year.
FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature)
Formerly CRYSTALS-Dilithium, ML-DSA is the primary quantum-resistant digital signature algorithm — the replacement for RSA-PSS and ECDSA. It handles code signing, certificate signing, document signing, and authentication. ML-DSA signatures are larger than traditional signatures (2,592 bytes at security level 2, compared to 64 bytes for ECDSA), which creates storage and bandwidth considerations for systems that process many signatures (certificate chains, software update channels, blockchain transactions). But the verification speed is competitive, and the security foundation — the Module Learning With Errors (M-LWE) problem over lattice structures — is considered the most well-studied and trusted quantum-resistant mathematical foundation.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature)
Formerly SPHINCS+, SLH-DSA is the conservative fallback. Unlike ML-KEM and ML-DSA, which rely on lattice assumptions that could theoretically be broken by new mathematical discoveries, SLH-DSA relies only on the security of hash functions. It is slower and has much larger signatures (up to 50KB at security level 3), but it provides a hedge: even if lattices turn out to be weaker than expected, SLH-DSA remains secure as long as your hash function is secure. NIST recommends SLH-DSA for long-lived signatures where performance is not critical — firmware signing, root certificate signing, archival signatures. The strategy most security teams are adopting is ML-DSA for everything fast and SLH-DSA for the few things that absolutely cannot fail over a 30-year horizon.
The Migration Problem Nobody Talks About: Hybrid Is Mandatory
You cannot flip a switch from RSA to ML-KEM. The transition takes years, during which your systems will need to speak both classical and quantum-resistant cryptography simultaneously. This is called hybrid mode — establishing a TLS connection using both a classical key exchange (X25519) and a quantum-resistant key exchange (ML-KEM-768), then combining the shared secrets so that the connection is secure even if either algorithm is broken. If the quantum computer arrives sooner than expected, the ML-KEM layer protects you. If a flaw is discovered in ML-KEM, the X25519 layer still protects you. This is the belt-and-suspenders approach that NIST, CISA, and the IETF all recommend during the transition period.
The IETF has standardized hybrid key exchange in TLS 1.3 as x25519+mlkem768, and it is already shipping in Chrome, Firefox, and Cloudflare's edge. Google enabled hybrid post-quantum TLS for all Google services in 2024. Apple added ML-KEM to iMessage in 2025. The infrastructure is arriving faster than most organizations can consume it, which is why the biggest gap is not algorithm availability — it is organizational readiness.
The real challenge is inventory. Most organizations do not know where their cryptography lives. It is in embedded systems, IoT devices, HSMs, certificate authorities, code-signing pipelines, VPN concentrators, SSH bastions, payment terminals, and dozens of applications that hardcode algorithm choices. The first step of any PQC migration is a cryptographic inventory — finding every instance of RSA, ECC, DH, and SHA-1 in your infrastructure, classifying its risk, and prioritizing what to migrate first. Tools like IBM Crypto Discovery, Cryptographic Risk Intelligence from SandboxAQ, and the open-source Cryptography Analysis Toolkit from CISA help automate this. But the inventory itself is a six-to-twelve-month project for a mid-size enterprise.
Secure Your Network with NordVPN →
Practical Migration Steps for 2026
If you have not started your PQC migration, here is what to do this year. The teams that wait until 2030 will be the ones paying premium rates to consultants while their compliance deadlines loom.
1. Build Your Cryptographic Inventory
Map every cryptographic asset in your organization: TLS certificates (and their issuing CAs), SSH keys, code-signing certificates, VPN configurations, HSM contents, embedded firmware with hardcoded keys, and any application that calls crypto libraries directly. Tag each asset with its data sensitivity and shelf life. Data with a 20-year confidentiality requirement (health records, classified data, long-term financial records) is your highest priority because it is already vulnerable to HNDL attacks.
2. Prioritize by Exposure Window
Not everything needs to move on day one. The assets that handle long-lived sensitive data — the ones targeted by harvest-now-decrypt-later — go first. These are typically your VPN infrastructure, TLS-protected external-facing services, and any system handling data with a confidentiality lifespan exceeding five years. Internal services with short-lived, low-sensitivity data can wait. Build a risk matrix: data sensitivity x algorithm vulnerability x system criticality. Start at the top.
3. Enable Hybrid TLS Where Available
This is the lowest-hanging fruit. If you use Cloudflare, AWS, or any major CDN for your public-facing services, hybrid post-quantum TLS may already be available as a toggle. Cloudflare has had it since 2024. AWS announced hybrid PQ TLS for Application Load Balancers in early 2026. Enabling it costs you milliseconds of latency and zero architectural changes. It is the single highest-ROI action you can take this quarter.
4. Pilot ML-DSA for Internal Code Signing
Code signing is one of the easiest places to pilot PQC because you control both the signer and the verifier. Start with a parallel ML-DSA signing pipeline alongside your existing RSA or ECDSA pipeline. Dual-sign your artifacts with both algorithms during the transition. Once all your verification endpoints support ML-DSA, you can drop the classical signature. This gives you hands-on experience with the larger signature sizes, key management, and HSM integration before you tackle the harder migration targets.
5. Harden Authentication with FIDO2
Cryptographic migration is also the moment to upgrade your authentication. Password-based authentication and OTP tokens are being replaced by FIDO2/WebAuthn, which uses public-key cryptography resistant to phishing and quantum harvesting. Deploying FIDO2 security keys like the YubiKey 5 across your organization eliminates phishing as an attack vector while your team works on the broader PQC transition. The NIST guidelines specifically recommend phishing-resistant authentication as a prerequisite for PQC readiness — you cannot protect a quantum-resistant TLS session if the user authenticates with a phishable password.
The Bottom Line
Post-quantum cryptography migration is not a future problem. It is a current problem with a deadline. The NIST standards are finalized and shipping. The White House has mandated federal completion by 2035, and the intelligence community is already treating harvest-now-decrypt-later as an active threat. The algorithms work. The libraries ship. The infrastructure (Cloudflare, AWS, Google, Apple) has already started the transition. What is missing in most organizations is the inventory, the prioritization, and the will to start.
The teams that begin their cryptographic inventory this quarter and enable hybrid TLS where available will find the migration manageable. The teams that wait until 2029 will find themselves in a compliance crunch, paying premium consulting rates, and racing a deadline that was announced three years before they started. The math is simple: start now, or pay more later.
Get weekly AI & security infrastructure guides
Join the GeniusTechLab newsletter for new cryptography guides, security reviews, and infrastructure recommendations — one email a week, no spam.
Subscribe to the newsletter →