BlogSupportDocumentation
TigerTrust
Solutions · ADCS Migration

Replace Microsoft ADCS without stopping issuance.

Shadow-issue in parallel with your running Active Directory Certificate Services forest. Prove parity for weeks before you cut over. Promote on a scheduled change window. Retire when the last ADCS cert expires - and rollback stays one click away the whole time.

Book a demoTalk to a PKI architect
Why ADCS migrations stall

The old CA is the one piece of infrastructure nobody wants to touch.

Big-bang cutovers break production. Hard cutovers with a new root miss trust stores. "We will rewrite the templates" ends in a quarter of PowerShell and a cancelled project. The problem is not the destination - it is the migration pattern.

Without a parallel-run plan
  • ADCS running on Windows Server 2012 R2 past end-of-extended-support
  • NDES bolt-on with a service-account password nobody wants to rotate
  • Templates nobody can explain, half of them unused for years
  • Auditors asking for issuance evidence that lives in a rotating event log
  • Every CA change requires a change-advisory board meeting with no risk model
  • Root ceremony overdue by years - and the Crypto Officer has left
With TigerTrust ADCS migration
  • Template importer reads ADCS directly - EKUs, SANs, validity, autoenroll
  • Shadow-issuance mirror runs for weeks against the live request stream
  • CA rotation wizard pushes the new root to every trust store, tracked per-appliance
  • Scheduled auto-advance moves state during the change window - without a human in the room
  • Rollback is a single click up to the retire step
  • ADCS retires when the last ADCS cert expires naturally
Phase 1 · Discover + import

Read your templates - don't rewrite them.

The ADCS Migration tab connects to a running forest, enumerates every certificate template, and converts each one into a TigerTrust SCEP / EST / ACME profile. You review the diff before anything goes live.

How it works
  • EKUs, SANs, validity, key sizes, autoenroll settings preserved
  • Rewrite rules translated from PowerShell into CEL expressions
  • Per-template import / modify / skip decisions in the console
  • Templates idle 90+ days surface for cleanup during import
ADCS template import
Phase 2 · Shadow-issue

Mirror every ADCS issuance before you flip anyone.

For every real cert ADCS issues, TigerTrust issues an identical shadow. Both responses land side-by-side in a diff table. Divergent SANs, EKUs, or validity surface immediately. Nothing hits production until the diff is clean.

How it works
  • Enrollment intercept covers SCEP, NDES, auto-enrollment, and REST
  • Per-request diff: subject, SAN, EKU, validity, key size, algorithm
  • Four- to eight-week parallel run proves parity for your change board
  • Shadow issuance records nothing on the client - zero production risk
Shadow issuance parallel run
Phase 3 · Dual-trust push

Push the new root everywhere the old root lives.

16 vendor adapters, 7 MDM targets, GPO, Linux agent trust-store install, and manual bundle export. The CA rotation wizard tracks per-appliance status, surfaces drift, and gates the promote step on fleet-wide confirmation.

How it works
  • Intune, Jamf, Workspace ONE, SOTI, Kandji, Mosyle, Google Workspace
  • FortiGate, PaloAlto, Cisco ISE, Juniper SRX, Check Point, F5, Aruba, Meraki
  • GPO installer for AD-joined Windows machines, no reboot
  • Agent-driven trust-store sync for Linux hosts (RHEL, Debian, SUSE, Arch families)
Dual-trust trust-anchor push
Phase 4 · Promote + retire

Scheduled transitions - no human-in-the-window.

The CA rotation state machine advances dual-trust → promoted → retired on timestamps you set. Operators plan Sunday 02:00 UTC the week before; the scheduler worker fires on time; the state advances; the audit log records who scheduled what.

How it works
  • scheduledPromoteAt / scheduledRetireAt timestamps per rotation
  • Scheduler polls every 5 min, advances when due, clears on advance
  • Signed audit event per transition: who, when, what moved
  • Rollback remains one click until retire
Scheduled CA rotation
The pieces that make it work

A migration pattern backed by product, not consulting.

Every phase above is a feature in the console - not a professional-services engagement.

ADCS template import
Reads templates from a running forest and converts to TigerTrust profiles. Reviewable diff per template.
Shadow issuance worker
Mirrors every ADCS issuance against the new CA. Side-by-side diffs. No client-visible effect.
CA rotation state machine
pending → dual-trust → promoted → retired, with rollback from any pre-retired state.
Trust-anchor push adapters
16 network/MDM vendors covered natively. GPO + agent for the rest. Per-appliance sync status.
Signed audit stream
Every issuance and every transition emits a signed audit line. JSON/syslog export to your SIEM.
HSM from day one
FIPS 140-3 Level 3 modules. Witnessed root ceremony. Signed export receipts per operation.

