Skip to content

47-Day Certificates: What Changes and How to Prepare

47-Day Certificates: What Changes and How to Prepare

Quick answer: 47-day certificates are publicly trusted TLS server certificates with a maximum validity period of 47 days. The limit takes effect on March 15, 2029, after intermediate reductions to 200 days in 2026 and 100 days in 2027. Because shorter lifetimes increase renewal frequency, organizations with large certificate inventories need end-to-end automation to keep certificate data current without multiplying manual work.

The move to 47-day certificates turns certificate management from occasional maintenance into a continuous operational process. That shift matters because a team that once absorbed a manual renewal, approval, or deployment step each year will soon repeat the same workflow several times annually for every public TLS certificate it manages.

The first transition has already happened: public TLS certificates issued on or after March 15, 2026 are subject to a 200-day maximum. Teams should use this phase to find inventory gaps and test automation before the 100-day limit arrives in 2027, since waiting for 2029 leaves little time to uncover brittle scripts, manual handoffs, or deployment paths that renew a certificate but fail to install it everywhere it is used.

What 47-Day Certificates Mean

Under CA/Browser Forum Ballot SC-081v3, the term 47-day certificates refers to the final maximum validity period for publicly trusted TLS server certificates. These certificates authenticate internet-facing servers to browsers and other relying parties that follow public root program requirements.

This rule does not set the lifetime of every certificate inside an enterprise. Private PKI certificates, internal mTLS certificates, code-signing certificates, and other certificate types may follow separate policies, although organizations can still choose shorter internal lifetimes. The CA/Browser Forum schedule specifically addresses publicly trusted TLS server certificates.

Teams should not wait until day 47 to renew. Because the operating window must cover issuance, domain validation when required, deployment, service reloads, and verification, renewal policies need enough buffer to recover from CA, network, application, or automation failures before the current certificate expires.

When 47-Day Certificates Take Effect

The reduction is phased so certificate authorities, software vendors, and certificate subscribers can adapt their processes over time. Which maximum applies depends on the certificate’s issuance date, not its renewal date.

Certificates IssuedMaximum ValidityOperational Meaning
Before March 15, 2026398 daysPrevious public TLS maximum
March 15, 2026 onward200 daysCurrent phase
March 15, 2027 onward100 daysRenewal cadence increases again
March 15, 2029 onward47 daysContinuous lifecycle operations become the norm

Certificate authorities can also reuse domain control validation data for less time under the same ballot, with the permitted reuse period reaching 10 days in 2029. Faster issuance does not remove every validation dependency, which means teams must understand which steps their CA can automate and which still depend on DNS changes, approvals, or another external system.

Why Public TLS Certificate Lifetimes Are Shrinking

A certificate records facts verified at issuance, including control of a domain and the binding between that domain and a public key. Those facts can go stale as time passes: a domain can change hands, control of a key can be lost, or a certificate can be misissued.

Shorter validity periods reduce how long an outdated or compromised certificate can remain trusted. They also speed changes to cryptographic algorithms because the public Web PKI can move away from aging technology without waiting for long-lived certificates to expire.

The security benefit comes with an operational requirement: the CA/Browser Forum explicitly expects shorter lifetimes to encourage more reliable, bidirectional certificate lifecycle automation. As a result, certificate renewal has to work as a repeatable production process rather than a calendar-driven task assigned to an individual.

How 47-Day Certificates Change Certificate Operations

At the 47-day maximum, an organization may complete roughly eight issuance cycles per year for each public TLS certificate, depending on how early it renews. Yet the practical workload grows faster than that figure suggests because one certificate may be copied to several endpoints, referenced by multiple teams, or tied to application-specific deployment and restart procedures.

Renewal is only one stage. A dependable lifecycle must discover certificates, identify owners, request or generate key material, complete validation, issue the replacement, deploy it to every endpoint, verify the new chain, and retain evidence of the change. Any manual step becomes a recurring bottleneck as validity periods contract, so teams need to automate the chain rather than one isolated task.

Renewal Alone Is Not End-to-End Automation

A certificate can be renewed successfully at the CA and still expire in production because the replacement never reached a load balancer, ingress controller, web server, API gateway, or appliance. That gap creates a false sense of safety: a dashboard reports the new certificate while the application continues serving the old one.

End-to-end automation closes the gap by connecting issuance to deployment and verification. When a workflow fails, it should identify the affected certificate, application, endpoint, and stage so teams can fix the exception without returning every certificate to manual management.

Preparing for the 47-Day Certificate Era: Demo of Automated Certificate Lifecycle Management

Will 47-Day Certificates Increase Outage Risk

Shorter certificate validity does not inherently cause outages. Risk rises when certificate operations cannot complete reliably within a smaller margin for error, because a missed renewal that once left weeks or months to respond can become a service-impacting incident much sooner.

