Website security certificates are easy to ignore until they expire. For many smaller businesses, the current arrangement still feels manageable: a hosting company, web developer or IT supplier renews the certificate roughly once a year, and the site keeps showing the padlock in the browser.
That model is becoming less forgiving. The public TLS certificate ecosystem is moving towards much shorter certificate lifetimes. The change is not a rumour or a social-media scare story. The CA/Browser Forum has approved a phased reduction that will make public website certificates valid for a maximum of 47 days from March 2029, with shorter limits starting before then.
This does not mean every business needs to panic today. It does mean that manual certificate renewal is becoming a weak operating model. If your website, customer portal, payment journey, booking system, API or email service depends on someone remembering a renewal date, now is the time to fix the process.
What Is Changing?
The CA/Browser Forum’s Ballot SC-081v3 on reducing validity and data reuse periods introduced a staged reduction for public TLS certificates. Its purpose is to shorten the period in which a compromised or incorrectly issued certificate can remain useful, while pushing the ecosystem towards better automation.
The current CA/Browser Forum Baseline Requirements set out the timeline:
- Until 15 March 2026: public subscriber certificates can have a maximum validity of 398 days.
- From 15 March 2026: the maximum falls to 200 days.
- From 15 March 2027: the maximum falls to 100 days.
- From 15 March 2029: the maximum falls to 47 days.
The rules also reduce how long some domain validation data can be reused. By 2029, domain name and IP address validation reuse falls to 10 days. In practice, certificate issuing will need to be repeatable, reliable and automated. A once-a-year manual admin task becomes a regular operational dependency.
Why Browser and Certificate Authorities Want Shorter Certificates
Shorter certificates are not a magic security fix. A poorly managed website can still be breached, and a valid certificate does not prove that a business is trustworthy. TLS certificates do a narrower job: they help users’ browsers confirm that they are connecting securely to the domain they intended to visit.
The security argument for shorter lifetimes is that mistakes and compromises age out faster. If a private key is exposed, a domain validation was performed incorrectly, or a certificate should no longer be trusted, a shorter certificate gives less time for that certificate to be abused before it naturally expires.
The operational trade-off is obvious. Shorter certificates create more renewal events. That is acceptable when renewal is automated and monitored. It is risky when certificates live in spreadsheets, inbox reminders, individual supplier accounts or control panels that nobody regularly checks.
What This Means for Small-Business Websites
For a brochure website on well-managed hosting, the change may be almost invisible. Many hosts already automate certificate issue and renewal through services such as Let’s Encrypt or a managed certificate authority. The owner may only need to check that renewals are monitored and that someone receives alerts if automation fails.
The risk rises where a business has more than one system. Common examples include:
- a WordPress site on one host and a separate booking platform on a subdomain;
- a customer portal, supplier portal or web app outside the main website;
- an API used by mobile apps, ERP integrations or manufacturing systems;
- email security services, redirects, CDNs, load balancers or legacy servers;
- staging sites, old campaign domains or regional domains that still point somewhere.
Those certificates are often owned by different suppliers. One may be renewed automatically, another may depend on a finance contact approving an invoice, and another may be hidden inside a server nobody has touched for two years. Shorter lifetimes make that fragmentation more likely to cause outages.
The Practical Standard Is Automation Plus Monitoring
The NCSC’s guidance on provisioning and managing certificates in the Web PKI is clear that automated certificate provisioning and renewal reduce human error, but automation itself needs monitoring. If a renewal job breaks quietly, the business still has a problem.
That distinction matters. A website owner should not just ask, “Is the certificate set to auto-renew?” The better questions are:
- Which domains and subdomains do we actually use?
- Who controls the DNS records for each one?
- Which certificate authority issues each certificate?
- Is renewal automatic, and how is it tested?
- Who receives alerts if renewal fails or a certificate is issued unexpectedly?
- Can the person receiving the alert fix the issue before customers are affected?
Automation also needs secure access. Certificate management software can prove control of a domain and request certificates on your behalf. That means its credentials, DNS permissions and server access should be treated as sensitive operational assets, not casual setup details.
Where ACME Fits In
The Automatic Certificate Management Environment standard, usually called ACME, is one of the main ways certificate lifecycle management is automated. It allows compatible software to request, validate, issue, renew and revoke certificates through a standard protocol.
Many businesses will never interact with ACME directly because their host, CDN or platform handles it. Others may use an ACME client on a server, in a container platform or in a cloud service. Let’s Encrypt maintains a useful list of ACME client implementation options, while noting that third-party clients vary and should be selected carefully.
The important business point is not the name of the tool. It is whether certificate renewal is repeatable without a person logging into a dashboard every few weeks, and whether failure is visible early enough to fix.
A Sensible Preparation Checklist
Small businesses do not need enterprise certificate-management software by default. The right answer depends on the number of domains, systems and suppliers involved. A practical preparation plan is usually enough:
- Inventory public-facing domains. Include the main website, subdomains, portals, APIs, redirects, staging domains and old microsites.
- Record ownership. Note who manages DNS, hosting, CDN settings, certificates and renewal alerts for each service.
- Remove what you no longer need. Retire unused domains, stale subdomains and forgotten test sites rather than carrying unnecessary certificate risk.
- Confirm automated renewal. Ask suppliers how renewal works, what happens if validation fails and whether the process is already compatible with shorter lifetimes.
- Monitor expiry and issuance. Use platform alerts, uptime monitoring and, where appropriate, Certificate Transparency monitoring for unexpected certificates.
- Avoid fragile manual steps. Certificate renewal should not depend on one named person, an annual invoice reminder or undocumented access to an old server.
- Test recovery. Know how quickly a broken renewal can be fixed, who can change DNS, and who can restart or reconfigure the affected service.
The Bigger Lesson
The 47-day certificate deadline is several years away, but the first reduction arrives on 15 March 2026. That makes this a good time to turn certificate renewal from an occasional admin chore into a managed part of website operations.
For most small businesses, the target is straightforward: use reputable managed hosting or a well-understood automated certificate setup, keep DNS ownership clear, monitor expiry, and make sure support responsibilities are written down. That will not only prepare the business for shorter certificate lifetimes. It will also reduce the chance of a preventable outage long before the 47-day limit arrives.