Quantum Academy is now open. Enroll in live online training – see the schedule.
Skip to content
Quantum Academy
Search Close search

Try a course name, a credential code such as PQCM, or an industry such as financial services.

Browse courses

Seven Exercises – PQC Migration Advisor

Post-Quantum Cryptography

Quantum Academy15 min read
Seven Exercises – PQC Migration Advisor

Learn how to use PQC Migration Advisor tool.

NIST published its first three post-quantum cryptography (PQC) standards in August 2024: FIPS 203 for ML-KEM key establishment, FIPS 204 for ML-DSA signatures and FIPS 205 for SLH-DSA signatures. Since then, most of the work has been migration. Organizations have to find where RSA and elliptic-curve cryptography run, choose a replacement for each use, and finish before dates that governments and regulators have already set.

In a post-quantum course you learn the reasons behind each of those choices: Shor’s and Grover’s algorithms, Mosca’s inequality, hybrid key exchange, FIPS validation and the legal status of a deadline. With the PQC Migration Advisor, you can apply them to a realistic organization. You describe its cryptography in a three-step form and get a report with the quantum exposure of each algorithm, its replacement, four timing checks, a prioritized action plan and the deadlines that apply. Change one input and generate the report again to see which recommendations differ and why.

Marin Ivezic created the Advisor and first published it on PostQuantum.com. QuantumAcademy.com publishes it in our Tools section with permission from Marin Ivezic and PostQuantum.com. For a description of every feature, read his article on the Advisor on PostQuantum.com.

What is the PQC Migration Advisor?

The PQC Migration Advisor is a free planning tool that runs in your browser, and nothing you enter is sent to a server or stored. Its knowledge base has 109 sources and was last reviewed on October 18, 2026. It is based on version 3.0 of the Applied Quantum PQC Migration Framework, a public methodology for enterprise PQC migration.

The form has three steps:

  1. Algorithms you use. There are 63 entries in five groups: key establishment and public-key encryption, digital signatures, symmetric encryption, hashes and MACs, and post-quantum or hybrid algorithms already in use. RSA appears six times, at three key sizes for key transport and the same three for signatures, because the replacements for the two roles differ.
  2. Where you use them. You can tick any of 18 protocol families, from public websites and VPNs to firmware signing, payments, blockchains and DNSSEC. The step is optional, but without it the action plan is much shorter.
  3. Your context. You choose one of nine sectors, one of four deployment environments and any of 20 jurisdictions and regulatory regimes, and you can set four time horizons in years. NIST’s transition timeline is included in every report.

At the top of the report are a summary and four timing checks. Below them, each recommended action is listed once, in one of four tiers:

  • Now: start within 90 days.
  • Next: plan and budget within 12 months.
  • Later: track, and act when standards or products are ready.
  • Keep: no change needed; re-check at each review.

Each action also belongs to a track. Track A is key establishment, Track B is signatures and public key infrastructure (PKI), and the rest are classical fixes, sector actions and program foundations. After the action plan you get the deadlines that apply, findings for each algorithm, a size table, mappings to standards and frameworks, and a numbered source list. You can download the report as a PDF, CSV or Markdown file, print it, or copy a share link.

Why is the Advisor useful for learners?

You can test what you learn against a realistic organization and see the effect of every input.

  • Cause and effect. In each exercise below, you change one input. You see which checks change and which actions move between tiers, and the reason is stated next to each result.
  • Primary sources. Every action, finding and deadline has a link to the document it comes from: NIST standards, IETF RFCs, guidance from the US National Security Agency (NSA), executive orders and regulators’ roadmaps. The source list at the end of each report works as a reading list.
  • Legal status. Each deadline is labeled with one of eight statuses, from binding and in force to draft and rulemaking pending. Many news reports give a post-quantum date without its status.
  • Realistic scenarios. With eight starting profiles, from a bank to a mobile network operator, you can load a typical set of algorithms, uses and context in one click.
  • Privacy. Your selections stay in your browser, so you can describe your employer’s systems without sending the details anywhere.

Seven exercises with the Advisor

Open the PQC Migration Advisor in a second tab and select Reset before each exercise. We use the default planning horizon of 2035 throughout, except where an exercise changes it. We ran every exercise on October 18, 2026. From 2027 there are fewer years left to 2035, so some numbers in your results will differ.

1. Sort algorithms by quantum exposure

Setup. In step 1, tick seven algorithms: RSA-2048 (encryption, key transport), ECDH P-256, ECDSA P-256, AES-128, SHA-256, SHA-1 and 3DES. Leave steps 2 and 3 empty and select Generate report.

