Parallel PKI Migration: Running Classical and PQC CA Hierarchies Together

Quick answer: Running classical and post-quantum CA hierarchies in parallel is not a workaround, it is the only supported path in AD CS and most other current CA platforms, since none support upgrading an existing certification authority to ML-DSA in place. A working parallel-migration architecture needs six pieces working together: a new PQC root established and pushed into every consuming trust store, certificate templates and issuance policies that support the new algorithm, relying-party segmentation so you know exactly which systems can and cannot validate the new hierarchy yet, a documented cross-certification or coexistence approach for the transition window, monitoring that tracks which hierarchy is actually issuing and being validated, and a formal decommissioning plan for the legacy hierarchy once every certificate it issued has expired or been replaced. This guide walks through each piece.

Most PQC migration guidance treats “issue certificates from a new PQC CA” as the whole task. The actual work is everything around that single step: getting the new root trusted everywhere it needs to be, knowing which systems still can’t validate it, and running both hierarchies safely, side by side, for what will likely be years, not weeks.

Key Takeaways

• AD CS and most current CA platforms have no in-place upgrade path to ML-DSA; a parallel hierarchy is the only supported migration method, not an optional architecture choice.
• Trust anchor distribution, pushing the new root into every consuming trust store, is typically the longest-lead-time item in the migration, longer than standing up the CA infrastructure itself.
• Relying-party segmentation, knowing exactly which systems can validate the new hierarchy today versus which cannot yet, is what determines a safe issuance sequencing plan.
• The legacy hierarchy stays operational until every certificate it issued has expired or been replaced; decommissioning is a controlled, dated event, not a switch flipped once the new hierarchy is live.
• A realistic parallel-hierarchy program runs on a multi-year timeline, typically inventory and design in year one, parallel operation and progressive migration in years two and three, decommissioning after that.

Why Parallel Is Mandatory, Not Optional

An existing certification authority cannot be upgraded to ML-DSA in place. This is not a conservative recommendation; it is a hard platform constraint covered in our ML-DSA CA hierarchy configuration guide, and it shapes the entire architecture decision. A new root and, typically, a new subordinate CA structure need to be established alongside the existing classical hierarchy, run in parallel, and migrated to deliberately, with the legacy hierarchy continuing to operate and issue where needed until it is fully retired.

Trust Anchor Distribution: The Longest Pole

A new root CA certificate is useless until it is actually trusted by everything that needs to validate certificates issued beneath it, and distributing a new trust anchor across an entire consuming estate is frequently the slowest part of the whole program, slower than standing up the CA infrastructure itself. For internal enterprise PKI, this means pushing the new root through Group Policy, MDM, or configuration management to every domain-joined machine, server, and managed device, and confirming receipt rather than assuming a push succeeded. For any certificate that needs to be trusted outside your own managed estate, partners, customers, public-facing services, trust anchor distribution depends on parties you do not control, which extends the realistic timeline further. Budget trust distribution and verification as its own workstream with its own completion criteria, not a footnote to standing up the new CA.

Templates and Issuance Policy

The new hierarchy needs its own certificate templates configured for the ML-DSA parameter sets you have selected by tier, and issuance policy needs to explicitly govern which requests route to the legacy hierarchy versus the new one during the transition. This is not automatic: without an explicit routing policy, enrollment can default inconsistently, sending some requests to whichever CA happens to be configured as default rather than the CA appropriate for that certificate type and its relying parties’ current readiness. Define issuance policy by certificate type and target system readiness, not by a single organization-wide cutover date.

Relying-Party Segmentation

This is the piece that determines whether issuance sequencing is safe or reckless. Before issuing certificates broadly from the new hierarchy, segment your relying parties into groups by actual validated readiness: systems confirmed to correctly validate the new ML-DSA hierarchy, systems not yet tested, and systems known to be incompatible for the foreseeable future, such as legacy appliances with no PQC roadmap at all. Issue from the new hierarchy first to the confirmed-ready segment, expand deliberately as more segments validate successfully, and maintain the known-incompatible segment on the legacy hierarchy explicitly and intentionally, rather than as an unaddressed gap discovered when something breaks in production.

Cross-Certification and Coexistence Considerations

