By Yair Knijn · February 23, 2025

Your team renews certs by hand four times a year. At 47 days that's a wall.

A platform director sees 47 days next to a 2029 date and files it under "plenty of runway." The number that should worry them is not 47. It is 200, and it arrives in March 2026. The phase-in puts the friendly-sounding figure at the end, which buries the year your manual process actually starts to crack.

If your team renews TLS certificates by hand on a quarterly rhythm, the schedule below is not a future risk. It is a workload multiplier you are already underfunding.

The SC-081 phase-in: 200 days, then 100, then 47, and DCV reuse cut to 10

The CA/Browser Forum approved Ballot SC-081v3 in April 2025, originally an Apple proposal. It steps the maximum lifetime of publicly trusted TLS certificates down from 398 days on a fixed calendar: 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. No CA gets an exception. Once a step lands, any certificate issued after it cannot be valid longer.

Most planning decks skip the domain-control-validation part. SC-081 also shrinks how long a CA may reuse your DCV evidence, dropping it to 10 days at the final step. A 47-day certificate outlives that window by a wide margin, so every renewal forces a fresh domain validation. The challenge response that used to be an annual chore becomes part of each issuance.

Renewal-event math: from four touches a year to one every few weeks

Manual teams plan around renewal events, not certificate lifetimes, and the events are what scale against you. A 398-day cert means roughly one renewal per cert per year. Renew before expiry and you are looking at about four touches annually.

At the 47-day ceiling you renew on closer to a 30-to-35-day cadence to keep any margin, which works out to roughly one renewal every few weeks per certificate. A hundred certs at one a year is a hundred ticketable events. The same hundred at the 47-day ceiling runs into the high hundreds, each one now carrying a fresh domain validation.

Where manual renewal quietly breaks first

The breakage does not wait for 2029. It starts at the 200-day step in 2026, when your quarterly calendar stops lining up with expiry and someone has to track each certificate on its own clock. Manual workflows fail in specific, boring places:

• The renewal owner leaves, and the runbook lived in their head plus one spreadsheet tab.
• A SAN gets bolted onto a load balancer and never reaches the tracking sheet, so it expires unwatched.
• The DCV step that was annual is now per-renewal, and nobody automated the DNS-01 challenge, so issuance stalls on a person pasting a TXT record.
• Expiry monitoring fires at 14 days, which was comfortable at 398-day lifetimes and is now a fire drill against a 10-day validation-reuse window.

None of this is exotic. These are the same gaps you carry today, hit several times more often, with far less slack to recover from a miss.

Why a human with a calendar stops being enough

At one renewal a year, a careful engineer with a calendar reminder gets the job done. At one every few weeks across a real fleet, that engineer becomes both the bottleneck and the single point of failure. The honest question for a director is not "should we automate eventually." The 2026 step already costs you either added headcount or an ACME pipeline, and headcount does not scale to the 2029 step at any price worth paying. The phase-in hid that decision behind a friendly final number.

Automate Certificates treats each customer environment as a live inventory of certificates and their challenge types, renews against the SC-081 cadence on its own, and alerts on challenge-failure rate rather than expiry alone, so a stalled validation surfaces while you still have room to fix it. If four-renewals-a-year math no longer fits your team, that is the gap to close. See what it covers on features.