From production ADCS migrations

< 60s
Fleet-wide revocation
From PCR mismatch to CRL propagation
0
Issuance outages
Shadow-issuance guarantees parity before cutover
8-12 wk
Typical cutover
Discovery through promote; retire runs on natural cert expiry
16+7
Trust-push targets
Network vendors + MDMs covered natively
Case study
Regional health system · 180K endpoints

Retired three ADCS forests and one NDES server in a quarter.

“Three forests from acquisitions, one NDES box on Server 2016 nobody wanted to touch. Shadow-issuance ran for six weeks and the diff table caught two SAN rewrite rules we would have missed. Cutover was a Sunday morning and nobody noticed.”
- Director of Identity & Endpoint Security
3
ADCS forests retired
0
Issuance outages during migration
6 wk
Shadow parallel-run before cutover
Trust-store coverage

The new root goes everywhere ADCS used to.

The CA rotation wizard pushes the new root to every registered appliance before the promote step unlocks.

Microsoft Intune
MDM
Jamf Pro
MDM
Workspace ONE
MDM
Kandji
MDM
SOTI
MDM
Mosyle
MDM
Google Workspace
MDM
GPO (AD-joined)
Windows
Kubernetes cert-manager
DevOps
FortiGate
Network
PaloAlto PAN-OS
Network
Cisco ISE
802.1X
F5 BIG-IP
Load balancer
Juniper SRX
Network
Check Point
Network
Aruba ClearPass
802.1X
Explore all integrations
FAQ

Frequently asked questions

Yes - that is the whole point of shadow issuance. ADCS continues to serve real certs to real clients while TigerTrust issues identical shadows against the new CA. Nothing on the client side changes until you flip the SCEP profile in Phase 3.
The ADCS Migration tab reads them from the running forest and converts each one into a TigerTrust profile. EKUs, SANs, validity, key sizes, and autoenroll settings all survive the import. Scripts and PowerShell rewrite rules become CEL expressions. You review the diff per template before anything goes live.
Only if you want to. The GPO installer pushes the new root to AD-joined Windows machines, so legacy auto-enrollment keeps working. Most teams migrate the enrollment protocol to ACME or EST on the natural renewal cycle - not during the cutover.
NDES disappears. TigerTrust ships native SCEP + Microsoft Intune integration, with compliance-gated issuance. You retire the NDES Windows service as part of the migration - one less server, one less rotating service-account password.
Mid-market enterprise (10,000-50,000 certs, 2-5 ADCS forests): 10-12 weeks active work, with the shadow phase taking the longest. Large enterprise (500K+ certs, 10+ forests): add 4-8 weeks to the shadow phase. Small (sub-5,000 certs, single forest): 4-6 weeks total.
Every issuance - ADCS or TigerTrust - that passes through the shadow-issuance pipeline emits a signed audit line. Every CA rotation transition emits a signed audit line. These stream to your SIEM in JSON or syslog, with prebuilt framework mappings (PCI DSS 4.0, SOC 2 Type II, HIPAA, IEC 62443, FIPS 140-3, CNSA 2.0).
Yes. The CA rotation wizard supports scheduledPromoteAt and scheduledRetireAt timestamps. The scheduler worker polls every 5 min and advances state when due. Operators plan Sunday 02:00 UTC the week before; the state machine advances on time; the audit log records who scheduled what.
Rollback is one click from any pre-retired state. From dual-trust: new root stays pushed, but SCEP profiles revert to ADCS. From promoted: SCEP profiles revert, new root stays trusted. After retire: rebuild ADCS - which is why retire only fires after a long parallel-expiry period and your explicit sign-off.
Related

More ADCS migration reading

Blog

Migrating off Microsoft ADCS

The pillar field guide: inventory, template import, shadow issuance, dual-trust, promote, retire.

Read more
Blog

Shadow ADCS: the coexistence pattern

Technical deep-dive on the shadow-issuance mirror and the diff table.

Read more
Comparison

TigerTrust vs Microsoft ADCS

Side-by-side capability comparison.

Read more
Product

PKI as a Service

The managed CA that replaces the ADCS footprint - HSM-backed, 99.99% SLA.

Read more

Retire ADCS on your timeline.

Book a demoTalk to a PKI architect