Result. The summary has three lines: “3 of the 7 algorithms you selected are quantum-vulnerable (2 for key establishment, 1 for signatures). 2 are already broken, disallowed or due for retirement on classical grounds: fix those first. 3 symmetric or hash algorithms need no algorithm change.” In the action plan, the SHA-1 and 3DES fixes are in Now. Replacing RSA and ECDH key establishment with ML-KEM is in Next, and AES-128 and SHA-256 are under Keep.

Why. RSA depends on the difficulty of factoring, and elliptic-curve cryptography on the difficulty of discrete logarithms. An attacker with a cryptographically relevant quantum computer (CRQC) could solve both with Shor’s algorithm and recover a private key from its public key, at any key size in use today. Against symmetric keys, the best known quantum attack is Grover’s algorithm, with at most a quadratic speedup that parallelizes poorly. NIST keeps AES-128 approved and uses AES-128 key search to define its lowest post-quantum security category.

SHA-1 and 3DES are in Now for classical reasons. Researchers published a practical SHA-1 collision in 2017 and a chosen-prefix collision in 2020. NIST disallowed three-key 3DES for encryption after 2023 in SP 800-131A Rev. 2. Attackers can exploit both weaknesses today, so their fixes come first.

Try next. Open the algorithm findings for RSA-2048. The replacement is ML-KEM-768 in a hybrid, or ML-KEM-1024 in US national security systems, and the dates from the NIST IR 8547 draft are listed: deprecated after 2030, disallowed after 2035. Then add RSA-2048 signatures. Their replacement is ML-DSA-65, and their actions are in Track B.

2. Test Mosca’s inequality

Mosca’s inequality, named after Michele Mosca, compares three numbers. X is how many years your data must stay confidential, Y is how many years your migration will take, and Z is how many years remain until a CRQC exists. If X + Y is larger than Z, data sent before the migration ends will still need protection after a CRQC exists. No one knows Z, so in the Advisor it is replaced by the years left until your planning horizon.

Setup. Keep the algorithms from exercise 1. Under Time horizons in step 3, set X to 25 years and Y to 7 years, then generate the report.

Result. The harvest-now-decrypt-later check is marked Act now: “X + Y = 25 + 7 = 32 years, more than the 9 years to your planning horizon (2035). Traffic sent before your migration ends (about 2033) must stay confidential until 2058, so ciphertext recorded today outlasts the horizon.” In the action plan, “Replace RSA, DH and ECDH key establishment with ML-KEM” has moved from Next to Now, labeled “Raised by your horizon check”.

Now set X to 2 years. X + Y is 9, equal to the 9 years left, so the check is marked Within margin and the ML-KEM action is back in Next. The check is marked Act now only when X + Y is larger than the years left.

Why. An adversary can record encrypted traffic today and decrypt it once a CRQC exists. This is called harvest now, decrypt later (HNDL). The keys that protect the traffic are agreed through RSA or elliptic-curve key exchange, so key establishment has to change before the data’s confidentiality period ends. A session token that matters for a day can wait. Health records that must stay confidential for 25 years cannot.

Try next. Keep X at 2 years and change the planning horizon to 2032. With six years left, X + Y = 9 is too long, and the check is marked Act now again. An earlier horizon is how you stress-test a plan against an earlier CRQC.

3. Check how long signatures must stay trusted

Setup. Tick ECDSA P-256 and RSA-2048 signatures. In step 2, tick “Code, firmware and software-update signing”. In step 3, set T, how long signatures and trust anchors you issue now must stay trusted, to 15 years, and Y to 7 years.

Result. The trust-now-forge-later check is marked Act now: “T + Y = 15 + 7 = 22 years, more than the 9 years to 2035. Signatures and trust anchors issued before your migration ends (about 2033) will still be relied on in 2048, when a CRQC could forge them.” The harvest-now-decrypt-later check is marked Not applicable, because none of your selections are used for key establishment. In the Now tier you see “Sign firmware and software updates with LMS or XMSS, dual-signed with your current algorithm”. “Make composite or dual signatures (ML-DSA plus classical) your default” has been raised from Next to Now.

Why. Nobody can forge a signature before a CRQC exists, so there is nothing to harvest in advance. The exposure is in signatures and trust anchors that are still relied on after that point, such as a firmware root key in a device that stays in service for 15 years or a signed contract kept for 30. This is called trust now, forge later (TNFL). LMS and XMSS are stateful hash-based signature schemes, approved by NIST in SP 800-208. Their security depends only on the hash function, and NSA allows them for software and firmware signing under its Commercial National Security Algorithm Suite 2.0 (CNSA 2.0).

