PQC Migration: The Hard Realities Nobody Warns You About

Quick answer: The hard realities of PQC migration are operational, not algorithmic: the migration surface is far larger than most discovery efforts map (spanning TLS, SSH, IPsec, code signing, HSMs, OT, and IoT), most cryptographic discovery methods (network scanning, code scanning, agent-based tools) each miss significant portions of the true footprint, and hybrid deployment is not a checkbox but a sustained operating model with its own testing, monitoring, and governance overhead. It matters because regulatory deadlines like the CNSA 2.0 January 2027 procurement gate and the September 21, 2026 FIPS 140-2 sunset are firm, and defense acquisition cycles running 18 to 36 months mean systems being designed today may already be too late if they don’t account for these requirements. The recommended action is to run cryptographic discovery continuously and in parallel with remediation rather than treating it as a prerequisite, since waiting for a “complete” inventory before starting means the 2030 deadlines arrive while the team is still building spreadsheets.

Key Takeaways

• CNSA 2.0’s January 2027 procurement gate and the September 21, 2026 FIPS 140-2 to Historical transition are near-term, firm deadlines, not distant milestones, and CMVP validation for FIPS 140-3 often takes 18 months or longer.
• No single discovery method captures the full cryptographic footprint: network scanning misses embedded and non-standard-port cryptography, code scanning misses runtime configuration, and agent-based tools are blind to OT and vendor-managed infrastructure.
• A cryptographic inventory decays almost immediately as containers scale, CI/CD pipelines deploy new builds, and vendors push firmware updates, which is why discovery must be continuous rather than a one-time project.
• A CBOM (Cryptographic Bill of Materials) captures what was built into a system at build time; runtime discovery confirms what is actually running. Organizations need both, not one in place of the other.
• Hybrid cryptography is a sustained operating model, not a transitional checkbox: it requires SOC detection rules for downgrade attacks, an expanded testing matrix, and per-jurisdiction regulatory tracking since hybrid guidance varies by region.

A Concrete Shift in Cryptographic Risk

August 2024 marked a concrete shift in how organizations must think about cryptographic risk. The National Institute of Standards and Technology (NIST) finalized three post-quantum standards: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based signature alternative, ending an eight-year standardization process.

NIST is also progressing FIPS 206 (FN-DSA/FALCON) toward publication and selected HQC (Hamming Quasi-Cyclic) as an additional key encapsulation mechanism (KEM) in March 2025, reflecting the continuing expansion of the post-quantum cryptography (PQC) portfolio. The algorithms are standardized, and the migration timelines are set by regulators, which means the destination is defined. The difficulty is in the execution, and most organizations have no reference point for a cryptographic transformation this broad.

The complication that makes timing non-negotiable is Harvest Now, Decrypt Later. Adversaries collecting encrypted traffic today can store it and decrypt it once a cryptographically relevant quantum computer becomes available. That means data protected by RSA or ECDH right now is already exposed to a future attack, and the window between collection and decryption is shrinking as quantum hardware matures.

Long-lived data, government communications, financial records, and anything with a confidentiality requirement beyond five to ten years carries real exposure today, not at some theoretical future point.

What makes PQC migration operationally difficult is not only selecting the right algorithms but also executing the transition across complex technology environments. Cryptography is embedded in every protocol, device, vendor dependency, and compliance obligation an organization carries. The programs that run into serious trouble are the ones that treat migration as a simple software update rather than an infrastructure-wide transformation. The sections below cover the specific points where that assumption breaks down.

The Migration Deadline Is Closer Than You Think

PQC migration is the process of replacing quantum-vulnerable public-key algorithms, RSA, ECDH, and ECDSA, with NIST-standardized quantum-resistant alternatives, including ML-KEM, ML-DSA, and SLH-DSA, across every protocol, application, and device in an organization.

The most common planning mistake in PQC programs is treating the timeline as open-ended. Teams assume the migration effort can begin when a cryptographically relevant quantum computer finally appears on the horizon. The reality is that by the time such a system exists, the time available for an orderly migration may already have passed.

