I Rebuilt the PQC Migration Advisor With 63 Algorithms, 18 Protocol Families and 20 Jurisdictions and Regimes

US federal agencies have until 22 October 2026 to send their post-quantum migration plans to the Office of Management and Budget and the Office of the National Cyber Director, under OMB memorandum M-26-15. EU member states are due to start their national transitions by the end of 2026, under the coordinated implementation roadmap the NIS Cooperation Group published in June 2025. Any company that stores, processes or transmits payment card data has had to keep a documented, annually reviewed inventory of its cipher suites and protocols since Requirement 12.3.3 of PCI DSS became mandatory on 31 March 2025.

Which of those dates applies to you depends on where you operate, who regulates you and which cryptography runs in which of your systems. For most organizations a government, a regulator or a payment scheme has already set the deadline for the migration. The question to put to a board is which dated obligation comes first, and whether the migration will be finished before it.

I rebuilt my PQC Migration Advisor so you can answer that question for your own systems. I first published it in August 2025 and released version 2.0 on 18 October 2026. Version 2.0 is built on version 3.0 of the Applied Quantum PQC Migration Framework and on a knowledge base of 109 sources, which I reviewed the same day. It has 63 algorithms, 18 protocol families, nine sectors, four deployment environments, and 20 jurisdictions and regulatory regimes, and NIST’s transition timeline is included in every report as a reference. It’s free and runs entirely in your browser.

What You Select in the Form

In step one, the only required step, you choose from 63 algorithms in five groups: key establishment and public-key encryption, digital signatures, symmetric encryption, hashes and MACs, and post-quantum or hybrid algorithms you may already run. RSA has six entries, three key sizes in two roles, because RSA key transport and RSA signatures get different replacements on different timelines. Also on the list are static RSA key exchange in TLS 1.2, Brainpool curves, secp256k1 and Schnorr signatures for Bitcoin, BLS signatures for Ethereum consensus, national algorithms such as SM2 and GOST, the stateful hash-based signature schemes LMS and XMSS, the pre-standard FN-DSA (Falcon) and HQC, and quantum key distribution. You can filter by the names engineers see in configuration files: type ES256, secp256r1 or X25519Kyber768Draft00 and you get the right entry.

In step two you tick where you use those algorithms, across 18 protocol families: public websites and APIs, internal services and service meshes, VPNs, SSH, certificate authorities, code and firmware signing, document signing and archives, email, data at rest, identity systems, payments, end-to-end encrypted messaging, IoT and OT devices, mobile networks, blockchains, DNSSEC, Wi-Fi and cloud services. The step is optional, but the action plan depends on it. With the algorithms from the Enterprise IT and cloud profile, the plan has 22 actions instead of 9 once you tick the profile’s nine protocol families. Among the additions are hybrid TLS on mail gateways and moving mTLS client authentication off publicly trusted certificates before 15 March 2027.

In step three you set your context: sector, deployment environment, the jurisdictions and regimes that apply to you, and four time horizons. The horizons are numbers of years, used in the timing checks: how long your most sensitive data must stay confidential (X), how long signatures and trust anchors you issue now must stay trusted (T), the longest service life of systems you deploy this year (L), and how long your migration will take (Y). Each field has examples. Session data needs confidentiality for under a year, customer and financial records for 5–10 years, and health, legal and intellectual-property records or state secrets for 25 years or more. In my framework I put a large enterprise at 4–15 years of execution. The planning horizon is 2035 by default.

Why the Same Algorithm Gets Different Advice

In version 1, each algorithm had one answer. RSA-2048 got the same advice whether you used it to protect a TLS session, sign a firmware image or wrap keys in an HSM. Those are separate problems with their own replacements, so in version 2.0 the advice depends on where you use the algorithm.

Two Tracks for Key Establishment and Signatures

An adversary can record traffic protected by RSA or elliptic-curve key exchange today and decrypt it once a cryptographically relevant quantum computer (CRQC) exists. That’s harvest now, decrypt later (HNDL), and it’s why key establishment is the more urgent half of the migration. Signatures can’t be forged in advance. Every signature and trust anchor still relied on after a CRQC exists can be forged then, which I call trust now, forge later (TNFL). Firmware roots, signed contracts and long-lived certificates stay exposed to it for as long as anyone relies on them. In my framework I split the migration into two parallel tracks: Track A for key establishment and Track B for signatures and PKI. Every action in the report belongs to one of the two tracks, or to classical fixes, sector actions or program foundations.

Each Protocol Has Its Own Replacement

The replacement, and how soon you can deploy it, differ by protocol:

