Post‑quantum cryptography
Be quantum‑safe before the deadline finds you.
Harvest now, decrypt later is already happening. We give you a five‑step framework, a migration plan in priority order, and a way to show progress to the people who ask. We do not resell a single product along the way.
Post‑quantum cryptographyHarvest now, decrypt later. The clock is already running.
What we do
- 01Cryptographic inventoryDiscover every algorithm, key, certificate and library across code, infrastructure and vendors.
- 02Risk & exposure assessmentScore assets by data lifetime, exposure and migration difficulty. Find the harvest‑now‑decrypt‑later risk.
- 03Migration roadmapSequence hybrid and pure PQC moves (ML‑KEM, ML‑DSA, SLH‑DSA) against your budget and vendor timelines.
- 04Vendor & standards alignmentTranslate NIST, CNSA 2.0 and regulator guidance into questions your vendors must answer.
Who it’s for
CISOs, security architects and platform leads at organisations with long‑lived secrets, regulated data or hardware in the field.
You leave with
- Crypto‑agility maturity score and gap report
- Prioritised 18–36 month migration roadmap
- Board‑ready briefing and vendor question set
Why the clock is already running
You do not need a quantum computer to exist for the risk to exist.
Three things are true at once. Encrypted traffic is being recorded today to be opened later. The standards you will migrate to are already final. And the regulators have written the dates down.
Anything protected by RSA or elliptic‑curve key exchange today can be stored and decrypted when a large enough quantum computer arrives. If the data must stay secret for longer than that wait, it is already exposed.
NIST published FIPS 203 (ML‑KEM), 204 (ML‑DSA) and 205 (SLH‑DSA) in August 2024. Hybrid key exchange is already the default in Chrome, Firefox, Safari, OpenSSL and OpenSSH. Waiting for the standards is no longer a reason.
NIST’s draft transition guidance deprecates today’s public‑key algorithms after 2030 and disallows them after 2035. The US, EU, UK, Australia and Singapore have all set milestones that land in the same window or earlier.
The only equation your board needs
Shelf life + migration time > time to a quantum computer
Michele Mosca’s inequality. If the years your data must stay secret, plus the years it takes you to migrate, add up to more than the years until a cryptographically relevant quantum computer, you are late already. Most enterprise migrations take five to ten years. Most sensitive data has a shelf life of seven or more. The Global Risk Institute’s annual expert survey puts real odds on such a machine within the next decade. Do the sum for your own estate and the argument for starting usually makes itself.
The Ideally Us PQC readiness framework
Five steps from “we should probably look at this” to provably quantum‑safe.
Our own framework, shaped by the NIST standards, the government roadmaps and the migrations we have actually lived through. Every step ends with a deliverable your engineers can act on and a question your board can ask.
Before step one
Three foundations we put in place in the first month.
One person, with a mandate that cuts across security, engineering, procurement and the business. The lead, rather than a committee, owns the timeline, the vendor conversations and the board update.
Urgent adopters hold long‑lived secrets, run critical infrastructure or sit under a regulator with a date. Regular adopters do not, yet. The answer sets the pace and the budget, and we help you make it honestly.
Share of the estate inventoried. Share of external interfaces on hybrid key exchange. Share of long‑lived data re‑keyed. Vendors with a committed PQC date. Few enough to fit on one slide, tracked from month one.
-
01
Inventory
Know where every piece of cryptography lives.
A cryptographic bill of materials across code, certificates, HSMs, protocols, SaaS and vendor products, built with scanning tools where they reach and interviews where they do not. We record what protects what, who owns it, and what nobody can see: offline keys, firmware, third parties.
- Scan code, endpoints, certificates and key stores
- Map data flows and the data each key protects
- Register vendor and partner dependencies
- Document the blind spots explicitly
Deliverable · Cryptographic bill of materials (CBOM)Board question: “Do we know where our cryptography is?” -
02
Assess
Turn the inventory into a ranked list of exposure.
Each asset gets three numbers: how long its data must stay secret, how long it would take to migrate, and how hard it is to reach. Mosca’s inequality does the rest. Confidentiality goes first, because harvested traffic is the live risk. Signatures follow, because they only fail on the day the machine arrives.
- Score data shelf life and migration effort per asset
- Separate key establishment from signatures
- Identify hardware that cannot be patched
- Quantify the harvest‑now‑decrypt‑later exposure
Deliverable · Risk heat‑map and exposure registerBoard question: “What is already at risk, and how much of it?” -
03
Prioritise
Decide what moves first, what waits, and what is accepted.
A sequence your budget can carry: external interfaces and VPNs, long‑lived data at rest, code and firmware signing, then internal PKI, then the hardware and embedded estate that takes years. For every asset the decision is written down: migrate, mitigate, or accept for now with a date to revisit.
- Sequence by exposure, then by ease
- Turn vendor dependencies into dated asks
- Update procurement language so new purchases are quantum‑safe
- Set quick wins: TLS 1.3, shorter certificate lifetimes, retire expired data
Deliverable · Prioritised 18 to 36 month roadmapBoard question: “What are we doing this year, and what will it cost?” -
04
Migrate
Move, system by system, without breaking anything.
Hybrid first, so nothing is less secure during the transition, then pure post‑quantum where the standards and the counterparties allow. Every change is piloted in one critical path before it is scaled, and every migrated system is left crypto‑agile: algorithms chosen by configuration, downgrades blocked, the next change a setting rather than a project.
- Pilot hybrid ML‑KEM on one external interface
- Roll out in priority order with rollback plans
- Build agility in: configuration‑driven crypto, agile HSMs and key management
- Hold vendors to their dates and test what they ship
Deliverable · Runbooks, vendor evidence and an updated CBOMBoard question: “How much of the estate is quantum‑safe today?” -
05
Verify
Prove it, then keep proving it.
Scans that show the old algorithms are gone from the paths that matter, interoperability tests with partners, attestations your auditors and regulators will accept, and a standing process for the next change. HQC, FN‑DSA and the parameter sets will keep moving. The point of the framework is that the second migration is routine.
- Post‑migration scans and interoperability tests
- Assurance pack for auditors and regulators
- Standards watch: FIPS 206, HQC, CNSA 2.0 milestones
- Workforce plan and annual re‑assessment
Deliverable · Assurance report and a repeatable processBoard question: “Can we show a regulator we are done, and stay done?”
The strategy
A 36‑month plan that lands before the 2030 deadlines.
Most regulators’ timelines converge on 2030 for the systems that matter and 2035 for everything else. Working backwards from there, this is the shape of a migration that finishes with room to spare. The phases overlap on purpose.
- Months 0 to 3
Mandate and discovery
Name the lead, decide urgency, agree the measures. Start the inventory with what already exists: certificate stores, code scanners, vendor lists.
- Months 3 to 9
Inventory and assessment
Complete the CBOM, score exposure, and publish the first heat‑map. Quick wins go live: TLS 1.3 everywhere, shorter certificate lifetimes, expired data deleted.
- Months 9 to 18
Pilots and vendor asks
Hybrid key exchange on external interfaces, VPNs and SSH. Vendor question set sent, dates collected, procurement language updated. First board report with real numbers.
- Months 18 to 30
Priority migrations
Key establishment across the estate in priority order. Long‑lived data re‑keyed or re‑encrypted. Code and firmware signing moved to ML‑DSA or SLH‑DSA in line with CNSA 2.0.
- Months 30 to 36
Signatures, PKI and proof
Internal PKI and certificates migrated, hardware refresh plan funded, assurance pack delivered. What remains is documented, dated and accepted by name.
What moves first
- 1External TLS, VPN and SSH: the harvestable traffic
- 2Long‑lived data at rest and backups
- 3Code, firmware and software signing
- 4Internal PKI, certificates and HSMs
- 5Embedded, OT and hardware with long refresh cycles
Principles we hold to
Classical plus post‑quantum together, so nothing is weaker during the transition than it was before.
Harvested traffic is the risk today. Signatures only fail on the day the machine arrives. Sequence accordingly.
Algorithms are settings. Downgrades need a signed exception. The next change should be a change request.
We do not resell anything. Vendors get a question set and a date, and we test what they ship before you trust it.
A system that cannot migrate yet keeps compensating controls and a revisit date. Disabling cryptography is never the fix.
Four or five numbers, tracked monthly and reported quarterly. You get what you measure, so the numbers track progress rather than busywork.
The algorithms, in one table
What replaces what.
| Use | Today | Quantum‑safe | Notes |
|---|---|---|---|
| Key establishment | RSA, ECDH, DH | ML‑KEM (FIPS 203), hybrid with X25519 during transition | Default in major browsers, OpenSSL 3.5 and OpenSSH 10. CNSA 2.0 requires ML‑KEM‑1024. |
| Digital signatures | RSA, ECDSA, EdDSA | ML‑DSA (FIPS 204); FN‑DSA (FIPS 206) pending | CNSA 2.0 requires ML‑DSA‑87. FN‑DSA is still in draft at NIST; plan for ML‑DSA now. |
| Firmware and software signing | RSA, ECDSA | SLH‑DSA (FIPS 205), LMS / XMSS | Stateless hash‑based signatures for long‑lived, high‑assurance signing. CNSA 2.0 milestone: exclusive use by 2030. |
| Backup key establishment | — | HQC (selected March 2025; draft standard expected 2026) | A code‑based fallback to ML‑KEM, for estates that need a second mathematical basis. |
| Symmetric and hashing | AES‑128, SHA‑256 | AES‑256, SHA‑384 or SHA‑512 | Not broken by quantum computers, but Grover’s algorithm halves effective strength. Larger parameters are the cheap fix. |
How progress is reported
Five numbers on one slide, every quarter.
- 01Estate inventoried
Share of systems with a complete cryptographic bill of materials.
- 02External interfaces on hybrid
Share of internet‑facing TLS, VPN and SSH using ML‑KEM hybrid key exchange.
- 03Long‑lived data protected
Share of data with a shelf life over five years re‑keyed under post‑quantum protection.
- 04Vendors with a date
Share of critical vendors with a written, dated PQC commitment and evidence.
- 05Agility score
Share of migrated systems where the algorithm is a configuration setting with downgrade blocked.
Our framework draws on NIST FIPS 203, 204 and 205, NIST IR 8547 (draft) and CSWP 39 on cryptographic agility, the CISA, NSA and NIST Quantum‑Readiness guidance, the UK NCSC and EU coordinated roadmaps, the Post‑Quantum Cryptography Coalition’s migration roadmap and CyberSecurity Malaysia’s PQC Migration Framework, and the migrations we have run ourselves. Standards and dates as of September 2026.
Standards and regulation
What the standards and regulators are asking for, region by region.
Most timelines converge on 2030 for high‑risk systems and 2035 for everything else, but the details differ by country and sector. We track them so you don’t have to, and we map your roadmap to whichever applies to you first.
The technical standards we build on
Policy and regulation by jurisdiction
United States
BindingExecutive Order 14412 (June 2026) makes PQC migration a legal obligation for federal civilian agencies and their contractors. The Department of Defense strategy reaches into the defence industrial base through CMMC.
- 2030Federal agencies and contractors migrated by 31 December
- 2031Defence systems using PQC; non‑compliant systems phased out
European Union
RoadmapThe NIS Cooperation Group roadmap (June 2025) asks member states for national strategies and cryptographic inventories first, then high‑risk systems, then everything else. The Cyber Resilience Act makes crypto‑agility a practical requirement for products.
- 2026National PQC strategies and inventories started
- 2030High‑risk and critical infrastructure transitioned
- 2035Full migration; CRA applies from December 2027
United Kingdom and Canada
RoadmapNCSC and the Canadian Cyber Centre (ITSM.40.001) share a phased approach. Canada required federal departments to file migration plans by April 2026 with annual progress reports.
- 2031High‑priority systems migrated
- 2035All remaining systems migrated
Japan
In progressThe National Cyber Command Office concluded in November 2025 that government agencies must complete the transition by 2035. CRYPTREC published its PQC guideline in April 2025 and added ML‑KEM to the Ciphers List in April 2026, which unblocks government procurement. The FSA has told deposit‑taking institutions to begin now.
- 2027Formal national roadmap expected by May
- 2035Government systems fully quantum‑safe
Australia
Firm datesThe ASD Information Security Manual sets the most compressed timeline in the region and expects traditional asymmetric cryptography (RSA, ECDH, ECDSA) to be retired by the end of the decade.
- 2026Refined PQC transition plan in place
- 2028Migration of critical systems and data under way
- 2030Transition complete; traditional public‑key retired
Singapore
SupervisoryMAS issued advisory guidance in 2024 asking financial institutions to assess quantum risk and inventory their cryptography. Formal supervisory expectations with milestones are expected later in 2026, and in Singapore those carry real weight.
- 2024MAS advisory on quantum‑related cyber risk
- 2026Milestone‑based expectations for FIs expected
Hong Kong
EmergingThe HKMA announced a Quantum Preparedness Index in February 2026 to score banking sector readiness, an early signal that supervisors will compare institutions against each other.
- 2026HKMA Quantum Preparedness Index for banks
India
FormingMeitY and CERT‑In published “Transitioning to Quantum Cyber Readiness” in July 2025, directing finance, defence and healthcare to move first. A national task force followed in early 2026 with proposed accelerated timelines for critical information infrastructure and mandatory cryptographic inventories.
- 2025First national migration whitepaper
- 2027Proposed 2027 to 2029 window for critical infrastructure
South Korea
Sovereign pathA pan‑national PQC transition master plan (2023) alongside a domestic algorithm competition (KpqC). Expect national algorithm requirements to sit next to the NIST suite for anyone operating there.
- 2035National transition target, aligned with allies
Landscape as of September 2026, from published government and regulator documents. It moves quickly, and we keep it current for the people we work with. None of this is legal advice; your counsel and your regulator have the final word.
Other practices
Book a 30‑minute call.
Tell us where you are. We will tell you honestly whether we can help, what it would take, and what we would do first. No pitch, no pressure.