The 47-Day Certificate Clock Just Started. Most Teams Still Renew by Hand.

October 20, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

A TLS certificate that used to last 398 days will soon last 47. The CA/Browser Forum's phased reduction means certificate renewal stops being an annual calendar reminder and becomes a continuous process that runs roughly eight times a year per certificate, and any team still renewing by hand will start missing deadlines long before 2029 arrives.

What exactly did the CA/Browser Forum change, and why now?

In April 2025 the CA/Browser Forum approved Ballot SC-081, a phased schedule that cuts the maximum validity of publicly trusted TLS certificates in stages. According to Infosecurity Magazine's coverage of the vote, the lifespan shrinks to 200 days on March 15, 2026, then to 100 days a year later, and finally to 47 days on March 15, 2029. All four major browser vendors, Apple, Google, Mozilla, and Microsoft, backed the proposal, which the same reporting describes as one of the most unified positions the forum has taken.

The logic is straightforward. A shorter validity window limits how long a misissued or compromised certificate stays trusted before it expires on its own. That same reporting notes the change also folds in a sharp reduction in how long domain validation data can be reused, which forces re-verification of domain control with nearly every issuance cycle. The practical effect is that certificate management shifts from a periodic task owned by whoever remembers to renew it, to a system that has to run itself.

This is also where the timeline collides with older guidance that many teams still default to. NIST's foundational cryptographic key management recommendation, NIST SP 800-57 Part 1, was written for a world of multi-year cryptoperiods and never anticipated certificates measured in weeks. Teams that built their key rotation policy around that older cadence now have a gap between what their documentation says and what the public CA ecosystem will actually allow them to do.

How should a security team actually operate under a 47-day renewal cycle?

The honest answer is that it can't be a person doing this work manually at scale. The Automated Certificate Management Environment protocol, standardized as RFC 8555, already exists for exactly this problem. It automates issuance, domain validation, and renewal through machine-to-machine communication between a client and the certificate authority, which is the only realistic way to keep pace with eight renewal cycles a year across an enterprise's full certificate inventory.

Federal guidance has been pointing in this direction for a while, even before the 47-day schedule existed. A joint NSA and CISA advisory on cloud identity practices, published as part of their top ten cloud security mitigations, states plainly that proper certificate management includes secure key storage, periodic rotation, and implementation of revocation, and that organizations should maintain documented control over which certificate authorities and certificates they trust. That advisory was written for a slower cadence than 47 days, which means its baseline requirements get harder, not easier, to meet as the clock compresses.

Here is the phased schedule every certificate owner now has to plan against:

Each step down in that table is a forcing function. A team that gets through the 2026 cut to 200 days on a spreadsheet and a reminder email will not survive the 2029 cut to 47 days with the same process, because the volume of renewals per year roughly doubles at each stage, as detailed in AppViewX's analysis of the new maximum validity periods.

The inventory problem underneath the renewal problem

None of this works if an organization does not know what certificates it actually has. This is the part that gets missed in conversations focused only on automation tooling. You cannot automate the renewal of a certificate nobody on the current team knows exists, and expired or orphaned certificates are a known source of outages and compromise, not a theoretical risk.

This connects to a broader identity problem security teams are already fighting. CyberArk's 2025 State of Machine Identity Security Report found that machine identities, which include TLS certificates alongside API keys and service accounts, now far outnumber human identities inside most organizations, and that many security leaders are still struggling to build a coherent approach to managing them. A 47-day renewal cycle applied to an inventory nobody has fully mapped is a recipe for a renewal failure that takes down a production service, not a minor compliance footnote.

What this means for the people doing the work

Certificate lifecycle management used to be a task you handed to whoever was free. It is becoming a control that needs someone who understands PKI design, automation workflows, and the operational consequences of a missed renewal window, because the failure mode is no longer a slow security drift, it is an outage with a specific root cause and a specific name attached to it.

This is exactly the territory covered in advanced security architecture training like CompTIA SecurityX, which goes into enterprise cryptographic design, PKI implementation, and the governance decisions around key and certificate lifecycles rather than treating PKI as a single exam objective to memorize and move past. If you are building a study plan that actually maps to this kind of operational responsibility, the curriculum breakdown on Forge University's resources page is a reasonable place to see how the topic areas line up against real job tasks before you commit to a track.

The reason this matters for a career, not just a system diagram, is accountability. When a certificate renewal fails under a 47-day cycle, the postmortem will ask who owned the automation, who maintained the inventory, and who signed off on the fallback plan when the CA's ACME endpoint had an outage of its own. Those are not questions a generic IT generalist background answers well. If you want a study plan built around this kind of enterprise cryptography and PKI operations work, you can start training whenever you're ready, rather than learning the gaps the hard way during an actual renewal failure.

What to do before March 2026

The first deadline is closer than the 47-day headline suggests. March 15, 2026 brings the cut to 200 days, and that is the point where manual renewal starts becoming genuinely unmanageable for any organization running more than a handful of public certificates. Before that date, a security team's realistic checklist looks like this:

• Build or validate a full certificate inventory across every public-facing service, including subdomains and internal systems that quietly depend on externally trusted certificates.
• Stand up an ACME-based renewal pipeline, or confirm an existing certificate lifecycle management tool actually supports the shortened domain validation reuse windows coming in each phase.

Neither of those is a one-time project. The 47-day certificate rule is not a deadline you meet once and close out. It is a permanent change to how often a specific category of trust artifact has to be proven again, and the organizations that treat it as ongoing governance rather than a one-time migration project are the ones that will not end up explaining an outage to a customer in 2029.

Start training free at Forge University