As the maximum validity period of public TLS certificates is shortened in phases starting in March 2026, certificate renewal is no longer an "occasional task" but an ongoing operational responsibility.
Based on DigiCert's "47-Day TLS Certificates FAQ" document, this article summarizes, in question-and-answer form, the validity reduction roadmap (200 days → 100 days → 47 days), the change in the domain validation reuse period (up to 10 days), and why automation is essential. The Q&A below will help you quickly check what your organization needs to prepare.
⏰47-Day TLS Certificates: FAQs
Q: What are the new rules for certificate validity periods?
The CA/B Forum's new TLS rules include three major changes that begin to take effect in March 2026:
Automating some public certificates may require specialized tools or expertise, but in most cases the work is relatively simple. Plenty of documentation is available, and the services are often free (as DigiCert provides).
Q: What is the timeline for the changes?
The maximum validity period of public TLS certificates will decrease over the next few years as follows:
The maximum reuse period for domain and IP address validation information will also decrease as follows:
Q: What is the difference between the maximum certificate validity period (down to 47 days) and the maximum domain validation reuse period (down to 10 days)?
The maximum validity period of a certificate is the maximum number of days the certificate is considered valid. To issue a certificate, a certificate authority (CA) must validate that the applicant controls the domain names or IP addresses included in the certificate. If you renew a certificate once a year, as under the current rules, control is revalidated every year when the renewal is ordered. But what if a certificate needs to be replaced before renewal (for example, if the private key is compromised)? In that case, the CA can reuse the validation performed at the most recent renewal, reducing the need to validate again. This is because the maximum domain validation reuse period has not yet expired.
The Baseline Requirements (the CA/B Forum's rules for certificate issuance) have long specified both of these time limits, but the two values have generally been set to the same number of days. The reason the final stage of the new rules changes so that "the maximum certificate validity period is (ultimately) 47 days" but "domain validation can only be reused for up to 10 days" is that validation information is considered to become stale quickly, so validation should be performed more often. This change also makes it clear that the CA/B Forum believes domain validation must be automated. On such a short timeline, manual validation becomes a heavy burden. With automation, the short timeline is not a problem at all.
Q: What are the options?
There is only one reasonable option: automating Certificate Lifecycle Management (CLM). For years, the CA/B Forum and the industry (including DigiCert) have been advising customers that certificate validity periods would be shortened and that manual certificate management would no longer be a realistic solution.
Most use cases for domain validation (DV) certificates can be automated relatively easily using the ACME (Automated Certificate Management Environment) and ARI (ACME Renewal Information) standards. This capability is included in DigiCert CertCentral at no additional cost. For more complex cases, DigiCert's Trust Lifecycle Manager (TLM) provides managed automation support for a variety of enterprise configurations.
For some applications, internal PKI (also called private PKI) can be another option. Many publicly trusted certificates are used to protect resources that do not need public access, and according to best practices, such resources should not be accessible from the internet. Administrators sometimes use public certificates for these resources because it is the easiest way, but the correct approach is to use an internal PKI.
An internal PKI issues certificates that are "valid" or trusted only within the enterprise, for communication between private resources inside the enterprise. As a result, you can set your own rules for certificate validity periods and many other parameters. You can operate all the software needed for an internal PKI yourself, but this is a complex and error-prone task. DigiCert offers several internal PKI solutions for enterprise, cloud, and manufacturing use cases.
The same domain validation timeline also applies to OV and EV certificates. Ultimately, OV/EV certificates must also perform domain validation on the same schedule as DV certificates (that is, every 200/100/10 days). However, the other information included in those certificates (such as organization name and address) only needs to be renewed every 398 days. Domain validation can and should be automated, just as with DV certificates, but the other information cannot be fully automated.
Q: From the date the changes take effect, will browsers no longer accept certificates with validity periods exceeding 200/100/47 days?
Not exactly. The limits apply to the types of certificates CAs can issue, not the types of certificates browsers can accept. Browsers check "whether the current date falls within the certificate's validity period."
Once a rule change takes effect, CAs can no longer issue TLS certificates with validity periods exceeding 200/100/47 days. However, 398-day certificates issued before the rule change remain valid until they expire. The same applies when 200-day certificates change to 100 days and when 100-day certificates change to 47 days.
Q: What is the CA/B Forum?
The CA/Browser Forum (abbreviated as CA/B Forum or CABF) is an industry standards body made up of certificate authorities such as DigiCert (called certificate issuers in the standards) and applications that use certificates to authenticate resources (usually web browsers, called certificate consumers in the standards). Other stakeholders also participate as members, but voting rights are limited to qualified certificate issuers and consumers.
The first TLS Baseline Requirements (BRs) for TLS certificates took effect in 2012. There are also working groups that address standards for public code signing and S/MIME certificates.
Q: Do these standards changes also affect internal (private) PKI?
No. The Baseline Requirements are binding only on public certificate authorities.
An internal PKI operates within a network or cloud. An internal PKI also includes certificate authorities, but the policies enforced by internal certificate authorities, including certificate expiration dates, are set by the user. Choosing short expiration dates may be best practice for internal PKI as well, but it is not required. You can operate all the software for an internal PKI yourself, but this is a complex and error-prone task. DigiCert offers several internal PKI solutions for enterprise, cloud, and manufacturing use cases.
Q: If I have to replace certificates more often, will I have to pay more?
No. At least not with DigiCert CertCentral. Certificates are paid for as an annual subscription. During the subscription period, you can renew or replace certificates as often as needed at no cost, and ACME/ARI automation is also included in the subscription at no additional cost. Anticipating these changes was one of the reasons we moved to a subscription model.
When customers automate certificate renewal, many voluntarily move to faster replacement cycles, because it becomes easy and there is no reason not to. For example, switching to renewing every 30 days right away gives you confidence that you are prepared for the 2029 change.
Q: Do the new rules also affect intermediate and root certificates?
No. These rules affect only leaf certificates issued by intermediate CAs.
The CA/B Forum and other standards bodies have no rules limiting the validity periods of root and intermediate certificates, but generally agreed-upon best practices exist, and software vendors that consume certificates have their own rules for their trusted root programs, which can vary significantly.
The Mozilla Root Store Policy (Section 7.4) states that Mozilla will distrust root certificates 15 years after their keys are generated. The validity rules in Chrome Root Program Policy version 1.6 (February 15, 2025) are more complex. There is no explicit upper limit on validity periods, but it states that "root CA certificates whose corresponding key material was generated more than 15 years ago will be continuously removed from the Chrome Root Store." Roots containing keys generated before April 16, 2014 will be removed according to a fixed annual schedule defined in the Root Program Policy. The Microsoft Trusted Root Program states that "newly minted root CAs must have a validity period of at least 8 years and at most 25 years from the date of submission." The difference between Microsoft's rules and other policies stems from the fact that the range of applications Microsoft supports with PKI is much broader than that of other browsers.
One commonsense best practice is to ensure that a root CA certificate does not expire before any intermediate CA certificate chained under it.
Mismanaging the lifecycle of root and intermediate CA certificates can have serious consequences. Recently, there was a case in which many Google Chromecast devices were unable to use the service when a seemingly "forgotten" Google intermediate CA certificate expired.
Q: How do I automate certificate lifecycle management?
For common and relatively simple cases such as web servers and public TLS certificates, CertCentral customers can automate for free using the widely supported ACME (Automated Certificate Management Environment) and ARI (ACME Renewal Information) standards.
Of course, not all certificates are public TLS, and not all technologies support ACME. In those cases, DigiCert's Trust Lifecycle Manager provides advanced automation capabilities and integrations.
ACME automation goes beyond simply checking a box. Changes need to be made on the device or application requesting the certificate (usually a web server). However, most administrators will find that the procedure is not complicated and is well documented.
Q: What are ACME and ARI?
ACME stands for Automated Certificate Management Environment, and ARI stands for ACME Renewal Information.
ACME is a standard supported by all major certificate authorities through which certificate client software (usually a web server) requests certificates from a CA and installs them on the client. (In this scenario, the client is the web server.) The client software must also support ACME. Support is widespread but not universal. ACME client programs usually run on the client system on a schedule using Linux cron or Windows Scheduled Tasks, but there are other solutions that integrate scheduling into a larger product.
ARI is a related standard that allows the server to suggest a schedule so the client knows it needs to renew a certificate before it expires. When configured correctly, ARI can also prevent outages by instructing the client to renew even when a certificate has been revoked.
Q: How does this change affect Organization Validation (OV) and Extended Validation (EV) certificates?
Under the new rules for TLS certificates, from March 15, 2026, SII (Subject Identity Information) validation can be reused for only 398 days, down from 825 days. In other words, the main impact on OV and EV certificates is that SII, the "information included in the certificate that identifies the organization," must be revalidated every year rather than once every two years.
According to the TLS Baseline Requirements, this requires an annual phone call with a DigiCert representative, so full automation is not possible.
Because OV and EV certificates also protect domain names, the validity periods of OV and EV certificates change on the same schedule as DV certificates. They are reduced to 200 days in 2026, 100 days in 2027, and 47 days in 2029. The need to automate the management of these certificates is just as great as for DV certificates.
Q: Why 47 days?
47 days may seem like an arbitrary number, but it is simply the result of a cascade:
This model of "setting odd-numbered periods by adding wiggle room" has long been standard practice at the CA/B Forum. The current 398-day limit was chosen as up to 1 year (366 days) + up to 1 month (31 days) + 1 day of wiggle room.
Q: How do these changes relate to cryptographic threats from quantum computing?
There is no direct relationship. However, by forcing organizations to adopt automated certificate management solutions, we expect these changes to improve readiness for post-quantum cryptography (PQC).
The future transition to PQC will involve many changes across the cryptographic systems of infrastructure (such as certificate authorities), customer environments (web servers and other applications that use digital certificates), and the software itself (web browsers, network equipment, and so on). To keep up with these changes, organizations must be able to make software changes quickly without disrupting operations. Automated certificate lifecycle management makes an important part of this possible.
Certificates are only one part of PQC (though an important one), and many other software and hardware products you use will also need to be updated by various vendors to support PQC. Notably, 2029, when these changes take full effect, is also the point by which Gartner says "organizations should be quantum ready."
Q: How are non-browser clients (such as network equipment) affected?
The public TLS certificate market overwhelmingly supports browser-facing certificates installed on web servers, but there are other cases as well. VPN gateways and some IoT devices are good examples.
These devices will also need tighter CLM (certificate lifecycle management) cycles. Many devices directly support ACME or other automation protocols, so changing the parameters may not be a big task. In other cases, however, devices may support alternative automation mechanisms or none at all, in which case users must program the automation themselves.
Accommodating the new schedule on these devices will emerge as a common challenge. It is important to build a complete inventory of affected assets, and DigiCert can support this process.
Q: If I renew certificates before the 2026 deadline, can I still get 398 days?
Yes, renewing before March 15, 2026 to get another 398 days is permitted under the rules. However, this is a one-time extension. The next time you renew a certificate, the maximum validity period will have been reduced to 100 days. To prepare, please build automation in advance using CertCentral or Trust Lifecycle Manager.
If you need to reissue (rekey) a certificate on or after March 15, 2026, DigiCert (or any public CA) must follow the rules in effect at that time, in which case the certificate can be valid for a maximum of 200 days. The best time to automate certificate management is as early as possible. Please put an automation framework in place as soon as possible so you can prepare without the risk of outages due to expiration or other causes.
The sooner you prepare for certificate automation, "now" rather than "someday," the safer you will be. Systematize certificate lifecycle management with DigiCert Trust Lifecycle Manager (TLM) and respond to the reduction schedule (200 → 100 → 47 days) without disruption.
▶ DigiCert TLM Learn More
▶ FAQs: 47-Day TLS Certificates View Original
