47-Day Certificates: Why ADCS Auto-Enrollment Can't Keep Up

The Cadence Problem

The CA/Browser Forum's SC-081 ballot in April 2025 set the glidepath for shorter certificate lifetimes:

That is public TLS. Private trust is formally independent, but no serious enterprise runs private trust on a different lifetime policy than public - the operational cost of two schedules is prohibitive, and the compromise-window argument that drives public lifetimes applies equally to private.

For an organisation running a 2-year ADCS template today, this is an 8-16x increase in issuance volume. 50,000 certs/year becomes 400,000-800,000 certs/year. That is not a scaling problem on paper; CAs can issue millions of certs. It is a scaling problem for the pipeline around ADCS.

Where ADCS Breaks Under 47-Day Cadence

Auto-enrollment polling

ADCS auto-enrollment relies on domain-joined Windows machines polling Active Directory for their list of applicable templates and the renewal threshold. The default policy is 8 hours. For a 2-year cert that renews at 80% (so, 20% before expiry = 146 days), 8-hour polling is fine - a client has weeks of overlap to notice and renew.

For a 47-day cert that renews at 2/3 of validity (so, ~15 days before expiry), 8-hour polling is a lot thinner. A client that misses its first poll window for whatever reason (laptop closed, VPN disconnected, GPO push failed) has only hours of margin before the cert expires. Operators who have never thought about auto-enrollment polling cadence are about to.

NDES RA cert

The NDES RA cert itself is a certificate. Its default validity in the Microsoft documentation is 2 years. At 2-year public validity, the NDES RA cert lasts the full OS reboot cycle. At 47 days, the NDES RA cert needs renewal 8x more often. Someone has to automate RA cert renewal, which is a scheduled task that nobody wrote because it was never necessary.

CRL cadence

ADCS CRLs are typically published daily or weekly. At 2-year cert validity, a cert that is revoked today will not naturally expire for 2 years - the CRL has to carry it. CRL file size grows with every unexpired revocation.

At 47-day validity, revoked certs leave the CRL within 47 days of revocation. CRL file size stays bounded. This is actually a benefit of shorter lifetimes - but the CRL publication cadence has to drop from daily to minutes for revocation to be meaningful on the 47-day scale. A 24-hour CRL window plus a 47-day cert means a compromised cert can be used for up to 24 hours after revocation. That is unacceptable in most threat models.

ADCS can publish delta CRLs on a 5-minute cadence. Doing it properly requires an operations-team decision that most teams running ADCS have not made.

OCSP responder scale

ADCS can serve OCSP, either via its own Online Responder role or by delegation to a third-party service. The OCSP response load scales roughly with the number of TLS handshakes per second. At 2-year cert validity, OCSP is a bursty load during the renewal window every two years. At 47 days, every handshake every 47 days generates OCSP traffic - the load profile flattens, but the mean rate goes up.

ADCS Online Responder is architected around the burst profile. The flat-rate profile requires a global edge, which ADCS does not have.

HSM operation counts

Signing operations cost real HSM budget. A typical FIPS 140-3 Level 3 HSM is rated for a few thousand signing operations per second. At 2-year cert validity with 50,000 certs/year, the mean rate is ~0.0016 ops/sec; peaks of 10 ops/sec during business hours.

At 47-day cert validity with 800,000 certs/year, the mean rate is ~0.025 ops/sec; peaks of 100-200 ops/sec during business hours. Still well within HSM capacity, but the renewal pattern matters - if everything renews at the same time of day, you can see 1,000 ops/sec spikes. Operations teams running ADCS with an HSM that was commissioned for 2010 cadence need to look at these numbers.

What You Actually Have to Do

For ADCS teams planning to stay on ADCS through the 47-day transition:

1. Shorten the auto-enrollment poll cycle. Group Policy setting EnterpriseEnroll - move from 8 hours to 1 hour (or less for critical templates).
2. Automate NDES RA cert renewal. Scheduled task plus a monitoring alert for when it fails.
3. Enable delta CRLs on a 5-minute cadence. ADCS can do this; most ADCS deployments don't.
4. Scale OCSP. Either stand up multiple Online Responders behind a global load balancer, or delegate to a service with global edge coverage.
5. Audit HSM capacity. Benchmark peak signing rate; confirm you have 10x headroom.
6. Review template validity. Templates with validity longer than the new policy need to be clamped during the transition.

Every one of those is a project. Together they are a program.

For teams migrating off ADCS, 47-day validity is one of the strongest arguments to accelerate. The new CA ships with 5-minute CRL cadence as default, global anycast OCSP as default, 30-day renewal windows as default, and native ACME/EST/SCEP that doesn't poll Active Directory for template changes. The 47-day transition is a configuration toggle, not a program.

The ACME Alternative

The 47-day transition is also a transition from GPO-driven auto-enrollment to protocol-driven renewal. ACME was designed for this cadence: short-lived certs with automated renewal from the start.

ADCS has no native ACME support. There are open-source wrappers (step-ca front-ending ADCS, ACME-ADCS projects) but none are production-grade at enterprise scale. Teams planning to stay on ADCS through the 47-day transition need to add an ACME layer; teams migrating get it as part of the new CA.

When the 47-Day Transition Forces the Decision

Three signals that the 47-day deadline is the reason to migrate rather than remediate:

1. ADCS is on an end-of-life OS. Fixing CRL cadence on an unsupported Windows Server is a dubious use of engineering time.
2. The device fleet is non-Windows. The 47-day transition for Jamf-managed Macs and Intune-managed iOS requires ACME or modern SCEP; adding that to NDES is harder than retiring NDES.
3. The compliance program is cross-framework. Multiple audits asking for evidence of 47-day readiness is a strong argument to invest the migration time once rather than remediate ADCS across every framework.

For teams with any of these three, the 47-day transition is the forcing function the ADCS migration has been waiting for.

Related Reading

• Migrating off Microsoft ADCS - the pillar guide
• Microsoft ADCS End-of-Life - the OS version pressure
• NDES Replacement - what to do about SCEP during the transition
• Road to 47-Day Certificates: The Full Timeline - the industry-wide picture