Regulators have already closed that window. The National Security Agency’s (NSA’s) Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets a January 2027 procurement gate: any new National Security System acquisition after that date must support quantum-resistant algorithms. For software and firmware signing, CNSA 2.0 requires exclusive use of LMS (Leighton-Micali Signature) and XMSS (Extended Merkle Signature Scheme), per NIST SP 800-208, by 2030. These are stateful hash-based schemes distinct from the general-purpose ML-KEM and ML-DSA algorithms.

Per CNSA 2.0 guidance, networking equipment must complete its transition to CNSA 2.0 algorithms by 2030, with mandatory use across covered categories by 2031, and operating systems, custom applications, and cloud services reaching exclusive use by 2033. This is not merely guidance for commercial organizations. CNSA 2.0 requirements directly influence defense procurement eligibility, NIAP validation, and Risk Management Framework (RMF) compliance activities.

On the federal side, NIST IR 8547 (Initial Public Draft, November 2024) outlines the expected federal migration timeline: quantum-vulnerable algorithms at 112-bit security strength are deprecated for federal systems by 2030, and all quantum-vulnerable public-key algorithms are disallowed by 2035. While the final version has not yet been published, the document’s timelines reflect NIST’s stated direction and are widely used as planning benchmarks. NIST IR 8547 anticipates widespread adoption of PQC across both federal systems and the broader technology ecosystem before those deadlines are reached.

The US regulatory picture does not stand alone. PQC planning is becoming part of broader cyber resilience and NIS2-related initiatives. The Australian Signals Directorate (ASD) Information Security Manual (ISM) recommends ceasing use of RSA, DH, ECDH, and ECDSA by the end of 2030, one of the most aggressive migration timelines published globally. While the specific deadlines vary, the message is consistent: organizations are expected to begin preparing now rather than waiting for quantum computers to become a practical threat.

What makes all of these deadlines collectively significant is the scale of the work required to meet them. A full enterprise PQC migration extends far beyond replacing cryptographic algorithms. Organizations must discover cryptographic assets, assess dependencies, evaluate vendor support, upgrade protocols and applications, replace incompatible hardware and software, and coordinate changes across complex technology environments.

The result is a narrowing window for preparation. Organizations that delay planning may find themselves facing compressed timelines, increased costs, and heightened operational risk as compliance milestones approach.

The practical consequence: defense acquisition cycles run 18 to 36 months. Systems being designed today may not be delivered until after the January 2027 transition point. If current procurements do not account for CNSA 2.0 requirements, the resulting systems may require costly redesign, recertification, or remediation soon after deployment. For programs with multi-year acquisition cycles, the planning window is rapidly narrowing.

Two near-term deadlines sharpen this further. On September 21, 2026, all FIPS 140-2 validated modules move to Historical status under NIST’s Cryptographic Module Validation Program (CMVP), making them generally unsuitable for new federal procurements. CMVP validation often takes 18 months or longer, meaning vendors not already well into the FIPS 140-3 validation process may struggle to meet the January 2027 CNSA 2.0 timeline.

Separately, Executive Order 14144 (January 2025, retained under subsequent amendments) requires federal agencies to support TLS 1.3 by January 2, 2030, as a foundational step toward PQC-capable communications. These are not distant milestones. The September 2026 transition is just a few months away.

The Migration Surface Is Larger Than You Think

Most of the systems in an organization run on cryptography. The scope becomes concrete once organizations map where cryptographic algorithms are actually used.

RSA, ECDH, and ECDSA appear throughout enterprise environments, including TLS connections, SSH sessions, IPsec tunnels, S/MIME email, code-signing workflows, certificate authorities, hardware security modules, device identities, and authentication systems. Those cryptographic dependencies extend across servers, workstations, cloud workloads, containers, network appliances, mobile devices, operational technology systems, and IoT devices. Together, they define the true migration surface for PQC.

The most challenging part of that surface is the portion that cannot be upgraded through a routine software update. Operational technology controllers, embedded devices, and specialized hardware often contain cryptographic implementations that were fixed when the device was manufactured. In many cases, transitioning those systems requires hardware refreshes rather than software patches.

