Post-Quantum Cryptography Migration Roadmap 2026
Post-Quantum Cryptography Migration Roadmap 2026
Post-Quantum Cryptography Migration Roadmap 2026
Post-quantum cryptography migration is no longer something enterprises can leave on a distant technology roadmap. With NIST standards now available, UK migration milestones extending to 2035, and the EU pushing Member States to begin transitioning by the end of 2026, organizations have concrete reasons to start preparing.
A practical post-quantum cryptography migration roadmap starts with discovery not a rushed replacement of every RSA or ECC implementation. Organizations should inventory cryptography, identify long-lived risks, build crypto agility, pilot standardized PQC mechanisms, and migrate priority systems in controlled waves.
What Is Post-Quantum Cryptography Migration?
A post-quantum cryptography migration roadmap is a structured plan for identifying quantum-vulnerable cryptography, ranking affected systems by risk, building crypto-agile architecture, and transitioning priority workloads toward approved quantum-resistant mechanisms.
It reaches far beyond swapping one algorithm for another. Applications, certificates, vendors, hardware, protocols, PKI, key management, testing, procurement, and operational dependencies can all be part of the migration.
From RSA and ECC to Quantum-Resistant Cryptography
RSA and elliptic-curve cryptography (ECC) underpin TLS, PKI, X.509 certificates, digital signatures, authentication, software signing, and key establishment throughout modern IT.
A sufficiently capable cryptographically relevant quantum computer could undermine important asymmetric algorithms used today. Post-quantum cryptography addresses that risk with mathematical approaches designed to remain difficult for both conventional and quantum computers.
That makes quantum-resistant cryptography relevant across SaaS applications, APIs, enterprise PKI, cloud infrastructure, key-management systems, and connected devices.
What a PQC Migration Roadmap Actually Covers
A serious migration program can reach.
Applications and APIs
Cloud infrastructure and SaaS platforms
TLS and certificate environments
Enterprise PKI
Hardware and HSMs
Firmware and embedded systems
Mobile applications
Operational technology
Third-party products and vendors
Software and technology supply chains
Teams already modernizing applications through back-end development or broader web development should treat cryptographic dependencies as architectural components rather than invisible implementation details.
Why Organizations Should Start Preparing in 2026
One reason for early planning is “harvest now, decrypt later” exposure. Information encrypted today could potentially be collected and retained until sufficiently capable quantum technology becomes available.
That matters most when information needs to remain confidential for years. Medical records, financial information, government communications, identity data, intellectual property, and critical-infrastructure information can all have long security lifetimes.
Migration itself can also take years. Legacy hardware, enterprise PKI, embedded devices, supplier dependencies, and procurement cycles rarely change overnight.
NIST finalized FIPS 203, FIPS 204, and FIPS 205 in August 2024. The UK NCSC has warned that large organizations may need roughly 2–3 years for discovery, strategy, and initial planning alone. At EU level, the coordinated roadmap adopted in 2025 calls for Member States to begin transitioning by the end of 2026.
Build a PQC Cryptographic Inventory Before Migrating
Before changing algorithms, find out where cryptography exists.
A PQC cryptographic inventory should identify algorithms, keys, certificates, libraries, protocols, applications, hardware, services, and third-party dependencies. It should also record ownership, the data being protected, business purpose, system lifetime, and likely replacement difficulty.
What Should a PQC Cryptographic Inventory Include?
At minimum, examine.
RSA and ECC keys
TLS endpoints
X.509 certificates
PKI infrastructure
Cryptographic libraries
APIs and authentication mechanisms
Signing systems
Key-management platforms
HSMs
Firmware and embedded devices
Cloud workloads
SaaS products
Vendor-controlled components
API-heavy organizations can incorporate cryptographic discovery into broader API security practices, particularly where authentication, mTLS, certificate management, and signing intersect.
Cryptographic Discovery, CBOMs and Dependency Mapping
Manual spreadsheets can be useful at the beginning, but complex environments often contain cryptography that is difficult to see from a central inventory.
Automated discovery can help identify certificates, libraries, cryptographic dependencies, and implementations distributed across an enterprise estate.
A cryptographic bill of materials, or CBOM, adds useful structure. It provides a record of the cryptographic components used by a product or system and can help teams trace which applications, services, and vendors depend on particular algorithms.
Turn Inventory Data Into Cryptographic Risk Management
An inventory becomes much more useful when it is connected to risk.
For each important dependency, consider recording.
Data sensitivity
Required confidentiality period
Business criticality
External exposure
System lifespan
Migration complexity
Vendor dependency
Replacement or upgrade path
This turns cryptographic discovery into a decision-making tool rather than another static asset list.
Prioritize Post-Quantum Cryptography Migration by Risk
Trying to replace every RSA or ECC implementation simultaneously can create unnecessary cost and operational risk.
Instead, prioritize systems according to data lifetime, consequences of compromise, reliance on vulnerable public-key cryptography, expected system lifespan, and migration difficulty.
Identify “Harvest Now, Decrypt Later” Exposure
Start with information that must remain confidential for many years.
Examples can include healthcare records, regulated financial information, government communications, identity information, intellectual property, and sensitive critical-infrastructure data.
Long-lived confidentiality creates a different risk profile from information whose value disappears quickly.
Rank Systems by Criticality, Data Lifetime and Migration Difficulty
A useful planning model is.
Quantum exposure × data lifetime × business criticality × migration complexity
This should not be treated as a universal mathematical formula. Its purpose is to help decision-makers separate high-impact, long-lived workloads from systems that can reasonably transition through standard technology refresh cycles.
Separate Quick Wins From Long-Lifecycle Systems
Modern, configurable TLS services may offer relatively fast migration opportunities.
Embedded systems, OT, hardware roots of trust, legacy PKI, and vendor-controlled appliances can be considerably harder to change. Those systems may need earlier planning even if their actual migration happens later.
Existing security modernization programs can help. For example, a zero trust strategy may already be exposing shared identity, certificate, authentication, and policy dependencies relevant to PQC.
Make Crypto Agility the Foundation of Your PQC Roadmap
Crypto agility is the ability to replace or adapt cryptographic algorithms across applications, protocols, hardware, software, and infrastructure without unnecessarily disrupting security or operations.
It matters because post-quantum cryptography is unlikely to be the last cryptographic transition an organization faces. NIST’s current crypto-agility guidance, CSWP 39upd1, was updated in June 2026.
What Is Crypto Agility?
Crypto agility reduces the dependence between business functionality and a specific cryptographic implementation.
Instead of hard-coding one algorithm into an application for years, teams build mechanisms that allow algorithms, certificates, keys, and cryptographic providers to be changed through controlled configuration, testing, and deployment.
Design a Crypto-Agile Architecture
Useful architectural patterns can include.
Cryptographic abstraction layers
Centralized cryptographic policy
Automated certificate lifecycles
Modular cryptographic services
Modern key-management systems
Cryptographic observability
Algorithm-independent application design
For custom platforms, back-end architecture and API design are natural places to introduce these controls.
Why Crypto Agility Matters Beyond PQC
Algorithms can be deprecated for reasons other than quantum computing. Vulnerabilities, advances in cryptanalysis, regulatory requirements, and changing standards can all trigger cryptographic transitions.
Crypto agility turns modernization from an emergency replacement exercise into a repeatable operational capability.
Implement ML-KEM, ML-DSA and Hybrid PQC Safely
Implementation should start with standards-based pilots, compatibility checks, and interoperability testing.
NIST’s FIPS 203 specifies ML-KEM for key establishment. FIPS 204 specifies ML-DSA for digital signatures, while FIPS 205 specifies SLH-DSA as a hash-based digital-signature standard.
Understand the NIST PQC Standards
The three standards serve different purposes.
ML-KEM — FIPS 203: Key establishment for creating shared secrets.
ML-DSA — FIPS 204: Lattice-based digital signatures.
SLH-DSA — FIPS 205: Hash-based digital signatures.
This distinction is important. Key establishment and digital signatures solve different security problems, so a migration plan should not treat PQC as one interchangeable technology.
Plan Hybrid Post-Quantum Cryptography Where Appropriate
Hybrid approaches combine classical and post-quantum mechanisms during a transition.
They may reduce dependence on a single new mechanism while ecosystems mature, but hybrid cryptography should not be deployed simply because it sounds safer. Protocol support, standards, interoperability, architecture, and risk should determine whether it is appropriate.
Test PKI, TLS, Certificates and Application Performance
Before broad deployment, test.
Certificate chains
Application interoperability
TLS and API behavior
Latency and bandwidth
Key and signature sizes
Hardware constraints
HSM compatibility
Rollback procedures
Monitoring and observability
The same staged discipline used for EDR implementation and security deployment is useful here: pilot first, measure behavior, resolve incompatibilities, and then expand.
Align US, UK and Germany/EU PQC Migration Roadmaps
The US, UK, Germany, and wider EU share the goal of preparing for quantum-resistant cryptography, but organizations should not treat their guidance or timelines as identical.
NIST provides core US standards and migration guidance, the NCSC has defined UK milestones, and the EU has established a coordinated roadmap for Member States.
USA.
US organizations can anchor technical planning around NIST’s PQC standards, NCCoE migration work, and crypto-agility guidance.
For federal environments and sectors handling long-lived sensitive information, the immediate priorities are cryptographic discovery, dependency mapping, risk classification, and migration planning rather than waiting for a cryptographically relevant quantum computer to appear.
Healthcare organizations should also consider applicable HIPAA and HHS security requirements within their broader security programs, without treating those requirements as standalone PQC deadlines.
NCSC Migration Milestones
The UK NCSC recommends.
By 2028: Complete discovery and build an initial migration plan.
By 2031: Complete the highest-priority migration activities.
By 2035: Work toward full migration.
These milestones are particularly relevant to complex organizations with large technology estates, including financial services, NHS environments, critical national infrastructure, and organizations with bespoke or long-lived systems.
UK GDPR remains an important data-protection consideration, but it should not be described as establishing a specific PQC migration deadline.
Germany and EU.
For Germany, Post-Quanten-Kryptografie planning intersects with BSI guidance and broader European coordination.
At EU level, the European Commission and NIS Cooperation Group roadmap calls for Member States to begin transitioning by the end of 2026. High-risk use cases are expected to transition as soon as possible and no later than the end of 2030.
Organizations in Germany and across the EU should also assess NIS2, DORA, eIDAS/eIDAS 2.0, and GDPR/DSGVO requirements where those frameworks apply.
Again, GDPR itself does not establish a specific PQC migration deadline. It remains part of the wider security and data-protection context.
How to Build a Post-Quantum Cryptography Migration Roadmap
A workable post-quantum cryptography migration roadmap can be organized into three broad phases: discover and assess, prepare and pilot, then migrate and govern.
Discover and Assess
Build the cryptographic inventory and map important dependencies.
Identify long-lived sensitive information, assign system owners, review suppliers, and classify affected systems into meaningful risk tiers.
Do not limit discovery to traditional servers. Cloud, web, mobile, SaaS, embedded, and third-party environments can all contain important cryptographic dependencies. Mobile app development, for example, often spans APIs, platform services, certificates, authentication, and external SDKs.
Prepare, Pilot and Modernize
Build crypto agility before attempting large-scale replacement.
Select priority use cases, assess vendor support, modernize PKI where necessary, and run controlled ML-KEM and ML-DSA pilots. Test hybrid approaches when the architecture, protocol, and applicable standards support them.
Where possible, integrate PQC work with application modernization, identity architecture, certificate management, and existing security programs rather than creating an isolated “quantum project.”
Migrate, Validate and Govern
Move priority systems in controlled waves.
Validate security, performance, and interoperability after each stage. Maintain rollback procedures, document exceptions, and track vendor readiness throughout the program.
Procurement also matters. New products should provide greater transparency into cryptographic dependencies, upgrade paths, and PQC roadmaps.
Finally, keep the cryptographic inventory alive after migration. A mature program should also connect migration governance with established cyber incident response processes so certificate, algorithm, or interoperability failures can be investigated and contained systematically.
Final Thoughts
PQC readiness begins with understanding the cryptography your organization already depends on.
Mak It Solutions can help teams assess application and infrastructure dependencies, modernization priorities, and security architecture before a large-scale migration begins.
Assess your cryptographic inventory and identify your highest-priority PQC migration candidates. Contact Mak It Solutions to discuss a scoped assessment.
Key Takeaways
Start PQC migration with cryptographic discovery and inventory, not mass algorithm replacement.
Prioritize long-lived sensitive information, critical systems, and infrastructure that is difficult to replace.
Build crypto agility so future cryptographic transitions are easier to manage.
Pilot ML-KEM, ML-DSA, and other approved mechanisms before broad production deployment.
Treat PKI, TLS, certificates, APIs, hardware, applications, and vendors as connected migration dependencies.
Align planning with NIST guidance in the US, NCSC milestones in the UK, and EU and Member State guidance where applicable.
FAQs
Q : Which systems should be migrated to post-quantum cryptography first?
A : Prioritize systems protecting information that needs to remain confidential for many years, particularly sensitive healthcare, financial, government, identity, intellectual-property, and critical-infrastructure information. Business impact, system lifespan, and replacement complexity should also influence sequencing.
Q : Can existing PKI support post-quantum cryptography?
A : Some PKI components can evolve toward PQC, but organizations should not assume existing infrastructure will accept new algorithms without changes. Certificate authorities, X.509 profiles, HSMs, applications, signing workflows, and relying parties can all create compatibility constraints, so controlled testing is essential.
Q : What is a cryptographic bill of materials (CBOM)?
A : A CBOM is a structured record of cryptographic components and dependencies within a product, application, or technology estate. It can document algorithms, libraries, keys, certificates, protocols, and related implementations, helping teams locate dependencies affected by a cryptographic transition.
Q : Do organizations need to replace all RSA and ECC certificates immediately?
A : No. PQC migration should be risk-based and staged rather than an uncontrolled replacement of every RSA or ECC certificate. Start with discovery, assess data lifetime and system criticality, evaluate standards and vendor readiness, and then migrate prioritized services through tested deployment waves.
Q : How should third-party vendors be assessed for PQC readiness?
A : Ask vendors which cryptographic algorithms their products use, whether they can provide a CBOM or equivalent inventory, which standardized PQC mechanisms they support, and when PQC-capable releases are planned. Procurement teams should also assess hybrid support, certificate compatibility, firmware dependencies, upgrade paths, testing evidence, and expected product lifetimes.