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

There is a silent pressing need in the enterprise security currently. The quantum computers that can break the modern RSA and elliptic-curve encryption are not yet available, but the risk is economic enough that the governments, banks, and cloud providers have already started taking action. The problem? The vast majority of organizations are unaware of the point of Post-Quantum Cryptography Migration.

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 migration of PQCC, TNOs model of migration using three steps, and NCCoE lab testing model. You are a security architect mapping the roadmap; CISO making the budget case; a developer who recently received this project then this is the implementation plan that you have been searching.

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 do not require 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.

This urgency is indicated by federal timelines. The US government agencies are aiming to have high priorities of completing system migration by 2031 and 100 percent completion of system migration by 2035. That sounds far off. It is not, because the cryptographic inventories of enterprise 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 as they are directly matched to phases, groups, and output.

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/ delegate of the CISO, having cross-functional authority. The migration lead is the owner of the roadmap and coordinates the vendors and communicates the advancements to the 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 invariance of the results is that legal and procurement are nearly always the last to learn, and when vendor contracts are influenced by algorithm options or regulatory submissions, is most likely the source of hold-ups.

Migration objectives should be clearly stated. Business risk should be associated with goals, as opposed to technical compliance. Example goal structures:

Phase 1: Migration Phasedeliverables Migration resulted in the following Phase 1 deliverables: Migration lead appointment memo, 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 that is always underappreciated in the whole migration process.

There is no single location of cryptography in most enterprises. It is dispersed in TLS certificates, code signing pipelines, database encryption, VPN, which is configured in hardware security modules (HSMs) and embedded in firmware.

I observed in a review of experience I have undertaken of enterprise security audits that most organizations find themselves with 30-40% more cryptographic dependencies than they had already estimated when a suitable automated discovery tool is run.

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)

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

Phased 2 Products A complete cryptographic asset inventory (preferably structured in 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 most by division into three sub-stages, which are prioritization, pilots and phased rollout.

3a. Prioritizing Systems and Data

All things do not move simultaneously. The objective is a risk-based plan with the highest risk systems migrating entrepreneurally.

High-priority signals:

• Secrets immortal: Data encrypted today, which shall remain a secret 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 the open networks (TLS endpoints, API, VPNs)
• Compliance requirements Systems under FISMA, HIPAA, PCI-DSS or industry-specific compliance requirements.

By approximately 2031, there is federal direction on high-priority system migration. The organizations replicating that schedule must have finished the inventory and pilots pre-2028 to allow some time to reset and to fix systems up.

Knowing the intersection of cryptographic infrastructure with edge deployments is also relevant here as the What Edge Computing Does to distributed trust chains is more surface area of migration that will have to be computed by central IT teams.

3b. Pilots, Interoperability, and Performance Testing

The lab testing model of NCCoE is the appropriate outline to use prior to anything goes to production. They have been tasked with their job under NIST SP 1800-38 to establish conditions of isolated test environments to describe the behavior of PQC algorithms under realistic conditions.

What pilots should measure:

• Key and signature sizes CRYSTALS-Kyber (since renamed ML-KEM) and CRYSTALS-Dilithium (ML-DSA) have much larger key and signature sizes, compared to RSA or ECC. As my experience demonstrated, teams always under-estimate the bandwidth and memory costs of bigger handshakes, in particular, on limited devices.
• Latency cost: There are post-quantum algorithms that are heavier in computing the keys and verifying the signature. Compare with your real traffic profiles, not some generic ones.
• HSM and embedded device compatibilities: A large number of hardware security modules along with embedded devices does not support the finalized PQC algorithms of NIST. This is a major gap. Execute a test and then commit to rollout programmes.
• Hybrid mode interoperability: It is best that a transitional change use simultaneous implementation of classical and PQC algorithms (hybrid TLS, etc.). Check that your infrastructure is able to negotiate hybrid handshaking with PQC-capable infrastructure and shared infrastructure with legacy infrastructure.
• Failure mode behavior: The behaviour occurring when a PQC-enabled service is ready to connect to a legacy endpoint? Test gracious 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 days test before going with it.

This is also the case with 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 blast radius in case anything goes awry and roll back decisions are purer.

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

By geographic area: In the case of multinational organizations where the IT governance is regional, region rollout could be compliant with local regulation requirements and local windows of change.

Prerequisites of change management per rollout wave:

• Identify rollback trigger (defined failure rate or time limit of latency)
• intentions to modify any protocol prior to 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 brings new vulnerabilities, especially in areas investigating major gaps in management and improperly configured hybrid configurations. The translation from one surface to another is a risk surface. Discipline of governance bridges such a 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 last standards published by NIST (FIPS 203, 204, 205) can be considered the initial stage, and the post-quantum world is still being built. Other algorithms are in consideration. There will be development of hybrid approaches. The regulatory requirements will be updated.

The format of continued monitoring:

• Cryptographic agility monitoring: Does the organization have the ability to change algorithms fast in case 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 they should be aware of the increased key sizes, which impact on storage and bandwidth.
• Tracking of vendors and supply chains: The preparation of PQC in vendors is quite different. A supplier that was capable of PQC in pilot phase might have revised their implementation. Follow up the status of vendors.
• Regulatory compliance calendar: Map map internal migration milestones as to regulatory deadlines. The federal 2031 target of high-priority systems establishes an external forced capability by nature.

This test layer also is 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 even secure enclave software are in place before they are purchased.

Outputs of the 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 with the greatest amount of implementation guidance on PQC migration in enterprise setting. It discusses discovery, testing methodology and migration patterns at sufficient depth as to directly answer pilot design.
   To be used as an 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 strong areas of TNO handbook are specifically on the organizational and governance front, namely, the alignment of stakeholders, risk controls in transition, and the architecture of crypto-agility. It is more available to the non-cryptographer audience as compared to 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

They are both free to obtain and aimed at practitioners as opposed to scholars.

The Bottom Line

The manuals of Planning and Executing Your PQC Migration is more about the management of the program than about cryptography. The ML-KEM and ML-DSA are selected as the technical algorithm that makes key encapsulation and digital signatures respectively, and SLH-DSA is a stateless digital signature backup that is a mere choice. The standards are completed, as per NIST.

The only thing left is the more difficult effort of the organization: to understand what you possess and what to transfer the first, to make managed pilots, to climb rollout not to create new loopholes.

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

Those organizations which are first to beat the curve today will have a decade where they can change their security posture. Waiting ones will be migrating under the gun, and have less time to test, and much exposure in the process itself.

Pranay Aduvala

I’m a technology writer with a passion for 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 curious. and encourage participation I continue to research innovation and technology. Let’s connect and talk technology!