• On TLS 1.3, the hybrid group X25519MLKEM768 is classical X25519 combined with ML-KEM (Kyber). Google, Microsoft, Mozilla and Apple have switched it on by default in Chrome (since version 131), Edge, Firefox and the iOS 26 and macOS 26 networking stacks. If you enable it at your CDN, load balancers and reverse proxies, most browser and app traffic is protected in one change.
• On IKEv2 VPNs, you can add ML-KEM to the classical key exchange with RFC 9370.
• SSH has its own hybrid key exchange, mlkem768x25519-sha256.
• In RFC 9980, the IETF’s post-quantum update to OpenPGP, ML-KEM and ML-DSA (Dilithium) are paired only with elliptic-curve components, so holders of RSA keys must generate new keys.
• DNSSEC has no standardized post-quantum algorithm yet, and DKIM has no post-quantum signature method.
• Public certificate authorities have no ML-DSA roots in browser trust stores yet. Google plans to bootstrap public Merkle Tree Certificates in Chrome, working with Certificate Transparency log operators, from the first quarter of 2027.

Deployment Environments and FIPS Validation

You choose one of four deployment environments:

• No FIPS requirement: you can deploy PQC now with current open-source libraries such as OpenSSL 3.5 or later, Go 1.24 or later, BoringSSL and rustls. The limit is your organization’s readiness.
• FIPS validation preferred but not mandated: I recommend algorithms tested under NIST’s Cryptographic Algorithm Validation Program (CAVP), with a documented risk acceptance, until the operation is covered by a validated module.
• FIPS 140-3 validated modules required: PQC can be put into production only through a module whose certificate includes the operation as an approved service. You can plan, stage and rehearse now, and switch a system over once such a certificate has been issued for the module it uses.
• US national security systems: under CNSA 2.0, NSA requires ML-KEM-1024 and ML-DSA-87, with AES-256 and SHA-384 or SHA-512. LMS and XMSS are allowed only for software and firmware signing. NSA doesn’t require hybrids, and it allows them only where it specifically recommends one, such as IKEv2.

Sector Constraints

Payment HSMs need PCI PTS HSM certification as well as FIPS 140-3. If an HSM loses its PCI certification when PQC firmware is installed, it can’t be deployed until it is re-certified. OT assets often stay in service for 15–25 years, some for 40, with no way to update them. In mobile networks a few infrastructure vendors control most core-network cryptography, so operators migrate at the pace of their vendors’ roadmaps. On a blockchain, a public key that has appeared on the ledger can be harvested for future forgery, and in most account models the holder can’t re-key without moving the asset. Each sector has its own actions and notes in the report, and for six sectors there’s a link to the matching extension of my framework.

What the Report Contains

Summary and Four Timing Checks

At the top of the report you see three lines: how many of your algorithms are quantum-vulnerable and in which role, how many are already broken or disallowed on classical grounds, and how many need no change. Four checks follow:

• Harvest now, decrypt later: X + Y against the number of years left until your planning horizon. This is Mosca’s inequality. When X + Y is larger, traffic you send before your migration ends must stay confidential past the horizon.
• Trust now, forge later: T + Y against the same horizon, for signatures and trust anchors.
• Service life: whether systems you deploy this year will still run after the horizon.
• Earliest migration deadline: the year your migration would finish, against the first dated migration milestone in the jurisdictions you selected.

I left drafts and unissued rules out of the deadline check, so your deadline never comes from a draft NIST date or a pending procurement rule. Under the checks, your migration, your confidentiality need and your signature lifetime appear as bars against the planning horizon, with the next dated milestone in your selections named underneath.

Priority Actions in Four Tiers

Actions come in four tiers: Now (start within 90 days), Next (plan and budget within 12 months), Later (track, and act when standards or products are ready) and Keep (no change needed; re-check at each review). Each action appears once, even when several of your selections lead to it, and under it you see the selections behind it, its sources and related analysis.

If you raise X from 3 to 25 years in the Enterprise IT and cloud profile, with a five-year migration estimate, the harvest-now-decrypt-later check fails and three actions are moved from Next to Now: replacing RSA, DH and ECDH key establishment with ML-KEM, forcing fresh hybrid handshakes on long-lived connections, and choosing a strategy for each long-horizon data store. Each is labelled “Raised by your horizon check”.

Below the tiers come seven program foundations from my framework, which apply to every organization:

