Industry to Shift to 47-Day SSL/TLS Certificate Validity by 2029
Starting in 2026, SSL/TLS certificate lifespans will be reduced from the current maximum of 13 months. By 2029, all public SSL/TLS certificates will have a 1.5-month maximum validity. Here’s what you need to know.
On April 11, 2025, the CA/Browser Forum (CA/B Forum) approved Ballot SC-081v3, a proposal from Apple that aims to dramatically reshape how organizations manage digital certificates and keys by reducing the lifespans of certificates and validation-related data.
But this update to the SSL/TLS Baseline Requirements isn’t just another technical change — it’s a fundamental shift that will require organizations to rethink their certificate management approach and strategies.
Here’s what you need to know about the coming changes to SSL/TLS certificate validity and data reuse periods and how they’ll affect your organization.
Let’s hash it out.
TL;DR: A Breakdown of the Changes to Come Starting in March 2026
- The industry is moving toward shorter SSL certificate lifespans (i.e., 47 days). The goal of the ballot’s phased reduction is to make the proposed changes “reasonable and attainable.”
- Google originally proposed 90-day validity. Apple said, “hold my beer” and proposed half the lifespan (45 days), but the negotiated validity period ultimately settled on 47 days. (Check out the FAQs at the end of the article to learn more about the changes in certificate validity periods over the years.)
- The certificate lifespan reductions will be implemented in phases:
- ~6 months (starting March 2026),
- ~3 months (starting March 2027), and
- 1.5 months (starting March 2029)
- The amount of time you can reuse validation data will be reduced starting March 15, 2026. This applies to both your organization’s subject identity validation data and your domain’s validation data.
- Certificates will need to be renewed more often. This increases the need for automation for organizations.
- These shorter validity certificates won’t cost you anything extra. TheSSLstore.com offers SSL/TLS multi-year plans. Meaning, you purchase the coverage period you want and then can re-issue your certificate as needed throughout its coverage period.
- Shorter lifespans ≠ higher costs. You can still buy one- or multi-year coverage for certificates and just renew/re-issue them in alignment with the decreasing validity periods.
Certificate Lifespans (# of Days) | # of Certificate Renewals/Re-Issues Per Year |
398 days (current) | ~1 |
200 days (starting March 15, 2026) | ~2 |
100 days (starting March 15, 2027) | ~4 |
47 days (starting March 15, 2029) | ~8 |
What’s Happening
Industry leaders engaged in an extended discussion over CA/B Forum Ballot SC-081, titled “Introduce Schedule of Reducing Validity and Data Reuse Periods.” As of April 11, they voted in support of the measure, which aims to
- reduce certificate validity periods,
- push organizations to adopt automation (as a byproduct of the shortened validity),
- shorten key usage periods and encourage more frequent rotation, and
- reduce the amount of time that organizations can reuse their SAN and non-SAN validation data.

When These Changes are Expected to Occur
The changes to SSL/TLS certificates outlined in Ballot SC-081 are going to roll out in phases. The following table provides an overview of the implementation phases that will affect the certificates’ lifespans:

Your Organization’s Identity & Domain’s Data Reuse Periods Will Also Change
In some cases, when reissuing or renewing a certificate, you might not have to go through the full validation process again because you were within the validation data reuse period. In addition to changing how long certificates are valid, the ballot also changes how long the validation data for your organization and domain/IP addresses can be reused.
However, due to the following approved changes to the validation data reuse periods, that may change:
Subject identity validation data can be reused for up to the maximum number of days:
- 825 days for current certificates (i.e., those issued on or before March 14, 2026)
- 398 days (for certificates issued on or after March 15, 2026)
What this change means for you: If you use OV or EV certificates, you’ll need to redo your organization validation for your SSL/TLS certificates once every 398 days starting March 15, 2026.
Domain and IP address domain validation data can be reused for up to the maximum number of days:
- 398 days for current certificates (i.e., those issued on or before March 14, 2026)
- 200 days (for certificates issued on or after March 15, 2026)
- 100 days (for certificates issued on or after March 15, 2027)
- 10 days (for certificates issued on or after March 15, 2029)
What these changes mean for you: You’ll need to revalidate your domain(s)/IP address(s) more frequently, in alignment with the timeframes listed above.
What These Changes Mean: You Must Start Planning for Automation Now
The bad news: Changes are coming, whether you’re prepared or not. Certificate automation tools can help future-proof your organization as certificate lifespans get increasingly shorter. Now is the time to think about how you want to automate the management and issuance of your certificates in the future.
Manual certificate management is going to become a thing of the past, as most website admins won’t want to manually re-install each certificate every month.
The good news: TheSSLstore.com already offers several cost-effective SSL automation tools, and we will be rolling out more certificate automation solutions over the next several months. We’re releasing these tools well in advance of the first deadline (i.e., March 2026) to give you time to integrate automation into your organization’s PKI operations and overarching security strategy.
Automation Solutions
Tool #1: AutoInstall SSL for Linux and Windows

AutoInstall SSL for Windows and Linux servers is an automation tool that sets tedious SSL/TLS certificate installation-related tasks on autopilot. Eliminating these essential (yet monotonous) tasks frees you up to focus on other critical initiatives that require your insights and skills.
Supported environments: Linux (Apache or NGINX) and Windows (IIS) Servers
Tool #2: AutoInstall SSL for Web Hosts
Web hosts: Want to help customers streamline their SSL/TLS certificate installation processes? You can with AutoInstall SSL for Web Hosts. With a single click, this automation tool enables customers to set their SSL/TLS certificates to install, reissue, and renew automatically.
Supported environments: cPanel, DirectAdmin, and Plesk.
Tool #3: Sectigo ACME Certificate-as-a-Service (CaaS)
Sectigo ACME CaaS is a subscription-based service that enables you to seamlessly deploy and manage your SSL certificates automatically using the Automatic Certificate Management Environment (ACME) protocol. After a one-time setup, you can issue, renew, and manage your certificates automatically using an ACME client.
Supported environments: Sectigo ACME CaaS is compatible with many web server and cloud hosting environments, web hosting control panels, and containers, including cPanel, Kubernetes, Linux, Plesk, and Windows IIS.
Tool #4: DigiCert ACME SSL Certificates
When it comes to installing, reissuing, and renewing SSL/TLS certificates, wouldn’t you love to be able to set them and forget them? With DigiCert CertCentral ACME automation, you can, as it supports all ACME agents.
Supported environments: Compatible with cPanel, Kubernetes, Linux, Plesk, Windows IIS, and other major web servers.
Tool #5: Certificate Lifecycle Management Platforms

Automation tools like DigiCert Trust Lifecycle Manager (part of DigiCert ONE) and Sectigo Certificate Manager allow you to deploy, track, and renew all certificates across your organization, regardless of which CA(s) issued them.
Supported environments: Pre-built integrations allow you to easily integrate these CLM automation solutions with your existing workflows and systems, including Apache, Nginx, IBM HTTP Server, Apache Tomcat, Microsoft IIS, Kubernetes, Amazon Web Services (AWS), Google Cloud Platform (GCP), and more.
How SSL Automation Works (Video Demos)
If You Manage Linux (Apache/NGINX) Server(s)
Here’s a quick demo that shows you how easy and fast the installation process is with AutoInstall SSL for Linux:
If You Manage Windows (IIS) Servers
Check out this quick demo, which shows how easy it is to automate your certificates using AutoInstall SSL for Windows IIS.
If You’re a Web Host That Provides cPanel Web Hosting
If you’re a web hosting company that uses cPanel, Plesk, or DirectAdmin, here’s how you can enable SSL automation for your customers.
Don’t Wait Until Next Year to Get the Ball Rolling
Configuring and testing your certificate automation takes time, and the March 2026 deadline is going to be here before you know it. Don’t get caught unprepared.
- Speak with our team of automation experts. We can help you choose the right automation solutions to meet your needs, whether it’s certificate automation or discovering where all the digital certificates are on your network.
- Work out all the kinks ahead of time. Test and configure everything well in advance of the first deadline. Give your team time to learn the new workflows and how everything works. This will help ensure you don’t run into any last-minute issues when the first deadline rolls around.
Have Questions? Here Are Answers to the Top FAQs
We thought it prudent to answer a few additional questions you likely have regarding these changes.
What Were the Results of the Voting Period?
The CA/Browser Forum (CABF) Server Certificate Working Group approved the ballot on Friday, April 11, 2025. Of the voting entities:
- 25 certificate issuers (CAs like DigiCert and Sectigo) and four certificate consumers (e.g., browsers like Google, Apple, Mozilla, and Microsoft) voted in favor of the measure.
- Five certificate issuers abstained, noting their concerns.
The Ballot Was Approved — What Happens Now?
Now that the voting period has concluded and the ballot has passed, it means the ballot will move on to the Intellectual Property Rights (IRP) Review Period. This allows CABR Server Certificate Working Group members time to review the ballot for any potential IP rights-related issues.
The official review period officially began at 03:00:00 UTC on Sunday, April 13, 2025, and will end at 03:00:00 UTC on Tuesday, May 13, 2025.
Which Types of Certificates Will the Changes Specified in SC-081 Impact?
The combined validity period and identity and domain validation changes will affect all public SSL/TLS certificates regardless of validation level. This means the constraints will apply to all domain validation (DV), organization validation (OV), and extended validation (EV) SSL/TLS certificates.
NOTE: These changes do not apply to code signing, S/MIME, and other types of digital certificates.
How Long Are SSL/TLS Certificates Valid Currently — 397 or 398 Days?
According to Section 6.3.2 of the current SSL/TLS Baseline Requirements (version 2.1.4), SSL/TLS certificate issued on or after Sept. 1, 2020 “SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
What Does This “SHOULD NOT” versus “MUST NOT” Stuff Mean?
Wondering why the ballot specifies “SHOULD NOT” and “MUST NOT” in its language? These keywords indicate requirement levels in accordance with the industry standard RFC 2119:
- “SHOULD NOT” essentially means that something isn’t recommended but allows leeway in situations where there are valid reasons for not abiding by the recommendation.
- “MUST NOT,” on the other hand, is a strict prohibition of the specified action.
So, ideally, all certificates SHOULD abide by the shorter “SHOULD BE” date. However, there is an extra day of leeway for those certificates that have mitigating circumstances.
Does This Mean You’ll Pay More Because Certificates Are Valid for Less Time?
Fair question. No, you won’t pay any more than you do now. For example, if you purchase one year of SSL/TLS coverage, you can simply reissue the certificate part way through its coverage period as needed.
Why Bother Reducing SSL/TLS Certificate and Validation Data Lifespans?
There are many reasons why these changes are deemed necessary. For example:
- Certificates represent a specific point in time. When a certificate is issued, the issuing CA validates that all the validation data it contains is accurate. The more time that passes, the higher the likelihood that the data will become outdated.
- Certificate automation is becoming more necessary as certificate-related outages become more prevalent. DigiCert’s State of PKI Automation report data shows that the average enterprise manages 50,000+ certificates, and two in three have experienced outages due to expiring certificates.
- Certificates and keys that are in use for extended periods can be less secure. For example, they contain outdated information or rely on outdated algorithms, libraries, etc.
- Cryptographic keys in use for extended periods pose security risks. Keys for certificates with extended lifespans are in use longer than their shorter validity counterparts. Furthermore, organizations lacking appropriate access controls may have active keys that are accessible by third parties who should no longer have access. It’s about reducing potential exposure time and risks.
- There are concerns regarding existing revocation methods (i.e., certificate revocation lists [CRLs] and online certificate status protocol [OCSP] servers) methods. However, experts are split on the efficacy and usefulness of modern revocation methods, and major browsers have stopped using some revocation-checking methods altogether.
Is This the First Time Certificate Validity Periods Have Been Reduced?
No. SSL/TLS certificates were originally issued with validity periods that extended upwards of five years. It was then reduced to 39 months, then 825 days, and subsequently to one year (or, more accurately, 398 days). However,
- Google proposed a move to shorter validity (i.e., 90-day) certificates back in 2019, but the ballot failed at that time. It brought it up again in early 2023 as part of its “Moving Forward, Together” initiatives.
- Apple picked up the mantle last fall (2024) in a CA/B Forum meeting, announcing the new ballot and originally proposing a gradual shift to 45-day certificates.
The good news is that we offer multi-year plans. This means you only have to purchase your certificates once, and then you can reinstall them as many times as necessary during that plan period in accordance with the industry’s evolving requirements.
Where in the Baseline Requirements Will the Changes Be Seen?
Now that the ballot is approved, the ballot will update sections 4.2.1 and 6.3.2 of the industry’s existing SSL/TLS Baseline Requirements relating to certificate operational periods and key pair use periods.
Be the first to comment