Post Quantum Cryptography (PQC) migration is the process of replacing quantum-vulnerable public-key cryptography, RSA, ECDH, ECDSA, and related schemes, with NIST-standardized post-quantum algorithms, including ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). It spans cryptographic discovery, risk-based prioritization, hybrid deployment during the transition period, and the long-term operational capability to rotate algorithms as standards evolve.
Unlike past algorithm transitions, PQC migration reaches across every layer of an enterprise: PKI, firmware, TLS, SSH, code signing, HSMs, and embedded devices.
Most organizations approaching PQC migration carry a mental model built from conference presentations, vendor whitepapers, and framework summaries. Those sources are not wrong, but they describe the destination, not the terrain. The gap between reading about a PQC migration and running one is wider than almost any comparable transition in enterprise security history.
The regulatory picture has removed the option to wait, and the threat picture explains why the wait was never safe to begin with. Adversaries can capture encrypted traffic today and store it for decryption once a cryptographically relevant quantum computer exists. For data with multi-year confidentiality requirements, that exposure is present-tense, not future.
Under NSA CNSA 2.0, new National Security System acquisitions must support quantum-resistant algorithms starting January 1, 2027. Software and firmware signing in covered systems must move to exclusive PQC use by 2030. Legacy networking equipment incapable of supporting CNSA 2.0 must be retired by 2030.
Australia’s Information Security Manual (ISM) recommends ceasing use of classical asymmetric cryptography, including RSA, DH, ECDH, and ECDSA, by the end of 2030. European regulators and agencies are increasingly incorporating PQC planning and crypto-agility considerations into cybersecurity guidance and resilience initiatives. These timelines are compressing, not relaxing.
What is often less visible than the deadlines themselves is the scale of the organizational and technical effort required to execute a successful migration. Many large enterprises expect migration to span multiple years and, for complex environments, potentially more than a decade. That gap, between the time available and the time required, is the core tension of PQC in 2026.
This blog covers what practitioners learn once a PQC migration program is underway: the realities that frameworks summarize too briefly, and vendors rarely mention at all.
The Migration Surface Is Larger Than Your Asset Inventory
NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. A significant portion of enterprise infrastructure relies on public-key algorithms that PQC standards are intended to complement or replace. These algorithms underpin technologies and trust systems throughout the enterprise, including hardware roots of trust, firmware signing, secure boot, TLS, SSH, IPsec, S/MIME, code signing, Hardware Software Modules (HSMs), and IoT attestation.
The comparison most people reach for is SHA-1 to SHA-2. It is misleading. SHA-2 was a hash function swap inside the same mathematical family. PQC changes the underlying mathematics entirely. An ML-KEM-768 public key share measures 1,184 bytes against 32 bytes for X25519, a factor of roughly 37. An ML-DSA-65 signature runs 3,309 bytes against 64 bytes for ECDSA, a factor of roughly 51. These figures use mid-range parameter sets for illustration.
CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87, which produce even larger keys and signatures, increasing the size overhead in real NSS deployments. As a result, a certificate chain built with ML-DSA signatures and public keys can easily exceed 10 KB.
These size differences produce real failures in production-representative environments. Firewalls with fixed buffer allocations drop oversized ClientHello messages. Middleboxes that parse TLS extension fields fail on the new sizes. PQC-related handshake growth can increase fragmentation pressure and may create challenges for protocols such as QUIC. These issues rarely appear in a single product tested in isolation.
They emerge across browsers, operating systems, load balancers, HSMs, TLS inspection devices, VPNs, certificate authorities, and third-party integrations. As a result, interoperability testing often becomes a significant workstream of the migration effort rather than a final validation step.
Many resource-constrained devices may struggle to support PQC algorithms due to memory, processing, or bandwidth limitations. LoRaWAN, a low-power wide-area network protocol widely used in industrial and smart city IoT deployments, permits approximately 51 bytes per uplink payload at its most conservative data rate setting in the EU. ML-KEM-768 ciphertext alone runs 1,088 bytes. For devices embedded in power grids, water systems, or hospital equipment, this is not a software configuration problem. It is a hardware replacement problem on a multi-decade asset lifecycle.
The Foundations Most Organizations Underestimate
Most organizations begin a cryptographic migration without a complete picture of their cryptographic estate. Gartner finds that most IT organizations are unaware of the cryptography they are running, including which applications use it, how it is configured, and who makes decisions about it. No single discovery method sees the whole surface.
Network scanning catches TLS handshakes but misses embedded crypto. Code analysis finds library calls, but cannot see the runtime configuration. Agent-based tools cover managed IT but cannot reach OT or third-party infrastructure.
External scanning reaches only the public perimeter and provides visibility into a relatively small portion of an organization’s overall cryptographic footprint. The practical answer is to run discovery and migration in parallel, prioritizing outward-facing systems first and continuously updating inventory as systems change, rather than treating a point-in-time scan as a completed deliverable.
Governance failures often delay cryptographic modernization before any technical work begins. Responsibility for cryptography is typically spread across security, IT operations, application teams, procurement, and OT, leaving no single group accountable for outcomes. When ownership is fragmented, decisions stall as teams debate priorities, budgets, and responsibilities.
Programs are more likely to make progress when a single executive is accountable, funding is clearly assigned, and participating teams are given a formal mandate to act. Organizations that have already begun establishing this governance structure are giving themselves the time needed to address the technical and operational challenges that lie ahead.
Vendor readiness is a related pressure point. When organizations ask their critical vendors for a PQC product roadmap with delivery timelines, they often find that those plans are still evolving or are not yet fully defined. Vendor replacement for a critical system takes two to three years under good conditions. The organizations that start those conversations now, and write PQC support timelines into contract renewals, are the ones that will not discover a vendor bottleneck in year five of a seven-year program.
The PKI Bottleneck
Many organizations assume PQC migration begins when post-quantum algorithms are deployed into production applications. In practice, the transition often starts much earlier in PKI. Certificate authorities, HSMs, certificate lifecycle management platforms, code-signing services, trust stores, and enrollment workflows all need to support new algorithms before certificates can be issued and managed at scale.
Support for PQC algorithms alone is not enough. Certificate templates, issuance workflows, validation services, monitoring platforms, TLS inspection devices, and certificate automation pipelines may all require testing and modification. Organizations frequently discover that PKI infrastructure becomes a critical dependency for the broader migration effort, making PKI modernization one of the earliest prerequisites for large-scale deployment.
The Difference Between Surviving the Transition and Sustaining It
Running hybrid cryptography during the transition, pairing classical algorithms alongside NIST-standardized PQC algorithms such as ML-KEM alongside X25519, is well-supported and appropriate. A session protected by both remains secure as long as either algorithm holds. What guidance tends to underplay is the operational overhead. Sovereign fragmentation means the same configuration can satisfy one regulator while conflicting with another.
Germany’s Federal Office for Information Security (BSI) guidance generally favors hybrid approaches during the transition. In contrast, Australia’s ISM specifies migration to ASD-approved post-quantum algorithms. ISM – 1996 states that hybrid classical-PQC schemes are not recommended, though not prohibited. Migration planning must consider not only technical requirements but also applicable regulatory guidance.
Crypto-agility is the organizational and technical capability to update, replace, or rotate cryptographic algorithms across systems without redesigning those systems. It is not a migration deliverable. It is an ongoing operational capability. Architecture built for crypto-agility must support per-jurisdiction configuration, abstract cryptographic choices behind policy controls, and include SOC detection rules for hybrid downgrade attacks before any hybrid deployment reaches production.
NIST is also finalizing additional signature schemes beyond the three 2024 standards. FIPS 206, standardized as FN-DSA and based on FALCON, was submitted for draft approval in August 2025, with the final standard expected in late 2026 or early 2027. HQC was selected in March 2025 as an additional code-based KEM and is progressing toward standardization.
Quantum computing is only one driver of cryptographic change. Vulnerabilities in algorithms, implementation flaws, advances in cryptanalysis, regulatory requirements, and evolving security standards can all necessitate cryptographic transitions. The ability to replace algorithms rapidly in response to a newly discovered weakness is fundamentally different from executing a planned, multi-year migration program.
Organizations that treat crypto-agility as a temporary capability created for PQC migration may complete the current transition but remain poorly positioned for the next one. Organizations that invest in crypto-agility as a permanent operational capability reduce the cost, risk, and disruption of future cryptographic transitions, regardless of what drives them.
How Encryption Consulting Can Help
Organizations that begin a PQC migration quickly discover that the challenge extends beyond algorithm selection. Success depends on understanding where cryptography exists, assessing the impact of quantum-vulnerable systems, coordinating with vendors, modernizing PKI infrastructure, and building the operational capabilities required to support future cryptographic transitions.
PQC Advisory Services
Encryption Consulting supports organizations throughout this journey with end-to-end PQC migration services covering discovery, assessment, planning, validation, and deployment.
Our PQC Advisory Services help organizations identify certificates, keys, algorithms, protocols, and cryptographic dependencies across cloud environments, applications, infrastructure, HSMs, source code repositories, containers, APIs, and CI/CD pipelines. Using this visibility, we assess exposure to quantum-vulnerable cryptography, identify high-priority remediation areas, and develop risk-based migration roadmaps aligned with NIST standards, regulatory requirements, and business objectives.
Beyond planning, Encryption Consulting assists with vendor readiness assessments, proof-of-concept validation, interoperability testing, hybrid cryptography deployments, crypto-agile PKI architecture design, and enterprise-scale implementation programs. This structured approach enables organizations to move from fragmented cryptographic visibility to a governed, measurable, and sustainable PQC migration program.
CBOM Secure
A successful post-quantum transition begins with visibility. Encryption Consulting’s CBOM Secure provides continuous discovery and inventory of cryptographic assets across enterprise infrastructure, cloud environments, applications, and cryptographic services.
Unlike a point-in-time inventory, CBOM Secure continuously generates and consumes Cryptographic Bills of Materials (CBOMs) while tracking certificates, keys, algorithms, and cryptographic dependencies across the environment. It provides visibility into what is deployed, where it is running, and how those dependencies evolve over time.
The platform supports policy-driven governance by validating cryptographic configurations against organizational standards, identifying deviations, and highlighting security, operational, and compliance risks. For organizations preparing for PQC migration, CBOM Secure helps identify systems that rely on quantum-vulnerable algorithms, prioritize remediation efforts, and establish the continuous cryptographic governance required to achieve long-term crypto-agility.
PQC migration touches every layer of cryptographic infrastructure. Encryption Consulting’s advisory services and product portfolio are designed to address that full scope, from initial discovery through long-term operational crypto-agility.
Conclusion
Most organizations begin PQC migration expecting a cryptographic upgrade. What they discover is an enterprise transformation effort that touches technology, governance, procurement, vendor management, operational resilience, and long-term risk management.
The standards are available, regulatory expectations are becoming clearer, and vendor support continues to evolve. Yet the organizations making the most progress are not necessarily those deploying PQC algorithms first. They are the organizations building visibility into their cryptographic landscape, engaging vendors early, modernizing PKI infrastructure, and establishing the governance needed to manage cryptographic change over time.
PQC migration is not a project with a single finish line. It is the beginning of a new operating model in which cryptographic change becomes a continuous business and security requirement. The organizations that build crypto-agility as a long-term capability today will be best positioned to navigate not only the transition to PQC, but every cryptographic transition that follows.
