ADCS End-of-Life in 2027: The IAM Team's Migration Checklist

Why 2027 Is the Silent Deadline for ADCS

Microsoft has never published a formal end-of-life notice for Active Directory Certificate Services. There will be no headline announcement, no support.microsoft.com banner counting down the days. What there is, when you read the product telemetry honestly, is a feature investment curve that flattened around 2019 and has not moved since. Windows Server 2022 shipped with the same ADCS role you would recognize from Windows Server 2012 R2: the same certsrv.msc, the same certutil.exe, the same Web Enrollment pages running on classic ASP, the same HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration registry tree. Windows Server 2025, released in November 2024, introduced exactly zero meaningful improvements to the CA role: no native ACME, no REST API, no first-class post-quantum support, no Kubernetes integration, no replacement for the NDES/SCEP service that SCEP became infamous for being.

The 2027 date matters because it is the convergence of three independent pressures. Windows Server 2016 mainstream support ended in January 2022 and extended support ends 12 January 2027 — the same year the CA/Browser Forum's roadmap drives public TLS lifetimes toward 47 days, when Microsoft's classic enrollment model with Group Policy autoenrollment running every eight hours becomes operationally untenable for any team that has stretched ADCS to issue internal TLS.

Auditors under NIS2, DORA, and the EU Cyber Resilience Act now ask for evidence of cryptographic agility, signed inventories of every CA certificate, and demonstrable rotation procedures for compromised intermediates. ADCS does not produce those artifacts natively. You build them around it, with PowerShell, with certutil -view, with parsing of the Jet database under %SystemRoot%\System32\CertLog. CISOs are starting to notice that the foundational trust anchor for every domain-joined workload is a 25-year-old role whose maintenance owner inside Redmond is, charitably, ambiguous.

None of this means ADCS will stop working in 2027. It means the cost of running it — auditor questions, missing APIs, hand-rolled automation, brittle Web Enrollment, no path to ML-DSA — will exceed the cost of replacing it for an increasing share of regulated organizations. The IAM lead who inherits an ADCS estate today is being asked to plan a migration whose deadline is invented internally, not announced by Microsoft. That is harder, not easier.

The Hidden Costs You Are Already Paying

The first conversation worth having with the CFO is not about migration cost. It is about the operational debt ADCS already extracts every quarter, which most finance teams have never seen quantified. Start with template sprawl. A ten-year-old enterprise CA typically carries between 40 and 120 published certificate templates, of which fewer than 15 are actively requested in any given month. The rest are duplicates of WebServer and Computer with one EKU changed, archived versions left behind by a project that finished in 2018, and templates created by an admin who has since left the company. The cost is not storage; it is the fact that nobody can answer the auditor's question “which templates can issue a Client Authentication certificate with private key export enabled,” because nobody has read all 90 of them.

Then there is the API surface. ADCS exposes DCOM (ICertRequest, ICertAdmin2), the certificate enrollment web services WSTEP and WSEP introduced with Windows Server 2008 R2, and the Web Enrollment pages. There is no REST. There is no JSON. There is no OAuth.

Every modern platform — Kubernetes cert-manager, HashiCorp Vault, ServiceNow, internal developer portals, container build pipelines — has to be glued to ADCS through PowerShell remoting, a custom NDES proxy, or a third-party shim. Each glue layer is a piece of code nobody wants to own, a credential that nobody wants to rotate, and a single point of failure for the entire certificate lifecycle.

Manual renewals compound the problem. Autoenrollment works for domain-joined Windows endpoints; it does not work for the F5 BIG-IP, the Citrix NetScaler, the Palo Alto firewall, the Java keystore inside the loan-origination platform, the iOS device that left the MDM scope last month, or the load balancer terminating TLS in front of the SAP HANA cluster. Those certificates are renewed by humans: a ticket, a CSR generated in OpenSSL, a copy-paste into Web Enrollment, a PFX export, an SCP to the device, a service restart at 2 a.m.

A bank we worked with counted 1,847 hours of operator time per year spent on manual renewals against a single ADCS estate — roughly one full-time engineer whose job title was “senior security architect.” The audit pain is the same shape: every CA database query becomes an ad-hoc certutil -view -restrict exercise, and the evidence sent to the auditor is screenshots.

Mapping Your ADCS Estate Before Anything Else

No migration plan survives until you know what you are migrating. The inventory phase is where most ADCS replacement projects either succeed cheaply or fail expensively, and it is where the temptation to skip steps is strongest. Six artifacts must exist on paper before any vendor selection conversation starts.