The largest outage risks usually come from operational gaps rather than the issuance step itself:

  • Incomplete inventory leaves unknown certificates outside the renewal workflow.
  • Unclear ownership delays approvals and incident response when automation fails.
  • Partial deployment leaves an expired certificate on one endpoint even though another endpoint is current.
  • Hard-coded scripts, expired CA credentials, or brittle integrations stop working without a visible alert.
  • Maintenance windows and application restart requirements delay certificate activation.
  • Monitoring checks the certificate repository but does not verify what each production endpoint is actually serving.

Automation reduces these risks only when it covers the full lifecycle and includes monitoring, exception handling, and tested recovery. A failing process can repeat the same mistake across every certificate it touches, so teams should treat certificate workflows like other production systems: version changes, test them, observe them, and assign clear owners.

A Practical Readiness Plan for 47-Day Certificates

The 200-day phase is a useful proving ground. Teams can remove manual work now, while renewal cycles still leave enough time to test changes safely and correct failures before the next reduction.

  1. Build a current certificate inventory. Find publicly trusted TLS certificates across cloud accounts, data centers, Kubernetes environments, CDNs, load balancers, appliances, and externally managed services. Record the owner, CA, expiration date, deployment location, and application dependency.
  2. Map the complete lifecycle. Document how each certificate is requested, validated, approved, issued, deployed, activated, monitored, and revoked. This exposes manual handoffs that a renewal-only view can miss.
  3. Automate issuance through deployment. Use supported protocols and integrations to connect the CA to the target system. Verify that the replacement certificate is installed and actively served, rather than assuming issuance completed the job.
  4. Set policy and renewal buffers. Define approved key types, certificate profiles, lifetimes, ownership rules, and a renewal point that leaves time for retries. The right buffer depends on validation, deployment, and maintenance constraints.
  5. Test failure and recovery paths. Simulate validation errors, unreachable endpoints, deployment failures, rollback needs, and expired automation credentials. Confirm that alerts reach an accountable owner with enough context to act.
  6. Measure automation coverage. Track which certificates are fully automated, partially automated, or manual. Review exceptions until the manual group is understood, accepted, and supported by a documented operating procedure.

How Akeyless Supports the 47-Day Certificate Era

Shorter lifetimes create repeated work across disconnected tools and endpoints. Akeyless Certificate Lifecycle Management connects certificate visibility with policy-driven issuance, renewal, deployment, and monitoring, which means teams can run the lifecycle as a continuous workflow.

Akeyless supports public and private certificate authorities, including ACME-compatible workflows, and can provision certificates to environments such as Linux, Windows, and Kubernetes. When an exception occurs, health tracking and notifications through email, Slack, ServiceNow, or webhooks help teams respond before an expiration becomes an incident. Centralized logging and access controls then provide evidence for operational reviews and audits.

Certificate automation also has to protect private key operations. Akeyless uses Distributed Fragments Cryptography (DFC) as part of its zero-knowledge architecture, so cryptographic operations can run across distributed fragments without reconstructing the complete key. This design connects lifecycle automation with the control required for sensitive machine identities.

The transition has already begun, so the current 200-day phase is the right time to test end-to-end automation. Explore Akeyless Certificate Lifecycle Management to see how discovery, policy, renewal, deployment, and monitoring can work together before the next validity reduction.

Frequently Asked Questions About 47-Day Certificates

Do 47-day certificates force automation adoption?

The CA/Browser Forum rule limits certificate validity but does not explicitly require a specific automation product. In practice, repeated validation, issuance, deployment, and verification become difficult to manage across a large certificate inventory, so end-to-end automation is the most reliable operating model.

When do 47-day certificates go into effect?

The 47-day maximum takes effect for publicly trusted TLS certificates issued on or after March 15, 2029. The phased schedule is already underway: the maximum fell to 200 days on March 15, 2026 and will fall to 100 days on March 15, 2027.

What are 47-day SSL/TLS certificates?

They are publicly trusted TLS server certificates whose validity cannot exceed 47 days under the CA/Browser Forum schedule. The rule applies to certificates used to authenticate internet-facing servers within the public Web PKI.

Will 47-day certificates increase outage risk?

They can increase outage risk when certificate inventory, renewal, deployment, or monitoring remains manual or incomplete. Shorter validity leaves less recovery time, but tested end-to-end automation can keep renewals routine and reduce dependence on last-minute intervention.

Do 47-day certificate rules apply to private certificates?

Not directly. Ballot SC-081v3 covers publicly trusted TLS server certificates; private PKI and internal certificate policies are outside that specific scope, although organizations may choose similar short-lived certificate practices for internal systems.

Never Miss an Update

 

The latest news and insights about Secrets Management,
Akeyless, and the community we serve.

 
  • G2 Fall 2026 Leader — Non-Human Identity Management
  • G2 Fall 2026 Momentum Leader — Privileged Access Management
  • G2 Fall 2026 High Performer — Certificate Lifecycle Management
  • G2 Fall 2026 Easiest To Do Business With — Secrets Management
  • G2 Fall 2026 Easiest To Use — Privileged Access Management, Enterprise
  • G2 Fall 2026 Best Support — Privileged Access Management, Enterprise

Ready to get started?

Discover how Akeyless simplifies secrets management, reduces sprawl, minimizes risk, and saves time.

Get a Demo