Try next. Set T to 1 year. The check is marked Within margin, but LMS or XMSS firmware signing stays in Now because you ticked firmware signing in step 2. To see why signature work needs more time than key exchange, read Why Signature Migration Needs the Longer Runway.

4. Compare hybrid TLS with pure ML-KEM-1024

Setup. Tick X25519 and ECDH P-256, then tick “Public websites and APIs (TLS)” in step 2. Under Deployment environment, choose “No FIPS requirement” and generate the report. Then change the environment to “US national security systems (CNSA 2.0)” and generate it again.

Result. In the first report, the first Track A action is “Enable hybrid X25519MLKEM768 key exchange on your TLS 1.3 endpoints”. In the second, it is replaced by “Use pure ML-KEM-1024 key exchange on TLS 1.3 endpoints in national security systems”, and there are seven actions in Now instead of three. Among the new ones are “Move national security systems to ML-KEM-1024 and ML-DSA-87” and “Use AES-256 and SHA-384 or SHA-512 on national security systems”.

Why. X25519MLKEM768 is a hybrid. It combines classical X25519 with ML-KEM-768, and the shared key stays secret as long as either half is unbroken. Chrome, Edge, Firefox and Apple’s iOS 26 and macOS 26 networking stacks have it on by default, and it is registered as a Recommended TLS 1.3 group in RFC 10024 (August 2026).

For US national security systems, NSA’s CNSA 2.0 rules apply. NSA requires ML-KEM-1024. It does not require hybrids, and it permits them only where it recommends a specific hybrid, as it does for IKEv2. Under a draft CNSA 2.0 profile for TLS 1.3 written by NSA authors, only pure ML-KEM-1024 is allowed, and neither half of X25519MLKEM768 is a CNSA 2.0 algorithm.

European agencies differ from NSA and from each other. Germany’s BSI says in TR-02102-1 that post-quantum key establishment should be used in hybrid form. France’s ANSSI requires hybrids inside its regulated perimeter and strongly recommends them elsewhere. The UK’s NCSC accepts hybrid key exchange as an interim measure on the way to post-quantum-only key exchange.

Try next. Read Why the World Can’t Agree on Hybrid PQC Deployment for the arguments on each side, then load the Defense / national security system profile and compare its Now tier with your second report.

5. Require FIPS 140-3 validated modules

Setup. Tick ECDH P-256 and ECDSA P-256, then “Public websites and APIs (TLS)”. Generate the report with “No FIPS requirement”, then again with “FIPS 140-3 validated modules required”.

Result. The second report has one more Now action, “Run PQC in FIPS-required systems only through modules whose certificates list the operation”, and one more Next action, “Replace non-approved primitives in FIPS-required systems”. If you choose “FIPS preferred, not mandated” instead, the extra Now action is “Deploy PQC with CAVP-tested algorithms and a documented risk acceptance”.

Why. ML-KEM is specified in FIPS 203. Products that implement it are validated separately, under FIPS 140-3. A system that must use validated cryptography can run ML-KEM in production only through a module whose certificate from NIST’s Cryptographic Module Validation Program (CMVP) includes ML-KEM among its approved services. Such certificates exist: certificate #5298, issued for AWS-LC 3 in June 2026, is one. NIST’s Cryptographic Algorithm Validation Program (CAVP) tests algorithm implementations, not whole modules, so CAVP-tested algorithms with a documented risk acceptance are the step recommended where validation is preferred but not mandated.

Try next. Open certificate #5298 on the CMVP site and find ML-KEM in its list of approved algorithms.

6. Read deadlines by legal status

Setup. Tick ECDH P-256, ECDSA P-256 and RSA-2048 signatures. In step 3, select “United States: federal civilian agencies”, “European Union (coordinated roadmap)” and “United Kingdom (NCSC)”, and set Y to 7 years.

Result. Every row in the deadlines table has a status. Compare these:

  • Binding: US federal agencies’ migration plans, due October 22, 2026 under OMB memorandum M-26-15. Under Executive Order 14412, agencies must move high-value assets and high-impact systems to PQC key establishment by December 31, 2030 and to PQC signatures by December 31, 2031.
  • Rulemaking pending: covered federal contractors. In EO 14412 the President directed a Federal Acquisition Regulation rule that would require them to comply by December 31, 2030, and the rule has not been issued.
  • Roadmap: the EU’s coordinated implementation roadmap, with the transition started by the end of 2026, high-risk use cases and critical infrastructure migrated by the end of 2030, and medium-risk use cases by the end of 2035.
  • Guidance: the UK NCSC’s milestones for 2028, 2031 and 2035.
  • Draft: NIST IR 8547’s 2030 and 2035 dates.

