The 47-Day TLS Certificate Is an Automation Deadline
Shorter public TLS certificate lifetimes turn certificate management from a periodic administrative task into a continuous operational discipline.
A TLS certificate is easy to ignore—until it expires.
Customers then see security warnings, APIs reject connections, and applications can become unavailable even though the servers themselves remain healthy.
That exposure is becoming harder to manage manually. Under the CA/Browser Forum Baseline Requirements, the maximum lifetime for publicly trusted TLS subscriber certificates follows this schedule:
Public TLS certificate timeline
Validity periods are getting shorter
Manual renewal must become an automated lifecycle.
The current 200-day phase is not merely another compliance date. It is the beginning of a structural shift from occasional certificate administration to continuous certificate lifecycle management.
Why certificate lifetimes are shrinking
A publicly trusted TLS certificate binds a public key to validated domain information and helps establish an encrypted, authenticated connection. The longer a certificate and its supporting validation remain usable, the longer incorrect or compromised information may remain trusted.
Shorter lifetimes reduce that exposure window and require more frequent revalidation. This strengthens the Web PKI, but it also transfers greater operational responsibility to certificate owners.
An annual manual task may already be unreliable. Repeating it every few weeks across websites, APIs, gateways, load balancers, appliances, and supplier-managed services is not a credible operating model.
Issuance is only one stage
Certificate automation is sometimes understood as automatically requesting a replacement from a Certificate Authority. ACME, standardized in IETF RFC 8555, supports automated domain validation, issuance, and other certificate-management functions. But obtaining the certificate is not the same as protecting the service.
- 01Discover
Identify every certificate, endpoint, environment, owner, and dependency.
- 02Issue
Validate the identifier and securely obtain the replacement certificate.
- 03Deploy
Install it on every relevant gateway, load balancer, node, appliance, and hosted component.
- 04Verify
Confirm independently that each user-facing endpoint presents the correct certificate.
- 05Recover
Detect failures, escalate ownership, and replace or revoke certificates when needed.
A renewal job can report success while a production load balancer continues serving the old certificate. Automation is complete only when the organization verifies the entire service path.
Public and private PKI are different scopes
The CA/Browser Forum schedule applies to publicly trusted TLS certificates. It does not impose the same maximum lifetime on certificates issued by an organization’s private internal Certificate Authority.
That distinction should not become an excuse for incomplete inventory. Teams still need to distinguish public website and API certificates from internal service certificates, device and appliance certificates, certificates embedded in integration platforms, and supplier-managed certificates whose renewal process may not be visible internally.
The immediate standards change concerns public TLS. The wider leadership concern is whether all certificate-dependent business services are known, owned, and controlled.
Automate according to service criticality
Buying a certificate-management platform without resolving ownership and deployment complexity automates only part of the problem. Preparation should follow business impact.
A four-control readiness test
The key principle is independence: the process that renews a certificate should not be the only process reporting that the renewal succeeded.
Automation also creates responsibilities
Lifecycle automation reduces outage exposure and repetitive work. It also accelerates emergency replacement, strengthens ownership, and produces better evidence for operational and security reviews.
However, automation introduces dependencies of its own. Credentials and private keys must be protected, deployment permissions controlled, failure paths observable, and exceptions documented. An automated process that nobody monitors can fail repeatedly and at scale.
Questions leaders should ask
- Can we identify every public TLS certificate and its accountable service owner?
- Does renewal automatically reach every production endpoint—not only the Certificate Authority?
- Can independent monitoring confirm the certificate actually presented to users?
- What happens when renewal or deployment fails outside business hours?
- Which exceptions will still require manual intervention at a 47-day maximum lifetime?
The 47-day certificate is not mainly a procurement change. It is an operating-model deadline.
The right question is not simply, “Can we renew certificates automatically?” It is whether the organization can discover, issue, deploy, verify, and recover every critical certificate without depending on someone remembering an expiry date.
The 200-day phase is the warning. The 100-day phase will expose weak processes. At 47 days, calendar-based certificate administration becomes an availability risk by design.