TECHNOLOGY EXPLAINER
Migrating to Post-Quantum Cryptography
— why prepare "now", and where to start (from a cryptographic inventory)
Switching cryptography to new schemes is not like changing a key: it is the work of finding public-key cryptography embedded everywhere, in communication, certificates, device firmware and stored data, and replacing it in turn. And even before quantum computers reach a practical scale, data encrypted today can be collected now and solved later. For this reason agencies in many countries have begun to publish timelines running to the mid-2030s.
Assuming no cryptography expertise, this article covers: (1) why preparation is needed "now" (Mosca's reasoning, with numbers), (2) the timelines published by countries and agencies and how they differ in nature, (3) where to start (a cryptographic inventory, priorities, dependencies) and (4) hybrid versus PQC alone. Deadlines are given as far as they could be confirmed in official documents, with the checking date (16 October 2026).
- The short version / before you read / where this fits in the series
- Why preparation is needed "now"
- Who, by when: timelines of countries and agencies (checked 16 October 2026)
- Where to start: a cryptographic inventory
- Setting priorities
- Hybrid or PQC alone / crypto-agility
- How to read evaluations and standards
- Glossary
- References (primary sources)
- Claim-to-source audit
Sourced = content stated in published material (with source links)
Our calculation = values we computed from stated assumptions
Not yet confirmed = drafts, plans, recommendations and other matters not yet settled or mandatory
Our own interpretation is labelled "Commentary". Inference is shown in bold.
Deadlines are of three kinds: (1) obligations (requirements on particular organisations, for example the dates the NSA sets for national security systems), (2) recommendations and guidance (roadmaps; for example the EU, the UK and Canada) and (3) drafts and plans, not yet fixed (for example the draft NIST IR 8547 and Japan's roadmap). Do not give dates of different nature the same weight. The dates are as stated in the official documents and can change with revisions. This article does not assert when quantum computers will break cryptography, does not explain how to break it, and gives no legal or investment advice. The numerical examples of X, Y and Z are our own assumptions to show the mechanism.
1. The short version / before you read / where this fits in the series
- Data can be collected "now" in order to be solved "later": even before quantum computers reach a practical scale, an attacker can collect and store data encrypted today and solve it in the future. This is called Harvest Now, Decrypt Later (HNDL)[Ref. 17, 12]
- The rule of thumb is "X + Y > Z": if the years X needed to migrate plus the years Y for which data should be protected exceed the years Z until a quantum computer, a danger arises (Mosca)[Ref. 8, 18]. Since Z is unknown, preparation means shortening X and Y, which an organisation can decide for itself
- The countries' timelines cluster around 2030 and 2035: the US NSA sets staged obligations for national security systems from 2027, the EU aims to finish high-risk uses by the end of 2030, and the UK, Canada and Japan among others aim for 2035[Ref. 11, 12, 13, 14, 15]. The first step is a cryptographic inventory
The previous article, "Post-Quantum Cryptography", helps. It explained that public-key cryptography is threatened by quantum computers while shared-key cryptography can respond by adjusting key length, and that NIST standardised ML-KEM, ML-DSA and SLH-DSA in 2024.
This article follows "Quantum Key Distribution and Quantum Communication", "Quantum Networks and Quantum Repeaters" and "Post-Quantum Cryptography" and is the practical part of the quantum-and-cryptography story. National investment and strategy for quantum technology is covered in the next article, "National Quantum Strategies".
2. Why preparation is needed "now"
(1) Take it now, solve it later: HNDL
Cryptography is made so that it does not matter when it is solved. But if the means of solving (a quantum computer) comes in the future, then anyone who records and keeps today's traffic can solve it then. The draft interim summary of Japan's inter-ministry liaison meeting explains HNDL as an attack that stores encrypted data and decrypts it after a quantum computer capable of breaking the cryptography becomes available[Ref. 17]. The EU roadmap likewise says that for uses where a leak 10 or more years later would still cause significant damage, attackers have a strong motivation to capture and store encrypted information even today[Ref. 12].
"Can the machine be built now?" and "is preparation needed now?" are different questions. The longer the life of the data to be protected, the more today can be the day the data is taken even if the day it is solved lies in the future. The NSA FAQ also states that the NSA does not know when there will be a CRQC (a cryptographically relevant quantum computer) and that expert assessments disagree significantly, and goes on to say that national security systems have long life cycles and the data they protect will need cryptographic protection for decades after the systems reach end of life, so requirements must be set now[Ref. 11].
(2) A rule of thumb: X + Y > Z (Mosca's reasoning)
In 2018 Mosca gave a rule of thumb for whether to prepare, in terms of three numbers of years[Ref. 8]. X is the years needed to move cryptography to a new scheme, Y the years for which the data should be protected, and Z the years until a quantum computer able to break the cryptography appears. If X + Y is longer than Z, then even when the migration is finished, data protected by the old cryptography is still around and can be solved. The report of the Financial Services Agency (Japan) study group explains this formula as the condition under which preparing for HNDL must be considered[Ref. 18].
The report of the Financial Services Agency gives exactly this numerical example: if migrating the cryptography of an information system protected by public-key cryptography takes at least 10 years and the generated data must be protected for 20 years, then even if migration starts now it is completed in 10 years, and data created just before completion must be protected for a further 20 years, so protection by the old cryptography must be maintained for 30 years unless special measures are taken[Ref. 18]. Using the same thinking, here is a table of combinations.
| Example | X + Y (years) | If Z = 10 | If Z = 15 | If Z = 20 |
|---|---|---|---|---|
| X = 3, Y = 5 years | 8 | Margin | Margin | Margin |
| X = 5, Y = 10 years | 15 | Danger | Margin | Margin |
| X = 10, Y = 10 years | 20 | Danger | Danger | Margin |
| X = 10, Y = 20 years | 30 | Danger | Danger | Danger |
Our calculation. "Danger" means X + Y > Z and "Margin" means X + Y ≤ Z (applying Mosca's formula). The values of X, Y and Z are illustrative assumptions, not forecasts for any organisation or quantum computer. Shortening X (starting the inventory and preparation early) and shortening Y (reviewing the protection period) can be decided by an organisation itself.
(3) Signatures are a little different
HNDL is serious mainly for protecting secret information (key establishment). The report of the Financial Services Agency notes that HNDL is effective against TLS key exchange but has hardly any effect on authentication[Ref. 18]. For signatures (confirming authenticity and absence of tampering), forging becomes a problem from the time a quantum computer appears. Long-lived signatures are different, however. What is hard to change after equipment has shipped, such as the code that verifies firmware signatures, cannot be swapped later unless it is moved early to a new scheme. The EU roadmap gives, as an example of "high" risk, signatures protecting software updates where migration takes more than eight years of effort[Ref. 12].
(4) Migration takes time
Another reason is the length of the migration itself. The draft interim summary of Japan notes that it took about 20 years from the proposal of a scheme such as RSA to its wide adoption in society, and expects PQC also to need a considerable period[Ref. 17]. The UK NCSC says migration will typically span several leadership cycles in most large organisations and that the cost could be significant, so organisations should budget for it[Ref. 13]. It also records that, because PQC keys and signatures are larger, significant changes to applications, interfaces, data formats and protocols are likely, and development cost and time may swell beyond what was usual[Ref. 17] (see the size comparison in the previous article).
Y (the years to protect) differs by kind of data. In materials and process work there are, for example, (1) trade secrets such as formulations and deposition conditions (very long if kept secret rather than patented), (2) equipment design drawings and process recipes (for the life of the equipment), (3) research data before filing (until filing), (4) customer contract information and (5) personal data (our commentary; examples, not exhaustive). The longer-lived the data, the larger Y and the more easily X + Y > Z, so writing down "what to protect for how many years" for each kind of data is the first question of the inventory.
3. Who, by when: timelines of countries and agencies (checked 16 October 2026)
Here are the timelines confirmed in official documents, set out together with their nature (obligation, recommendation or draft).
| Country or agency (document, date) | Timeline given (as stated in the document) | Nature | Caution |
|---|---|---|---|
| US NSA: CNSA 2.0 (advisory v1.0, September 2022; FAQ v2.1, December 2024) | National security systems (NSS): new acquisitions from 1 January 2027 must comply with CNSA 2.0; equipment and services that cannot support it are to be phased out by 31 December 2030; CNSA 2.0 use is mandated on 31 December 2031; the intent is for all NSS to be quantum-resistant by 2035 (NSM-10). For software and firmware signing, CNSA 2.0 is to be preferred in 2025 and exclusive in 2030 (the 2022 advisory)[Ref. 11, 10] | A requirement for NSS (CNSSP 15)Sourced | Applies to NSS and does not directly reach the general private sector (our commentary) |
| US NSM-10 (4 May 2022) | The goal of mitigating as much of the quantum risk as is feasible by 2035; orders federal agencies, among other things, to deliver annually an inventory of their IT systems that remain vulnerable[Ref. 9] | A memorandum (federal policy)Sourced | A target year; dates for individual agencies are in other documents |
| US NIST IR 8547 (initial public draft, 12 November 2024) | For RSA, ECDSA, DH, ECDH and so on, those at 112 bits of strength are deprecated after 2030 and disallowed after 2035; those at 128 bits or more are disallowed after 2035[Ref. 2] | DraftNot yet confirmed; no final version was found at the checking date | Describes the treatment in NIST standards and guidelines; this document alone creates no legal obligation for the private sector |
| EU: Coordinated Implementation Roadmap (NIS Cooperation Group, 23 June 2025) | By the end of 2026, the "first steps" and national transition roadmaps; by the end of 2030, high-risk uses completed (no stand-alone use of traditional public-key schemes after that) and software and firmware upgrades quantum-safe by default; by the end of 2035, medium-risk uses completed and low-risk ones as far as feasible[Ref. 12] | A recommendation to Member StatesNot yet confirmed | A roadmap, not a law; a "should" document |
| UK NCSC: migration timelines (20 March 2025) | By 2028, define goals, carry out a full discovery exercise and build an initial plan; by 2031, carry out the early, highest-priority migration and refine the roadmap; by 2035, complete migration of all systems (a small set of rarely used technologies may find this harder)[Ref. 13] | GuidanceNot yet confirmed | Aimed mainly at large organisations, critical infrastructure and companies with bespoke IT |
| Canada: roadmap for the Government of Canada (ITSM.40.001, effective 23 June 2025) | By April 2026 an initial departmental migration plan, with annual progress reports thereafter; by the end of 2031 migration of high-priority systems; by the end of 2035 the rest[Ref. 14] | A requirement and guidance for federal departments | "Completion" means quantum-vulnerable algorithms are disabled, isolated or tunnelled, i.e. the risk is mitigated |
| Japan: interim summary of the National Cyber Office, Cabinet Secretariat (20 November 2025) | Aims to complete the transition of government bodies to PQC in principle by 2035, and to draw up a roadmap in FY2026 (April 2026 to March 2027)[Ref. 15] | A policy direction (interim summary)Not yet confirmed | No published roadmap could be confirmed at the checking date. The scope is government bodies (the draft mentions extension to critical infrastructure and the private sector) |
| Japan: report of the Financial Services Agency study group (26 November 2024) | For high-priority systems, it is desirable, while watching technological progress and overseas regulation, to make PQC algorithms usable by around the mid-2030s[Ref. 18] | A study group report (framed as "desirable")Not yet confirmed | Aimed at deposit-taking financial institutions; the report says the deadline is not fixed and will be reviewed |
Sourced / Not yet confirmed. Dates and content are as stated in each agency's official document (checked 16 October 2026). Because the nature (obligation, recommendation or draft) differs, the earliness or lateness of a date does not indicate a better or worse national stance.
2035 is the target for completion, not the time to start. Looking closely at the timelines, the first milestones are already close: the EU's "first steps" at the end of 2026, the UK's discovery and plan by 2028, Canada's initial plan in April 2026 and the NSA's requirement for new acquisitions in 2027[Ref. 12, 13, 14, 11]. The EU also says information that must stay confidential for 10 years or more should be protected from quantum attacks by the end of 2030[Ref. 12].
4. Where to start: a cryptographic inventory
Every agency's document puts the first step in the same place: knowing where, and which, cryptography you use. The EU roadmap calls creating and maintaining current inventories of assets that perform cryptographic operations and assets that have cryptographic operations performed on them a "no-regret" first move for every entity[Ref. 12]. The UK NCSC asks for a "full discovery exercise" by 2028, including recording the expected lifetime and the value to an adversary of the data held, and checking how data is protected[Ref. 13]. Japan's draft interim summary calls it building a "crypto inventory"[Ref. 17].
Where does cryptography hide?
Public-key cryptography is not only in website encryption. It is used, often where nobody is conscious of it, in the signing of software and firmware, in certificates, VPNs, remote maintenance of equipment, the management of backup keys and inside software components.
What to write in an inventory: an example
An inventory need not be complete from the start. The table below is a fictional example made for this article, a model of the items to record (not a real company or product).
| Asset (fictional example) | Public-key cryptography used | What it protects, and for how long | How easy to update | Priority guide (Fig. 6) |
|---|---|---|---|---|
| Traffic between the company and the cloud | TLS key exchange (elliptic curve) | Formulations and process conditions; 10+ years | Possible by software update | High (Q1) |
| Site-to-site VPN appliance | RSA key exchange | Design data; 15 years | Replacement of the appliance needed | High (Q1, Q2) |
| Firmware signing of production equipment | RSA-2048 signature verification | Equipment safety and quality; 15-year equipment life | Hard to change after shipment | High (Q3) |
| In-house certificate authority (PKI) | RSA certificate signatures | Validity of certificates (some years) | Migration takes long | Medium or higher (Q2) |
| Email signatures | RSA signatures | Some years | Possible by software update | Low to medium (Q4) |
This is not an Our calculation but our commentary (a fictional example). It does not describe any real organisation or product, and the priorities are illustrative.
An information-systems department's inventory tends to start from servers and PCs. But on the floor of materials and process work there is long-lived equipment that is hard to update (production equipment, instruments, control panels and sensors), and the signatures of its communication and updates may rest on public-key cryptography (our commentary). The EU roadmap treats signatures protecting software updates as "high" risk when the migration effort is large, and sets out a path to making quantum-safe software and firmware updates the default by the end of 2030[Ref. 12]. The NSA also puts software and firmware signing first in line for migration[Ref. 10]. Concretely, the inventory work means asking equipment makers about their signature scheme and update plans and, for equipment you build yourself, designing for future replacement.
5. Setting priorities
Not everything can be moved at once. The EU roadmap divides risk into low, medium and high, setting the end of 2030 for high risk and the end of 2035 for medium risk[Ref. 12]. Risk is decided by (1) the quantum weakness of the cryptography, (2) the impact if it is broken and (3) the time and effort of migration; the roadmap explains that this focuses on the parts of the Mosca formula (X + Y > Z) that the organisation itself controls[Ref. 12].
The EU document's illustrations run roughly as follows: uses protecting confidentiality are medium or high risk; if confidentiality must be kept for 10 years or more and an attack after 10 years would still have significant impact, high; if the migration effort is large (more than 8 years), medium or high; if the effort is large and the impact large too (for example securing software updates), high[Ref. 12].
Migration is not a one-off task. New schemes too may be found weak in the future (previous article: two schemes broken in 2022, and examples of implementation holes). The UK NCSC advises using the migration as an opportunity to build broader cyber resilience[Ref. 13]. Japan's draft interim summary also lists information systems whose cryptographic part can be swapped quickly (crypto-agility)[Ref. 17]. The EU roadmap calls the ability to replace cryptographic components "cryptographic agility", but cautions that this is distinct from a requirement to negotiate the cipher suite during protocol execution, which, done carelessly, often leads to downgrade attacks[Ref. 12].
6. Hybrid or PQC alone / crypto-agility
As seen in the previous article, a hybrid uses a classical scheme and PQC together so that the key stays safe if one is broken. In a migration, should a hybrid or PQC alone be used? Agencies' views differ.
| Agency | What it says about hybrids | Document |
|---|---|---|
| US NSA | Because it has confidence in the CNSA 2.0 algorithms, it will not require NSS developers to use hybrid products. Product availability and interoperability may nevertheless lead to hybrids. It also says hybrids add complexity and a second transition later (dropping the classical algorithms). Where the large ML-KEM-1024 public key cannot easily be placed directly, as in IKEv2, it expects to use the solution standardised in the IETF (a small key establishment followed by a larger, encrypted one) | CNSA 2.0 FAQ v2.1 (December 2024)[Ref. 11]Sourced |
| EU (NIS Cooperation Group) | When migrating, it recommends using standardised and tested hybrid solutions whenever feasible and suitable; where RSA or a discrete-logarithm mechanism is used, replacement by a standardised hybrid that includes PQC should be considered | Coordinated Implementation Roadmap (June 2025)[Ref. 12]Not yet confirmed |
| Japan (government bodies) | Depending on the environment of use, adopting PQC in combination with currently mainstream cryptography, rather than a complete move to PQC, may be considered | Draft interim summary (November 2025)[Ref. 17]Not yet confirmed |
| IETF | Standardised hybrid key agreement for TLS 1.3 (X25519MLKEM768 and others) in RFC 10024 (Standards Track, August 2026) | RFC 10024[Ref. 5]Sourced |
Sourced / Not yet confirmed. The choice is not about which is right, but about what is protected, regulation and interoperability. Each agency's view is guidance for its own scope (NSS, EU Member States, government bodies).
The big impact of quantum computers falls on public-key cryptography, while shared-key ciphers are seen as quantum-resistant given sufficient key length. The NSA FAQ says symmetric algorithms are considered secure provided the key size is sufficiently large, and that the CNSA 2.0 symmetric algorithms are essentially the same as CNSA 1.0 (AES with 256-bit keys)[Ref. 11]. Japan's draft interim summary likewise names public-key cryptography as the main object of migration and says to consider moving to stronger key lengths for shared-key ciphers and hash functions[Ref. 17]. But where the key of a shared-key cipher is shared using public-key cryptography, that sharing part becomes an object of migration.
The EU roadmap says every organisation must start a dialogue with the suppliers of its products and services because the transition depends on them[Ref. 12]. For a materials or process company, the concrete work is questions to equipment makers, instrument makers, cloud services and customers' systems (our commentary). For example: (1) what public-key cryptography is used for, (2) the plans and timing for supporting the PQC standards (FIPS 203, 204, 205 and others), (3) the firmware signature scheme and update method, (4) the procedure and cost for swapping the cryptographic scheme and (5) the validation status of supported products (NIAP, CMVP and so on). A party that cannot answer is itself information about risk.
As for using quantum key distribution (QKD) in place of this migration, as seen in the earlier article on QKD, the NSA does not generally consider it a practical security solution for protecting national security systems against quantum computers and says NSS owners should not use or research QKD without consulting the NSA[Ref. 11]. Japan's draft interim summary notes that, depending on the environment of use, introducing QKD may also be considered[Ref. 17].
7. How to read evaluations and standards
Progress in migration is measured by (1) deadlines (whose, and of what nature), (2) usable standards (FIPS, RFCs and so on), (3) checks on supporting products (validation schemes) and (4) the inventory and prioritisation. For (1) see the table of Chapter 3 and for (2) the previous article. Checked 16 October 2026.
| What is assessed | Representative benchmark or method (name, source) | Standards and guidance (NIST, NSA, EU, IETF and others) | Caution in reading |
|---|---|---|---|
| Migration deadlines | Mosca's X + Y > Z (2018)[Ref. 8]Sourced; the Financial Services Agency report explains it with a numerical example[Ref. 18] | NSA CNSA 2.0 (obligation, NSS), NIST IR 8547 (draft), the EU roadmap (recommendation), UK NCSC and Canada (guidance), Japan's interim summary (direction) (table of Chapter 3)[Ref. 11, 2, 12, 13, 14, 15]SourcedNot yet confirmed | Check the nature (obligation, recommendation, draft) and scope; do not compare on dates alone |
| Estimates of when the threat arrives | Global Risk Institute expert survey (2025 edition, published 9 March 2026; 26 experts)[Ref. 6]Sourced | Could not be confirmed (no standard fixes the timing). NSA: it does not know when there will be a CRQC and expert assessments disagree significantly[Ref. 11]Sourced | A survey of opinion is not a forecast. Z is unknown, so shorten X and Y |
| Usable standards | — | NIST FIPS 203, 204, 205 and SP 800-208 (previous article), IETF RFC 10024 and others, ETSI TS 103 744[Ref. 3, 4, 5, 7]Sourced | A standard existing and a product supporting it are different things |
| Checking supporting products | — | The NSA says commercial products in NSS must be NIAP-validated and that validation will generally require CNSA 2.0 compliance. NIST administers the Cryptographic Module Validation Program (CMVP). In Japan, CRYPTREC is evaluating the security and implementation performance of FIPS 203, 204 and 205 in turn (as stated in the draft interim summary)[Ref. 11, 1, 17]Sourced | The number and progress of validations could not be confirmed |
| Inventory and prioritisation | — (no common benchmark could be confirmed) | The "first steps" of the EU roadmap (cryptographic asset management, dependency maps, quantum risk analysis and so on), the discovery of the UK NCSC and Japan's crypto inventory (Chapter 4)[Ref. 12, 13, 17]Sourced | No common criterion of the form "enough once N% is done" was found; an organisation sets its own priorities |
The organisation of the table is Our calculation (arrangement). Numbers, dates and status checked in each agency's official documents (checked 16 October 2026).
Cautions in reading (for materials engineers)
- Look at the "nature" of a deadline: an obligation (the NSA's, for NSS), a recommendation or guidance (EU, UK, Canada) or a draft (NIST IR 8547). Whether a private company has a direct legal obligation depends on its sector and its customers' requirements (our commentary; not legal advice).
- Dates get updated: NIST IR 8547 remains a draft and Japan's roadmap is planned for FY2026. Watch for revisions after the checking date.
- Do not try to guess Z: both the expert survey (GRI) and the NSA say the timing is unknown. Acting to shorten X and Y is more reliable than predicting Z[Ref. 6, 11].
- A standard existing is not the same as your own readiness: even once FIPS exist, migration is not finished until your own equipment and partners support them.
8. Glossary
- PQC (post-quantum cryptography)
- Cryptography based on problems believed hard even for quantum computers.
- CRQC
- A quantum computer large enough to actually break cryptography (cryptographically relevant quantum computer).
- HNDL (Harvest Now, Decrypt Later)
- An attack that stores encrypted data now and decrypts it in the future with a quantum computer.
- Mosca's formula (X + Y > Z)
- The rule of thumb that danger arises when migration years X plus protection years Y exceed years Z until a quantum computer.
- Cryptographic inventory
- A list of where and which cryptography is used.
- Crypto-agility
- The property or design that makes cryptographic components easy to replace later.
- Hybrid approach
- Using a classical scheme and PQC together so that protection survives if one is broken.
- CNSA 2.0
- The set of quantum-resistant cryptographic algorithms the NSA defines for national security systems.
- NSS (national security systems)
- US information systems involved in national security.
- NSM-10
- The US national security memorandum of 4 May 2022, with the goal of mitigating quantum risk by 2035.
- NIST IR 8547
- NIST's draft on moving away from quantum-vulnerable cryptography; deprecation after 2030 and disallowance after 2035 are proposed.
- NIAP and CSfC
- NSA-related schemes for validating and approving products.
- CMVP
- NIST's Cryptographic Module Validation Program.
- CRYPTREC
- Japan's project that evaluates and monitors the cryptography recommended for e-government.
- High, medium and low risk (EU)
- The three levels of the EU roadmap, decided by quantum weakness, impact and migration effort.
- Firmware signing
- A mechanism that confirms by signature that an update of a device's embedded software is genuine.
- Supply chain
- The chain of suppliers of equipment, parts and services; migration depends on it.
- QKD (quantum key distribution)
- Sharing keys using the quantum properties of light; needs dedicated optical links.
- FIPS
- US Federal Information Processing Standards, set by NIST.
- RFC
- Documents on Internet technology, some on the Standards Track and some informational.
9. References (primary sources)
- NIST "Post-Quantum Cryptography" project page, CSRC (checked 16 October 2026) — csrc.nist.gov/projects/post-quantum-cryptography
- NIST NIST IR 8547 (Initial Public Draft) "Transition to Post-Quantum Cryptography Standards" (12 November 2024; comment period closed 10 January 2025; no final version found at the checking date) — csrc.nist.gov/pubs/ir/8547/ipd
- NIST FIPS 203 "Module-Lattice-Based Key-Encapsulation Mechanism Standard" (published 13 August 2024), DOI 10.6028/NIST.FIPS.203 — csrc.nist.gov/pubs/fips/203/final
- NIST SP 800-208 "Recommendation for Stateful Hash-Based Signature Schemes" (October 2020), DOI 10.6028/NIST.SP.800-208 — csrc.nist.gov/pubs/sp/800/208/final
- Kwiatkowski K., Kampanakis P., Westerbaan B. E., Stebila D. (IETF) RFC 10024 "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3" (Standards Track, August 2026) — rfc-editor.org/rfc/rfc10024.html
- Mosca M., Piani M. (Global Risk Institute and evolutionQ) "Quantum Threat Timeline Report 2025" (published 9 March 2026; survey of 26 experts) — globalriskinstitute.org/publication/quantum-threat-timeline-report-2025b/
- ETSI TS 103 744 V1.2.2 (2026-02) "CYBER; Quantum-Safe Cryptography (QSC); Quantum-safe Hybrid Key Establishment" — etsi.org/deliver/etsi_ts/103700_103799/103744/01.02.02_60/ts_103744v010202p.pdf
- Mosca M. "Cybersecurity in an Era with Quantum Computers: Will We Be Ready?", IEEE Security & Privacy 16 (5), 38–41 (2018), DOI 10.1109/MSP.2018.3761723 — doi.org/10.1109/MSP.2018.3761723
- The White House National Security Memorandum 10 (NSM-10) "Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems" (4 May 2022; archived White House page) — bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/nation
- NSA "Announcing the Commercial National Security Algorithm Suite 2.0", Cybersecurity Advisory PP-22-1338, Ver. 1.0 (September 2022). The official media.defense.gov copy was not reachable from our environment; we read an Internet Archive copy — web.archive.org/web/2026/https://media.defense.gov/2025/May/30/2003728741/-1/-1/
- NSA "The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ", Cybersecurity Information Sheet PP-24-4014, Ver. 2.1 (December 2024). Read through an Internet Archive copy of the official media.defense.gov file — web.archive.org/web/2026/https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/
- NIS Cooperation Group (EU Member States, supported by the European Commission) "A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography" (published 23 June 2025; document of 17 pages) and the Commission page — digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-tran
- NCSC (UK) "PQC migration timelines" (guidance, version 1.0, published 20 March 2025) — ncsc.gov.uk/guidance/pqc-migration-timelines
- Canadian Centre for Cyber Security "Roadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)" (effective 23 June 2025) — cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-c
- National Cyber Office (NCO), Cabinet Secretariat, Japan Announcement of the interim summary "Transition to Post-Quantum Cryptography (PQC) in Government Bodies" (20 November 2025) (in Japanese) — cyber.go.jp/pdf/press/20251120_PQC_chukantorimatome.pdf
- Cabinet Secretariat, Japan Page of the inter-ministry liaison meeting on the use of PQC by government bodies, with the interim summary and the list of meetings (in Japanese; checked 16 October 2026) — cas.go.jp/jp/seisaku/pqc/index.html
- Cabinet Secretariat, Japan Draft of the interim summary of the transition to PQC in government bodies (November 2025; material 1 of the second meeting) (in Japanese) — cas.go.jp/jp/seisaku/pqc/dai2/shiryo1.pdf
- Financial Services Agency (FSA), Japan Report of the study group on PQC for deposit-taking financial institutions (26 November 2024) (in Japanese) — fsa.go.jp/singi/pqc/houkokusyo.pdf
10. Claim-to-source audit
| Claim in the text | Basis | Category |
|---|---|---|
| The definition of HNDL (storing encrypted data and decrypting it once decryption becomes possible); the statements on migration, crypto inventory, crypto-agility and that QKD may be considered; the statement that about 20 years passed from the proposal of RSA to its wide adoption; the direction of aiming at 2035 | Draft interim summary of the Cabinet Secretariat (November 2025) Reference 17 https://www.cas.go.jp/jp/seisaku/pqc/dai2/shiryo1.pdf | Sourced |
| Japan's policy to aim at completing the PQC migration of government bodies in principle by 2035 and to draw up a roadmap in FY2026 | National Cyber Office announcement (20 November 2025); the liaison meeting page (checked 16 October 2026) Reference 15 https://www.cyber.go.jp/pdf/press/20251120_PQC_chukantorimatome.pdf Reference 16 https://www.cas.go.jp/jp/seisaku/pqc/index.html | SourcedNot yet confirmed |
| The Financial Services Agency report: X + Y > Z; the example of 10 years of migration and 20 of protection making 30; HNDL is effective against key exchange and has hardly any effect on authentication; high-priority systems by around the mid-2030s; the deadline is not fixed | Financial Services Agency report (26 November 2024) Reference 18 https://www.fsa.go.jp/singi/pqc/houkokusyo.pdf | SourcedNot yet confirmed |
| Title and bibliography of Mosca (2018) on whether we will be ready in an era with quantum computers | Bibliographic data (confirmed through Crossref) Reference 8 https://doi.org/10.1109/MSP.2018.3761723 | Sourced |
| NSM-10 (4 May 2022): the goal of mitigating quantum risk as far as feasible by 2035; annual delivery by federal agencies of inventories of their IT systems | Archived White House page Reference 9 https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2022/05/04/national-security-memorandum-on-promoting-united-states-leadership-in-quantum-computing-while-mitigating-risks-to-vulnerable-cryptographic-systems/ | Sourced |
| NSA CNSA 2.0 (v1.0, September 2022): software and firmware signing preferred in 2025 and exclusive in 2030, timelines for other uses, use of LMS and XMSS | NSA advisory (Internet Archive copy) Reference 10 https://web.archive.org/web/2026/https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF | Sourced |
| NSA FAQ (v2.1, December 2024): new acquisitions from 1 January 2027, phase-out by 31 December 2030, mandate on 31 December 2031, the 2035 goal, the position of not requiring hybrids and the IKEv2 example, treatment of shared-key ciphers, the timing of a CRQC being unknown with expert assessments disagreeing, not regarding QKD as a practical means, and NIAP validation | NSA FAQ (Internet Archive copy) Reference 11 https://web.archive.org/web/2026/https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF | Sourced |
| NIST IR 8547 initial public draft (12 November 2024): deprecation after 2030 and disallowance after 2035 for RSA, ECDSA, DH, ECDH and others; no final version found at the checking date; the 2035 statement on NIST's PQC page and its administration of the module validation program | NIST pages and the text of the draft Reference 2 https://csrc.nist.gov/pubs/ir/8547/ipd Reference 1 https://csrc.nist.gov/projects/post-quantum-cryptography | SourcedNot yet confirmed |
| The EU roadmap: first steps by end 2026, high risk by end 2030, medium and low risk by end 2035, examples of risk classification (confidentiality of 10+ years, migration over 8 years, update signatures), information to be kept 10+ years protected by end 2030, the hybrid recommendation, the caution on crypto-agility and downgrade attacks, inventory, dependencies and the supply chain | The Commission page and the text of the roadmap (23 June 2025) Reference 12 https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography | SourcedNot yet confirmed |
| UK NCSC: targets for 2028, 2031 and 2035, discovery, recording the lifetime and value of data, spanning several leadership cycles at significant cost | NCSC guidance (20 March 2025) Reference 13 https://www.ncsc.gov.uk/guidance/pqc-migration-timelines | SourcedNot yet confirmed |
| Canada's government roadmap: an initial plan in April 2026 with annual reports, end 2031, end 2035, and the meaning of completion | Canadian Centre for Cyber Security document (effective 23 June 2025) Reference 14 https://www.cyber.gc.ca/en/guidance/roadmap-migration-post-quantum-cryptography-government-canada-itsm40001 | SourcedNot yet confirmed |
| The GRI 2025 report (published 9 March 2026): a survey of 26 experts | GRI page Reference 6 https://globalriskinstitute.org/publication/quantum-threat-timeline-report-2025b/ | Sourced |
| RFC 10024 (Standards Track, August 2026), FIPS 203, SP 800-208 and ETSI TS 103 744 V1.2.2 (February 2026) are the standards for PQC and hybrids | Each document (confirmed in the previous article) Reference 5 https://www.rfc-editor.org/rfc/rfc10024.html Reference 3 https://csrc.nist.gov/pubs/fips/203/final Reference 4 https://csrc.nist.gov/pubs/sp/800/208/final Reference 7 https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.02.02_60/ts_103744v010202p.pdf | Sourced |
| The X, Y and Z examples of Fig. 2 and the table (X = 10, Y = 20, Z = 10, 15, 20 and so on) and the X + Y judgement | Our calculation (applying Mosca's formula; the values are illustrative assumptions) | Our calculation |
| The example inventory table (fictional), examples of where cryptography hides, the priority figure, the materials engineer's viewpoints (estimating Y, the blind spot of equipment and firmware, a questionnaire for partners), the classification of deadlines by nature (obligation, recommendation, draft), and the way agency views are set side by side | Our organisation and commentary based on published material; not views stated by the bodies concerned | Commentary |
| The contents of Japan's roadmap, whether there is a legal obligation for private companies, the number of validations, any prediction of when quantum computers will break cryptography, procedures for breaking cryptography, and legal or investment advice | This article does not state these (they could not be confirmed or are outside its scope) | Commentary |
| Figures 2-6 are explanatory diagrams, not observations of real data; Figure 1 is an ImageGen-generated conceptual illustration | Note by this article | Commentary |
Last updated: 16 October 2026. Sources are limited to primary material (official documents of NIST, the NSA, the European Commission, the UK NCSC, the Canadian Centre for Cyber Security, the Cabinet Secretariat and Financial Services Agency of Japan; IETF RFCs; a peer-reviewed paper; and a Global Risk Institute report). The NSA's official files were not reachable from our environment, and we read Internet Archive copies. Deadline dates are as stated in each document at the checking date. We do not state the contents of Japan's roadmap, whether there is a legal obligation for private companies, the number of validations, or "when quantum computers will break cryptography", because these could not be confirmed or cannot be asserted. All figures are explanatory concept diagrams or charts including our calculation; Figure 1 is an ImageGen-generated conceptual illustration. This article is neither legal nor investment advice, and not an explanation of how to break cryptography.