TL;DR
- Maximum TLS certificate validity is falling in scheduled steps: 398 days, then 200 days (live since 15 March 2026), 100 days from 15 March 2027, and 47 days from 15 March 2029. Renewals per certificate rise from about one a year to nearly eight, and the schedule applies to every organisation using publicly trusted certificates.
- Domain validation reuse shrinks at the same time, from 398 days to just 10 by 2029, so validation has to be automated alongside renewal. The NCSC’s Web PKI guidance, published on 10 December 2025, advises automated renewal such as ACME and active monitoring.
- Certificates issued before 15 March 2027 keep their current validity, so there is a window to get discovery and automation in place before renewal volumes double. ITogether is a listed G-Cloud 15 supplier, which gives public sector bodies a direct route to DigiCert without a full tender.
What Is Changing and When
Public TLS certificates have been getting shorter for years, but the CA/Browser Forum has now fixed the remaining steps in a single schedule. The ballot, SC-081v3, was approved in April 2025 with support from the major browser makers and certificate authorities. It applies to every organisation with publicly trusted TLS certificates, public sector or not, and it applies by issue date:
| From | Maximum certificate validity | Domain validation reuse | Renewals a year, per certificate |
| Before 15 March 2026 | 398 days | 398 days | About 1 |
| 15 March 2026 (live now) | 200 days | 200 days | About 2 |
| 15 March 2027 | 100 days | 100 days | About 4 |
| 15 March 2029 | 47 days | 10 days | Nearly 8 |
We covered why this is happening, and why machine identities make it a resilience issue, in our earlier piece on certificate lifespans. This article picks up where that left off: what the NCSC now advises, the validation change that gets less attention, and what to do before the next step. The detailed dates above come from the ballot itself and from DigiCert’s published summary of it.
What the NCSC Advises
The NCSC’s Provisioning and managing certificates in the Web PKI, published on 10 December 2025, is written for architects and engineers, but its recommendations map directly onto the decisions CIOs and IT directors need to resource:
| NCSC recommendation | What it means in practice |
| Use automated provisioning and renewal, such as ACME | Remove the human step from routine renewals so a missed email doesn’t become an expired certificate |
| Consider ACME Renewal Information (ARI) | Let the certificate authority prompt early renewal if it needs to revoke or manage load |
| Monitor issuance and renewal | Know which certificates are in use where, and get early warning when automation fails |
| Generate a new private key at renewal | Limits the value of any undetected key compromise |
| Use CAA DNS records and avoid unnecessary wildcards | Restrict which authorities can issue for your domains and limit the impact of a single compromise |
| Monitor Certificate Transparency logs | Spot certificates issued for your domains that you didn’t request |
It also notes that automation tools typically renew when between a quarter and a third of the validity period remains, so the working renewal cycle is shorter than the headline figure. Monitoring matters even when renewal is automated: with shorter lifetimes, it is imperative to have effective monitoring on the automation itself so problems can be fixed before the current certificate expires.
Domain Validation Is the Quiet Part of the Change
Most of the attention goes to validity periods, but the reuse period for domain validation is shrinking in step, from 398 days to 10 days by March 2029. That is how long a certificate authority can rely on a previous proof that you control a domain before it must check again.
- A 47-day certificate with 10-day validation reuse means validation effectively happens at every renewal, not once a year.
- DigiCert’s own summary notes that manual revalidation will still be technically possible in 2029, but describes doing so as a recipe for failure and outages.
- The practical consequence is that DNS or ACME-based validation needs to be set up and owned by someone, and tested, before the shorter cycles bite.
- The NCSC also recommends domain validated certificates for all use cases, in part because the extra checks behind organisation and extended validation usually need manual intervention and can’t be fully automated.
The Window Before 15 March 2027
The limits apply on the date of issue, so nothing falls off a cliff. A certificate issued in the days before 15 March 2027 can still run for up to 200 days. But from that date, every new or renewed public certificate is capped at 100 days, which roughly doubles the renewal workload for anyone still working manually; the same again at 47 days.
That gives a useful window, a little over five months from today, to do the unglamorous groundwork without a deadline crisis:
- Find every public certificate, including those issued by other providers and those nobody remembers requesting.
- Name an owner for each, so alerts go to a person rather than a shared mailbox.
- Choose how renewal and domain validation will be automated, and test it on a low-risk service first.
- Switch on expiry alerting that covers the automation as well as the certificate.
Where DigiCert Fits
Any approach that meets the NCSC’s advice will do the job, and open-source ACME clients suit simple estates. Where estates are larger or mixed, DigiCert’s platform is built around three things, and as a UK Digicert partner, ITogether sees all three come up in most estates we review:
- Discovery: scanning networks, clouds and endpoints to find certificates, including those from other providers, and importing them into one inventory. Capability varies by Trust Lifecycle Manager plan, so check which tier covers multi-CA discovery.
- Automation: renewal and issuance through ACME, SCEP, Windows auto-enrolment and APIs, via Trust Lifecycle Manager or CertCentral. DigiCert’s ACME supports DV, OV and EV certificates and ARI.
- Visibility: approval workflows, validation tracking and expiry alerts routed to the right owners, so the estate can be governed rather than just renewed.
DigiCert also states that pricing is based on an annual subscription rather than per replacement, so more frequent renewal does not in itself raise the cost. As with any vendor claim, confirm this against your own contract.
Where Other Options Fit
DigiCert isn’t the only sensible route, and the right answer depends on where your certificates live and how many certificate authorities you use. Capabilities below are as described by each vendor, so confirm them against current documentation before you buy.
| Option | What it does | Where it tends to fit |
| DigiCert Trust Lifecycle Manager and CertCentral | Discovery, ACME and other automation, and expiry alerting, with ACME supporting DV, OV and EV certificates | Mixed estates that want issuance and management from one vendor, and public bodies buying via G-Cloud 15 |
| AppViewX AVX ONE CLM | Lifecycle management across public and private certificate authorities, with ACME, automated domain validation and short-lived certificate support | Estates using several certificate authorities that want a single management layer independent of any one CA |
| AWS Certificate Manager | Managed public certificates for AWS services, plus a managed ACME endpoint (announced July 2026) issuing 45-day certificates | Estates running mostly on AWS; check which certificate types and lifetimes apply to your services |
| Portnox Cloud PKI | Certificates that authenticate users and devices to the network | A different problem: private certificates for network access, outside the public TLS schedule, but worth planning alongside it |
| Open-source ACME clients, such as Certbot | Free automation of issuance and renewal for individual servers | Small or simple estates with few certificates and in-house skills; weaker on discovery, ownership and reporting |
Our view: choose by estate shape, not by brand. A single-cloud estate may be well served by its provider’s tooling, a multi-CA estate by a CA-neutral platform, and a mixed one by discovery first, whichever product follows.
Buying Through G-Cloud 15
ITogether is a listed supplier on G-Cloud 15, with DigiCert among the services available under Infrastructure Software as a Service. For public sector bodies, that means certificate discovery, ACME automation and expiry alerting can be bought directly through the Digital Marketplace without running a full tender. Buyers should still follow their own procurement guidance and confirm the current listing on the Digital Marketplace before committing.
What We’re Seeing in Practice
What we see most often when this comes up:
- Certificates are tracked in a spreadsheet or a calendar, and ownership sits with whoever raised the original request, which is often someone who has since moved on.
- Estates are mixed: certificates from several authorities, bought at different times by different teams, with no single view of what exists.
- Teams are confident about the main public website and less sure about APIs, VPN gateways and supplier-hosted services, which is where unexpected expiries tend to surface.
UK & New Zealand Perspective
The schedule is global, but the starting points differ:
- UK: estates, particularly in the public sector, are often large and long-lived, with legacy systems and supplier-hosted services, and G-Cloud gives buyers a ready procurement route.
- NZ: the same browser and authority rules apply to any publicly trusted certificate, so the timetable is identical, though leaner IT teams may feel the extra renewal workload sooner.
ITogether’s Independent Verdict
None of this is a reason to panic. The schedule is published, the dates are known, and the steps are gradual. But it is a one-way change, and each step makes manual management less workable than the last.
The sensible response is unglamorous: find your certificates, name their owners, automate renewal and validation together, and monitor the automation. DigiCert is one credible way to do that, particularly for mixed estates, but the NCSC’s advice stands regardless of which tool you choose.
👉 Not sure how many public certificates you have, or who owns them? Get in touch.
📞 UK +44 (0) 113 341 0123
📞 NZ +64 (0)9 802 2444
📧 hello@itogether.com
FAQs
Does This Apply Only to the Public Sector?
No. The schedule is set by the CA/Browser Forum and applies to every publicly trusted TLS certificate, whoever buys it. Public sector bodies are the focus here because G-Cloud 15 is a public sector buying route.
Do Certificates Issued Before 15 March 2027 Keep Their Validity?
Yes. The limits apply to the date of issue, so a certificate issued before 15 March 2027 can keep its current validity of up to 200 days. New and renewed certificates issued from that date are capped at 100 days.
Does This Affect Internal or Private PKI?
The schedule applies to publicly trusted TLS certificates. The NCSC addresses privately hosted PKI in separate guidance, so check which of your certificates are public before assessing the impact.
Can Public Sector Bodies Buy DigiCert Without a Tender?
ITogether is a listed supplier on G-Cloud 15, and DigiCert is among the services listed, so eligible bodies can buy through the Digital Marketplace without a full tender. Follow your own procurement guidance and check the current listing first.

0 Comments