The first is the CA topology: every root, every issuing CA, every policy CA, every standalone CA that someone stood up “temporarily” in 2016 and never decommissioned. certutil -dump against each CA database gives you the CA certificate, the CRL distribution points, the AIA URLs, and the configured key length and hash algorithm.

Capture the offline root's status: when was the CRL last signed, where is the HSM that holds its key, who holds the activation credentials, when was the last drill.

The second is the template catalog. Export every published template with certutil -dstemplate and the AD attribute pKICertificateTemplate from CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=.... For each template, record the EKUs, the application policies, the key usage, the minimum key size, the subject construction rules, the enrollment permissions ACL, the “archive subject's encryption private key” flag, the validity period, and the renewal overlap.

The output is rarely shorter than 500 lines and frequently surfaces templates with Private Key Export and Client Authentication both enabled — a finding the CISO will want to act on independently of migration. This work feeds directly into a defensible certificate policy and governance posture, which is the artifact auditors will actually read.

The third is autoenrollment scope. Pull every Group Policy Object that sets Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client - Auto-Enrollment or its user-side equivalent. Map which OUs and security groups are in scope.

The fourth is the enrollment agent population: members of the Enrollment Agents security group on each CA, plus any account configured under Certificate Managers and Officer roles.

The fifth is the key archival inventory: every certificate where msPKI-Private-Key-Flag includes CT_FLAG_REQUIRE_PRIVATE_KEY_ARCHIVAL, the count of archived keys in the CA database, the Key Recovery Agent (KRA) certificates and who holds them. Archived keys are a separate migration problem — you cannot re-issue them, you have to transport them.

The sixth is the RA delegation surface: every NDES server, every Web Enrollment server, every HSM partition serving the CA, every CES/CEP endpoint with its bound service account, every certificate connector in Intune or third-party MDM. The output of the inventory phase is a spreadsheet with around 40 columns; do not pretend you can hold this in anyone's head.

Three Modernization Paths and How to Choose

From inventory, three viable paths emerge. The honest framing is that none of them is universally correct. The choice depends on regulatory perimeter, operating model, and how much in-house cryptography expertise you intend to keep.

The first path is rebuild on ADCS with hygiene. You keep the role, stand up a fresh two-tier hierarchy with a new offline root, decommission the legacy intermediates, rewrite the template catalog from scratch, enforce minimum key sizes (RSA-3072 or ECDSA P-256), bind the CA keys to an HSM, and wrap the whole estate in a CLM platform that talks to ADCS over WSTEP.

This is the lowest-risk path if your team has deep ADCS muscle memory, your application landscape is overwhelmingly Windows, and you have no near-term post-quantum mandate. It does not solve the API surface problem; you accept that the CA itself remains a black box and that all modernization happens in the layer above. Cost is moderate; payback horizon is two to four years before the same conversation repeats.

The second path is swap to a modern internal CA platform. You replace the ADCS issuing CAs with a software CA that exposes REST, ACME, EST, and CMP natively, runs on Linux, integrates with cloud KMS and HSMs, and supports both classical and post-quantum algorithms in the same hierarchy. The offline root may stay as-is (cold storage does not need modernization for its own sake) or be re-issued under a fresh root.

Templates become policies expressed in YAML or JSON, version-controlled in Git. Autoenrollment is replaced by ACME for servers, SCEP or EST for devices, and a portal for the long tail. This is the most common choice for organizations with a hybrid Windows/Linux footprint and a five-year horizon for crypto agility.

The third path is move to managed PKI. The CA itself is operated by a provider; you consume issuance through documented APIs and surrender control over the day-to-day. This is attractive when in-house PKI expertise is shrinking, when the regulatory regime allows it (some sectors do not), and when the existing ADCS estate is small enough that the migration cost is dominated by client reconfiguration rather than CA rebuild. The tradeoff is sovereignty: someone else holds your private CA keys, the cryptographic policy is partly theirs, and exit costs are non-trivial.

• Rebuild on ADCS: lowest disruption, lowest cost in year one, preserves Group Policy autoenrollment, leaves you with the same architectural debt in five years, no path to ACME or PQC inside the CA itself.
• Modern internal CA platform: highest engineering effort up front, full API surface, native automated certificate management for servers and workloads, sovereign key custody, viable PQC roadmap, requires a real PKI team.
• Managed PKI: lowest operational burden, fastest to credible production, predictable OpEx, reduces in-house cryptography exposure, surrenders some control over root key material and policy cadence, exit costs must be modeled before signature.
• Hybrid: a common fourth answer in practice — keep ADCS for Windows smartcard logon and domain controller certificates, move everything else to a modern platform. Two CAs, two policies, one CLM tying them together.

