Planning and Executing Your PQC Migration: From Pilots to Full Rollout

Last updated on September 21st, 2026 at 07:51 am

Enterprise security currently faces a silent, pressing need. Quantum computers that can break modern RSA and elliptic-curve encryption aren’t available yet. Still, the economic risk is high enough that governments, banks, and cloud providers have already started taking action. The problem? Most organizations don’t realize they need to migrate to post-quantum cryptography.

This guide approaches it in a more tangible form of a staged implementation plan – where owners, deliverables, and decision points are presented at each stage. It is based on the four categories of PQCC migration, TNOs’ three-step migration model, and the NCCoE lab testing model. You are a security architect mapping the roadmap; a CISO making the budget case; a developer who recently received this project; this is the implementation plan you have been searching for.

Why PQC Migration Can’t Wait Until Quantum Is “Here”

The Harvest Now, Decrypt Later Problem

This is what most people fail to realize: today, your adversaries don’t need a quantum computer to use your encrypted data tomorrow. Such attacks as harvest now, decrypt later are already occurring – in which channel encrypted traffic is recorded and saved until a sufficiently powerful quantum system is developed that can read it.

In the case of any organization that works with long-lasting secrets, with health records, financial contracts or government credentials, intellectual property, the exposure window has already begun.

Federal timelines underscore this urgency. US government agencies aim to complete high-priority system migrations by 2031 and achieve 100 percent completion by 2035. That sounds far off. But it is, because enterprise cryptographic inventories are complicated.

The PQCC Roadmap: Four Categories, One Concrete Plan

The Post-Quantum Cryptography Coalition (PQCC) is structured to have a four-functional migration roadmap. These are not abstraction boxes; they map directly to phases, groups, and outputs.

Phase 1- Preparation: Get the Right People in the Room

The organization must establish governance before touching any given system.

Appoint a Migration Lead. This is usually a top-level security architect or CISO delegate with cross-functional authority. The migration lead owns the roadmap, coordinates vendors, and communicates progress to executive leadership. PQC migration goes adrift without a named owner.

Align stakeholders early. Migration is a PQC that cuts across IT, legal, procurement, compliance, and business operations. I have applied stakeholder mapping at the early stages of infrastructure projects, and the results are consistent: legal and procurement are nearly always the last to learn. When algorithm options or regulatory submissions influence vendor contracts, they are most likely the source of hold-ups.

Migration objectives should be clearly stated. Associate business risk with goals, not technical compliance. Example goal structures:

Phase 1: Migration Phase deliverables. Migration resulted in the following Phase 1 deliverables: a migration lead appointment memo, a stakeholder RACI matrix, documented migration goals based on business risk, and an initial project charter.

Phase 2 – Baseline Understanding: Know What You’re Migrating

This process is commonly referred to as the cryptographic inventory, but it is the step most often underappreciated in the overall migration process.

Most enterprises have no single source of truth for cryptography. It is dispersed across TLS certificates, code-signing pipelines, database encryption, and VPNs configured in hardware security modules (HSMs), and embedded in firmware.

In my experience reviewing enterprise security audits, most organizations find 30-40% more cryptographic dependencies than they estimated when they run a suitable automated discovery tool.

Inventory assurance: That should be what the inventory catches:

• Type of algorithm (RSA, ECC, AES, and so on) and the key size.
• The location at which it is used (protocol, system, application)
• Classification of data sensitivity.
• Holding time (important in prioritization)
• Complexity rating, system owner, and update.
• Vendor dependency check (third party or not)

NCCoE discovery guidance and Open Quantum Safe open-source projects help with automated scanning. This stage directly provides the prioritization output for Phase 3.

Phase 2 Products: A complete cryptographic asset inventory (preferably structured in a CMDB or other similar format), dependencies, risk rating of each system, and a vendor communication history.

Phase 3 – Planning & Execution: Prioritize, Pilot, Then Scale

It is the most massive stage – and the one that will gain the most by division into three sub-stages, which are prioritization, pilots, and phased rollout.

3a. Prioritizing Systems and Data

Not all things move simultaneously. The objective is a risk-based plan that migrates the highest-risk systems in an entrepreneurial way.

High-priority signals:

• Secrets immortal: Data encrypted today, which shall remain a secret for over 10 years (health records, financial instruments, government classified data).
• Systems with high business impact: Core transaction systems, infrastructure of identity and authentication, software or contract signing systems.
• External exposure: all services that negotiate cryptography protocols across open networks (TLS endpoints, API, VPNs)
• Compliance requirements: Systems under FISMA, HIPAA, PCI-DSS, or industry-specific compliance requirements.

By approximately 2031, federal direction will be issued on high-priority system migration. Organizations replicating that schedule must finish the inventory and pilots pre-2028 to allow time to reset and fix systems.

Knowing the intersection of cryptographic infrastructure with edge deployments is also relevant here, as what edge computing does to distributed trust chains is more surface area for migration that will have to be computed by central IT teams.

3b. Pilots, Interoperability, and Performance Testing

The NCCoE lab testing model is the appropriate framework to use before anything goes to production. Under NIST SP 1800-38, they are tasked with establishing isolated test environments to describe how PQC algorithms behave under realistic conditions.

What pilots should measure:

• Key and signature sizes: CRYSTALS-Kyber (renamed ML-KEM) and CRYSTALS-Dilithium (ML-DSA) have much larger key and signature sizes than RSA or ECC. In my experience, teams always underestimate the bandwidth and memory costs of larger handshakes, especially on constrained devices.
• Latency cost: Some post-quantum algorithms are heavier in key generation and signature verification. Compare with your real traffic profiles, not some generic ones.
• HSM and embedded device compatibility: Many hardware security modules and embedded devices do not support the finalized NIST PQC algorithms. This is a major gap. Run tests, then commit to rollout programs.
• Hybrid mode interoperability: A transitional change should implement classical and PQC algorithms simultaneously (hybrid TLS, etc.). Check that your infrastructure can negotiate hybrid handshaking with PQC-capable infrastructure and shared infrastructure with legacy infrastructure.
• Failure mode behavior: The behavior occurring when a PQC-enabled service is ready to connect to a legacy endpoint? Test graceful degradation, rather than success.

Pilot scope recommendation: Select one service facing the outside and one flow of authentication inside. Test them in a 90- 60-day test before moving forward.

This also applies to specific areas. What Are Digital twins? In industry and manufacturing, digital twins require secure communications between real and virtual models – those cryptographic layers should be piloted as well as traditional IT systems.

3c. Phased Rollout Patterns

When pilots approve performance and interoperability, rollout starts – not simultaneously.
First recommended patterns of phasing:

By business line: Choose one line of business/ product line to migrate at a time. This restricts the blast radius if anything goes awry and makes rollback decisions cleaner.

In order of protocol: Migrate TLS endpoints, then code signing, followed by storage encryption, then device/embedded systems. The protocol-level phasing leverages existing change management channels.

By geographic area: For multinational organizations with regional IT governance, a regional rollout could comply with local regulatory requirements and local change windows.

Prerequisites of change management per rollout wave:

• Identify rollback trigger (defined failure rate or time limit of latency)
• Intentions to modify any protocol before doing so.
• Concurrent operation times whereby old and new configurations are used within the same period.
• Record the configuration at the beginning and the end of every change wave.

The PQC handbook of TNO specifically mentions that a rushed migration introduces new vulnerabilities, especially in areas with major management gaps and improperly configured hybrid configurations. The translation from one surface to another is a risk surface. The dGovernance discipline bridges that gap.

Outputs of Phase 3: Pilot test documents (performance measurements, interoperability measurements, failure mode specifications), priority chart, algorithm choice reasons, rollout plan by waves with wave owners, and rollback plan.

Phase 4 – Monitoring & Evaluation: Migration Is a Program, Not a Project

This is one of the vivid indicators of the roadmap process created by PQCC: PQC migration is not a single achievement. It’s an ongoing program.

The latest NIST standards (FIPS 203, 204, 205) represent the initial stage, and the post-quantum world is still being built. Other algorithms are under consideration. Hybrid approaches will be developed. The regulatory requirements will be updated.

The format of continued monitoring:

• Cryptographic agility monitoring: Can the organization change algorithms quickly if a vulnerability is found in ML-KEM or ML-DSA? Crypto-agility is not only a design principle, but should be tested once a year.
• Monitoring key and certificate lifecycle: PQC certificates require the same tracked expiry, rotation processes, and revocation as classical certificates, but you should be aware of the increased key sizes, which impact storage and bandwidth.
• Tracking vendors and supply chains: PQC preparation varies widely across vendors. A supplier that was capable of PQC in the pilot phase might have revised their implementation. Follow up on vendor status.
• Regulatory compliance calendar: Map internal migration milestones to regulatory deadlines. The federal 2031 target for high-priority systems creates an externally forced capability.

This test layer is also linked to Best Edge Computing Devices tests of hardware in a natural manner – since edge hardware refreshes, customers must be verifying that PQC tests are supported in software and that secure enclave software is in place before they are purchased.

Outputs of Phase 4: Seasonal reports on migration status, test outcomes of crypto-agility, register of those vendors PQC-ready, and revised cryptographic version (re-run discovery after every year) and regulatory alignment.

Governance Structure: Who Owns What

Unscrupulous migration is not successful. The following is a convenient model of governing:

The status dashboard is a product of the migration lead that should be seen by executive leadership; a technical team is not sufficient. Migration status is required in decisions on the budget, renewal of vendor contracts, and regulatory filing, and that information should always reach up the pyramid.

Trust Boosters: Two External Resources Worth Reading

Two outside sources are recommended to those teams who would like to go deeper on the technical and organizational side:

1. NIST SP 1800-38 (Preliminary Draft) NCCoE. This is publicly available and provides most of the implementation guidance on PQC migration in an enterprise setting. It discusses discovery, testing methodology, and migration patterns in enough depth to directly inform pilot design.
   To be used as anchor text: NIST NCCoE Post- Quantum Cryptography Migration Practice Guide. Link: https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38b-preliminary-draft.pdf
2. TNO PQC Migration Handbook (v2.0). The TNO handbook’s strengths are in organizational and governance areas, namely stakeholder alignment, risk controls during transition, and crypto-agility architecture. It is more accessible to a non-cryptographer audience compared to the NIST technical spec.
   Anchor clinical sample to be applied: TNO Post-Quantum Cryptography Migration Handbook Link: https://ir.cwi.nl/pub/32988/PQCmigrationhandbookEN2.0.pdf

Both are free to obtain and aimed at practitioners rather than scholars.

The Bottom Line

The Planning and Executing Your PQC Migration manuals focus more on program management than on cryptography. ML-KEM and ML-DSA are the selected technical algorithms for key encapsulation and digital signatures, respectively, and SLH-DSA is a stateless digital-signature backup option. The standards are complete, as per NIST.

The only thing left is the harder part: understanding what you have, what to move, running aged pilots, and planning the rollout without creating new loopholes.

Start with governance. Run a real inventory. Pilot before you roll out. And plan this as a multi-year program with quarterly checkpoints – not a project with a one-ship date.

Organizations that beat the curve today will have a decade to change their security posture. Those that wait will migrate under the gun, with less time to test and much more exposure in the process.

Pranay Sai Aduvala

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!