The next deadline for shorter HTTPS certificates is approaching. Under the CA/Browser Forum’s published schedule, the maximum validity of newly issued, publicly trusted TLS certificates falls to 100 days on March 15, 2027, down from the 200-day ceiling that took effect in March 2026.
For companies running websites, APIs and internet-facing applications, the change makes certificate renewal a more frequent operational responsibility. It also shifts attention toward a weakness that can remain hidden for years: certificates that someone still renews by hand, installs through an appliance dashboard or tracks in a spreadsheet.
This is a scheduled industry transition, not a newly announced browser policy. But with the next reduction less than five months away as of October 19, 2026, organisations still relying on manual renewal have a narrowing window to prepare. A further reduction to 47 days is already on the calendar for 2029.
What changes, and when
The CA/Browser Forum’s TLS Baseline Requirements establish common requirements for certificate authorities issuing certificates trusted by browsers. Its adopted timetable progressively reduces both certificate lifetimes and the period for which certain validation information can be reused.
For certificate validity, the principal milestones are:
- March 15, 2026: a maximum of 200 days for newly issued certificates.
- March 15, 2027: the maximum drops to 100 days.
- March 15, 2029: the maximum drops to 47 days.
These are maximum permitted lifetimes, not a requirement that every certificate last that long. Providers can issue certificates with shorter validity, and many already do.
The dates also apply to issuance. A certificate issued before a transition date does not automatically become invalid on that date simply because the new ceiling is shorter. Its permitted validity is governed by the requirements applicable when it was issued, subject to other reasons it might be revoked or distrusted.
The distinction matters for planning: March 15 is not a single global expiration event. The effects work through certificate inventories as organisations request, renew and replace certificates.
The security argument is about reducing stale trust
A TLS certificate links a domain name to a public key and helps a browser or other client authenticate the server it is contacting. That assurance is based on checks performed before issuance. Over time, circumstances can change: a domain can change hands, infrastructure can move, or a private key can be exposed.
Shorter lifetimes reduce the period during which an issued certificate can remain valid without replacement. They also encourage more frequent validation and make it possible to cycle changes through the certificate ecosystem faster.
That does not make certificate revocation unnecessary. A compromised certificate may still need to be revoked immediately, and issuing a fresh certificate is not, by itself, proof that a compromised private key has been replaced. Shorter validity is one part of the security model, not a substitute for incident response or sound key management.
There is a practical trade-off. More frequent replacement reduces the lifetime of stale credentials, but an unreliable renewal process gets more opportunities to fail. For users, those failures can appear as browser warnings, unavailable checkout pages or applications unable to connect to an API.
Renewing the certificate is only half the job
The immediate pressure is on certificate lifecycle automation. At a 100-day maximum, an organisation needs several successful replacement cycles each year for every continuously operating endpoint. At 47 days, treating each renewal as a separate administrative project becomes still harder to justify.
Protocols such as ACME can automate certificate requests and issuance. Managed hosting platforms, content delivery networks and cloud services may handle much of that work for customers already. Businesses using those services should nevertheless establish which endpoints are covered and where responsibility remains with their own teams.
The difficult cases often sit outside the main website: a legacy load balancer, a supplier-operated portal, an internet-facing appliance or an API gateway with a separate certificate store. A renewal job can succeed while the production service continues presenting the old certificate.
That is why automated certificate renewal needs to include deployment and verification, not just obtaining a replacement file. Teams need evidence that the endpoint users actually reach is presenting the expected certificate after the update.
Independent certificate expiration monitoring remains useful even when issuance is fully automated. It can detect a stalled deployment, an overlooked hostname or a renewal process that stopped working after credentials or network settings changed.
Domain validation has its own tightening timetable
The schedule also reduces how long certificate authorities may reuse earlier domain or IP-address validation results. Under the adopted requirements, the maximum domain validation reuse period falls to 100 days in March 2027 and then to 10 days in March 2029.
Certificate validity and validation reuse are different clocks. The former determines how long an issued certificate can remain valid; the latter governs whether a certificate authority can rely on an earlier check when issuing another certificate.
The distinction becomes especially significant in 2029. A 47-day certificate ceiling does not mean an earlier domain-control check can necessarily be reused throughout those 47 days. Organisations will need dependable ways to complete fresh validation when their certificate authority requires it.
For teams using DNS-based domain validation, that can put DNS provider integrations and credential management directly into the availability chain. Permissions should be appropriately restricted, but they also need to remain functional when certificates are due for replacement.
What businesses should check before March
The scope is narrower than “every digital certificate.” These requirements concern publicly trusted TLS certificates. Private certificate authorities used solely within an organisation do not automatically inherit the same limits, and code-signing certificates are governed by different requirements.
Even within that scope, ownership can be fragmented. A useful inventory needs more than domain names and expiration dates: it should identify the issuing authority, the system performing renewal, the deployment destination and the team responsible when something fails.
Businesses should also examine managed TLS services rather than assuming a hosting contract covers every certificate. A provider may manage certificates at its network edge while the connection to the customer’s origin server uses a separately maintained certificate.
The central question before March is straightforward: can every affected service obtain, install and verify a replacement certificate without relying on someone remembering a calendar reminder? The published timetable gives organisations advance warning. Whether shorter certificates become routine maintenance or recurring outages depends on the reliability of that entire process.
Source and timing: This report is based on the CA/Browser Forum’s adopted certificate-validity and validation-reuse schedule, available through its TLS Baseline Requirements documents. It covers the scheduled transition rather than a newly announced policy change.
