CISO’s Guide to PQC Migration Planning and Execution

Post-quantum cryptography (PQC) is the set of encryption and digital signature algorithms designed to stay secure against attacks from quantum computers, and it is one of the most talked-about topics among security leaders today. Most security leaders have already accepted that quantum computing will break today’s public-key cryptography. The debate has moved on. The question now is not whether to act, but how to turn a quantum risk assessment into a PQC migration program that is funded, governed, and unlikely to take down production along the way.

That is a harder problem than it looks. Discovery and inventory tell you where you are exposed. Planning and execution decide whether you actually fix it without breaking the trust infrastructure your business runs on every day. This guide walks through that middle stretch of the journey: the planning decisions that follow discovery, the architectural choices that shape cost for years, and the execution discipline that separates a real program from a slide deck.

Why Does PQC Planning Deserve Executive Attention?

Because PQC is not a patch cycle, and treating it like one is the fastest way to lose control of the budget and the timeline. A routine upgrade swaps a version number. This swaps the mathematical foundation underneath authentication, encryption, and digital trust across the enterprise.

Six realities make structured planning a board-level concern rather than an engineering footnote:

• The New Algorithms Behave Differently: Larger keys and signatures and higher compute demands affect bandwidth, latency, and storage, which means capacity assumptions baked into existing systems may no longer hold. The jump is substantial: ML-KEM-768 produces a 1,184-byte public key against just 32 bytes for X25519, and an ML-DSA-44 signature runs to 2,420 bytes versus 64 bytes for Ed25519. Multiply that across every handshake and signed artifact in a high-volume environment and the effect on bandwidth, storage, and connection overhead becomes a real capacity-planning concern rather than a rounding error.
• The Blast Radius Is the Entire Trust Fabric: PKI, TLS, VPNs, code signing, and identity systems all depend on the cryptography you are replacing, so dependencies have to be mapped before anything is sequenced.
• Software Updates Will Not Cover Everything: Some hardware cannot accept post-quantum keys at all, which pulls procurement lead times and refresh cycles into the budget conversation early rather than late.
• Compliance Is a Moving Target: Certification and audit requirements are still evolving, so documentation has to be built into the timeline instead of reconstructed under pressure afterward.
• The Clock Already Has Dates on It: The National Security Agency (NSA)’s CNSA 2.0 timeline requires new National Security System acquisitions to support post-quantum algorithms by January 1, 2027, equipment that cannot be upgraded to be phased out by 2030, and full quantum resistance across all National Security Systems by 2035. These deadlines bind defense contractors and the federal supply chain directly, and they set the benchmark enterprises are increasingly measured against. With major government acquisitions running 18 to 36 months, requirements written today already need to account for them.
• A Mistake Here Is an Outage: Because cryptographic systems anchor identity and secure communication, a planning gap shows up as failed logins, broken integrations, or downtime, not a quiet rollback.

Put those together and the conclusion is unavoidable: this is a multi-year modernization program, and it needs to be planned like one.

How Do You Build the Migration Plan and Budget?

Start by turning the prioritized asset list from your risk assessment into a decision for every asset. Each one needs a defensible answer to a simple question: do we migrate now, hold the line and mitigate, or accept the risk? Most assets fall into one of three treatment paths:

• Immediate Migration: This is for high-value systems and anything protecting data with a long confidentiality life. These are the systems most exposed to “harvest now, decrypt later (HNDL)“, the attack in which adversaries collect encrypted traffic today and store it, then decrypt it later once a cryptographically relevant quantum computer (CRQC) exists. Delay here is the most expensive choice.
• Mitigation Pending Migration: This is for systems that belong in the immediate group but cannot get there yet, usually because a vendor is not ready or the deployment is genuinely complex. Apply interim controls and keep the migration on the calendar.
• Risk Acceptance or Managed Exception: This is for low-impact systems, assets near end of life, or cases where the cost of migrating clearly exceeds the residual risk.

Once each asset has a path, the budget stops being guesswork. A credible cost model reaches well past software, and naming every component up front is what keeps the program from quietly overrunning later. Build in:

• System redesign or refactoring, especially where cryptography is embedded deep in application code.
• Hardware replacement for devices that cannot hold larger post-quantum keys.
• Test environments that mirror production closely enough to catch performance regressions before users do.
• Downtime mitigation, including maintenance windows, tested rollback, and continuity planning.
• Vendor licensing, support, and any premium attached to post-quantum-capable products.
• Compliance work, including FIPS 140-3 module validation through the CMVP where it applies, which is a separate effort from algorithm standardization.
• Workforce cost, because few internal teams already carry deep cryptographic engineering skill.

A work breakdown structure turns that list into numbers tied to phases, which is also the format that survives a board review. When finance can see spend mapped to delivery milestones, the program reads as a managed plan with a visible end state.

How Do You Identify the Right Solution for Each System?

With budgets and treatment paths set, match every prioritized system to a viable technical path. This is where many programs discover their inventory was shallower than they thought, so treat it as a checkpoint, not a formality. The following four questions resolve most cases:

• Can this be solved with a software update, or does it need new hardware?
• Does a commercial solution exist today, or is one credibly on the roadmap?
• Is custom development unavoidable, as it often is for legacy or mission-specific systems?
• How does the option align with the NIST standards, namely FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, for stateless hash-based signatures), and what validation path, such as CMVP, applies?

One nuance on that last question is worth building into procurement timelines. FIPS 140-3 module validation through the Cryptographic Module Validation Program (CMVP) is a separate process from NIST algorithm standardization. As of mid-2025, many PQC implementations are FIPS 203, 204, and 205 algorithm-compliant in specification but have not yet appeared on the CMVP Validated Modules List. For federal contractors in particular, an algorithm being standardized is not the same as a module being validated, so plan for that gap rather than assuming the two arrive together.

Keep the algorithm landscape in view as well, because it is still expanding. NIST published IR 8547, its roadmap for transitioning to post-quantum standards, in November 2024. It has also moved beyond the first three finalized standards: a fourth algorithm FN-DSA (FIPS 206), the FALCON-based lattice signature scheme, reached Initial Public Draft stage in late 2025 and is expected to be finalized in 2026–2027. Organizations can begin evaluation against the IPD now.

Then in March 2025, NIST selected HQC, a code-based key encapsulation mechanism, as a fifth algorithm, documenting that decision in NIST IR 8545, the status report on the fourth round of the standardization process. HQC is not a replacement for ML-KEM but a backup built on different mathematics, so a single cryptanalytic breakthrough is less likely to compromise both. For a multi-year roadmap, designing for that diversity now is easier than retrofitting it later.

Two architectural choices made now will quietly shape cost for the next decade:

• Hybrid Cryptography: This means running a classical and a post-quantum algorithm together. You get backward compatibility with partners who have not migrated, forward protection against quantum attack, and lower operational risk during the transition. For anything externally facing, it is often the only path that does not break interoperability on day one.
• Crypto-Agility: This is the more strategic of the two, and it is an architecture principle more than a product. In practice, a crypto-agile system selects its algorithm through a configuration parameter rather than hard-coded calls, and it places an abstraction layer between application logic and the underlying cryptographic primitives, so swapping ML-KEM for a future algorithm does not mean rewriting the application. Systems built this way absorb the next standards change as a configuration update, sparing you a second full migration. Build agility in now, and future post-quantum changes will be much easier and less costly to manage.

What Should You Confirm with Vendors Before Committing?

Vendor readiness can make or break the timeline, so the planning phase is where exploratory conversations have to become commitments on paper. Five questions are worth pressing until you get specific answers:

• When will post-quantum-capable products ship, and what is the upgrade path for what we already run?
• Is this a software change, or does it require a hardware refresh?
• What is the total cost of ownership, including licensing, support, and professional services?
• What is the operational impact during deployment, including downtime and interoperability?
• Will you provide a Cryptographic Bill of Materials (CBOM), an inventory of the cryptographic assets and dependencies inside a product, so we can see embedded dependencies and plan future upgrades?

Use this opportunity to update procurement requirements. New contracts should require post-quantum algorithm support, demonstrated crypto-agility, a transparent roadmap, and long-term support commitments. Otherwise, the organization keeps buying quantum-vulnerable systems while spending to retire the old ones, which is a hole worth closing before it widens.

When Does It Make Sense to Build Instead of Buy?

Some systems will have no commercial path, particularly custom applications and legacy platforms with cryptography woven into the code. For these, make a deliberate build-or-replace call rather than retrofitting by default. Weigh:

• The development timeline and what it takes to deliver and validate a custom solution.
• The in-house expertise available, and whether you need to hire or contract cryptographic engineering.
• Whether the change is software only or reaches into hardware.
• The performance hit once post-quantum algorithms are integrated, which matters most for latency-sensitive workloads.
• The validation burden, including any third-party review or certification.
• Whether replacing the system outright beats retrofitting an aging one.

Often, replacing a system near end of life is cheaper than retrofitting it. Putting that option on the table during planning stops teams from pouring effort into a retrofit that will be obsolete in a few years.

How Do You Protect Data While PQC Migration Is Underway?

Full migration takes years, so the plan has to cover the gap. This matters most for data that adversaries can collect now and decrypt later, where the clock is already running even though the quantum computer is not here yet. Several interim controls meaningfully reduce exposure:

• Shorten certificate lifetimes to narrow the window a stolen credential stays useful.
• Increase classical key sizes where doing so reduces exposure to classical attacks, but be clear that no increase in RSA or ECC key length provides quantum resistance. Shor’s algorithm can solve integer factorization (breaking RSA and DH) and the elliptic curve discrete logarithm problem (breaking ECC) in polynomial time. Revoke or replace overly long-lived certificates that predate current practices.
• Move to TLS 1.3 across the environment for its stronger cryptographic posture, but treat it as only partially quantum-safe on its own. To close the gap, enable hybrid post-quantum key exchange, such as X25519 paired with ML-KEM-768, on your TLS endpoints so the session is protected even if the classical half is later broken.
• Harden physical security and data-at-rest protection for the highest-value data.
• Add layered defenses such as VPNs or tighter network segmentation around sensitive systems.
• Move symmetric encryption and hashing to quantum-ready strengths. Grover’s algorithm roughly halves the effective security of a symmetric key, which drops AES-128 to about 64-bit equivalent security against a cryptographically relevant quantum computer (CRQC).