The challenge is compounded by the fact that post-quantum algorithms generally use larger keys, signatures, and protocol messages than the classical algorithms they replace. Those increases can affect certificate sizes, TLS handshakes, network traffic, and application behavior. Systems that were designed with assumptions about message size, buffer capacity, or protocol overhead may require modification before they can support PQC reliably.

This is not a theoretical concern. Early production deployments and interoperability testing programs have uncovered compatibility issues in load balancers, firewalls, middleboxes, and other network devices that assumed cryptographic messages would remain within traditional size limits. The lesson is clear: migrating to PQC requires more than algorithm replacement. It requires validating every component that processes, stores, transmits, or depends on cryptographic data.

What Most Organizations Get Wrong About Cryptographic Discovery

Ask most security teams how they plan to find all the cryptographic assets in their environment, and the answer is usually “scanning.” Scanning finds some assets, but not the entire cryptographic footprint.

Network scanning catches TLS handshakes at the perimeter but misses any cryptography inside encrypted payloads, embedded in firmware, or operating over non-standard ports. Code scanning finds library calls in source but does not see runtime configuration, dynamically linked libraries, or third-party components.

Agent-based discovery covers managed IT endpoints but is blind to OT networks, IoT devices, and vendor-managed infrastructure. External surface scanning, the kind that generates a ‘quantum readiness assessment’ in 48 hours, covers an organization’s public-facing TLS endpoints, which represent a small fraction of its total cryptographic footprint. The confidence those reports produce is not proportional to what they actually measure.

The second problem is that the inventory decays almost immediately. A container scales up with pinned cipher suites in minutes. A CI/CD pipeline deploys a build using a different crypto library without a change ticket. A vendor pushes a firmware update overnight that modifies the embedded crypto stack. A new SaaS integration starts negotiating its own TLS configuration before anyone reviews it. A point-in-time inventory is accurate at the moment it is captured and gets less accurate continuously after that.

What the inventory needs to produce is not a spreadsheet but a maintained Cryptographic Bill of Materials (CBOM), a structured record of the cryptography present in a software system, firmware image, or device. It lists the algorithms, key sizes, cryptographic libraries, certificates, and protocols in use. A CBOM does not discover assets on its own. It captures what is present in a software artifact based on build-time or static analysis. That is different from runtime discovery, which tracks what is actually running across the environment. Organizations need both: the CBOM captures what was built in, and runtime discovery confirms what is live.

The programs that handle this well treat cryptographic discovery the same way mature security teams treat vulnerability management: continuous, automated, integrated into the CISO’s monitoring stack, and running in parallel with remediation rather than as a prerequisite to it. The NIST National Cybersecurity Center of Excellence’s (NCCoE’s) SP 1800-38 practice guide (preliminary draft) reflects this operational model, covering cryptographic discovery tools, cryptographic inventories and CBOMs, and phased migration planning across multiple protocol and application categories.

Waiting until discovery is “complete” before starting migration means the 2030 deadlines arrive while the team is still building spreadsheets.

What Most Organizations Get Wrong About Hybrid Deployment

NIST IR 8547 (Initial Public Draft) describes hybrid cryptographic approaches as an interim migration strategy, where a classical algorithm and a post-quantum algorithm are used together, and security is intended to rely on at least one component remaining secure. This is the correct approach for the current transition period, and it is helpful for those organizations that cannot afford to bet entirely on brand-new algorithm implementations being bug-free from day one.

What the guidance leaves out is what a hybrid deployment actually costs operationally. It requires the SOC to maintain detection rules for downgrade attacks, where a connection that should be hybrid is forced back to classical-only. The testing matrix expands: teams must validate classical-only fallback behavior, PQC-only operation, and hybrid combinations across every protocol in scope.

Network appliances need to handle the combined key material sizes, which are larger than either scheme alone. Engineering teams must track per-jurisdiction requirements, as regulatory guidance on hybrid varies meaningfully across regions, and a single global TLS configuration is unlikely to satisfy all of them simultaneously.

