SSL Certificates Are Getting Shorter: Is Your Business Ready for 47-Day TLS Certificates?

Public SSL/TLS certificates are becoming much shorter-lived. The maximum permitted validity period has already fallen from 398 days to 200 days, will fall to 100 days in March 2027, and will eventually reach just 47 days in March 2029.

That change improves internet security, but it also changes certificate management from an occasional administrative task into a continuous operational process.

For businesses running websites, APIs, customer portals, mail services and other internet-facing systems, manual renewal will become increasingly risky. Certificate automation, independent monitoring and reliable alerting will no longer be optional extras.

UpMonix helps businesses watch certificate expiry, validity, hostname matching, issuer changes and certificate-chain problems so failed renewals can be found before customers see a security warning.

The change is now an adopted industry requirement

The reduction was introduced through CA/Browser Forum Ballot SC-081v3. It was supported by major certificate authorities and unanimously approved by the participating browser and platform members Apple, Google, Microsoft and Mozilla.

The timetable applies to publicly trusted TLS server certificates:

Before 15 March 2026: 398 days
15 March 2026 to 14 March 2027: 200 days
15 March 2027 to 14 March 2029: 100 days
On or after 15 March 2029: 47 days

The first stage therefore took effect on 15 March 2026. This is not a distant proposal businesses can postpone considering until 2029.

Certificate authorities may issue certificates for less than the permitted maximum. For example, Let’s Encrypt plans to move its standard certificates from 90 days to 64 days in February 2027 and then to 45 days in February 2028.

SSL and TLS: what is actually changing?

“SSL certificate” remains the familiar term used by many website owners, hosting companies and control panels. Modern secure connections actually use TLS, the successor to SSL.

The change concerns publicly trusted TLS server certificates used to authenticate internet-accessible services, including:

Websites and ecommerce stores
APIs and application endpoints
Customer and staff portals
Load balancers and reverse proxies
Content delivery networks
Mail and collaboration services using public TLS
Public cloud services and gateways

Private certificates issued by an organisation’s own internal certificate authority are not automatically governed by the public Web PKI timetable, although shorter lifetimes and better automation may still be sensible.

Why are certificate lifetimes being reduced?

A certificate confirms that certain information was valid when it was issued. The longer it remains valid, the greater the chance that circumstances change while the certificate is still trusted.

Shorter certificate lifetimes reduce the period during which a compromised, incorrectly issued or outdated certificate can continue to be accepted.

The CA/Browser Forum identified several benefits:

Reduced exposure after compromise

When a private key or certificate is compromised, a shorter remaining lifetime limits how long it can potentially be abused.

More current validation

Certificate authorities must confirm that the applicant still controls the relevant domain. More frequent validation reduces reliance on information collected many months earlier.

Less dependence on revocation

Certificate revocation systems such as CRLs and OCSP have limitations involving scale, privacy, performance and reliability. Short-lived certificates naturally stop being trusted sooner, even if revocation does not work perfectly.

Faster security transitions

Shorter lifetimes make it easier for the ecosystem to move away from an algorithm, key type or certificate practice if a weakness is discovered.

Better certificate-management practices

Frequent replacement encourages organisations to automate issuance, deployment and rotation instead of relying on calendar reminders and manual installation.

Domain validation is also becoming more frequent

Certificate validity is only part of the change. The maximum period for reusing domain-name and IP-address validation data is also being shortened:

From 15 March 2026: 200 days
From 15 March 2027: 100 days
From 15 March 2029: 10 days

By 2029, a certificate may be valid for up to 47 days, but the certificate authority will generally be able to reuse domain-control validation for no more than 10 days.

This matters because certificate renewal workflows must be able to complete domain validation reliably and frequently. Systems that depend on a person uploading a file, changing a DNS record or approving an email are more likely to fail under this model.

What shorter certificates mean for businesses

A 47-day maximum does not mean administrators should renew on day 46. Renewal must happen much earlier to allow time for validation, deployment and recovery from errors.

