AI Security · Post-Quantum Cryptography
Post-Quantum Readiness
A CISO Roadmap for the PQC Migration
A quantum computer that can break RSA and elliptic-curve cryptography does not exist yet — and the migration away from them is still a now problem. The reason is harvest now, decrypt later: an adversary recording your encrypted traffic today can decrypt it the moment that machine arrives. NIST finalized the first post-quantum standards in August 2024 and set deprecation deadlines of 2030 and 2035. This guide covers why the timeline is shorter than it looks, what the standards actually replace, and a five-phase roadmap to get there.
30-SECOND EXECUTIVE TAKEAWAY
- It is a now problem because of "harvest now, decrypt later." Encrypted data stolen today can be decrypted once a quantum computer exists, so any secret with a long shelf life is already exposed in transit. Mosca’s inequality — secrecy lifetime + migration time > time to quantum — says start now.
- The standards are ready: FIPS 203, 204, and 205 (August 2024). ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures. You can migrate today; FN-DSA (FIPS 206) is still pending but is not a reason to wait.
- The deadlines are 2030 and 2035. NIST IR 8547 deprecates RSA-2048 and P-256 after 2030 and disallows quantum-vulnerable public-key cryptography after 2035. A full inventory and migration is a multi-year program — the clock has started.
Why a 2035 deadline is a today problem
The instinct is to file post-quantum cryptography under "future risk" and revisit it when a quantum computer actually threatens RSA. That instinct is wrong, and the reason is a single attack pattern: harvest now, decrypt later. An adversary does not need a quantum computer today to benefit from one tomorrow. They need only to record your encrypted traffic now — TLS sessions, VPN tunnels, exfiltrated databases — and store it until a cryptographically relevant quantum computer exists, at which point Shor’s algorithm unwinds the RSA and elliptic-curve cryptography protecting it. The confidentiality of that data was decided the day it crossed the wire, not the day it gets decrypted.
Michele Mosca’s inequality turns that into a decision you can actually make. Call X the number of years your data must stay secret, Y the years it will take you to migrate, and Z the years until a quantum computer can break your cryptography. If X + Y is greater than Z, you are already behind. Z is genuinely unknown — estimates range from years to more than a decade — but for data with a ten- or twenty-year confidentiality requirement, and migration programs that realistically run three to five years across a large estate, the inequality fails long before anyone agrees on Q-Day. The uncertainty in Z is the argument for starting, not for waiting.
What actually breaks — and what does not
The damage is concentrated, which is good news for scoping. Two quantum algorithms matter. Shor’s algorithm efficiently factors large numbers and computes discrete logarithms — the exact hard problems that RSA, Diffie-Hellman, and elliptic-curve cryptography depend on. Against those, a sufficiently large quantum computer is not a weakening; it is a full break. That is where the entire migration effort lives: key exchange and digital signatures, the public-key half of your cryptography.
Symmetric cryptography is barely touched. Grover’s algorithm gives only a square-root speedup against AES and hash functions, which effectively halves the security level — so AES-128 drops to about 64 bits of quantum security, but AES-256 keeps roughly 128 bits and remains safe. The practical response is to standardize on AES-256 and SHA-384/SHA-3, not to adopt new symmetric algorithms. So the program is narrower than "replace all our encryption": it is replace RSA and ECC, and double up symmetric key lengths where you have not already. Knowing that boundary keeps the inventory focused on the systems that genuinely need new algorithms.
The standards, and which to deploy
NIST finalized the first three post-quantum standards on August 14, 2024, after an eight-year selection process. FIPS 203 standardizes ML-KEM (derived from CRYSTALS-Kyber) for key encapsulation — the replacement for RSA and ECDH key exchange. FIPS 204 standardizes ML-DSA (from CRYSTALS-Dilithium) and FIPS 205 standardizes SLH-DSA (a stateless hash-based scheme from SPHINCS+), the two digital-signature replacements. ML-DSA is the general-purpose signature standard; SLH-DSA trades larger signatures for security resting only on well-understood hash functions, which makes it the conservative choice for long-lived roots of trust.
A fourth signature standard, FN-DSA (FIPS 206, based on FALCON), was submitted for approval in August 2025 and remains in clearance as of mid-2026, with finalization expected in late 2026 or early 2027. Its appeal is a smaller signature, which matters in bandwidth- or storage-constrained protocols — but it is not on the critical path. The three finalized standards are enough to migrate key exchange and the overwhelming majority of signing today. Waiting for FN-DSA is a way to spend the runway you do not have.
THE FIVE-PHASE READINESS ROADMAP
From cryptographic inventory to rolled-forward signatures
The phases are sequential in dependency, not in calendar — inventory and crypto-agility should run in parallel from day one, because both are long poles. Each phase pairs the problem it solves with the concrete first move.
Discover and inventory your cryptography
You cannot migrate what you cannot see. Most organizations have no map of where RSA and ECC are actually used — in TLS, code signing, VPNs, databases, hardware, and third-party dependencies.
First move: Build a cryptographic bill of materials (CBOM). Scan code, network traffic, certificates, and vendor attestations. The inventory is the single longest pole in the program — start it first.
Prioritize by data shelf-life
Not all data is equally exposed. Long-lived secrets — health records, financial data, state secrets, identity keys — are the harvest-now-decrypt-later targets that justify acting before Q-Day.
First move: Rank systems by how long their data must stay confidential and how exposed it is in transit. Apply Mosca’s inequality (X + Y > Z) per data class. Migrate the longest-shelf-life data first.
Build crypto-agility
Hard-coded algorithms are why migrations take years. The first PQC standard you deploy will not be the last, so a rip-and-replace per algorithm is a recurring cost you can design away.
First move: Abstract cryptography behind a service or library boundary. Make algorithm and key size configurable, not compiled-in. This is the investment that makes every future transition a configuration change.
Pilot hybrid key exchange
New lattice-based algorithms are young; deploying them alone means betting on schemes that have had far less cryptanalysis than RSA. A flaw found later would be catastrophic if PQC were your only protection.
First move: Deploy hybrid mode — a classical algorithm and a PQC algorithm combined, secure if either holds. Start with TLS to internal services where you control both ends. ML-KEM (FIPS 203) is the key-exchange standard to pilot.
Migrate signatures and roll forward
Digital signatures protect software supply chains, firmware, and identity — and signed artifacts created today must verify for years, so signing infrastructure is an early, high-leverage target.
First move: Move code signing and PKI to ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). Sequence the broader estate against the 2030 deprecation and 2035 disallowance dates, vendor by vendor.
Why hybrid, and why agility outlasts any single algorithm
The lattice-based schemes at the center of the new standards are strong but young — they have had a fraction of the cryptanalysis that RSA has absorbed over four decades. Deploying a PQC algorithm as your only protection is a bet that no one finds a flaw in it later, and a flaw found after you have migrated would be worse than the quantum threat you were defending against. Hybrid key exchange removes the bet: combine a classical algorithm and a post-quantum one so the channel stays secure as long as either holds. It costs some bandwidth and a little latency, and it is the right default for new deployments through this transition.
The deeper lesson is that this will not be the last migration. FIPS 206 is still coming, the lattice schemes will keep getting scrutinized, and a decade from now there may be a third generation of standards. The organizations that handle the next transition in a quarter instead of three years will be the ones that spent this migration building crypto-agility — abstracting cryptography behind a boundary, making algorithms configurable instead of compiled-in, and maintaining a cryptographic bill of materials that answers "where do we use this?" in minutes. Agility is the asset; any specific algorithm is a tenant.
FOR YOUR ROLE
What to do this quarter
For the technical CTO
Make cryptographic inventory a funded engineering project this year, not a checkbox — the CBOM is the program’s critical path. Mandate crypto-agility in new architecture reviews so you stop accumulating hard-coded cryptography, and pilot hybrid ML-KEM on internal TLS where you control both endpoints before touching anything customer-facing.
For the business CAIO
Add quantum risk to the enterprise risk register as a dated, budgeted program tied to the 2030 and 2035 deadlines, not a someday item. The exposure is asymmetric: harvest-now-decrypt-later means long-lived data is at risk today, so fund the inventory and longest-shelf-life migrations first. See the AI risk management guide for how this fits the broader register.
For the CISO
Own the cryptographic bill of materials and the migration sequence. Demand PQC roadmaps from every vendor whose product holds or transmits long-lived data, and treat their answers as a procurement gate. Establish hybrid key exchange as the standard for new deployments and a deprecation schedule for RSA-2048 and P-256 that lands well inside the 2030 window.
Post-Quantum Readiness: Frequently Asked Questions
What is post-quantum cryptography (PQC)?
Why migrate now if quantum computers cannot break encryption yet?
When do I have to be migrated by?
Does post-quantum cryptography also affect symmetric encryption like AES?
What is crypto-agility and why does it matter for PQC?
Is FIPS 206 / FN-DSA finalized yet?
Continue the AI security cluster
Post-quantum readiness is one layer of the enterprise security program. The rest of the cluster covers the others.