Post‑quantum cryptography
Plan and implement post‑quantum migration.
We inventory your cryptography, assess exposure and prioritise migration work using a five‑step framework. The deliverables include a migration roadmap and measures for reporting progress.
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 to 36 month migration roadmap
- Board‑ready briefing and vendor question set
Why plan now
Encrypted data can be collected before it can be decrypted.
Migration planning needs to account for recorded encrypted traffic, published post‑quantum standards and regulatory deadlines.
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. These standards provide a basis for migration planning.
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.
Data lifetime and migration time
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 estimates the likelihood of such a machine within the next decade. Estimate these times for your systems to set migration priorities.
The IDEALLY US PQC readiness framework
Five steps for post‑quantum migration
The framework follows NIST standards, government roadmaps and our migration experience. Each step defines the work, deliverables and progress to report to the board.
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 assessment sets the pace and budget.
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. Use Mosca’s inequality to assess the exposure. 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
Migrate systems with testing and rollback plans.
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, with a tested process for future algorithm changes.
- 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
Verify the migration and reassess regularly.
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. Maintain a repeatable process for future algorithm changes.
- 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 migration plan
Most regulators’ timelines converge on 2030 for the systems that matter and 2035 for everything else. Working backwards from there, the plan sets out overlapping phases for assessment, implementation and verification.
- 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 measured progress.
- 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. Use the measures to report migration progress.
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 | Not applicable | 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 quarterly migration measures
- 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
Standards and regulatory requirements 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 about your project. We will discuss the requirements, whether we can help and the next steps.
Based in Hong Kong, working with teams across Asia Pacific and remotely. Email [email protected] if you prefer.