In practice, certificates may be replaced roughly every month or even more frequently. A company with 100 public certificates could therefore process well over 1,000 certificate replacements each year.

Manual renewal becomes unsafe

A yearly diary reminder may have worked when certificates lasted roughly 13 months. It is not a reliable process when renewals occur every few weeks across multiple systems.

Staff absence, ownership changes, missed emails or a forgotten server can quickly cause an outage.

Old renewal schedules may expire certificates

Some legacy scripts use fixed rules such as “renew every 60 days” or “renew when 30 days remain”.

A process that runs every 60 days cannot safely manage a certificate valid for only 45 or 47 days. Fixed-day thresholds can also create poor timing as certificate lifetimes vary between issuers.

Renewal systems should follow the certificate authority’s recommended renewal window or use a percentage of the certificate lifetime.

Deployment failures become more visible

Obtaining a new certificate is only one part of renewal. It must also be installed on the correct service, paired with the correct private key, supplied with the required intermediate certificates, loaded by the service and deployed to every node and region.

An automated order can succeed while deployment fails. The certificate authority may report success even though customers still receive the old certificate.

Forgotten certificates become a larger risk

Certificates may exist on systems outside the main website, including API gateways, development systems, VPN portals, mail servers, control panels, load balancers, CDN custom domains and third-party platforms.

Businesses need an inventory showing where certificates are used, who owns each service and how renewal occurs.

More frequent domain validation may expose DNS problems

DNS permissions, API credentials, delegated zones, CAA records and validation records must all work reliably.

A change of DNS provider, expired API credential or removed _acme-challenge delegation can stop automated issuance even though the live certificate remains valid for the moment.

Alert fatigue must be avoided

A static “30 days remaining” warning is less useful when a certificate begins with only 45 days of validity. Monitoring should understand the certificate’s total lifetime, expected renewal point and urgency.

It should also distinguish between a short-lived certificate by design, a renewal that has not happened when expected, a newly issued certificate that was not deployed, an invalid chain and a hostname mismatch.

Let’s Encrypt is moving earlier than the final deadline

Let’s Encrypt currently issues 90-day certificates, but it has announced its own staged reduction:

13 May 2026: its opt-in tlsserver ACME profile began issuing 45-day certificates for testing and early adoption.
10 February 2027: its default classic profile is scheduled to move to 64-day certificates, with a 10-day authorisation reuse period.
16 February 2028: its default profile is scheduled to move to 45-day certificates, with a seven-hour authorisation reuse period.

Let’s Encrypt recommends ACME Renewal Information, usually called ARI, so compatible clients can learn when the certificate authority wants a certificate renewed.

It also warns that hardcoded 60-day renewal intervals will no longer work and advises organisations to monitor their systems so they are alerted when renewal does not happen as expected.

Automation is necessary—but monitoring is the safety net

Automation and monitoring solve different parts of the problem.

Certificate automation requests, validates, installs and rotates certificates.

Certificate monitoring independently checks what customers are actually receiving.

Relying only on automation creates a dangerous blind spot. A renewal job can fail silently, install a certificate on the wrong host or miss one node in a cluster.

A resilient process should therefore include:

Automated certificate issuance and renewal.
Automated deployment to every required endpoint.
Independent external verification.
Alerts to people who can take action.
Escalation if a warning is not acknowledged.
Testing and documentation for emergency replacement.

How UpMonix can help

UpMonix gives businesses an independent view of their public certificate health.

Depending on the selected monitor and plan, UpMonix can help teams watch for:

Certificate expiry

Receive warnings before a certificate reaches a critical point. Alert thresholds should be appropriate for shorter-lived certificates rather than assuming every certificate lasts a year.

Failed or missing renewal

If the expected replacement certificate is not observed, UpMonix can warn the responsible team while time remains to investigate.

Hostname mismatch

A valid certificate can still fail if it does not cover the hostname customers are using.