1. Tie the program to your dated obligations and secure an executive mandate.
2. Classify every system by deployment environment.
3. Scope by risk first, then build a minimum viable inventory.
4. Run key establishment and signatures as parallel workstreams.
5. Send PQC questionnaires to your critical vendors and write PQC into contracts.
6. Record findings in a queryable cryptographic bill of materials (CBOM).
7. Make algorithms changeable by configuration and rehearse a change in every migration wave.

Deadlines Labelled by Legal Status

The deadlines table contains every milestone for the jurisdictions you select. If you choose the national security systems environment, CNSA 2.0 is added; if you choose payments as a sector or use, PCI DSS is added. Each row has one of eight statuses: in force, binding, government policy, guidance, roadmap, stated aim, draft or rulemaking pending.

Under Executive Order 14412, US federal high-value assets and high-impact systems must use PQC key establishment by 31 December 2030 and PQC signatures by 31 December 2031, so I marked both rows binding. In the same order, the President directed a rule under the Federal Acquisition Regulation that would require covered federal contractors to comply by 31 December 2030; until that rule is issued, its row is labelled “Rulemaking pending”. NIST’s 2030 and 2035 dates for deprecating and disallowing quantum-vulnerable algorithms come from NIST IR 8547, which is still the initial public draft NIST released in November 2024, so I labelled those rows “Draft”.

Findings, Mappings and Sources

For each algorithm you select, you get its classical status, quantum exposure, replacement, NIST IR 8547 dates, CNSA 2.0 status, FIPS 140-3 validation notes and sizes. For capacity planning, there’s a size table: an ML-DSA-65 signature is 3,309 bytes against 64 for a raw ECDSA P-256 signature, and an ML-KEM-768 public key is 1,184 bytes against 32 for X25519.

Your selections are mapped to the standards and frameworks that apply to them, from NIST’s FIPS 203 to DORA’s risk-management standards and NIS2 in the EU. Every action, finding and deadline has its sources next to it, and the last section of the report is a numbered source list.

Example Report for a European Bank

With the Bank profile, 12 algorithms are preselected, including static RSA key exchange, 3DES and SHA-1, along with nine protocol families, including payments. The environment is set to FIPS preferred but not mandated, and the horizons to 25 years of confidentiality, 10 years of signature trust and a seven-year migration. I added the European Union and the United Kingdom as jurisdictions.

The first lines of the report are: “6 of the 12 algorithms you selected are quantum-vulnerable (4 for key establishment, 2 for signatures). 2 are already broken, disallowed or due for retirement on classical grounds: fix those first. 5 symmetric or hash algorithms need no algorithm change.”

Both quantum checks fail. For confidentiality, X + Y is 25 + 7 = 32 years against nine years to 2035, so traffic the bank sends before its migration ends, around 2033, must stay confidential until 2058. Signatures the bank issues before the migration ends will still be relied on in 2043. On the deadline check, the migration would finish around 2033, after the EU roadmap’s 31 December 2030 date for migrating high-risk use cases and critical infrastructure. The next dated milestone is 31 December 2026, when EU member states are due to start their transitions.

There are 20 actions in the Now tier. The first three are classical fixes: remove SHA-1 from signatures and certificates, replace 3DES, and disable static RSA key exchange. Next come the Track A actions: hybrid key exchange on TLS 1.3 endpoints and IKEv2 VPNs, a register of every HSM and KMS with its PQC capability, and a strategy for each long-horizon data store. The first Track B actions are LMS or XMSS for firmware signing, shorter certificate lifetimes and a pilot ML-DSA intermediate CA under the existing root. In the sector actions, the bank asks its payment HSM vendors for their PQC firmware and re-certification dates, and starts key-exchange work on external payment and treasury APIs, HSM-protected keys and SWIFT interface cryptography.

The deadlines table has the EU roadmap’s three dates (end of 2026, 2030 and 2035), the UK National Cyber Security Centre’s milestones for 2028, 2031 and 2035, NIST’s draft dates, and PCI DSS Requirement 12.3.3, added because the profile includes payments. The mappings include Article 6(4) of DORA’s risk-management standards, under which a financial entity’s encryption policy must provide for updating its cryptography on the basis of developments in cryptanalysis, as well as Article 21(2)(h) of NIS2 and PCI DSS Requirement 12.3.3. In all, 51 sources are cited.

How to Run the Advisor

1. Open the advisor and pick the profile closest to your organization, or tick algorithms yourself. If you don’t know what you run, ask your teams for the algorithms configured in your TLS, VPN, PKI and key-management systems.
2. Tick where you use them.
3. Choose your sector, deployment environment and jurisdictions, then fill in the four horizons. If you leave a horizon on “Not sure”, its check is marked “Needs input”, with the value to set.
4. Press Generate report. Start with the summary and the checks, then the Now tier.
5. Export the report, or copy a share link.

