PQC Migration in 2026: Building a Roadmap That Survives Contact With Production

On May 13, 2026, Microsoft shipped general availability of ML-DSA support in Active Directory Certificate Services on Windows Server 2025, taking post-quantum cryptography out of documentation and into the boxes most enterprise PKIs actually run on. Three weeks earlier, the same teams were still arguing with auditors over whether their CA hierarchies could even be inventoried. The gap between those two conversations is what makes 2026 the year a PQC migration roadmap stops being a discussion artifact and becomes a delivery program with named owners, line-item budget, dependency lists, and quarterly compliance reporting.

This article is for PKI architects, infrastructure leads, and CISOs who need to convert that program from slide deck to runbook. We will walk through the regulatory pressure map shaping 2026 plans, the inventory problem nobody wants to look at directly, the three migration strategies that actually fit different risk profiles, why PKI is the rate-limiting step in any honest roadmap, what a phased rollout looks like when ML-DSA signatures are roughly forty-eight times the size of ECDSA, and how to instrument the program so it survives the next eighteen months of standards churn and platform updates.

The 2026 Pressure Map

The shift from “we should plan” to “we need to ship” happened on a calendar, not in theory. Seven anchors now define the planning horizon any enterprise roadmap has to respect, and none of them is more than nine years away.

Anchor	Source	Date	Operational meaning
FIPS 203 / 204 / 205 finalized	NIST	August 13, 2024	ML-KEM, ML-DSA, SLH-DSA are production-eligible standards, not drafts
HQC selected as backup KEM	NIST	March 11, 2025	Algorithm diversity in the KEM lane; draft FIPS expected 2026, final 2027
EU NIS CG PQC Roadmap	European Commission, NIS Cooperation Group	Published June 23, 2025	Member State national plans due by December 31, 2026
FIPS 140-2 modules moved to Historical	NIST CMVP	September 21, 2026	Federal procurement requires FIPS 140-3 validated modules; FIPS 140-3 validation backlog averages over 500 days
ADCS ML-DSA GA on Windows Server 2025	Microsoft	May 2026 update	First mainstream enterprise CA platform issuing PQC certificates in production
CNSA 2.0 acquisition gate	NSA	January 1, 2027	New National Security System acquisitions must support ML-KEM-1024 and ML-DSA-87
NIST IR 8547 algorithm phaseout	NIST	2030 deprecation, 2035 disallowed	RSA-2048 / ECC P-256 deprecated 2030; quantum-vulnerable algorithms disallowed by 2035

Read horizontally, this is not a 2035 problem. The procurement deadlines, FIPS 140 transitions, and platform availability shifts cluster between the last quarter of 2026 and January 1, 2027. Organizations selling into federal, NSS, or critical-infrastructure markets either ship CNSA 2.0 capability inside that window or they exit the bid. Even unregulated enterprises are caught indirectly: their vendors are now writing CNSA 2.0 requirements into RFPs, and procurement officers in regulated sectors are starting to require PQC roadmaps as part of due diligence. The window where “we will start planning next year” is a defensible answer to a board question closes in the third quarter of 2026.

Why HNDL Is Not a Hypothetical

The phrase “harvest now, decrypt later” has been recycled into marketing copy enough times that some teams have started treating it as future tense. It is not. Collection is happening on present-day infrastructure: nation-state actors capture TLS sessions, IPsec tunnels, and stored encrypted backups today, retain them, and wait for a cryptographically relevant quantum computer (CRQC) to make the wrapped keys retrievable. The EU’s draft NIS2 amendment released in early 2026 names HNDL attacks as “likely occurring already now,” which is the most explicit attribution any major regulatory text has made to date.

Two implications follow. First, encryption migration matters more urgently than signature migration for any data with a confidentiality requirement longer than the projected CRQC arrival window. Banking transaction records, healthcare records under HIPAA retention, intellectual property tied to product lifecycles, classified material, citizen records under GDPR, and merger-and-acquisition working documents all qualify. Second, signature migration matters most for long-lived signing identities (root CAs, code-signing certificates, firmware update keys) where the signature must remain trustworthy for years after issuance. A forged signature has a different threat model than a decrypted message, but asset lifetime determines urgency in both cases.

The takeaway: prioritize ML-KEM rollout for confidentiality-critical channels first, and sequence ML-DSA into the signing identities with the longest tails. Any other ordering inverts the actual risk model.

