47-Day TLS Certificates Are Coming: How to Prepare for Automated Renewal

Shorter TLS Certificate Lifecycles Are Coming. Manual Renewal Is the Risk.

Public TLS certificate lifecycles are getting shorter. For many organisations, the change will expose a certificate management problem that has been tolerated for years because it only surfaced occasionally.

The CA/Browser Forum’s SC-081 changes reduce the maximum validity period for publicly trusted TLS server certificates in stages:

• Before 15 March 2026: 398 days
• From 15 March 2026: 200 days
• From 15 March 2027: 100 days
• From 15 March 2029: 47 days

That matters because certificate renewal is still too manual in many environments. Certificates are tracked in spreadsheets, monitored through email alerts, renewed by application teams, deployed by infrastructure teams, and investigated by security teams only when something breaks.

That model is already fragile. Shorter certificate lifecycles make it much harder to sustain.

Why Shorter Certificate Lifecycles Change The Workload

Shorter certificate validity is intended to reduce risk. If a certificate is compromised, misissued, or incorrectly managed, a shorter validity period reduces the time it can remain trusted. It also pushes organisations towards better certificate agility.

The operational problem is frequency.

Certificate renewal is not just “getting a new certificate”. A complete process usually includes discovery, domain validation, issuance, deployment, testing, monitoring, and record-keeping. When certificates last more than a year, weak processes can stay hidden. Teams can get by with reminders, shared knowledge, and last-minute coordination.

At 47 days, the same process becomes much more exposed. There is less time to find missing certificates, chase owners, fix validation issues, or recover from failed deployments. Every gap repeats more often.

An organisation with 500 certificates renewed roughly once a year has around 500 renewal events to manage annually. With 47-day certificates, that same estate creates roughly 3,900 renewal events a year. For 1,000 certificates, the number is closer to 7,800.

That is before accounting for failed renewals, forgotten systems, vendor-managed certificates, load balancers, cloud services, API gateways, Kubernetes ingress controllers, or legacy applications that still need manual handling.

The risk is not only more work. It is more opportunities for small process failures to become outages.

Where Manual Certificate Management Breaks

Most certificate outages are not caused by a lack of cryptographic knowledge. They happen because ownership and visibility are poor.

A certificate may be attached to a service that changed teams two years ago. It may sit behind a load balancer no one regularly audits. It may have been issued by a cloud service outside the central PKI process. It may belong to a vendor-managed platform where renewal depends on a ticket, not an automated workflow.

Spreadsheets and calendar reminders cannot keep up with that environment for long. They depend on people knowing where certificates are, who owns them, how they are renewed, and whether deployment actually succeeded.

Shorter lifecycles put pressure on each of those assumptions.

The first issue is inventory. If the organisation cannot produce a current list of publicly trusted TLS certificates, expiry dates, issuing authorities, owners, and deployment locations, it cannot reliably manage renewal risk.

The second issue is ownership. A certificate should be tied to the service it protects, not just to the person who requested it. When renewal fails, someone needs the authority and context to act quickly.

The third issue is deployment. Issuing a replacement certificate is only useful if it reaches the right endpoint and the service presents it correctly. Many incidents happen after issuance, not before it.

The fourth issue is evidence. As renewal frequency increases, audit trails become harder to reconstruct manually. Teams need system records that show when certificates were issued, renewed, deployed, and retired.

What Organisations Should Do Now

The starting point is discovery. Security and infrastructure teams need a reliable view of public TLS certificates across cloud platforms, internet-facing services, load balancers, APIs, and third-party environments.

That inventory should show:

• which service the certificate supports
• who owns the service
• where the certificate is deployed
• which certificate authority issued it
• when it expires
• how renewal currently works
• whether renewal is automated or manual

Once the estate is visible, teams can prioritise. Customer-facing systems, revenue-critical services, externally exposed APIs, and certificates without clear ownership should be addressed first.

Automation should follow the highest-volume paths. ACME-based workflows can help automate validation and issuance for many environments, but automation is not just about getting the certificate. The deployment and verification steps matter just as much. A renewed certificate that is not installed correctly can still create an outage.

Monitoring also needs to move beyond expiry alerts. Teams should know when renewal fails, when deployment fails, when a service is presenting the wrong certificate, and which certificates still depend on manual steps.

Finally, exceptions need to be managed deliberately. Some systems will not support clean automation immediately. Some certificates will sit inside vendor-managed services or older infrastructure. Those cases should be visible, owned, and reviewed, rather than hidden in a spreadsheet until the next expiry warning.

Questions To Ask Before The Deadlines Arrive

Security, infrastructure, and platform leaders should be able to answer these questions now:

• Can we list every publicly trusted TLS certificate we depend on?
• Do we know which service and owner each certificate maps to?
• Which renewals are already automated?
• Which renewals still require manual validation, deployment, or approval?
• How do we know a renewed certificate has actually been deployed?
• Which systems cannot support automated renewal today?
• Can we produce renewal and deployment evidence without searching through email or tickets?

Weak answers do not mean the organisation has failed. They show where the work needs to start.

Conclusion

Shorter TLS certificate lifecycles are not just a standards update. They change the operating model for certificate-dependent services.

At 398 days, manual renewal can look manageable. At 200 days, it becomes harder to defend. At 100 days, it starts to create recurring pressure. At 47 days, manual renewal becomes a reliability risk.

The organisations that prepare early will not simply renew certificates more often. They will improve discovery, assign ownership, automate renewal paths, monitor deployment, and make evidence part of the process.

The ones that wait will find the gaps through expired certificates, failed deployments, and avoidable service disruption.

Cryptomathic helpS assess your certificate lifecycle management approach, identify manual renewal risk, and define a practical path towards automated, policy-driven certificate management. Talk to an expert today.