Migrating from Microsoft ADCS to a Modern PKI Platform

Microsoft Active Directory Certificate Services (ADCS) has quietly issued the majority of internal enterprise certificates for the past two decades. It was cheap, bundled with Windows Server, and tightly integrated with Active Directory — the perfect choice when "PKI" mostly meant smart-card logon, Wi-Fi auth, and a handful of internal TLS endpoints.

That world is gone. With 47-day public TLS lifespans landing, machine identities outnumbering humans 50:1, and NIST's post-quantum standards forcing algorithm changes across every certificate, most ADCS deployments are now the single most fragile component in the enterprise security stack. This article lays out why teams are migrating off ADCS, what a modern replacement looks like, and how to execute the cut-over without breaking production.

Why ADCS Is Becoming a Liability

ADCS itself still works. The problem is the operating model around it.

• No real lifecycle management. ADCS issues certificates. It does not discover them, monitor expiry, rotate keys, or revoke at scale. Most enterprises bolt on spreadsheets, PowerShell, and a ticket queue — which is exactly the model that fails when lifespans shrink to 47 days.
• Weak crypto agility. Algorithm changes (SHA-1 → SHA-2, RSA-2048 → RSA-3072, classical → ML-DSA) require template rewrites, CA re-issuance, and in many cases a full hierarchy rebuild. There is no clean path to swap algorithms across millions of endpoints.
• Security exposure. ESC1–ESC15 misconfiguration classes (popularised by SpecterOps' Certified Pre-Owned research) turn a misconfigured certificate template into domain-wide privilege escalation. Most ADCS environments have at least one of these live today.
• Operational fragility. The CA database is a Jet/ESE file. HSM integration is optional and often skipped. Offline root ceremonies are rare. Backups are inconsistent. Recovery from a compromised or corrupted CA is measured in weeks.
• Limited protocol support. ADCS speaks DCOM, RPC, and a partial implementation of MS-WCCE. Modern workloads expect ACME, EST, SCEP, CMPv2, and REST. Cloud-native and Linux estates end up with parallel, unmanaged PKIs.
• AD-coupled trust. Every certificate path ultimately depends on a domain controller being reachable and healthy. Zero-trust and hybrid-cloud architectures want the opposite.

What "Modern PKI" Actually Means

A modern replacement is not just "ADCS in the cloud." It is a different operating model built around four pillars:

1. Discovery and inventory. Continuous network and cloud-API scanning to find every certificate — including the shadow ones nobody documented. You cannot manage what you cannot see.
2. Automated lifecycle management (CLM). Enrollment, renewal, rotation, and revocation driven by ACME, EST, or platform-native APIs. Humans approve policy; machines execute issuance.
3. Crypto agility. Algorithm and key-size changes applied by policy, not by template edits. Hybrid and post-quantum certificates (ML-DSA, ML-KEM, composite) supported out of the box.
4. Hardened issuance. Roots offline in FIPS 140-3 Level 3 HSMs. Issuing CAs in network HSMs or cloud KMS. Policy-as-code with audit trails that satisfy CA/B Forum, WebTrust, and internal SOX controls.

Choosing a Target Platform

Most enterprises end up in one of three buckets:

• Managed PKI-as-a-Service — DigiCert ONE, Sectigo Certificate Manager, GlobalSign Atlas, Keyfactor Command (SaaS). Lowest operational burden, fastest crypto-agility upgrades, predictable cost per identity.
• Self-hosted modern CA — EJBCA Enterprise, Keyfactor EJBCA SaaS, HashiCorp Vault PKI, Smallstep. Higher control, lower per-cert cost at large scale, but you own the HSMs, the audits, and the upgrade path.
• Cloud-provider PKI — AWS Private CA, Azure Key Vault Managed HSM + CA, GCP Certificate Authority Service. Excellent for workloads inside a single cloud, weaker for hybrid or multi-cloud estates.

The decision driver is rarely the CA software itself — it is the CLM layer in front of it. Pick the CLM first, then the issuing CA.

A Phased Migration Plan

A safe ADCS migration is measured in months, not weekends. The pattern below has worked across regulated and unregulated enterprises alike.

Phase 1 — Discover and Baseline (Weeks 1–4)

• Run a full certificate discovery: network scan, AD query, cloud APIs, Kubernetes secrets, load balancers, F5/NetScaler stores, container registries.
• Export every ADCS template and audit it against the SpecterOps ESC criteria. Document owners.
• Capture issuance volume by template, by subject pattern, and by consuming system. This dataset drives every later decision.

Phase 2 — Stand Up the New PKI in Parallel (Weeks 4–10)

• Build the new offline root and issuing CAs with HSM-backed keys. Do not import ADCS keys — start clean.
• Cross-sign or chain-trust only where strictly required for transition.
• Deploy the CLM platform and integrate it with AD, Intune, ServiceNow, and your secrets manager.
• Distribute the new root via GPO, MDM, and configuration management so trust is in place long before any certificate is issued from it.

Phase 3 — Migrate by Workload, Not by Template (Weeks 8–20)

Migrate one consuming system at a time, in this rough order of risk:

1. New workloads — point them at the new CA from day one.
2. Linux, Kubernetes, and cloud workloads via ACME/EST — usually the easiest wins.
3. Web servers, load balancers, and reverse proxies — automate with ACME where possible.
4. Wi-Fi, VPN, and 802.1X — coordinate with NAC and RADIUS owners.
5. User certificates (smart card, S/MIME) — last, because they touch every endpoint.

For each workload, run old and new in parallel until the new issuance is proven, then revoke and decommission the ADCS-issued cert.

Phase 4 — Retire ADCS (Weeks 20+)

• Stop issuance on the old CA but keep it online for CRL/OCSP responses until every issued certificate has expired or been revoked.
• Archive the CA database and audit logs per your retention policy (typically 7–10 years for regulated industries).
• Remove the old root from trust stores only after a final discovery scan confirms zero dependent endpoints.
• Decommission the CA servers, HSMs, and AD objects. Document the wind-down in your compliance evidence pack.

Common Pitfalls

• Treating it as a CA swap. The CA is 10% of the work. CLM, discovery, and consumer onboarding are the other 90%.
• Forgetting the CRL. Decommissioning ADCS before its CRLs expire breaks every cert it ever issued. Plan the CRL tail-off explicitly.
• Skipping HSM-backed roots. A software-key root in 2026 will not pass any serious audit and cannot be trusted to outlive the project.
• Ignoring post-quantum. If the new platform cannot issue ML-DSA or hybrid certificates today, you will be doing this migration again within five years. Make PQ support a hard requirement, not a nice-to-have.
• No rollback plan per workload. Every cut-over needs a documented "revert to ADCS-issued cert" procedure until the new issuance has run through at least one full renewal cycle.

Bottom Line

ADCS earned its place, but it was built for a world of long-lived certificates, static algorithms, and a single Windows estate. The 47-day TLS mandate, post-quantum migration, and explosion of non-human identities have all moved the goalposts. A modern PKI — automated, crypto-agile, HSM-anchored, and decoupled from Active Directory — is now the baseline.

Plan the migration as a 6–12 month program, lead with discovery and CLM, and migrate by workload rather than by template. Done well, the result is a PKI that quietly handles the next algorithm change, the next lifespan cut, and the next compliance regime without another rebuild.