A CA that doesn't need a Windows Server team.
Active Directory Certificate Services solved the 2005 problem of issuing user and machine certificates inside a Windows domain. In 2026 your workloads are Kubernetes, iOS, IoT, and multi-cloud - and your renewal cadence is 47 days. TigerTrust is the modern PKI that replaces ADCS without a big-bang cutover: it mirrors your templates, shadow-issues alongside the old CA, then takes over on your schedule.
ADCS wasn't built for any of the problems you have now.
ADCS was designed when the perimeter was the firewall, user certs were the main use case, and renewals happened yearly. Four things changed - and every one of them cuts against ADCS.
What changes when the CA stops being a Windows service.
- CA lives on a Windows Server VM that nobody wants to patch
- Enrollment is GPO + auto-enroll - fine for domain-joined, blind to everything else
- NDES bolt-on for SCEP, with its own availability and credential-rotation headaches
- OCSP + CRL served by a Windows service with no global edge
- Audit = Windows event log + a quarterly screenshot
- Templates sprawl: nobody can tell you which EKUs are in production
- Managed CA control plane with HSM-backed keys and a 99.99% SLA
- ACME, EST, SCEP, and REST issuance - cross-platform, cross-cloud
- SCEP + Intune natively - NDES disappears from the architecture diagram
- Global anycast OCSP + 5-min CRL cadence
- Signed audit stream to Splunk / Sentinel / Chronicle, mapped to your framework
- Policy-driven profiles with cryptographic name constraints
Capability comparison, head to head.
ADCS covers the Windows-domain use case well. Here is where the scopes overlap and - more importantly - where they diverge.
| Capability | TigerTrust | Microsoft Active Directory Certificate Services |
|---|---|---|
Issues X.509 certificates | ||
Windows auto-enrollment (GPO) TigerTrust ships a GPO installer for the trust anchor; renewal moves to ACME/REST | ||
SCEP for iOS / Android / Intune (no NDES) ADCS needs NDES - another Windows service to maintain | ||
ACME v2 (cert-manager, Traefik, Caddy) | ||
EST (RFC 7030) | ||
CMPv2 for OT / industrial | ||
TPM 2.0 attestation on issuance | ||
Global anycast OCSP ADCS can serve OCSP; global edge distribution is DIY | ||
Delta + full CRL on a 5-min cadence | ||
HSM-backed root with witnessed ceremony | ||
Multi-cloud certificate discovery | ||
Audit stream to SIEM (JSON / syslog) | ||
Prebuilt compliance evidence packs | ||
Managed service option | ||
Cross-sign and private-root hierarchies | ||
Template → profile import from existing CA The ADCS Migration tab reads your existing templates and maps EKUs, SANs, validity, and rewrite rules |
Replace ADCS without stopping issuance.
Nobody has a change window wide enough to cut over a production CA in one shot. TigerTrust runs the migration in parallel: your old CA keeps issuing, the new one shadow-issues, and you flip relying parties when you are ready.
Import your templates
TigerTrust reads your ADCS templates (EKUs, SANs, validity windows, key sizes, autoenroll rules) and maps each one to a SCEP / EST / ACME profile. Nothing gets lost in translation.
Shadow-issue in parallel
The shadow-ADCS worker mirrors every incoming request - ADCS still issues the real cert, TigerTrust issues an identical shadow. You compare, diff, and prove parity before cutting over.
Dual-trust the new root
Push the new CA to every trust store (ADCS GPO, Jamf, Intune, Workspace ONE, SOTI, Google Workspace, cert-manager, F5, PaloAlto, FortiGate, and more). Both roots are trusted during the window.
Promote and retire
Flip SCEP profiles to TigerTrust, let auto-renewal replace certs on the natural cadence, then retire ADCS when the last old cert expires. Rollback is a single click up to the retire step.
Frequently asked questions
Can we keep ADCS running during the migration?
Yes - that is the entire point. The shadow-issuance pattern means ADCS continues to issue production certs while TigerTrust mirrors every request. You get weeks or months of parallel-run proof before you flip relying parties. Rollback stays a single click until you retire the old root.
What happens to our existing ADCS templates?
The ADCS Migration tab reads your templates directly from the running CA and converts each one into a TigerTrust profile. EKUs, SANs, validity, key size, autoenroll settings, and rewrite rules all survive the import. You review the diff before anything goes live.
We rely on NDES for Intune and mobile. Does that go away?
NDES disappears from the architecture. TigerTrust speaks SCEP natively, with built-in Microsoft Intune integration that gates issuance on compliance status. You remove a Windows service and a dedicated service account - and gain policy-driven SCEP that can be rotated without a reboot.
What about auto-enrollment for domain-joined Windows machines?
Keep it or replace it - your call. TigerTrust ships a GPO installer that pushes the new root to AD-joined machines, so legacy auto-enrollment keeps working. Most teams migrate the renewal mechanism to ACME or EST on the next renewal cycle, but it is not a hard requirement for the cutover.
Can we move to a fully managed CA, or do we need to self-host?
Both are supported. TigerTrust runs as a managed service on FIPS 140-3 Level 3 HSMs with a 99.99% SLA, or as a self-hosted deployment on Kubernetes with your own HSM (Thales Luna, Entrust nShield, AWS CloudHSM). Most ADCS migrations go managed - the entire reason to leave ADCS is to stop operating a CA.
How do you handle revocation? ADCS was always slow at that.
Global anycast OCSP with sub-second stapling. Delta CRLs republished every 5 minutes. On a security incident, the fleet-wide CRL update propagates in under 60 seconds. ADCS can be configured to look like this - at the cost of a project in itself.
What about compliance evidence?
Every signing operation emits a signed audit line - subject, SANs, template / profile, issuing CA, timestamp, operator. Those feed JSON or syslog into your SIEM. Prebuilt mappings exist for PCI DSS 4.0, SOC 2 Type II, HIPAA, IEC 62443, NIST 800-53, FIPS 140-3, and CNSA 2.0. Auditors get read-only workspace roles and can export directly.
How long does a typical ADCS migration take?
Discovery and template import: 1-2 weeks. Shadow-issuance parallel run: 4-8 weeks (set by how long you want parity proof before cutover). Cutover and retire: a scheduled change window plus a renewal cycle. End-to-end: 2-3 months for most enterprise estates. Scope-dependent for very large template / template-reader setups.
Retired three ADCS forests and one NDES server in a single quarter.
“We had three forests from acquisitions, three ADCS deployments, and one NDES box that was running Windows Server 2016 and nobody wanted to touch. Shadow-issuance ran for six weeks. We cut over on a Sunday morning and nobody noticed.”
Everywhere ADCS doesn't go.
ADCS speaks fluent Active Directory. TigerTrust ships the surface it does not.
More ADCS migration reading
ADCS Migration solution
Full walkthrough of the shadow-issuance migration pattern - templates, parallel run, cutover, retire.
Migrating off Microsoft ADCS
The pillar guide to replacing ADCS without a big-bang cutover.
TigerTrust vs HashiCorp Vault PKI
The other common ADCS successor - and where it falls short as a full CLM.
PKI as a Service
The managed CA that replaces the ADCS footprint - HSM-backed, with issuance APIs your workloads already speak.