Hybrid deployment is also not the final state. It is a transition strategy. Organizations should plan for hybrid deployments to coexist with ongoing modernization efforts, regulatory changes, and future migration phases. Organizations should treat hybrid cryptography as a sustained operating model with its own governance, testing, monitoring, and lifecycle management requirements rather than a checkbox on the path to completion.

How Encryption Consulting Can Help

For most organizations, building a complete cryptographic inventory and migrating to post-quantum cryptography cannot be done with existing tooling and internal capacity alone. Encryption Consulting works with enterprises at every stage of this process, from initial discovery through full PQC migration, with services and purpose-built tooling designed specifically for the complexity of real enterprise PKI environments.

PQC Advisory Services

Our advisory engagement includes:

• A Cryptographic Asset Register, produced through systematic discovery across your endpoints, applications, APIs, and infrastructure. This is the baseline that makes every subsequent step possible.
• A Risk Assessment Report, evaluating your exposure to quantum threats, identifying RSA and ECC dependent systems, and delivering prioritized findings with risk severity ratings by category: security, compliance, and operational.
• A PQC Migration Roadmap, a phased plan aligned to your risk appetite, regulatory requirements, and NIST timelines, including cryptographic agility so your systems can adapt as standards continue to evolve.
• Vendor Evaluation and Pilot Testing support, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.
• Full Implementation, covering deployment of hybrid classical and quantum-safe models, rollout of PQC across your PKI and infrastructure, and monitoring setup for long-term cryptographic health.

CBOM Secure

A note worth making explicitly: CBOM Secure is not the same thing as a CBOM. A CBOM is a structured artifact, a record of the cryptographic components in a given application or system. CBOM Secure generates and consumes CBOM data, but it also performs continuous discovery and runtime inventory management across the full enterprise environment. The distinction matters because a CBOM alone tells you what was built into an application at a point in time. CBOM Secure tells you what is actually running, where it is running, and how it is changing.

A successful post-quantum transition begins with visibility. Organizations cannot modernize cryptography if they do not know where certificates, keys, algorithms, and cryptographic dependencies exist across their environment.

Encryption Consulting’s CBOM Secure provides a continuous view of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services. Rather than producing a point-in-time inventory, it helps organizations understand how cryptography is being used, where it is deployed, and how it changes over time.

CBOM Secure continuously discovers and tracks certificates, keys, algorithms, and cryptographic dependencies across the enterprise. It provides visibility into asset ownership, certificate and key relationships, algorithm usage, lifecycle events, and cryptographic exposure, helping teams identify unmanaged assets, deprecated algorithms, and systems that may require modernization.

The platform also supports policy-driven governance by validating cryptographic configurations against organizational standards and highlighting deviations before they become operational or compliance risks.

For organizations preparing for post-quantum cryptography, CBOM Secure identifies systems that rely on quantum-vulnerable algorithms and provides the visibility needed to prioritize remediation and migration activities.

CertSecure Manager

Cryptographic discovery identifies where quantum-vulnerable algorithms exist across an environment. Certificate lifecycle management is what enables organizations to address that exposure at scale. The volume of certificates that must be reissued during a PQC migration, spanning TLS endpoints, code-signing workflows, device identities, S/MIME, and internal PKI hierarchies, makes manual migration operationally impractical for any enterprise environment of meaningful size.

CertSecure Manager is Encryption Consulting’s certificate lifecycle management platform, built with crypto-agility at its core. It continuously discovers and manages certificates across Microsoft, public, and private CAs; automates issuance, renewal, and revocation through ACME, SCEP, and EST protocols; and enforces cryptographic policy to flag and restrict deprecated algorithms before they create compliance or operational exposure.

During PQC migration, CertSecure Manager manages the transition from RSA and ECC certificates to hybrid and quantum-safe alternatives, with policy enforcement applied consistently across the full certificate estate.

For organizations navigating both PQC migration and the CA/Browser Forum’s mandated reduction of TLS certificate lifetimes to 47 days by 2029, the combination of continuous discovery, automated certificate lifecycle management, and quantum-ready issuance in a single platform removes the coordination overhead that otherwise causes large-scale certificate transitions to stall.

