Last updated on September 21st, 2026 at 08:09 am
It’s a threat that is right in your encrypted archives at this very moment – and it does not have to do anything today.
Enemies will soon reap encrypted information in bulk, store it latently, and bide their time. This strategy is called harvest now, decrypt later. Once a quantum computer capable of cryptanalytic significance is developed (with enough strength to break RSA and elliptic curve cryptography), years of intercepted data can be decrypted overnight.
Organizations are confronted with classified records, monetary dealings, enduring identity releases, and confidential communications that they had thought were safely secured in an encrypted database being suddenly turned upside down.
The painful reality is that the quantum is still years off is no excuse to postpone. When your organization has a confidentiality requirement of five years or more for the data it handles, that data is already compromised today, as the harvest has already begun.
NIST realized this and acted expeditiously. It completed the first generation of post-quantum cryptographic standards, FIPS 203, 204, and 205, in 2024, which provided the industry with an implementation of the first concrete and easily implementable algorithms. This publication eliminated the final viable justification for listing PQC under the watchlist column.
Governments are moving into hard times now. Canada’s quantum-safe migration roadmap recommends having departmental migration plans in place by April 2026, finalizing high-priority system migrations by 2031, and fully migrating the remaining systems by 2035.
The European Union, the United States, and others are moving at the same pace, converging into the same phasing schedule. Although your organization may not have these jurisdictions, these 5- to 10-year migration timeframes are more or less universally agreed as the timeframe for realized large-scale cryptographic migrations.
2026 isn’t the deadline. It is the most realistic starting point to meet the deadline.
Table of Contents
The Quantum Threat and PQC Basics – What Security Teams Actually Need to Know
Quantum computing subverts public-key cryptography in a certain algorithmic attack. Shor’s algorithm was executed on a quantum computer of high enough power to factor large integers and break discrete logarithm problems in a limited amount of time. That kills the mathematical basis of RSA, Diffie-Hellman, and elliptic curve cryptography (ECC) – the keys to the encryption of most current encrypted communications, digital signatures, and key exchanges.
Symmetric cryptography, e.g., AES, is another thing. Grover’s algorithm provides quantum computers with a quadratic speed-up over symmetric ciphers. Still, the countermeasure is simple: to deny the algorithms their protection, increase the key length (say, AES-128 to AES-256)—no rearchitecting required.
Post-quantum cryptography addresses key publicity by replacing RSA and ECC with algorithms based on mathematical problems quantum computers cannot solve efficiently. The concluded standards of NIST provide two major families:
Key Encapsulation Mechanisms (KEM): Key exchange. FIPS 203 codifies ML-KEM (previously CRYSTALS-Kyber), a lattice-based scheme and the main alternative to classical key exchange protocols.
Digital Signature Schemes: These provide authentication and integrity. The FIPS 204 standardizes ML-DSA (CDIL to CRYSTALS), and the FIPS 205 standardizes SLH-DSA (SPHINCS+). They displace RSA and ECDSA signatures in code signing, certificate authority, and authentication systems.
NIST Post-Quantum Standards Explained: KEMs and Signatures further divides how these algorithms work and where they apply best; that article covers the cryptographic properties, performance/cost considerations, and application scenarios for each standard.
Global Roadmaps and Deadlines Security Teams Should Map Against
The schemata are no longer existential. Concrete, as in phases of migration, have been published by various governments and standards organizations – and unorganized organizations who have not matched internal planning to external milestones are already falling behind.
One of the most detailed public structures is Canada’s PQC Migration Roadmap. It establishes three specific milestones to be achieved by April 2026. It includes initial departmental migration plans, high-priority and high-impact systems to be migrated by 2031, and the remaining systems to be migrated by 2035.
The architecture follows the same staged approach advocated by the Post-Quantum Cryptography Coalition (PQCC): preparation, inventory, planning, execution, and monitoring.
The United States National Cybersecurity Strategy and the NSA’s CNSA 2.0 suite are pressuring national security systems, and by 2025, software and firmware must be PQC-supported. By 2030 and beyond, the network equipment and legacy systems must come on board. NIST NCCoE has posted migration guidance in NIST SP 1800-38 to help organizations operationalize these transitions.
The European Union coordinated the PQC transition by releasing an implementation roadmap, and ENISA released a dedicated PQC integration study on how post-quantum standards interact with existing security frameworks in member states.
The common use of all these frameworks is a 5-10 year implementation plan, with planning activities packed into 2025 and 2026. Companies that use the end date (2031, 2035) as the planning date, instead of the execution date, will find themselves cramming years of intricate migration work into a shrinking time slot.
These timelines should serve as calibration points even in organizations outside these three jurisdictions. Migration complexity is real; the discovery stage is always underestimated, and the dependency graphs within the current cryptographic infrastructure are longer than most security teams anticipated.
Your PQC Migration Phases – Aligned With Official Roadmaps
All four-category roadmaps from the PQCC and TNO PQC Migration Handbook andthe NIST NCCoE migration project follow the same high-level phase architecture. This structure is then organized into an operational framework.
Phase 1 – Preparation and Quantum-Vulnerability Diagnosis
Organizations need a governing body before starting technical work. This step focuses on building the internal systems that will support migration in a multi-year implementation.
Select a single migration head – owner of crypto or veteran security architect who can make decisions on behalf of faculties. Build the stakeholder group (security, compliance, legal, procurement, and business unit representatives) that owns systems with cryptographic dependencies. Determine the risk the organization is prepared to take regarding quantum exposure (i.e., sensitive data that lasts longer than a year).
Initial quantum-vulnerability diagnosis: This stage also entails an initial high-level determination of the types of systems that tend to have RSA or ECC dependencies before the detailed inventory begins. The output does not deliver a list of all asset components; it is a knowledgeable scope statement that influences how Phase 2 is resourced.
As a more comprehensive model of threat modeling including risk classification at this level, see Quantum Threat 101: Why RSA and ECC Won’t Last.
Phase 2 – Cryptographic Inventory and Baseline Understanding
This is where most teams find the migration is even bigger than expected. Cryptographic dependencies span a broader surface than security teams can typically monitor, e.g., TLS configuration, certificate authority, code-signing pipelines, SSH deployment, VPN infrastructure, database encryption layers, IoT and embedded systems, and third-party software libraries.
The intent of such a phase is a Cryptographic Bill of Materials (CBOM) – a formal listing of all cryptographic assets, the algorithm that they employ, the key length, and the sensitivity designation of the data they are protecting. The CBOM then drives prioritization for the next phases.
Discovery tooling, which I find, always counts cryptographic usage in custom applications and, in legacy systems, generally undercounts cryptographic calls, since they are usually not called from a standard library. Manual verification and developer interviews aren’t ingredients, but they’re needed to make it complete.
A more realistic approach to creating and maintaining a CBOM is available at Cryptographic Inventory and Quantum-Vulnerability Diagnosis.
Phase 3 – Planning and Execution
Using a repository, the planning process then turns the discovery findings into a prioritized migration plan. The criteria for priority involve:
- Sensitivity and longevity (high-sensitivity data last). The first data type that comes to mind is sensitive in nature (high sensitivity) and long-lived.
- System urgency and exposure (high urgency for internet-facing systems)
- Complexity of dependency (dependencies with many cryptographic dependencies take more time to lead time)
- Vendor and third-party fitness (it is as fast and slow as the slowest dependency)
The group of pilot projects needs to target a representative high-priority system – one complicated enough to expose the issues in integration, but small enough to finish and test between specified intervals. Hybrid cryptographic configurations that pilots can test are easy to run during transition, with both classical and post-quantum algorithms running simultaneously.
Rollout planning should account for performance differences. Classical schemes consume less overhead than lattice-based KEMs; however, signature algorithms such as SLH-DSA have larger key and signature sizes, so they impact bandwidth-limited functions. It is not a choice to test under production loads and then roll out.
Planning and Executing Your PQC Migration: From Pilots to Rollout outlines detailed execution structures, including prioritization methodology, vendor engagement, and rollout order.
Phase 4 – Monitoring, Crypto-Agility, and Continuous Alignment
Migration completion does not establish itself. The PQC topography will change – NIST has indicated that it is possible to standardize more algorithms, and cryptanalysis against existing candidates is ongoing. Organizations that incorporate crypto-agility into their design early on can transition cryptographic algorithms without redesigning systems and can adapt to future change without repeating the entire migration process.
Monitoring tasks may include tracking NIST and NCCoE guidance updates, tracking the CBOM as systems are modified, tracking vendor PQC roadmaps for dependencies that are not yet migrated, and ensuring post-quantum configurations remain intact as systems are updated.
The 2026 Migration Checklist – What to Do This Year
The phase framework can be translated into specific 2026 actions as shown in the table below. These are the bare-minimum steps you need to be in a credible migration position by year-end.
| 1 | Appoint PQC migration lead | CISO | Named owner with mandate |
| 2 | Establish steering group | Security + Compliance | Cross-functional team in place |
| 3 | Define scope — classify long-lived sensitive data | Crypto owner | Risk-stratified data map |
| 4 | Launch cryptographic discovery | Security architecture | Initial CBOM draft |
| 5 | Assess vendor PQC readiness | Procurement + Security | Vendor roadmap register |
| 6 | Identify pilot candidate system | Security architect | Pilot scope document |
| 7 | Review applicable regulatory timelines | Compliance lead | Jurisdiction gap analysis |
| 8 | Establish crypto-agility design principles | Architecture team | Design standards update |
The checklist above is only the start of a program plan, not a comprehensive one. Everyone is connected to thorough execution work; discovery alone can take 6 to 12 months in a huge organization. The difference between having a pilot in progress and in discovery at year-end is starting in Q1 2026 versus Q4 2026.
Common Pitfalls – What Early Adopters Learned the Hard Way
The TNO PQC Migration Handbook, as well as the PQCC guidance, are based on initial organizational experiences with the PQC transition. The trends are similar enough that we can treat them as planning assumptions rather than edge cases.
Delay in making a discovery. The cryptographic inventory stage is more expensive and lasts longer than virtually all organizations estimate. Applications written directly, legacy systems, and third-party integrations always create cryptographic dependencies that automated scanning doesn’t detect.
From my experience revising migration programs early on, preliminary discovery estimates should usually be doubled to allow for manual scrutiny and developer interaction. Develop the schedule as a result.
Disregarding constrained machines. The IoT, operational technology, and embedded systems become a unique challenge. Large post-quantum signature schemes can outgrow the memory and processing capabilities of older equipment.
Organizations that treat constrained devices as an afterthought often realize too late in the deployment cycle that much of their environment needs replacement hardware, not a software upgrade. Identify these in the inventory stage and include them in budget and timeline planning.
Pushing flying crew without crypto-agility. Hard-coding post-quantum algorithm options that aren’t designed to be agile generates technical debt and makes later algorithm transitions harder. The crypto-agility architecture cannot be omitted at the pilot stage, but it must be validated then.
Complacency and dependency on vendors. PQC migration relies on vendor coverage at all levels of the technology stack. Vendors do not all share their roadmaps, and some dependencies may not have a post-quantum upgrade path within a timeline that suits organizational needs. PQC vendor preparation analysis should begin in 2026, not when rollout planning starts.
Failure to factor in the precedent of previous migrations. The withdrawal of SHA-1 had bedeviled the industry for more than a decade, even though it was a well-known, focused, and technically simpler move than the mass PQC decommissioning. The move to 1024-bit RSA also lagged several years behind estimated times.
PQC migration is the concept of substituting basic cryptographic primitives on an immensely larger scale. It is reasonable to begin in 2026, with an anticipated completion date of 2031 or 2035. Starting in 2028 is not feasible.
Technical advice on designing hybrid constructions that allow systems to switch between classical and post-quantum modes can be found in Hybrid and Crypto-Agile Strategies: Migrating Without Breaking Everything.
Free Resources Worth Using and How to Leverage Them
The PQC migration research foundation is truly robust, and most of the finest articles are free to access.
Migration planning is primarily covered in NIST1800800by NISTthe NCCoE. It includes discovery methodology, risk prioritization, and integration guidance. It is thick, and even the first drafts are already detailed enough to brief program planning. Consider the NCCoE migration content.
The main open-source project on experimentation with post-quantum algorithms is Open Quantum Safe / liboqs. My evaluation of liboqs showed it is a solid basis for studying algorithm performance before moving to a production version. It supports ML-KEM, ML-DSA, and SLH-DSA, as well as experimental algorithms on openquantumsafe.org.
Cloudflare’s post-quantum TLS experiments provide real-world data on hybrid TLS performance and compatibility with the public internet. Cloudflare has been operating post-quantum key exchange in production systems and reporting results – these can be useful metrics to organizations intending to deploy hybrid TLS. Engineering crews should read their series of post-quantum blogs.
ENISA PQC Integration Study under consideration: an analysis of how post-quantum standards interact with current EU security frameworks would benefit compliance leads operating under European regulations. Accessed on the ENISA publications page.
External Authoritative Related Links: Trust Boosters.
- NIST Post-Quantum Cryptography Standards (FIPS 203/204/205) – this is the main standards reference for any PQC program. Anchor text: “Finalized standards of post-quantum cryptography of NIST.
- PQCA / Open Quantum Safe Project – the industry group that orchestrates open-source PQC tooling and open-source PQC adoption. Anchor text: Post- Quantum Cryptography Alliance and the Open Quantum Safe Project.
Who This Playbook Is For and the Honest Assessment
This guide is built for the people who need to build the plan, not read about the threat. Boards that need CISOs to brief them. Security architects that must scope the migration program. The owners of the CBOM will be crypto. Compliance leaders will have to chart domestic timetables against government standards.
The truth is told: The next stage of cryptographic transition on this scale is post-quantum migration, purportedly the most difficult undertaking the industry has ever ventured into. It involves broader systems, has more durable dependencies, and therefore demands greater sustained organizational commitment than any previous migration. SHA-1 depreciation was less complex, and it took up to a decade. The necessary time will not be shorter because it is scheduled over a longer period on paper.
2026 is a plausible starting point because the standards are no longer in flux, the guidance frameworks have been published, the open-source tooling is operational, and the government timelines are tangible. It’s hard to believe you have to wait for this to become clear, but the clarity is there.
Start the inventory. Appoint the lead. Engage the vendors. The ones that achieve the 2031 milestones will then be the organizations that start structured migration programs in 2026. Those that wait until 2028 will be the regulatory people explaining why they did not.
The article is part of a group of papers describing the entire PQC migration lifecycle. Some of the following articles discuss Quantum Threat 101: Why RSA and ECC Won’t Last, NIST Post-Quantum Standards Explained: KEMs and Signatures, Cryptographic Inventory and Quantum-Vulnerability Diagnosis, Planning and Implementing Your PQC Migration: From Pilots to Rollout, and Hybrid and Crypto-Agile Strategies: Migrating Without Breaking Everything.
Read:
Identity Crisis – Securing Non-Human Identities for AI Agents
Data Privacy in AI-Powered Security Systems: Protecting Privacy While Detecting Threats
I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!
