Quantum computers will break today’s public-key cryptography. The data your adversaries harvest now, they’ll decrypt later — unless you migrate first.
Book a ConsultationRSA, ECC, and Diffie-Hellman — the algorithms protecting nearly every TLS connection, VPN, code signature, and encrypted archive — will fall to a cryptographically relevant quantum computer. Adversaries aren’t waiting for that day: harvest-now, decrypt-later campaigns are collecting encrypted traffic today, betting your data still matters when the hardware arrives.
The standards are ready. NIST finalized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), then followed them with SP 800-227 on how to use key-encapsulation mechanisms correctly — because the algorithm was never the hard part. CNSA 2.0 sets hard deadlines for national security systems, the EU has told member states to inventory by the end of 2026, and NIST IR 8547 puts a date on when RSA and ECDSA stop being acceptable at all.
Organizations that inventory and plan now migrate on their terms; the rest scramble under mandate. The work that takes years isn’t swapping an algorithm — it’s finding every place you use one.
Discovery of every algorithm, key, certificate, and protocol across your applications, infrastructure, and vendor stack — the cryptographic bill of materials most organizations have never assembled. We inspect code, configuration, and live traffic to capture what’s actually in use, not what the documentation claims.
Each finding ranked by data lifetime, exposure, and migration difficulty — so you fix what matters first, not what’s easiest. Records that must stay confidential for a decade carry different urgency than tokens that expire in minutes — and your budget should follow the actual risk.
A phased, budget-aware plan to NIST-standardized algorithms, including hybrid schemes for the transition and crypto-agility patterns so the next migration is easier than this one. Each phase is sequenced to fit your release cycles, with clear owners and measurable exit criteria.
Assessment of your vendors’ PQC posture and the questions to put in your next procurement cycle — your cryptography is only as strong as your dependencies’. We review contracts, roadmaps, and library dependencies to flag the suppliers most likely to slow your migration down.
The published standards are only half the picture — the transition guidance is what sets your deadlines. Current as of August 2026.
| Standard | Status | Why it matters to you |
|---|---|---|
| FIPS 203 — ML-KEM | Final, Aug 2024 | The key-establishment algorithm. This is what replaces RSA and ECDH in TLS, VPNs and anything negotiating a session key. |
| FIPS 204 — ML-DSA | Final, Aug 2024 | The general-purpose signature algorithm — certificates, code signing, authentication. |
| FIPS 205 — SLH-DSA | Final, Aug 2024 | Hash-based signatures. Slower and larger, but its security rests on different assumptions from ML-DSA — the hedge if lattices disappoint. |
| SP 800-227 — KEM recommendations | Final, Sept 2025 | How to use a KEM correctly. Most real failures will be integration errors, not broken algorithms, and this is the document auditors will cite. |
| NIST IR 8547 — transition | Draft | The one that sets your calendar: 112-bit classical algorithms deprecated after 2030 and disallowed after 2035. Certificates issued today that outlive 2030 are already a finding. |
| FIPS 206 — FN-DSA (Falcon) | Draft, expected 2026–27 | Compact signatures, roughly 1 KB. Matters where signature size is the binding constraint — firmware, constrained devices, certificate chains. |
| SP 800-230 — SLH-DSA parameter sets | Draft, Apr 2026 | Six additional parameter sets for fast verification and smaller signatures, capped at 2²⁴ signatures per key. Useful for firmware and code signing — not approved for general use, and exceeding that limit breaks the security argument. |
| HQC | Selected Mar 2025, draft pending | A code-based backup KEM, chosen precisely because it is not a lattice scheme. Relevant to crypto-agility planning, not to today’s migration. |
| When | What |
|---|---|
| End of 2026 | EU member states to have published national PQC strategies and begun cryptographic inventories. |
| 1 Jan 2027 | Newly acquired US national security systems must be CNSA 2.0 compliant. This is a procurement gate, not a migration deadline — it binds vendors first. |
| 2030 | CNSA 2.0: software and firmware signing, and networking equipment, exclusively PQC. NIST IR 8547 deprecates 112-bit classical. EU high-risk critical infrastructure migrated. |
| 2033 | CNSA 2.0: operating systems exclusively PQC. |
| 2035 | Classical algorithms disallowed under IR 8547; EU medium-risk migration complete. |
A readiness assessment starts with a conversation about your data, its lifetime, and your compliance horizon.
Get in Touch