What Standards Are Actually Shippable Today

Five algorithms now sit inside or near production-eligible NIST standards. Knowing which to deploy where is the difference between a migration roadmap and a procurement document.

Algorithm	Standard	Type	Production status in mid-2026
ML-KEM (Kyber)	FIPS 203	Key encapsulation	Primary KEM; ML-KEM-768 for civilian, ML-KEM-1024 for CNSA 2.0
ML-DSA (Dilithium)	FIPS 204	Digital signature	Primary signature; ML-DSA-65 civilian, ML-DSA-87 CNSA 2.0
SLH-DSA (SPHINCS+)	FIPS 205	Stateless hash-based signature	Conservative fallback; not in CNSA 2.0; large signatures
HQC	Draft FIPS expected 2026, final 2027	Backup KEM (code-based math)	Crypto-agility reserve in case lattice math breaks
FN-DSA (Falcon)	Draft FIPS 206, expected late 2026 or early 2027	Compact signature	Not in CNSA 2.0; smaller signatures than ML-DSA but harder to implement safely

The CNSA 2.0 parameter selections matter and tend to catch civilian teams off guard. Roadmaps that default to ML-KEM-768 and ML-DSA-65 are not portable into NSS environments without rework. Any product team selling into the defense industrial base needs to plan for ML-KEM-1024 and ML-DSA-87 from day one, with the larger key, ciphertext, and signature sizes those parameter sets imply. CNSA 2.0 also explicitly disallows HashML-DSA (the pre-hash variant) and does not plan to add future NIST PQC algorithms like FN-DSA. The suite is intended to remain stable through the transition, which simplifies vendor planning at the cost of flexibility.

The Inventory Problem Nobody Wants to Look At

Discovery is where every PQC roadmap stalls, and the failure mode is consistent: teams scope the cryptographic inventory to the assets they already manage and miss the ones causing the actual risk. A credible inventory in 2026 has to span at least six discovery surfaces.

Endpoint and server scanning catches cryptographic libraries (OpenSSL, BoringSSL, BCFIPS, the .NET cryptography stack) and their versions. Network discovery captures TLS configurations on live ports, including the fingerprints that reveal which clients still negotiate RSA key exchange or SHA-1 signatures. CA APIs and Certificate Transparency logs surface publicly issued certificates, but CT logs only capture publicly-trusted issuance; private CAs (the majority of enterprise PKI) require direct integration with AD CS or whichever platform issues internal trust. HSM inventories show key material but not the certificates those keys back, so HSM partition mapping needs cross-referencing with CA databases.

CMDB and infrastructure-as-code repositories surface the configuration that ties cryptography to applications, which is where shadow crypto lives: hardcoded algorithm strings in legacy Java code, SSH keypair sprawl across CI/CD systems, signed JAR files with embedded certificates, hardcoded private keys committed to repositories. Vendor disclosures and SBOMs close the gap on third-party libraries, particularly for embedded systems and IoT.

Manual audits return a snapshot that is stale before the spreadsheet closes. Automated continuous discovery is the only approach that holds up at enterprise scale, and it has to be re-run on a schedule because the cryptographic estate changes daily as containers spin up, vendors push updates, and engineers commit new code. The inventory should record, for each artifact: algorithm and parameters, key size, issuer, expiration, business owner, technical owner, data classification, system criticality, and replacement complexity. Without those fields, the inventory cannot feed risk scoring.

A useful pre-flight test: ask the team to list every X.509 certificate that will expire in the next 90 days. If the answer is “we’d have to check,” the inventory is not ready to feed a migration roadmap, and the roadmap is going to ship with blind spots.

Three Migration Strategies, Three Risk Profiles

The literature offers many ways to slice migration approaches. In practice, three patterns describe what most enterprises actually deploy in 2026, and the choice between them is driven by regulatory exposure and the cost of an algorithm being wrong.