A 90-Day Migration Playbook

Ninety days is not enough to complete a migration of a real ADCS estate. It is enough to reach a state where the migration is irreversible and on schedule, which is the goal of the first quarter. The plan that consistently works runs in twelve weekly slices.

Weeks 1 and 2 — charter and inventory completion. Name the accountable executive and the technical lead. Freeze new template creation on the legacy CA. Complete the six-artifact inventory described above. Publish the certificate count broken down by template, EKU, and consumer team. Do not start vendor conversations until the inventory is signed off; it is the only document that lets you compare options on equal terms.

Weeks 3 and 4 — target architecture and pilot scope. Document the target hierarchy, the target template-to-policy mapping, the chosen enrollment protocols per consumer class (ACME for nginx and Apache, EST for network devices, SCEP for legacy MDM, REST for cloud-native workloads), and the HSM topology. Define the pilot: typically one non-production environment plus one low-risk production workload — an internal monitoring stack or a developer-tools cluster. The pilot must use the real target CA, real HSM, real CLM, not a lab shortcut.

Weeks 5 and 6 — new root and issuing CA build. Stand up the new offline root in its HSM, sign the issuing CA certificates, publish CRLs and AIA URLs to the locations that will serve them in production. Validate the chain end-to-end with openssl verify and certutil -verify from a Windows endpoint that does not yet trust the new root. Distribute the new root to a small trust-store ring (typically the IT team's own laptops) and confirm AIA chasing and CRL fetch behavior across HTTP and LDAP.

Weeks 7 and 8 — pilot issuance and observation. Issue real certificates to the pilot workloads. Measure renewal latency, revocation propagation, audit log completeness, and operator effort per request. Compare against the ADCS baseline you captured in the inventory phase. Fix the top three operational friction points before extending scope — not after. The most common findings are over-strict subject construction rules and under-specified SAN handling for multi-host applications.

Weeks 9 and 10 — coexistence and dual issuance. Add the new root to the enterprise trust store via Group Policy Trusted Root Certification Authorities push, alongside the old root. Reissue certificates for the next ring of workloads, typically internal load balancers and the first wave of Kubernetes clusters. The legacy ADCS continues to serve domain controllers, smartcard logon, and any workload not yet migrated. Both chains are trusted simultaneously; this is the only safe path.

Weeks 11 and 12 — governance, runbooks, and the irreversibility gate. Publish the new certificate policy and certification practice statement, the rotation runbooks, the incident response procedures for a compromised issuing CA, and the decommission timeline for the legacy hierarchy. Define the “point of no return”: a date after which no new certificates are issued from ADCS for migrated workload classes. Past this gate, every team that has not migrated owes a written justification, signed by their director, and a date.

Common Migration Pitfalls (and the Rollback You Wish You Had Designed)

Five failure modes recur across every ADCS migration we have seen. Each has a known shape, and each requires a rollback plan written before the failure, not after.

Broken autoenrollment. The legacy ADCS hierarchy renews thousands of domain controller and workstation certificates through Group Policy autoenrollment running on an eight-hour cycle. When you turn off the issuing CA, autoenrollment fails silently — the event log entry under Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational shows a hash error or an “Enrollment policy cannot be retrieved” message that no monitoring agent is watching for.

Endpoints continue to function until the existing certificate expires; then Kerberos PKINIT, 802.1X, and VPN all break in the same week. The rollback is leaving the legacy CA online and signing CRLs for at least 18 months after the migration nominally completes. Do not decommission the old CA on the day the new one goes live.

Orphaned templates and EKU drift. When you rebuild the template catalog on the new platform, it is tempting to consolidate. Three templates that all chain to the same EKU set become one; one template that nobody appeared to use is dropped. The two that nobody used were holding open a code path in a five-year-old internal application, and on rotation day the application refuses to start because the new certificate is missing the 1.3.6.1.5.5.7.3.21 SSH Client EKU or the legacy 1.3.6.1.4.1.311.20.2.2 Smart Card Logon OID.

The rollback is keeping the legacy template definitions in version control, with a documented mapping to the new policies, and a fast path to re-add a missed EKU. Plan for four to seven such findings during the migration window.

CRL gaps. The legacy CA publishes CRLs to a specific URL embedded in every previously issued certificate. If that URL stops resolving, every relying party that performs revocation checking starts to fail open or fail closed depending on its configuration — and you do not control that decision uniformly across browsers, OpenSSL versions, .NET, Java, and embedded TLS stacks.

The rule is simple: the CRL distribution point of the legacy CA must continue to serve a valid, signed CRL for the entire validity window of the longest-lived certificate ever issued by that CA. For a CA that issued five-year certificates, that obligation outlives the CA's operational role by five years. Plan the archive accordingly. Both the underlying PKI mechanics and the operating model around them have to keep that CRL alive.

NDES and SCEP swap risks. The NDES server is the bridge between mobile device management and ADCS. The challenge password is short-lived, the enrollment endpoint is hard-coded into MDM profiles, and changing it is a multi-stage operation: new profiles pushed to all enrolled devices, devices that fail to receive the update become orphans, the certificate they hold continues to authenticate until expiry, then they vanish from the network. The least-bad approach is running both SCEP endpoints in parallel for the entire MDM rotation cycle, with the new endpoint backed by the new platform and the old NDES kept in place behind a read-only firewall rule.

Smartcard logon. ADCS is deeply wired into Windows smartcard logon through the KDC's PKINIT implementation. The KDC trusts certificates chaining to the NTAuth store (certutil -enterprise -viewstore NTAuth). When you introduce a new issuing CA, you must publish its certificate to NTAuth before any user attempts to log on with a card issued by it. Forgetting this step produces a Monday-morning outage in which every cardholder is locked out of every domain-joined workstation simultaneously. The rollback is staged: NTAuth publication, then a single-team pilot, then a department, then the enterprise — never an instant cutover.

What Good Looks Like After Migration

The post-migration end state is measurable. Six criteria separate a migration that closed cleanly from one that left an operational tail.

The first is time-to-issue. For automatable workloads (web servers, Kubernetes ingress, internal APIs), issuance latency from request to installed certificate should be under five minutes end-to-end, with no human in the loop. For the long tail still requiring approval, the median should be under one business day. ADCS estates typically deliver two-to-five business days on the latter; halving that is a realistic target.

The second is renewal automation coverage. The metric is the percentage of issued certificates whose renewal is fully automated, with no human action between expiry minus N days and the new certificate being live. A mature post-migration estate runs at 85 to 95 percent automation coverage. ADCS estates often run at 30 to 50 percent because autoenrollment covers Windows endpoints only.

The third is policy-as-code. Every certificate policy lives in version control, is reviewed via pull request, and is enforced at issuance time by the CA platform itself, not by spreadsheet vigilance. Drift between policy and reality should be detectable with a single query, not reconstructed from CA database dumps.

The fourth is full chain visibility. Every issued certificate is discoverable in a single inventory, with its key location, its consumer team, its expiry date, and its issuing template/policy. The inventory updates within hours of issuance, not nightly. Time-to-locate any certificate is under one minute.

The fifth is crypto-agility readiness. The CA platform can issue ML-DSA-65 (FIPS 204) or ECDSA P-384 or RSA-3072 by changing a policy entry, not by re-architecting. The HSM supports the algorithm. The trust store distribution mechanism can roll out a new root in days, not quarters. The cryptographic inventory ties to the broader PKI surface and feeds the Cryptographic Bill of Materials regulators are starting to ask for.

The sixth is audit readiness. The evidence pack for the next NIS2, DORA, or ISO 27001 audit is a generated artifact, not a manually assembled binder. CA configuration snapshots, issuance logs, key custody records, policy review history, and rotation drills are exported with a documented procedure and a known refresh cadence.

Where Evertrust Fits

An ADCS migration is not a vendor purchase, it is a multi-year program. The certificate authority is one piece; the much larger piece is the management plane that has to keep thousands of certificates accurate, automated, and auditable across a hybrid estate that will contain ADCS, a modern internal CA, and probably one or more public CAs simultaneously for most of the migration window. That coexistence is where most projects stall, because the operational interface to ADCS is fundamentally different from the operational interface to anything modern.

Evertrust sits in that management plane. It discovers and inventories every certificate already issued by your ADCS estate without requiring agents on the CA itself. It governs renewal, revocation, and policy enforcement uniformly across legacy ADCS, a new internal CA platform, public CAs, and cloud-native issuers. It exposes ACME, REST, and policy-as-code interfaces to the workloads ADCS could never serve, while continuing to consume from ADCS over its native WSTEP and DCOM interfaces for as long as the migration window requires.

It produces the audit artifacts — signed inventories, policy drift reports, rotation evidence — that the next regulator will ask for without warning. To see how it supports an ADCS-to-modern migration without forcing a day-one cutover, explore Evertrust Certificate Lifecycle Management.