ARTICLE
·
October 2, 2026

How to Start Building a PQC Readiness Roadmap

Five steps to a PQC readiness roadmap, from organizational alignment to meeting CNSA 2.0 and EO 14412 deadlines.

Executive summary

Building a PQC readiness roadmap includes five core steps: establishing organizational alignment, discovering cryptographic assets, building a structured inventory, prioritizing systems by risk, and reconciling the plan against regulatory deadlines like CNSA 2.0 and Executive Order 14412. The initial phases alone will take many organizations as long as six years to implement, so those working toward 2030-2031 federal milestones cannot afford to wait.

An organization’s move to post-quantum cryptography (PQC) will take time to plan and execute. By planning early to ensure PQC readiness, you set the stage for a successful PQC migration and help avoid an ad hoc, fragmented process.

A PQC readiness roadmap provides compliance, security, technology, and business teams a systematic, phased approach that guides activities proactively across multiple functions.

Without a roadmap, organizations risk:

  • Overlooking layers where algorithms are embedded, whether that’s firmware or certificates
  • Discovering cryptographic dependencies or vulnerable algorithms late in the migration or during a security incident or audit
  • Deploying inconsistent or incompatible cryptographic implementations across applications, infrastructure, and business functions

For compliance consultants, creating a repeatable framework for PQC readiness is also an opportunity to provide a valuable service to clients and expand their engagements.

A typical roadmap comprises the following five core steps.

Step 1: Establish organizational alignment

A Ponemon survey shows that the lack of sponsorship from senior leaders and the board is one of the top barriers to PQC migration. Insufficient budgets and the inability to have an enterprise-wide strategy are also at the top of that list. This indicates that overcoming organizational challenges is just as important as overcoming technical and operational ones.

Organizational readiness starts at the top. Getting to quantum safety competes for resources with various other technology and modernization initiatives. To make PQC migration an organizational priority and allocate budget for it, the board and senior leaders need to understand the operational and financial risk of delaying.

Even with that buy-in secured, a structural challenge remains: No single function within the organization typically owns PQC readiness because the cryptographic assets that need to be modernized are owned by different teams. For example, the identity team may manage certificates or certificate authorities, the network team may manage firewalls and VPNs, and application teams may manage APIs and databases.

However, accountability still requires clear ownership. In addition to designating a program owner to coordinate the roadmap and track progress, you’ll need to identify who needs to be on the cross-functional team responsible for execution.

Step 2: Conduct cryptographic asset discovery

According to the Cybersecurity & Infrastructure Security Agency (CISA), “Organizations are often unaware of the breadth of application and functional dependencies on public-key cryptography that exist within the products, applications, and services widely deployed within their operational environments, leading to a lack of visibility.” That’s why CISA recommends creating an inventory of quantum-vulnerable systems and assets to prioritize the risk.

Asset discovery is an essential part of building an inventory. And historically, many organizations hadn’t had a process, or even a reason, for tracking cryptographic assets.

This activity is often harder than it sounds, especially in large, hybrid environments. As UK’s National Cyber Security Centre notes, one of the challenges of migration is that “particularly in older systems, cryptographic services have evolved over many years in sometimes haphazard ways.”

Cryptographic components are embedded in many layers of the IT infrastructure, scattered across on-premises systems, data centers, branch locations, cloud applications, IoT devices, and user endpoints. Some of these components are easy to miss because they’re in less obvious places, such as firmware, third-party libraries, APIs, and legacy applications.

Step 3: Build a cryptographic inventory

To turn cryptographic asset discovery into an inventory you can actually act on, the assets need to be correlated to hardware, software, and services in your environment. The Canadian Centre for Cybersecurity recommends creating a comprehensive record with more than 10 data points for each system, including details such as:

  • The system component
  • The vendor and product version of each component
  • Cryptographic configurations
  • System dependencies
  • The point of contact for the responsible team

