Migrating off Microsoft ADCS: The No-Downtime Playbook

Why ADCS Became a Migration Project, Not an Upgrade

Active Directory Certificate Services was a good answer to the 2005 question: how do we issue user and machine certificates to domain-joined Windows machines? Group Policy auto-enrollment, templates with human-readable names, and a free CA bundled with the operating system you were already licensing. For twenty years that was enough.

The problems you have now are different. Your workloads are Kubernetes pods, iOS devices, Linux CI runners, cloud functions, OT gateways, and IoT fleets. Your renewal cadence is weeks, not years - and in 2029 it will be 47 days. Your auditor doesn't accept "we exported the Windows event log" as evidence. Your Windows Server 2012 R2 CA stopped getting support in October 2023. The team that stood ADCS up has mostly left.

ADCS can be made to serve some of this, but every workaround is a Windows service: NDES for SCEP, a custom web enrollment page for REST, an HSM integration that nobody has rotated, a CRL distribution point that is secretly a file share. The architecture diagram keeps growing boxes.

This guide is the opposite. It walks through replacing ADCS with a modern CA on a timeline that doesn't require a change-freeze window the size of a quarter.

The Three Migration Patterns (And Which One You Want)

Big-bang cutover

Stand up the new CA, flip DNS, deprecate ADCS. This is how most 2010-era CA migrations ran. It is also why most teams you talk to have a horror story about a certificate migration.

Avoid this. It is only tractable if your estate is small enough to fit in one person's head and your relying parties all accept the new root instantly, which they do not.

Hard cutover with new root

Stand up the new CA with a brand-new root. Push the new root to every trust store. Reissue every certificate the moment it is up for renewal. Retire ADCS when the last ADCS-issued cert expires.

This works for small estates (hundreds of certs) with simple consumers (web servers, APIs). It falls over the moment you have a device fleet, a Jamf server, an Intune tenant, a FortiGate, or anything that pins the trust anchor.

Shadow issuance + dual-trust (the one you want)

Mirror every ADCS issuance in the new CA while ADCS keeps serving production. Push both roots to every trust store. Prove parity for weeks. Then flip the SCEP profile / enrollment URL and let natural renewal replace the old certs over their lifetime. Retire ADCS when the last old cert expires.

This is the pattern TigerTrust is designed around. The rest of this guide walks through it concretely.

Phase 1: Inventory Before You Touch Anything

Before any CA work, build an inventory of what ADCS is actually issuing. The common surprise: templates in your ADCS console that haven't issued in years, and shadow issuance paths that exist outside your console.

Capture, for every certificate currently in your estate:

• Issuing CA chain - which ADCS forest, which intermediate, which template
• Consumer - who is relying on this cert (which load balancer, which device fleet, which app)
• Enrollment protocol - auto-enrollment via GPO? NDES/SCEP? Web enrollment? REST wrapper?
• Expected validity - the template says 1 year; the cert says 2 years; something is wrong
• Owner - the human who owns the renewal

TigerTrust discovery agents will populate most of this automatically against your running estate. Export the result; this is the migration spec.

Phase 2: Import Your Templates

ADCS templates encode years of real decisions - EKUs, SANs, validity windows, autoenroll settings, key sizes, allowed cryptographic algorithms. You don't want to rewrite them. You want to read them.

TigerTrust's ADCS Migration tab connects to a running ADCS forest, enumerates the certificate templates, and converts each one into a profile:

• EKUs → eku list on the SCEP / EST profile
• SAN rules → subject + SAN rewrite rules (with CEL expressions where templates had scripts)
• Validity window → maxValidityDays on the profile, clamped by the issuing CA's own policy
• Key size / algorithm policy → algorithmPolicy with explicit allow-lists
• Autoenroll settings → mapped to the issuance policy; renewals move to ACME or EST on cutover

You review the diff. For every template, you can decide: import as-is, modify, or skip. Templates that haven't issued in 90 days usually get skipped - this is where the shadow template cleanup happens.

Phase 3: Shadow Issuance

This is the migration pattern's load-bearing idea. For every real issuance that ADCS performs, TigerTrust mirrors the request against the new CA and records what it would have issued. Nothing goes to the client; nothing hits production. The point is parity proof.

The implementation is a worker that intercepts the enrollment request (SCEP, NDES, auto-enrollment, or REST) and, after ADCS has responded to the real client, replays the same request against the new CA. Both responses land in a side-by-side diff table.

What you watch for:

• Divergent SAN contents - usually a rewrite rule that didn't make it across
• Different EKUs - usually a template setting that was modified without updating documentation
• Different validity - usually a per-CA policy clamping the template value
• Different key size - usually a template that permits weak keys you want to shut off

Run shadow issuance for four to eight weeks. The length is set by two things: how long until you've seen every template exercised, and how much parity proof your change-approval board wants.

Phase 4: Dual-Trust the New Root

With parity proof in hand, the next step is making the new root trusted everywhere the old root is trusted. "Everywhere" is longer than it looks:

• Windows domain machines - GPO installer, no reboot required
• MDM-managed Apple / Android / Windows devices - Jamf, Intune, Workspace ONE, SOTI, Google Workspace, Kandji, Mosyle
• Linux servers - update-ca-trust / update-ca-certificates via agent or configuration management
• Network appliances - FortiGate, PaloAlto, Cisco ISE, F5 BIG-IP, Juniper SRX, Check Point, Aruba ClearPass, Juniper Mist, Meraki
• Kubernetes clusters - cert-manager CA bundle, ingress controller trust store
• CI/CD - GitHub Actions trusted roots, GitLab CI, Jenkins

TigerTrust ships adapters for each of these. The CA rotation wizard walks you through the push, tracks per-appliance status, and surfaces drift (an appliance that was reachable yesterday and isn't today). You enter the "dual-trust" state when every appliance confirms both roots are trusted.

Phase 5: Promote

Flip the SCEP profile / enrollment endpoint from ADCS to TigerTrust. From this point onward, new issuance and renewal flows go to the new CA. The old CA continues to validate its outstanding certs (OCSP + CRL) but issues nothing new.

The CA rotation wizard supports scheduling this transition for a change window ("promote at Sunday 02:00 UTC"). The scheduler worker advances the state when the time arrives - operators don't need to be in the room.

Everything is reversible until the next phase.

Phase 6: Retire

Wait out the longest validity window of any ADCS-issued cert still in the field. For most estates that is 1-2 years. During this time, ADCS serves OCSP and CRL and nothing else.

When the last ADCS cert expires, retire. The ADCS root comes out of every trust store, the ADCS server gets a shutdown date, and the Windows Server VM gets reclaimed by the virtualisation team that has been asking for it for years.

Rollback is possible all the way up to this step. After retire, rollback requires rebuilding ADCS from scratch - at which point you were right to be sure before you clicked the button.

What the Timeline Actually Looks Like

For a typical mid-market enterprise (10,000-50,000 certs, 2-5 ADCS forests, Intune or Jamf, a few network appliances):

Total active work: 10-12 weeks. Total elapsed: 12 weeks plus whatever the longest ADCS cert validity is in your fleet.

Larger estates (500,000+ certs, 10+ forests, multiple MDMs, OT) add 4-8 weeks to the shadow phase. Smaller estates (sub-5,000 certs, single forest) can compress to 4-6 weeks total.

What the Migration Doesn't Change

Some things stay. If auto-enrollment via GPO works for your domain-joined Windows machines, you can keep it - the TigerTrust GPO installer pushes the new root and lets Windows do what Windows does. Many teams migrate the enrollment protocol to ACME or EST on the next cert renewal, but it is not required for the cutover.

If you have workloads that pull certs out of Windows cert stores by thumbprint, those keep working too. The cert in the store is still a cert in the store - only the issuing CA changed.

The Compliance Angle

Auditors ask three ADCS-specific questions:

1. Who issued what? - ADCS writes to the Windows event log. The event log rotates. Nobody can tell you what was issued six months ago without a lot of forensic work. TigerTrust emits a signed audit line per issuance, exported to your SIEM in JSON or syslog, retained for your framework's required period.
2. How fast can you revoke? - ADCS CRLs are typically published daily. Delta CRLs are optional and often not configured. Mean time from compromise to fleet-wide revocation can be 24 hours in the pathological case. TigerTrust ships 5-minute CRL cadence with delta CRLs enabled by default, plus global anycast OCSP.
3. Where are the keys? - ADCS can bind to an HSM; the audit trail of key operations lives in the HSM's own log, not the CA's. TigerTrust ships every signing operation through the HSM boundary and emits a signed audit line per operation, with the HSM module ID and operator identity attached.

If any of these show up in your audit findings, the migration pays for itself before Phase 3.

Common Objections (And What To Do About Them)

"We built custom tooling on top of ADCS." - Most custom tooling is either template management or an enrollment wrapper. The template management is covered by the ADCS Migration import. The enrollment wrapper is replaced by the native API; most teams delete 2,000 lines of PowerShell on cutover.

"Our root ceremony is overdue." - This is actually the strongest argument for migration. The new root ceremony happens as part of the TigerTrust onboarding; it is video-recorded, witnessed, and the key material lives in FIPS 140-3 Level 3 HSMs from day one. If you were going to redo the root ceremony anyway, do it on the new CA.

"NDES is working fine for us." - It is working fine until it isn't. NDES is a Windows service running IIS with a service-account password that has to rotate, a URL that has to stay reachable, and a certificate it uses to sign its own responses. The number of production outages caused by NDES is non-trivial. TigerTrust ships native SCEP + Intune integration with no NDES in the path.

"We can't change the trust store on legacy devices." - This is the one real constraint. For devices that are already in the field with the ADCS root pinned and no over-the-air trust-store update path, you keep ADCS as a non-renewing CA for the remaining device lifetime. New device shipments go to the new CA from day one.

Where to Go Next

• If you want the comparison first: TigerTrust vs Microsoft ADCS
• If you want the solution page: ADCS Migration solution
• If you want to see shadow issuance in action: Book a demo and we'll shadow-issue against a scratch workspace with the templates you bring.
• If you want the technical deep-dive: Shadow ADCS: the coexistence pattern

The CA you have is not the CA you want. The migration can be shorter and less painful than the one that's been on your roadmap for three years. Start the inventory this quarter; cut over before the end of the year.