Strategy	What it means	Best fit	Trade-off
Staged migration	Migrate key establishment to ML-KEM first; signatures to ML-DSA in a later wave	Organizations with heavy HNDL exposure but constrained PKI change capacity	Defers signature complexity but leaves classical signing identities exposed for years
Hybrid cryptography	Combine classical (e.g., X25519, ECDSA) with PQC in a single operation; both must hold for security	Regulated industries, high-assurance environments, anyone wary of young PQC math	Doubles cryptographic artifact size, complicates testing, creates a second migration (hybrid to pure PQC) downstream
CNSA 2.0 alignment	ML-KEM-1024, ML-DSA-87, AES-256, SHA-384 / SHA-512 across the board	NSS, defense industrial base, federal contractors	Stricter parameters than the civilian default; larger keys, signatures, ciphertexts; longer HSM and platform readiness timeline

Hybrid deserves a specific note. Microsoft’s ADCS implementation supports composite certificates that pair a classical signature (RSA or ECDSA) with an ML-DSA signature, requiring both to validate for the certificate to be trusted. The composite approach is operationally cleaner than parallel dual-stack hybrid because the certificate is a single artifact, but it inflates chain sizes and demands relying parties that understand the composite format. Plan for both forms during the transition window. The 2030 to 2035 NIST IR 8547 phaseout will eventually disallow the classical component, and any hybrid construction that weakens the PQC half will not survive that boundary; NIST has flagged this point explicitly in IR 8547 public comments.

The crypto-agility decision underneath all three patterns is the same. None of these strategies survives without an architecture that can swap algorithms via policy rather than code change. That is the operational capability worth building first, regardless of which migration pattern the rest of the program selects.

PKI Is the Rate Limiter

PKI is the longest pole in any PQC migration tent, and the reasons are arithmetic.

ML-DSA-87 produces signatures of approximately 4,627 bytes. ECDSA P-384 produces signatures of approximately 96 bytes. A four-cert chain (root, intermediate, issuing, leaf) replicates that size delta across every TLS handshake, every OCSP response, every authenticated session establishment. The downstream consequences are increased bandwidth, more handshake round trips, MTU fragmentation on path segments that did not anticipate the change, and pressure on HSM throughput because PQC signature operations process more bytes internally. Pre-hashing helps mitigate the HSM impact, and CNSA 2.0 explicitly disallows it for that suite, which puts NSS deployments in the position of needing more capable HSMs rather than smarter pre-processing.

Certificate chains also have hierarchical sequencing problems that the algorithm choice cannot help with. Migrating a leaf certificate to ML-DSA without first migrating the issuing CA breaks validation. Migrating the issuing CA without first migrating the offline root produces a chain rooted in classical math, undermining the migration purpose.

HSM readiness compounds the timeline. SafeNet Luna and Thales platforms have published firmware support for ML-DSA on current-generation hardware, but older modules require hardware refresh, partition restructuring, and KSP reconfiguration on every Windows server that consumes them. The May 2026 ADCS update relies on Key Storage Provider selection with Signature flagged in Request Handling, and any CA with an HSM partition that was registered by serial rather than slot label needs a fresh KspConfig pass before it will see the new algorithms in the dropdown.

Plan eighteen to twenty-four months from procurement decision to a steady-state PQC-rooted internal CA. Plan longer if you cross forests or have dependent middleware: NDES, Intune SCEP connectors, Java keystores, and code-signing pipelines all have their own readiness curves that the CA migration cannot bypass.

The punchline: every other PQC migration step depends on PKI, and PKI is the slowest thing to move.

A 2026 Operator’s Sequence

The following is the sequence we use when an enterprise asks what the first eighteen months of a PQC migration actually look like. It assumes a Microsoft-heavy estate with a two-tier AD CS hierarchy, HSM-backed roots, and a mix of classical TLS, S/MIME, and code-signing workloads. Adjust the depth of each step to the environment; do not reorder them.