Inventory gaps, algorithm drift, and untracked shadow certificates are recurring operational risks in cryptographic migration programs. CertSecure Manager helps organizations detect, track, and remediate each of them.

Whether your organization is starting from scratch with no formal inventory in place or is looking to operationalize an existing discovery effort into a continuous governance program, Encryption Consulting brings both the advisory depth and the platform capability to move you forward. To learn more about our PQC Advisory Services, CBOM Secure, or CertSecure Manager, visit encryptionconsulting.com or reach out to our team directly.

Conclusion

PQC migration is not a future problem with a future budget. The regulatory deadlines are active, the cryptographic surface is larger than most discovery efforts have mapped, and the operational complexity of hybrid deployment is already being felt by teams that started early.

The organizations that are making real progress share one characteristic: they stopped waiting for a complete picture before acting. They defined a bounded first phase, assigned a single accountable owner to it, and ran discovery in parallel with remediation rather than treating it as a prerequisite.

The work ahead is substantial, but it is also well-defined. The algorithms are standardized. The migration path is documented. What remains is execution, and execution at this scale rewards programs that are structured like engineering programs rather than security projects.

If your team has not yet mapped its cryptographic surface, engaged its vendors on PQC roadmaps, or stress-tested its hybrid deployment assumptions, those are the right starting points. The 2030 deadlines do not wait for organizational readiness. The programs that will meet them are the ones building that readiness now.

Frequently Asked Questions

Why is the PQC migration deadline closer than it appears?

Because defense acquisition cycles run 18 to 36 months, and CMVP validation for FIPS 140-3 often takes 18 months or longer. Systems being designed today may not deliver until after CNSA 2.0’s January 2027 procurement gate, and if current procurements don’t account for that requirement, the resulting systems may need costly redesign or recertification soon after deployment.

Why does relying on a single cryptographic discovery method create blind spots?

Because each method covers a different slice of the environment. Network scanning catches TLS handshakes at the perimeter but misses cryptography inside encrypted payloads or firmware. Code scanning finds library calls in source but not runtime configuration or dynamically linked libraries. Agent-based discovery covers managed IT endpoints but is blind to OT networks and vendor-managed infrastructure. A 48-hour “quantum readiness assessment” typically only covers public-facing TLS endpoints, a small fraction of the total footprint.

What is the difference between a CBOM and runtime cryptographic discovery?

A Cryptographic Bill of Materials (CBOM) is a structured record of the cryptography built into a specific application, firmware image, or system, captured through build-time or static analysis. Runtime discovery tracks what is actually running live across the environment. Organizations need both: the CBOM shows what was built in, and runtime discovery confirms what is currently deployed and how it’s changing.

Why can’t organizations wait for a “complete” cryptographic inventory before starting migration?

Because an inventory decays almost immediately: a container scales up with pinned cipher suites in minutes, a CI/CD pipeline deploys a build using a different crypto library, and a vendor pushes a firmware update overnight that changes the embedded crypto stack. A point-in-time inventory is accurate only at the moment it’s captured. Programs that treat discovery as continuous and run it in parallel with remediation make progress; those that wait for discovery to be “complete” risk hitting 2030 deadlines while still building spreadsheets.

What operational overhead does hybrid cryptography actually require?

The SOC needs detection rules for downgrade attacks, where a connection that should be hybrid gets forced back to classical-only. The testing matrix expands to cover classical-only fallback, PQC-only operation, and hybrid combinations across every protocol in scope. Network appliances must handle combined key material sizes larger than either scheme alone, and engineering teams need to track per-jurisdiction hybrid requirements, since regulatory guidance varies meaningfully across regions.

Why is the migration surface larger than most organizations expect?

Because RSA, ECDH, and ECDSA appear throughout TLS, SSH, IPsec, S/MIME, code signing, certificate authorities, HSMs, and device identities, spanning servers, cloud workloads, containers, network appliances, mobile devices, OT systems, and IoT devices. The hardest portion is often OT controllers and embedded devices with cryptography fixed at manufacturing time, which frequently requires hardware refreshes rather than software patches, plus larger PQC keys and signatures can break systems with fixed assumptions about message size or buffer capacity.