Eight Starting Profiles

Each profile is a typical combination of algorithms, uses and context, which you can edit before generating the report.

Exports and Share Links

With Download PDF you get a text-based PDF with selectable text and clickable links. The summary and the checks come first, then the action plan and the deadlines, so the PDF can go straight into a steering-committee pack. The CSV export has the actions, deadlines, algorithm findings and protocol guidance in one table, ready for a tracker or spreadsheet. Markdown is for wikis. With Print you get the report on paper, without the rest of the page. In a share link, your selections are stored in the URL fragment, the part after the # sign, which isn’t sent to the server; a colleague who opens the link sees the same report.

Limits of the Advisor

There’s no Q-Day prediction in the advisor. The planning horizon is 2035 by default because, under the NIST IR 8547 draft, quantum-vulnerable algorithms are disallowed after that year, and the UK’s NCSC expects every system, service and product to be migrated by then. Under the EU roadmap, medium-risk use cases are due to be migrated by the end of 2035, and in the national security memorandum NSM-10 the White House set 2035 as the US goal for mitigating as much quantum risk as feasible. If you hold a view on when a CRQC will exist, set an earlier year and watch which actions move.

It isn’t an inventory. Everything in the report comes from what you tell it. Organizations routinely underestimate how much cryptography they run, so expect your selections to be incomplete. In my framework I introduced the minimum viable inventory as the alternative to spending years on a complete inventory that is out of date when it’s finished: scope by risk first, then inventory the systems with the most exposure. Treat your selections as a first draft of that scope, and confirm them with discovery tools and a CBOM.

There are no vendor recommendations in the advisor. Where a product is named in the report, the name is evidence for a statement, such as a FIPS 140-3 certificate that includes ML-KEM as an approved service.

None of your data is collected. Your selections stay in your browser, no cookies are set, and the only thing stored is your light or dark mode preference, in your browser’s storage.

Changes Since Version 1.2.2

• Algorithms: 63 entries, up from 32, separated by key size and role.
• Inputs: protocol families, sectors, deployment environments, jurisdictions and regimes, four horizons and a planning year, eight starting profiles, and a filter for aliases such as ES256.
• Report: timing checks, an action plan in four tiers with each action listed once, deadlines with legal status, standards mappings and numbered sources.
• Exports: with Download PDF you now get a text PDF; in 1.2.2 you got the print dialog instead. CSV, Markdown and share links are new.
• Corrections: in 1.2.2 I attributed a “2030–2035” target to PCI DSS, and an instruction to use 256-bit symmetric keys and SHA-384 or SHA-512 to NIST SP 800-57. Neither document contains that. I also told users in 1.2.2 to move from AES-128 to AES-256, which NIST doesn’t require: AES-128 remains approved. I now recommend AES-256 for new deployments, long-horizon data and CNSA 2.0.
• Accessibility and compatibility: every control is labelled, the whole form can be used from the keyboard, status messages are announced to screen-reader users, and the form is visible even while the page’s JavaScript is held back by a caching plugin.

Who Can Use the Report

• CISOs and program leads: a steering committee can take the timing checks, the first 90 days of work and the dates that apply, each with its legal status, straight from the PDF.
• Architects and engineers: guidance per protocol, the parameter choice behind each replacement and the size table. You can load the CSV straight into a tracker.
• Procurement and vendor managers: several actions are questions for vendors, from payment HSM firmware dates to which connections a cloud provider protects with PQC. In my article on PQC vendor and supply-chain governance, I cover what else to ask.
• Risk, compliance and audit teams: the mappings to ISO/IEC 27001, PCI DSS, DORA, NIS2 and the NIST Cybersecurity Framework 2.0, with every deadline and its status.
• Students and instructors: change one input at a time and compare the reports. If you switch the environment to “FIPS 140-3 validated modules required”, a new Now action appears: run PQC only through modules whose certificates include the operation as an approved service. If you add a jurisdiction, its dates appear with their status. Each action has links to its primary sources, so you can use the source list as a reading list. With a share link, an instructor can give a whole class the same scenario. At the end of each report’s reading list are my book Quantum Ready, which I based on the same framework, and Quantum Academy‘s PQC migration training.

The date I last reviewed the knowledge base, 18 October 2026 for this release, is printed on every report. US federal agencies are due to file their migration plans by 22 October, and EU member states are due to start their transitions by the end of the year. Run the advisor with your own selections, and at the top of the report you’ll see your earliest dated migration milestone and whether your migration would finish before it.

From the author