1. Stand up continuous cryptographic discovery. Deploy an automated scanner across endpoints, network segments, CA databases, HSM partitions, container images, and code repositories. Output a living inventory keyed to business owner, expiration date, algorithm, parameter set, and data sensitivity. Without this, every later step is guesswork dressed as planning.
2. Score risk by data confidentiality lifetime, not asset count. Build a risk matrix that ranks certificates and keys by how long the data they protect must remain confidential, weighted by HNDL exposure and system criticality. A 90-day TLS cert for a marketing site ranks below a code-signing key whose signatures need to validate for ten years. Prioritization by count produces a backlog dominated by low-value assets.
3. Build a non-production ML-DSA test hierarchy. On a lab Windows Server 2025 environment with the May 2026 update applied, stand up a parallel two-tier AD CS hierarchy using ML-DSA-65 for the issuing CA and ML-DSA-87 for the offline root. Issue test certificates for code signing, web server authentication, computer authentication, and user authentication. Document what works today (code signing is the cleanest scenario), what is partial (TLS web server, certain authentication scenarios), and what is not yet supported (broad TLS, VPN, Remote Desktop). The gap analysis from this lab is the basis for every subsequent production decision.
4. Pilot hybrid TLS on a contained workload. Pick a single internal application with a low blast radius. Configure its TLS endpoint for X25519MLKEM768 hybrid key exchange against modern clients. Measure handshake size, latency, certificate chain size, and HSM throughput against the classical baseline. Document the deltas, including the MTU and load-balancer behavior that the larger handshake triggers. These numbers, not vendor whitepapers, are what production sign-off will hinge on.
5. Pre-stage HSM and CA platform readiness. Audit every HSM partition against vendor firmware levels supporting ML-DSA. Schedule firmware updates inside maintenance windows that respect the offline-root ceremony cadence. For CA platforms, validate that AD CS or your CLM platform can issue PQC certificates, and that downstream consumers (Intune, NDES, code-signing pipelines, certificate-consuming applications) can request, deliver, and validate them. Note that ADCS PQC issuance currently requires KSP selection with Signature set in Request Handling, and certain template versions need to be republished.

None of these steps requires a cryptographically relevant quantum computer to exist. All of them are blocked by the discovery problem in step one, which is why every credible PQC program assigns an inventory owner before it assigns anyone else.

How CertSecure Manager Delivers PQC-Ready Certificate Lifecycle Management

CertSecure Manager (CSM) is built to operate as a CA-agnostic certificate lifecycle layer across classical, hybrid, and PQC certificate populations, which is the deployment shape PQC migration actually demands.

Multi-CA orchestration: CSM brokers issuance and renewal across Microsoft AD CS, other enterprise CA platforms, and public CAs from a single policy plane, so a shift from RSA to ML-DSA on the back-end CA does not break the consuming application’s enrollment workflow.

Continuous cryptographic discovery: Endpoint and network scanners feed CSM with a real-time inventory of certificates, algorithms, parameter sets, key sizes, and expiration windows, mapped to business and technical owners and data sensitivity.

Policy-driven crypto-agility: Algorithm selection lives in policy, not application code. Switching a certificate population from ECDSA P-384 to ML-DSA-65 becomes a policy update, not a redeployment, which is the only way to keep up with FIPS 140 and CNSA 2.0 timelines.

Composite and hybrid certificate support: CSM is being extended to handle the Microsoft-defined ADCS composite certificate format and the IETF hybrid certificate patterns, so transitional artifacts validate end to end across consuming applications.

How Can Encryption Consulting Help?

Encryption Consulting has spent more than a decade implementing PKI, cryptography, and CLM programs for regulated enterprises across financial services, healthcare, energy, telecom, and manufacturing. At the center of our PQC delivery is CertSecure Manager, a CA-agnostic certificate lifecycle platform that orchestrates issuance, renewal, discovery, and policy across Microsoft AD CS, other enterprise CA platforms, and public CAs (classical, hybrid, and PQC) from a single control plane.

We complement that with our PQC Advisory Services for migration planning and crypto-agility roadmaps, PKI Services for assessment and modernization of enterprise CA hierarchies, and HSM Services for SafeNet Luna and Thales platforms ready for ML-DSA. To start your roadmap, reach out at [email protected] or visit www.encryptionconsulting.com.

Frequently Asked Questions

What is PQC migration?

PQC migration is the program of replacing quantum-vulnerable cryptographic algorithms (RSA, ECDSA, ECDH, Diffie-Hellman) across an organization’s systems, applications, certificates, keys, libraries, and protocols with quantum-resistant algorithms standardized by NIST in FIPS 203, 204, and 205. It is a multi-year program rather than a single-event upgrade and touches PKI, identity, network, application, and procurement workstreams simultaneously.

Why is 2026 the year PQC migration moved from planning to delivery?

Three independent dates converge in late 2026 and early 2027: NIST’s FIPS 140-2 to Historical transition on September 21, 2026, the EU NIS Cooperation Group’s national strategy milestone on December 31, 2026, and the NSA CNSA 2.0 acquisition gate on January 1, 2027. All three convert advisory guidance into procurement, audit, and compliance teeth that affect contracts being signed today.