Most enterprise parallel-hierarchy migrations run the two hierarchies as fully independent trust chains rather than attempting formal cross-certification between the classical and PQC roots, since cross-certification adds real path-validation complexity for a transition that is meant to be temporary. The simpler, more common pattern is coexistence: both roots are trusted independently by the consuming estate for the duration of the transition, and a given relying party trusts whichever hierarchy issued the certificate it is currently validating, rather than needing a certified trust path between the two roots themselves. Reserve formal cross-certification for the narrower cases where a specific partner or federation relationship genuinely requires a certified trust path between the old and new hierarchies rather than independent trust in both.

Monitoring the Transition

Track, explicitly, which hierarchy is issuing each certificate type and which hierarchy relying parties are actually validating successfully against in production, not just in a lab test. A migration that looks complete in issuance volume but has not been confirmed against real validation telemetry can be masking a segment of relying parties silently failing or falling back in ways that only surface as an outage later. The same negotiated-algorithm observability principle covered in our hybrid PQC decision framework applies directly here: instrument the transition, don’t assume it based on issuance counts alone.

Retirement: A Dated, Controlled Event

The legacy hierarchy is not decommissioned once the new one is live; it remains operational until every certificate it issued has either expired naturally or been actively replaced, at which point retirement can proceed under controlled conditions, following the same change-management discipline as standing up the new hierarchy in the first place. Sequencing which services and certificate types migrate first, typically starting with well-understood, lower-criticality services to validate profile parity and trust distribution before addressing higher-consequence services, is what keeps the legacy hierarchy’s remaining footprint predictable and shrinking on a known schedule rather than lingering indefinitely as an unmanaged tail.

What We’d Actually Recommend

Budget trust anchor distribution as its own multi-quarter workstream, not a footnote, since it is typically the true pacing constraint on the whole program. Build relying-party segmentation before issuing broadly from the new hierarchy, and sequence rollout by validated readiness, not by a fixed calendar date. Choose independent coexistence over formal cross-certification unless a specific partner relationship genuinely requires it, and set an explicit, dated decommissioning target for the legacy hierarchy from the start, tied to when its remaining issued certificates will have expired, rather than leaving retirement open-ended.

How Encryption Consulting Can Help

Relying-party segmentation depends entirely on knowing exactly which systems in your estate can validate ML-DSA today, which is precisely the inventory gap CBOM Secure is built to close, mapping validation capability across your consuming systems so issuance sequencing is based on confirmed readiness rather than assumption.

Our PQC Advisory Services design the full parallel-hierarchy program this guide describes, trust distribution sequencing, issuance policy, relying-party segmentation, and a dated retirement plan for the legacy hierarchy, tailored to your specific estate. CertSecure Manager then operates both hierarchies from a single policy plane during the transition, so running two CA structures in parallel does not mean doubling your operational tooling.

A Program, Not a Cutover

A parallel PKI migration is not a single event, it is a multi-year program with its own sequencing discipline: trust distribution, templates and policy, relying-party segmentation, coexistence, monitoring, and a dated retirement plan for the hierarchy being replaced. The organizations that get through this cleanly are the ones that treat trust anchor distribution as the real pacing constraint, segment their relying parties honestly before issuing broadly, and set a retirement date for the legacy hierarchy from day one rather than letting it become an indefinite tail.

Frequently Asked Questions

Can I avoid a parallel hierarchy and upgrade my existing CA to ML-DSA?

No, not on AD CS or most current CA platforms. There is no in-place upgrade path; a new root and, typically, a new subordinate CA structure must be established alongside the existing hierarchy and migrated to deliberately.

What is usually the slowest part of a parallel PKI migration?

Trust anchor distribution, getting the new root actually trusted by every system that needs to validate certificates issued beneath it, is typically slower than standing up the new CA infrastructure itself, especially for certificates that need to be trusted outside your own managed estate.

Do I need formal cross-certification between the classical and PQC hierarchies?

Usually not. Most enterprise migrations run the two hierarchies as independently trusted, coexisting chains rather than establishing a formal cross-certified trust path, reserving cross-certification for specific partner or federation relationships that genuinely require it.

When can the legacy CA hierarchy be decommissioned?

Only after every certificate it issued has either expired naturally or been actively replaced. Decommissioning is a controlled, dated event that should be planned from the start of the migration, not an open-ended cleanup task.

How should certificate issuance be sequenced across a parallel migration?

By validated relying-party readiness, not a fixed calendar date. Start with systems confirmed to validate the new hierarchy correctly, expand as more segments are tested, and keep known-incompatible systems intentionally on the legacy hierarchy until they have their own migration path.