CNSA 2.0 mandates AES-256 and SHA-384 or SHA-512 for National Security Systems. NIST SP 800-131A Rev. 3 (Initial Public Draft, 2024) continues to approve AES-128 for general use, and AES-128 remains a Category 1 post-quantum benchmark, so it is not deprecated. That said, organizations handling long-lived sensitive data should align with the AES-256 and SHA-384/512 floor that CNSA 2.0 establishes. Public-key systems carry the urgent risk, but symmetric and hash choices belong in the same plan.

Note: SP 800-131A Rev. 3 cited here is an Initial Public Draft (2024); Rev. 2 remains the finalized standard until NIST publishes the final version.

Be candid with leadership about what these controls are. They buy time. They do not remove quantum risk, and leaning on them too heavily creates a false sense of safety that can quietly stall the migration they were meant to support.

What Does Disciplined Execution Look Like?

Once plan, budget, vendor commitments, and interim controls are in place, execution turns strategy into purchase orders, development work, and integration. The order matters: follow the risk-based sequence you built, not whichever system happens to be easiest this quarter. The core moves are simple to state and harder to hold to:

• Allocate budget and resources against the prioritized asset list.
• Run procurement for commercial solutions, including required certifications.
• Launch internal development for systems with no commercial path.
• Coordinate across business units so decisions stay visible instead of siloed.

The discipline is resisting easy wins. Migrating a low-risk system because its vendor is ready feels like progress, but it does not reduce real exposure. Holding the sequence is what makes the program safer rather than merely busier.

Deployment is where the planning either pays off or shows its gaps, so roll out in phases rather than flipping a switch. Before the first production change, have:

• Maintenance windows agreed with business owners, especially for systems anchoring identity.
• Rollback plans that have actually been tested, because cryptographic changes cascade in ways that surprise people.
• Continuity measures and a communication plan for any extended disruption.
• Compatibility management across classical, hybrid, and post-quantum systems through a transition that can run for years.

After deployment, update the governance record as rigorously as the systems themselves: asset inventories, cryptographic documentation, compliance records, and risk assessments. Skip this and you lose visibility into your own progress and build audit debt that only grows. Holding that discipline across a multi-year program is demanding, which is where an experienced partner earns its place.

How Encryption Consulting Supports Your PQC Journey

Not sure where your post-quantum journey should begin, or how to keep it moving? That is where Encryption Consulting fits in. We work as a trusted partner through every phase, grounding each step in clarity, confidence, and real-world expertise.

We start with a Cryptographic Discovery and Inventory, sweeping your full environment to surface the certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.

From there, our PQC Assessment measures your exposure to quantum threats, isolates the RSA- and ECC-dependent systems, and delivers a prioritized report of vulnerable assets ranked by severity.

With that clarity, we shape a PQC Strategy and Roadmap: a phased plan tuned to your risk appetite, regulatory obligations, and long-term goals, with crypto-agility engineered in so your systems adapt as standards evolve.

We then guide Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept trials, and validate interoperability before any full-scale rollout.

Finally, we lead Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and standing up monitoring for long-term cryptographic health.

CBOM Secure

Encryption Consulting’s CBOM Secure platform plays a central role here. Instead of wrestling with spreadsheets, raw OpenSSL outputs, or scattered configuration files, you get a clear view of cryptographic usage across environments. It shows which algorithms are in use, what must change for post-quantum readiness, and whether systems meet their security targets. When a board update, architecture decision, or compliance deadline is bearing down, that clarity lets you move quickly.

CBOM Secure is more than a reporting tool; it compresses the timeline. It automates cryptographic inventories, inspects TLS configurations, validates algorithms, and reconciles them against policy, so teams move from discovery to action without guesswork. Upcoming releases will add automated remediation, cloud-native integrations, and continuous policy enforcement to keep configurations aligned with security standards at all times.

Now is the time to start trial PQC in a staging environment, map your current cryptographic usage, and begin drafting internal policies. If your organization wants to pilot quantum-safe projects, share feedback, or help shape new features, we encourage you to reach out. The earlier teams begin, the easier the long-term work becomes.

Conclusion

Planning and execution are the stages where a post-quantum program stops being a study and becomes an enterprise transformation. It runs on prioritization that survives scrutiny, crypto-agility built into the architecture, and documentation kept rigorously enough to prove progress and satisfy an audit.

The risk is systemic and time-sensitive, but it yields to discipline far more than to raw speed. The organizations that emerge in the strongest position will be the ones that built crypto-agility into their architecture, sequenced the work against actual risk, and kept the documentation to prove it.

For CISOs, the takeaway is direct. The cryptography is hard, but the leadership work is harder: governance, sequencing, vendor management, and defending the budget. Get those right, and the engineering that follows has a real chance of delivering quantum resilience without destabilizing the trust your business depends on every day.