The days of multi-year TLS certificates are over. The industry is rapidly moving toward shorter validity periods, with 47-day certificates on the horizon. This shift will fundamentally change how organizations manage their certificate estates.
For years, TLS certificates could be valid for three, four, or even five years. Administrators would request a certificate, install it, and largely forget about it until the next renewal cycle came around. That era is ending.
The trajectory is unmistakable: certificate validity periods have been shrinking steadily, and the pace is accelerating. As of 2024, the maximum validity for publicly trusted TLS certificates is 398 days (roughly 13 months). By 2029, that window will shrink to just 47 days. This means organizations that once renewed a certificate once a year will soon need to renew it roughly eight times a year, per certificate.
The shift is not arbitrary. It reflects a growing consensus among browser vendors, security researchers, and standards bodies that shorter lifespans dramatically reduce risk. But for IT teams still relying on manual processes or spreadsheets, the operational implications are enormous.
The history of TLS certificate validity is a story of steady compression. Each reduction was met with industry pushback, followed by adaptation, followed by calls for even shorter periods.
In the early days of commercial TLS, certificates could be purchased with validity periods of three to five years. Renewal was infrequent, and certificate management was largely a manual, ad hoc process handled by a small number of administrators.
The CA/Browser Forum voted to cap TLS certificate validity at 825 days (approximately two years). This was the first major reduction and signaled the industry's direction. Organizations with large certificate estates began to feel the operational pressure.
Apple unilaterally announced that Safari would reject certificates with validity periods exceeding 398 days. Google and Mozilla followed suit. The CA/Browser Forum had debated this change but couldn't reach consensus; browser vendors forced the issue. This became the standard that holds today.
Google publicly advocated for a 90-day maximum validity period, citing the success of Let's Encrypt (which issues 90-day certificates by default). The proposal gained broad support among browser vendors and security researchers, setting the stage for the next formal reduction.
Apple's ballot SC-081 was adopted by the CA/Browser Forum, establishing a phased reduction: 200 days by March 2026, 100 days by March 2027, and 47 days by March 2029. Domain Control Validation (DCV) reuse will also be limited to just 10 days, meaning the entire issuance process must be automated end to end.
The push toward shorter validity periods is driven by concrete security and operational benefits. Understanding these motivations is essential for communicating the urgency to stakeholders within your organization.
If a private key is compromised, the damage is limited to the remaining validity of the certificate. A 47-day certificate means an attacker can exploit a stolen key for weeks, not months or years. Shorter lifespans make revocation less critical because certificates naturally expire quickly.
Every renewal cycle typically generates a fresh key pair. More frequent renewals mean keys are rotated more often, reducing the window in which a single compromised key remains useful. This aligns with zero-trust principles of continuous verification.
When domain validation data can be reused for a year, changes in domain ownership may go undetected. Shorter DCV reuse periods (down to 10 days) ensure that every issuance reflects the current state of domain control, preventing certificates from being issued to parties that no longer own the domain.
When a cryptographic algorithm is found to be weak, short-lived certificates mean the ecosystem transitions faster. Instead of waiting years for old certificates to expire, the entire fleet can be migrated within weeks. This is especially relevant as the industry prepares for post-quantum cryptography.
The CA/Browser Forum is the industry body that sets the rules governing publicly trusted certificates. Its members include Certificate Authorities (like DigiCert, Sectigo, and Let's Encrypt) and browser vendors (Apple, Google, Mozilla, Microsoft). Decisions require consensus from both sides.
In 2024, Apple submitted Ballot SC-081, proposing a phased reduction of maximum TLS certificate validity. Unlike previous attempts that stalled in committee, this ballot gained broad support. The key provisions are clear: maximum certificate validity drops to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. Equally important, the maximum DCV reuse period drops in parallel, reaching just 10 days by 2029.
Google had separately proposed moving to 90-day certificates, reinforcing the direction. The convergence of Apple's ballot and Google's advocacy made it clear that shorter lifespans are not a question of "if" but "when." Organizations that wait until 2028 to begin preparing will face a painful and rushed transition.
The security benefits of shorter lifespans are real, but so are the operational challenges. For organizations still managing certificates manually, the impact will be severe.
An organization with 10,000 certificates renewing annually will need to process roughly 80,000 renewals per year under a 47-day regime. That is an 8x increase in operational volume. Without automation, this workload is unsustainable.
Manual certificate management (spreadsheets, email reminders, ticket-based workflows) simply cannot keep pace with 47-day cycles. Automated certificate management via protocols like ACME, EST, and SCEP is no longer a nice-to-have; it is a requirement for operational survival.
More renewal cycles means more opportunities for something to go wrong. A missed renewal, a failed deployment, a misconfigured server: each of these leads to certificate outages. The margin for error shrinks with every reduction in validity period.
You cannot automate what you cannot see. Organizations must first achieve complete certificate lifecycle visibility before they can reliably automate renewals. Discovery and inventory are prerequisites, not optional extras.
The transition to shorter lifespans does not happen overnight, but preparation should start now. Here is a practical roadmap for getting ahead of the change.
Start with a complete discovery of all certificates across your infrastructure: servers, load balancers, cloud environments, CDNs, IoT devices, and internal services. You need to know exactly how many certificates you manage and where they live.
For each certificate, determine whether the renewal and deployment process can be automated. Certificates on legacy systems, appliances without ACME support, or manually managed infrastructure will need special attention and possibly custom integrations.
Implement ACME, EST, or SCEP across your environment. Prioritize high-volume systems first (web servers, load balancers, Kubernetes clusters) and work outward toward edge cases. Test renewal workflows thoroughly before the deadlines hit.
Do not wait for the mandates. Begin issuing 90-day certificates now, wherever possible, to stress-test your automation pipelines and operational workflows. Organizations that have already adopted short-lived certificates through Let's Encrypt or internal CAs are well positioned for what's next.
Even with automation, things fail. Implement real-time monitoring of certificate status, renewal success rates, and deployment health. Configure alerts well in advance of expiration so that failures are caught and resolved before they cause outages.
Full-estate discovery: Evertrust CLM scans your entire infrastructure continuously, identifying every certificate regardless of issuer, location, or owner. You get a single source of truth before you begin automating.
Protocol-native automation: Evertrust PKI supports ACME, EST, SCEP, and CMP natively, enabling fully automated enrollment, renewal, and deployment without manual intervention. Whether you need to renew every 90 days or every 47 days, the process is the same.
Proactive alerting: Configurable alert policies notify the right teams at the right time, whether that's 30 days, 14 days, or 7 days before expiration. Escalation paths ensure no renewal falls through the cracks.
Readiness dashboards: See at a glance which certificates are already automated, which still require manual intervention, and where your gaps are. Track your progress toward full 47-day readiness across the entire organization.