The earliest-deadline check is marked Act now. Your migration estimate ends around 2033, and the first migration milestone in your selections is the EU roadmap’s date for high-risk use cases and critical infrastructure, December 31, 2030.

Why. Who must meet a date depends on its legal status. US federal agencies are bound by executive orders and OMB memoranda. EU member states agreed the roadmap through the NIS Cooperation Group in June 2025. UK organizations use the NCSC timelines as guidance. NIST IR 8547 is still the initial public draft that NIST released in November 2024, so its dates are proposals. Drafts and pending rules are left out of the earliest-deadline check.

Try next. Add “PCI DSS (card payments)”. You get Requirement 12.3.3 of PCI DSS, in force since March 31, 2025: a documented, annually reviewed inventory of cipher suites and protocols. For the US federal dates in detail, read Which US Federal Post-Quantum Deadline Binds You.

7. Compare three sector profiles

Setup. Choose the Bank profile and generate the report. Then do the same with Utility or OT operator and Digital-asset custodian. Each profile is a preset of typical algorithms, uses, sector, environment and time horizons.

Result.

  • Bank: 6 of 12 algorithms are quantum-vulnerable. Both quantum checks are marked Act now, with X + Y = 25 + 7 = 32 years and T + Y = 10 + 7 = 17 years. There are 20 actions in Now, starting with SHA-1, 3DES and static RSA key exchange.
  • Utility or OT operator: the service-life check is marked Act now: “Equipment deployed in 2026 and kept 20 years will still run in 2046, after 2035.” The Now tier includes “Terminate PQC at the OT/IT boundary gateway and migrate firmware signing first” and “Require PQC-capable, updatable cryptography in the devices and systems you buy now”.
  • Digital-asset custodian: 5 of 8 algorithms are quantum-vulnerable, and 4 of the 5 are signature schemes: ECDSA and Schnorr on secp256k1, Ed25519 and BLS12-381. The Now tier includes “Inventory blockchain addresses by public-key exposure and set a rotation policy”.

Why. All three organizations face the same quantum attacks under different constraints. A bank keeps records that must stay confidential for decades, and its payment hardware security modules (HSMs) must be certified under PCI PTS HSM in addition to being FIPS 140-3 validated. Operational technology (OT) equipment often stays in service for 15–25 years, some of it for 40, with no way to update its cryptography. Once a public key has been published on a blockchain, anyone can copy it now and attempt a forgery later. In most account models, changing the key means moving the asset.

Try next. Pick the profile closest to an organization you know, change one input to match it, and note which actions move. For more depth on these sectors, see our courses on Quantum-Safe Financial Services, Quantum-Safe OT and Critical Infrastructure and Quantum-Safe Digital Assets.

Using the Advisor in a class or study group

When you select Copy share link, your selections are written into the link after the # sign, a part of the URL that browsers keep on the device rather than send to the server. Everyone who opens the link sees the same report, so an instructor can give a whole class one scenario.

For coursework, you have three export formats:

  • The PDF from Download PDF is text-based. You can select its text, click its links and hand it in as it is.
  • In the CSV file, actions, deadlines, algorithm findings and protocol guidance are rows of a single table that you can sort and filter in a spreadsheet.
  • The Markdown export is for notes or a course wiki.

Four assignments we suggest:

  1. Load a profile and justify its first three Now actions from their primary sources.
  2. Change one time horizon and explain why each affected action changed tier.
  3. Choose two jurisdictions and sort their dates by legal status.
  4. Take a commercial TLS migration plan and rewrite it for a national security system under CNSA 2.0.

Four limits to know before using the results

  • No Q-Day prediction. No one knows when a CRQC will exist. The default planning horizon is 2035 because quantum-vulnerable algorithms are disallowed after 2035 under the NIST IR 8547 draft, the NCSC expects every system migrated by then, and EU member states aim to migrate medium-risk use cases by the end of 2035. In NSM-10, the White House also set 2035 as the US goal for mitigating as much quantum risk as feasible. To test a faster scenario, set an earlier year.
  • No scanning. Only what you select is in the report, and organizations routinely underestimate how much cryptography they run. Check your selections against what discovery tools find and against the organization’s cryptographic bill of materials (CBOM). For how to find the rest, see Building a Crypto Inventory That Covers the Whole Estate.
  • No vendor recommendations. You will see a product named only where it is evidence for a fact, for example a module with a FIPS 140-3 certificate for ML-KEM.
  • A dated snapshot. The knowledge base was reviewed on October 18, 2026. Standards and deadlines change, so check a row’s status at its source before you cite it.

Where to study these topics