What is harvest now, decrypt later (HNDL), and why does it matter today?

HNDL describes adversaries capturing encrypted data today and storing it for future decryption once a cryptographically relevant quantum computer is available. It matters today because data captured now is already exposed. The encryption migration has to happen before the CRQC exists, not after, and the EU’s draft NIS2 amendment from early 2026 explicitly names HNDL attacks as occurring already.

What is the difference between ML-KEM and ML-DSA?

ML-KEM (FIPS 203, formerly Kyber) is a key encapsulation mechanism used for establishing shared keys, replacing classical key exchange like ECDH. ML-DSA (FIPS 204, formerly Dilithium) is a digital signature algorithm replacing classical signature schemes like ECDSA and RSA signing. The two solve different problems and migrate on different timelines.

Does AES-256 need to be replaced as part of PQC migration?

No. AES-256 is symmetric encryption and is considered quantum-resistant when correctly implemented. PQC migration focuses on public-key cryptography (RSA, ECDSA, ECDH) used in key exchange and digital signatures, where Shor’s algorithm provides a quantum advantage. Symmetric algorithms only need their key sizes adjusted to account for Grover’s algorithm, which AES-256 already accommodates.

What are the NIST IR 8547 deprecation deadlines?

Under the initial public draft of NIST IR 8547 (November 2024), algorithms providing 112-bit security (RSA-2048, ECC P-256) are deprecated by 2030. All quantum-vulnerable public-key algorithms are disallowed in NIST standards by 2035, aligning with National Security Memorandum 10’s target date. The 2030 to 2035 window is a controlled migration period, not a free pass.

Is hybrid cryptography required during PQC migration?

Hybrid is not universally required, but it is recommended for high-assurance environments and is used by Microsoft’s ADCS implementation in the form of composite certificates pairing a classical and an ML-DSA signature. Civilian deployments may go directly to pure PQC for new artifacts; regulated environments often run hybrid through the transition window for defense in depth.

How does Microsoft AD CS support PQC in 2026?

The May 2026 Windows Server 2025 update introduced general availability of ML-DSA-44, ML-DSA-65, and ML-DSA-87 in AD CS, allowing issuing and offline root CAs to sign certificates with quantum-resistant algorithms. Code signing scenarios work reliably as of mid-2026; broader TLS, VPN, and Remote Desktop scenarios remain partially supported and require workload-by-workload validation.

Does CertSecure Manager support PQC certificates today?

CertSecure Manager operates as a CA-agnostic lifecycle layer that brokers issuance across Microsoft AD CS, other enterprise CA platforms, and public CAs, with policy-driven algorithm selection that includes ML-DSA where the back-end CA supports it. Composite and hybrid certificate support is being extended to cover the Microsoft ADCS and IETF formats, and discovery, automation, and compliance reporting are already production-ready.

What is the single most important first step for a PQC migration roadmap?

Continuous cryptographic discovery. Until an organization knows where its cryptographic dependencies actually live (algorithms in code, libraries in containers, certificates in CA databases, keys in HSMs, hardcoded secrets in CI/CD), risk cannot be scored, priorities cannot be assigned, and migration progress cannot be measured. Every credible PQC program assigns an inventory owner before it assigns anyone else.

Conclusion

The forces converging on 2026 are no longer abstract. NIST has shipped three standards and a fourth backup; the NSA has set January 1, 2027 as the new acquisition gate; the European Commission has anchored Member State strategies to December 31, 2026; Microsoft has placed ML-DSA inside the platform most enterprise PKIs already depend on. Each of these turns a planning document into a delivery requirement, and each carries a procurement or audit consequence that lands well before 2030.

The operational evidence is equally concrete. PQC signatures are larger than classical signatures by roughly two orders of magnitude. HSM firmware is not uniformly current. PKI hierarchies sequence from root outward, and that ordering takes months. Discovery is the universal blocker. Cryptographic inventory is still a project before it can be a system. Every enterprise that has tried to shortcut these steps has discovered they cannot be shortcut, only paid for later in incident response cost, audit findings, and procurement disqualifications.

In cryptography, the calendar wins. The 2030 deprecation date is closer than the gap between the last NIST PQC competition round and today. The roadmap that survives contact with production is the one whose first step starts now.