Invalid or incomplete chain

A missing intermediate certificate or invalid trust chain may work on some devices but fail on others.

Issuer changes

An unexpected change of certificate authority or issuing chain can indicate an infrastructure change, misconfiguration or activity that requires investigation.

Multi-channel alerts

Warnings can be routed to the channels your team actually monitors, including email and supported messaging or incident channels. Critical warnings should not depend on a single inbox.

Monitoring across client estates

Agencies and managed service providers can track certificates across multiple customer websites and services from one place, helping them include certificate readiness in maintenance and support plans.

UpMonix does not replace your certificate authority or ACME client. It provides the independent monitoring layer that confirms renewal and deployment have worked.

A certificate-readiness checklist

Businesses should begin preparing now rather than waiting for the 47-day stage.

1. Create a complete certificate inventory

Record the domain, service, environment, certificate authority, expiry date, renewal method, deployment location, technical owner, business owner and alert recipients.

2. Remove manual renewal where possible

Move publicly trusted certificates to a supported automated process such as ACME or a certificate-management platform.

3. Review ACME-client compatibility

Confirm that the client runs frequently enough, does not depend on a fixed 60- or 90-day interval, supports ARI where available, retries safely and produces useful failure notifications.

4. Test domain validation

Check HTTP, DNS and TLS validation paths. Review DNS API credentials, permissions, CAA records, firewalls and delegated challenge zones.

5. Verify deployment, not merely issuance

After renewal, test the certificate served from every important hostname, load balancer, region and edge endpoint.

6. Add external SSL/TLS monitoring

Do not make the renewal system responsible for confirming itself. Monitor from outside the network so the result reflects the customer experience.

7. Update warning thresholds

Use thresholds appropriate to the total certificate lifetime and expected renewal point. Escalate rapidly when a short-lived certificate enters its final days.

8. Run a failed-renewal exercise

Test how the team responds when issuance or deployment fails. Confirm who receives the alert, who can access the system and how quickly a certificate can be replaced.

9. Review suppliers and managed services

Ask hosting companies, CDN providers, SaaS vendors and IT partners how they are preparing for shorter certificate lifetimes. Clarify who owns renewal and who receives failure alerts.

10. Document emergency replacement

Keep a short runbook covering validation, issuance, installation, service reload, rollback and external verification.

Do businesses need to replace existing certificates immediately?

No. A certificate that was validly issued under the rules applying at the time can generally continue until its existing expiry date.

The new maximum applies according to the date a new certificate is issued. When that certificate is renewed or replaced, the validity permitted at the new issuance date applies.

However, the 200-day stage is already active, and renewal frequency will increase again in March 2027.

Will certificates need to be renewed every 47 days?

Not exactly.

Forty-seven days will be the maximum permitted public TLS certificate validity from 15 March 2029. Certificate authorities will normally issue for slightly less than the maximum, and renewal should occur well before expiry.

For example, Let’s Encrypt plans to issue 45-day certificates rather than use the full 47-day maximum.

A well-designed automated system may replace certificates roughly two-thirds of the way through their lifetime or follow an ARI-provided renewal window.

Is this only an issue for large enterprises?

No.

Large organisations may have more certificates, but smaller businesses often have less formal ownership and fewer people available to respond. A certificate tied to a forgotten email address or manually managed hosting account can take an entire online business offline.

Shorter lifetimes make reliable automation and monitoring valuable for every organisation that depends on its website, API, customer portal or mail service.

Prepare before the next reduction

The move toward short-lived certificates is a positive security change, but it removes the margin for error that allowed weak certificate-management practices to survive.

The businesses best prepared for 47-day certificates will know every certificate they operate, automate renewal and deployment, and independently monitor the certificate customers actually receive.

UpMonix can provide that external monitoring layer—watching certificate expiry and validity and alerting your team when something changes or fails.

Start by checking your most important domain, then add continuous SSL/TLS monitoring before the next certificate renewal becomes an outage.