ADCS Autoenrollment Breaks Silently. SC-081 Just Made That Your Problem.

The event log that tells you nothing useful

A thread from r/sysadmin, March 23, 2026. Sysadmin has a web server certificate with Subject Alternative Names. ADCS is configured. GPO is deployed. Permissions look right. The Kerberos authentication template renews automatically. The web server certificate doesn't. The event log shows "certificate about to expire," then later, "certificate expired." Nothing in between. No error code explaining why autoenrollment skipped it. Six months of troubleshooting. Six comments on the thread. No clean answer.

That's the ADCS autoenrollment experience, in a nutshell. It works until it doesn't. When it doesn't, the failure is silent and the root cause is buried somewhere in a chain of seven implicit prerequisites, any one of which can be quietly wrong.

This has been true for years. What changed on March 15, 2026, is that SC-081 Phase 1 went live. Maximum public TLS certificate validity is now 200 days. And organizations that were coasting on annual renewals are about to discover that their autoenrollment has been silently failing for longer than they knew. The 200-day cycle finds what the annual cycle hid.

Why SAN certificates are the hard part

ADCS handles different certificate types very differently, and the distinction matters a lot here. Kerberos authentication templates are relatively simple: the Subject is built from a predictable UPN or machine name pulled from Active Directory. Autoenrollment knows exactly what to request.

Web server certificates with SANs are a different problem. The subjectAltName fields need to reflect the actual hostnames of the service being secured. ADCS has to figure out what to put there, which means the template has to be configured to build the SAN dynamically from Active Directory attributes, and those attributes have to be populated correctly, and the template version has to support it, and the CA has to have read access to those attributes.

Any one of those links can be broken. And if it is, autoenrollment doesn't fail with a useful message. It skips the renewal. The event log notes the expiry approaching. Then it notes the expiry. There's nothing in between that tells you why the renewal didn't happen.

ADCS was designed for a world where certificates lasted two years. An admin had eighteen months after a failure to notice the event log entry, investigate, fix the template, and re-enroll before the cert expired. That window is gone now. At 200 days, a silent failure in March is an outage before the end of summer.

SC-081 just multiplied the blast radius

SC-081 Phase 1 capped public TLS certs at 200 days as of March 15. Phase 2, dropping to 100 days, arrives March 2027. Phase 3, at 47 days, follows in 2029. Each phase roughly halves the validity period and doubles the annual renewal frequency. A team that renewed manually once a year now needs to do it six times. If they're relying on ADCS autoenrollment for that cadence, they're about to run a stress test on configurations that were set up years ago and never verified under load.

The enforcement date is, in practical terms, a mass compatibility test for every ADCS autoenrollment configuration that nobody has touched since it was first deployed. The ones that have been silently failing will keep failing, just faster. And the ones that worked fine at annual cadence may have edge cases that only appear when the renewal cycle shortens.

The worst case: when the CA itself goes down

There's a thread from March 13, 2026 on r/sysadmin that shows where this failure mode goes when it escalates. A sysadmin is reporting that their intermediate CA service won't start. The MFA product is throwing SSL errors across the organization. The underlying cause: the CRL (Certificate Revocation List) on the intermediate CA expired. The service can't start because it can't reach the revocation server, which is also offline. The root CA is powered off. The manager who originally built the system and understood the architecture has left the company.

This is the PKI version of a cascading failure. It starts with a forgotten expiry on a component that nobody monitors, escalates to a service outage, and ends with a support incident that essentially reads: "the person who knows how this works isn't here anymore." The thread has eight comments. Most of them are people asking clarifying questions. Nobody has a clean fix.

ADCS was designed with the assumption that a dedicated PKI team would maintain the hierarchy: monitoring CRL lifetimes, keeping the offline root CA procedurally documented, rotating intermediate CA certificates on schedule, maintaining an operational runbook. Most organizations that deployed ADCS never had that team. They had one person who understood it, and when that person left, the understanding left with them.

SC-081 doesn't create this vulnerability. It accelerates when it surfaces. A PKI hierarchy that could coast for two years on institutional memory can't coast for 200 days. The clock is too short for inertia.

What "working autoenrollment" actually requires

The reason ADCS autoenrollment fails silently is that it depends on a chain of implicit prerequisites, none of which produce useful errors when they're wrong. For SAN certificate autoenrollment to actually work, all of the following have to be true simultaneously:

Seven prerequisites. Each one fails silently. In a typical ADCS deployment that's been running for a few years, at least one of them is probably subtly wrong for at least some certificates. You just haven't found out yet because the cert that was issued when everything was working is still valid. The 200-day clock is going to change that.

ACME changes the failure mode

The fundamental difference between ADCS autoenrollment and ACME-based enrollment isn't that one automates renewal and the other doesn't. Both automate. The difference is when and how they fail.

ADCS autoenrollment fails silently during the renewal cycle. ACME fails loudly at request time. If the ACME client can't reach the CA, the request fails immediately with a connection error. If the CSR is malformed, the CA rejects it with a specific RFC 8555 error code. If the account credentials are wrong, you find out in seconds, not after the cert expires. There's no mechanism in ACME by which a renewal "looks fine" while silently not happening.

This observability property is what makes ACME viable at high renewal frequency. 47-day certs don't work if your renewal tooling fails silently. You need to know immediately when something breaks, because at that cadence you have weeks, not months, to fix it before the outage.

The community is doing the math

A thread that's been running across r/sysadmin and r/PKI: "Now that cert lifetimes will be reduced, how are you handling internal services?" The most common answer isn't "we're going to automate ADCS better." It's "we're moving internal services to a private CA."

The reasoning is concrete. Chrome and Firefox accept private CA-issued certificates valid for up to 10 years. SC-081's enforcement timeline applies only to certificates issued by publicly trusted CAs. Move your internal services to a private CA, and the 200-day clock simply doesn't apply to them. You set the validity period. You control the renewal schedule. You stop being subject to a compliance timeline driven by the public internet's revocation failure modes.

Another thread, 53 comments, from February 18, 2026: a team switching internal hardware (switches, routers) from a public wildcard cert to an internal CA specifically to avoid the shrinking public cert lifespan schedule. They hit six hours of troubleshooting on the migration: SHA-1 upgrade, browser trust distribution, SAN field quirks. The friction was real. But the reason they migrated is now showing up in thread after thread: private trust is on your terms, and public trust increasingly isn't.

The question worth asking now

If you're running ADCS autoenrollment for certificates subject to SC-081, the useful question isn't "when do these certs expire?" It's: when did they last renew automatically, and how do you know?

If the answer is "I trust the autoenrollment configuration is working," that's not actually an answer. That's the assumption that produced the six-month-unsolved r/sysadmin thread. If you have cert expiry monitoring but no enrollment success monitoring, you're watching for the outage rather than preventing it.

SC-081 didn't create the problem with ADCS autoenrollment. It created a deadline by which the problem will surface, one way or another. The organizations that find out because their enrollment broke cleanly in a staging environment, with an ACME error log pointing to the exact cause, are in a much better position than the ones that find out because a SAN cert expired silently in production and the person who understands the template configuration is no longer at the company.

The sysadmins migrating to private CAs to escape the renewal treadmill are making a reasonable bet. Private trust is exempt from the SC-081 schedule. ACME fails loudly when it fails. And the institutional knowledge required to operate a modern private CA is a lot lower than what ADCS demands. That calculus looks different at 200 days than it did at 398.