This step provides you the information you need to start conversations with vendors and learn about their plans and timelines for implementing PQC. From these conversations, you’ll gain a better understanding of what systems can be upgraded and which ones will need to be replaced. Engaging vendors early allows for better planning and is another reason why every organization should start building a PQC readiness roadmap now.

A cryptographic inventory is a standing metric rather than a one-time deliverable. Systems change, new applications get deployed, and vendors update their libraries. Automated tools make this process sustainable.

The National Institute of Standards and Technology (NIST) specifically calls out automated tools as the practical way to identify vulnerable algorithms. That includes those used for key establishment and data in transit, which is what a lightweight scanner like Cipherscan checks for.

Step 4: Prioritize systems by risk and data sensitivity

Transitioning to quantum-safe cryptography is a large undertaking that can result in problems related to availability, interoperability, and operational issues. That’s why not everything should migrate at the same time. The quantum threat is also not uniform, and prioritizing which systems are more urgent than others to migrate will help improve security.

The Canadian Centre for Cybersecurity’s own roadmap prioritizes systems that protect confidential data as it travels through public networks because of their exposure to the harvest now, decrypt later threat. Questions to ask beyond that include:

  • How long does the data need to be protected?
  • Does the system already support cryptographic agility?
  • How damaging would the business impact be if that system becomes compromised?

Ranking the cryptographic inventory based on data sensitivity, lifespan, exposure, and business impact will surface the highest priorities. Then, consider additional criteria for further prioritization:

  • The function beyond protecting confidentiality: Is the vulnerable cryptography authenticating users or systems, signing firmware or code, validating certificates, or supporting the establishment of keys?
  • The remediation difficulty: Start sooner on systems that are hard to upgrade and may need replacing, which may require additional planning.
  • System dependencies: Prioritize foundational components and services that many systems depend on, such as identity and shared cryptographic libraries.

Step 5: Reconcile the roadmap against regulatory timelines

Risk-based priorities may not line up with regulatory deadlines. Federal government suppliers need to add another lens to their readiness roadmap: PQC compliance and vendor requirements.

While none of the compliance frameworks that apply to federal contractors have incorporated PQC mandates yet, federal procurement requirements are beginning to establish PQC expectations for covered suppliers.

NIST’s IR 8547, “Transition to Post-Quantum Cryptography Standards,” which is currently in draft, provides a technical baseline for overall PQC readiness. The draft proposes deprecating quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035. For many systems, this transition window can help you sequence migration based on your risk.

Executive Order 14412 builds on that baseline by establishing milestones for federal PQC migration: 2030 for key establishment schemes and 2031 for digital signatures for high-value and high-impact federal systems excluding National Security Systems (NSS).

For NSS, CNSA 2.0 establishes a separate, more prescriptive path. The framework sets technology-specific transition timelines for quantum-resistant cryptography, including:

  • Beginning software and firmware signing transition immediately
  • Using CNSA 2.0 exclusively for software and firmware signing and traditional networking equipment by 2030
  • Updating or replacing custom applications and legacy equipment by 2033

For contractors selling into that space, planning and vendor engagement should already be underway.

Start planning proactively

According to the UK’s National Cyber Security Centre, the initial phases of PQC migration alone can take four to six years. For organizations working toward 2030–2031 PQC migration milestones, this estimated timeline doesn’t leave much room to wait for more clarity.

National cybersecurity authorities emphasize that planning and migration are iterative: You can refine your roadmap over time as requirements, standards, and vendor capabilities evolve.

Organizations that haven’t started their planning activities yet can still prepare proactively if they act now, starting with organizational preparedness. Compliance teams that are yet to make the case for prioritizing PQC to their leadership can use Cipherscan to quickly assess their cryptographic posture. The data provided by this free, simple tool gives you a concrete starting point for technical roadmapping activities.

Start with visibility

Assess your cryptographic posture with Cipherscan before having to wait for a procurement cycle.

Try Cipherscan free →

Written by the team behind Anvil Secure.
Wondering if this applies to you? Check a domain, free, no signup.
Check a domain