Most writing about the shrinking TLS certificate lifetime is a countdown clock. It tells you that 47 days is coming in 2029, tells you to "start automating", and stops there. That framing is wrong in two ways: it points at the wrong date, and it points at the wrong problem.
The wrong date, because the change that will actually break your stack already happened. Since 15 March 2026 the maximum lifetime of a publicly trusted TLS certificate is 200 days, not 398. The annual renewal ritual your team runs is already illegal to issue against. The wrong problem, because in a small startup the certificate that expires is almost never the one you were watching. It is a load balancer listener somebody stood up during a launch, a partner webhook endpoint, or a staging domain that quietly became production.
This post is written for a five to twenty person engineering team with no dedicated platform or PKI owner. It covers the exact schedule, the second column of that schedule that nearly every summary skips, the three classes of thing that automation will not fix for you, and the specific managed options each cloud shipped in 2026 that make this a one-afternoon job instead of a quarter.
Quick context: what changed and when
In April 2025 the CA/Browser Forum passed Ballot SC-081v3, unanimously among certificate consumers and 25 to 0 among certificate issuers. It sets a staged reduction in two linked numbers: how long a public TLS certificate may be valid, and how long a CA may reuse the domain control validation it already performed for you.
Both numbers step down on the same three dates. Every publicly trusted CA is bound by it, which means there is no vendor you can switch to in order to opt out. This is not a Let's Encrypt policy or an AWS policy. It is the floor of the public web PKI.
Takeaway: the first step is behind you, the second lands in March 2027, and the change is non-negotiable across every CA you could pick.
1. The schedule, including the column most summaries drop
Here is what SC-081v3 actually mandates. Maximum certificate validity falls from 398 days to 200 days on 15 March 2026, to 100 days on 15 March 2027, and to 47 days on 15 March 2029. Alongside it, the maximum period a CA may reuse your domain control validation data falls from 398 days to 200 days in 2026, to 100 days in 2027, and to 10 days in 2029.
That second column is the one that gets left out of vendor blog posts, and it is the one with teeth. Certificate validity determines how often you need a new certificate. Validation reuse determines how often you need to prove domain ownership again. Those are different engineering problems with different failure modes, and they diverge sharply at the end of the schedule: a 47-day certificate against a 10-day validation window means the proof mechanism runs roughly five times per certificate.
Practitioner opinion: teams that plan only against the validity column will build something that works fine in 2027 and falls over in 2029, because they will have automated issuance while leaving validation resting on a DNS record somebody added by hand.
Takeaway: write both numbers into your plan. Whatever you build has to survive a validation challenge running on its own clock, faster than issuance.
2. Why validation reuse is the harder half
Under the old 398-day reuse window, a CA could issue you a certificate today using ownership proof it collected a year ago. That is why plenty of teams have working renewal without working validation: the renewal path never re-ran the challenge, so nobody noticed the challenge had rotted.
The common rot is mundane. The DNS TXT record for a DNS-01 challenge was placed manually and the domain later moved registrar. The HTTP-01 challenge path, /.well-known/acme-challenge/, is now intercepted by a CDN rule, an auth middleware, or a catch-all redirect to HTTPS that was added for a security scan. The IAM credentials your ACME client uses to write DNS records were issued to an engineer who has since left, or are a long-lived static key of the kind workload identity federation exists to remove.
None of these show up until the reuse window expires and the CA insists on a fresh proof. Under the 2026 rules that is at most 200 days, so the blast radius of a rotted challenge is now bounded to roughly half a year instead of hiding for a full one. That is an improvement, and it is also why some teams will meet this failure for the first time in 2026.
Takeaway: force a validation run now rather than discovering it on expiry. Issue a throwaway certificate for a test subdomain through the same client and credentials your production renewal uses.
3. Start with an inventory, because you do not have one
Ask most seed-stage teams where their certificates are and you get the CDN and the main load balancer. The list is nearly always longer: origin certificates behind the CDN, regional load balancer listeners, an API gateway custom domain, a marketing site on a separate host, a status page, a docs subdomain, mail and tracking subdomains, a partner-facing webhook receiver, and any legacy virtual machine still terminating TLS directly.
Build the list from the outside in rather than from memory. Certificate Transparency logs give you every publicly trusted certificate ever issued for your domains, searchable through crt.sh. That catches the hosts nobody remembers, including ones a contractor provisioned. Then cross-reference from the inside: list ACM certificates per region, Google Cloud Certificate Manager entries, Cloudflare edge and origin certificates, and any Kubernetes Secret of type kubernetes.io/tls.
For each row record three things: who issues it, what renews it, and what consumes it. The third is the one people skip and the one that determines whether an automated renewal actually reaches the thing serving traffic.
Takeaway: a certificate whose renewal path you cannot name in one sentence is a scheduled outage. Treat "unknown" as a finding, not a gap in the spreadsheet.
4. The certificates automation will not save you on
Some endpoints break precisely because renewal succeeded. If a mobile app pins a specific leaf certificate or its public key, a successful renewal that rotates the key ships a working server that your own app refuses to talk to, and you cannot fix it from the server side. The same applies to embedded devices with a baked-in trust store, and to enterprise partners who allowlisted your certificate fingerprint in their firewall during onboarding.
At 398-day lifetimes a team could survive this with a calendar reminder and a coordinated app release once a year. At 100 days it is a recurring release dependency. At 47 days it is not viable at all.
The fix is to stop pinning leaves. Pin to an intermediate or root where you must pin at all, keep a backup pin for a second CA chain, and set an expiry on the pin set so a stale build fails open rather than bricking. Practitioner opinion: for most startups the right answer is to remove pinning entirely and rely on the platform trust store, because a botched pin has caused far more self-inflicted outages than it has prevented interception.
Takeaway: grep your mobile and firmware code for pinned hashes today. Anything pinned to a leaf must be reworked before the 2027 step, not after.
5. The manual copy step is where the outage actually happens
Plenty of teams technically have automation: a cron job runs an ACME client, gets a fresh certificate, and writes it to disk. Then a human copies it into the load balancer console, or a deploy pipeline bakes it into a container image, or an engineer restarts nginx by hand so the new file is picked up.
That last hop is where short lifetimes bite. Renewal that requires a human once a year is an annoyance. The same step every 30 days is a job nobody owns, and the failure is silent until customers see a browser warning. Practitioner opinion: this is the single most common shape of certificate outage in small teams, well ahead of anything a CA does.
Close the loop by making the consumer read the certificate from a store rather than a file that gets replaced. Point AWS listeners at an ACM ARN so rotation is invisible to the listener. In Kubernetes, mount the Secret and give the workload a reload path so a rotated Secret takes effect without a manual restart. Where a process genuinely needs a signal, wire the ACME client's post-renewal hook to send it.
Takeaway: trace one certificate from issuance to the process serving traffic. Every human step you find is a recurring outage on a 30-day timer.
6. ACME plus ARI is the standards-based answer
The protocol to build on is ACME, defined in RFC 8555. It automates account registration, domain validation, issuance and renewal, and it is supported by every mainstream CA and client worth using.
The newer piece is ACME Renewal Information, standardised as RFC 9773. ARI adds a renewalInfo endpoint that a client polls per certificate. The CA answers with a suggestedWindow carrying a start and end timestamp, and the client picks a random moment inside it. Certbot and a growing set of clients support it.
Two reasons this matters more than it sounds. First, it decouples your renewal timing from a fixed threshold you guessed at, and spreads load so the whole internet does not renew at midnight UTC. Second, it gives the CA a channel to pull your renewal forward. ARI came directly out of Let's Encrypt having to revoke around three million certificates in 2020 with no way to tell subscribers to replace them early. If a CA hits a mass revocation event, an ARI-aware client renews before the revocation lands rather than after.
Takeaway: pick a client with ARI support and turn it on. It is the difference between surviving a CA incident automatically and reading about it on a status page.
7. What each cloud shipped in 2026 to make this easier
The managed options improved substantially this year, and for most startups they remove the need to run an ACME client at all.
On AWS, ACM managed renewal has always handled certificates attached to integrated services such as ALB, CloudFront and API Gateway. From 18 February 2026 ACM public certificates carry a maximum validity of 198 days, down from 395, to sit inside the new limit. More interesting is the ACME support ACM added on 6 July 2026: a managed ACME endpoint issuing 45-day certificates from Amazon Trust Services, usable from any ACMEv2 client including certbot, acme.sh and cert-manager, in all commercial regions, with domain scope and wildcard restrictions plus CloudTrail logging.
On Google Cloud, Certificate Manager issues and renews Google-managed certificates automatically for supported load balancers.
If you would rather not depend on a cloud, Let's Encrypt made six-day certificates and IP address certificates generally available on 15 January 2026 via the shortlived profile, at a 160-hour lifetime.
Takeaway: if your TLS terminates on a managed load balancer or CDN, use the provider's managed certificate and delete your ACME client. Reserve self-managed ACME for endpoints the provider cannot cover.
8. Kubernetes: check your renewal maths before the next step
In Kubernetes the standard tool is cert-manager, and the default that matters is when it renews. Per the Certificate resource docs, cert-manager renews at two thirds through the certificate's duration by default, and the default spec.duration is 90 days.
Run that against shorter lifetimes. A 47-day certificate renewed at two thirds leaves roughly 16 days of buffer, which is workable. The trap is renewBefore set as an absolute duration. A team that hardcoded renewBefore: 720h for 90-day certificates has asked to renew 30 days before expiry; hand that config a 47-day certificate and it renews after 17 days, and hand it a shorter one and cert-manager can enter a renewal loop. The docs recommend renewBeforePercentage exactly because it recomputes against the duration the CA actually issued rather than the one you expected.
Also confirm the whole chain keeps up at the new cadence: the ACME solver, the DNS provider API and its rate limits, the credentials behind it, and Secret propagation to pods. This belongs on the same list as the other cluster security defaults worth checking on your current minor version.
Takeaway: replace absolute renewBefore values with renewBeforePercentage now. It is a one-line change that stops a class of failure you will otherwise meet in 2027.
9. Revocation stopped being your safety net in 2025
Shorter lifetimes exist largely because revocation never worked well, and the industry has now acted on that. Let's Encrypt ended OCSP support in 2025: OCSP URLs were removed from certificates and CRL URLs added on 7 May 2025, and the OCSP responders were shut down entirely on 6 August 2025. The stated reasons were privacy, since every OCSP query told the CA which site a visitor was loading, and the operational cost of running responders.
The practical consequence is that if a key of yours leaks, you should not assume clients will honour a revocation quickly or at all. Your real containment control is a short lifetime plus the ability to rotate on demand, which is only a control if rotation is automated and you have tested it deliberately.
Practitioner opinion: run a rotation drill the same way you would a restore drill. Force a renewal outside the normal window on one production certificate, in business hours, and watch what breaks. The teams that find pinning and manual copy steps in a drill are the ones that do not find them at 03:00.
Takeaway: treat short lifetimes as your revocation strategy, and prove the rotation path works before you need it.
10. What to monitor once renewal is automated
Automation moves the failure rather than removing it, so the alert has to move too. Expiry monitoring on its own is necessary but late; by the time a 47-day certificate is inside a week of expiry, several renewal attempts have already failed silently.
Alert on three things. First, days remaining on the certificate actually being served, probed from outside your network rather than read from your config, so you are measuring what a browser sees. Second, renewal attempt failures from the client or controller, which is the earliest signal you get. Third, unexpected issuance for your domains, watched through Certificate Transparency monitoring, which catches both a rogue certificate and a forgotten host you never inventoried.
Set the expiry threshold as a fraction of lifetime, not a fixed 30 days. A 30-day warning on a 47-day certificate fires two thirds of the way through normal operation and will be muted within a month.
Takeaway: alert on renewal failure first and expiry second, and probe the live endpoint rather than trusting your own configuration.
Summary
| Item | Now (since 15 Mar 2026) | 15 Mar 2027 | 15 Mar 2029 |
|---|
| Max certificate validity | 200 days | 100 days | 47 days |
| Max DCV data reuse | 200 days | 100 days | 10 days |
| Manual renewal | Painful | Unsustainable | Not viable |
| Leaf certificate pinning | Fragile | Release blocker | Must be gone |
Absolute renewBefore | Works by luck | Loop risk | Broken |
Where to start, by stage
Pre-seed. Do the inventory from Certificate Transparency, then move every endpoint you can onto a managed certificate from whatever load balancer or CDN already terminates your TLS. Aim to own zero renewal jobs. This is a half day of work.
Seed. Same baseline, plus the endpoints a managed product cannot cover. Run one ACME client with ARI enabled, replace absolute renewBefore with renewBeforePercentage, add renewal-failure alerting, and run one deliberate rotation drill.
Series A. Add ownership. Someone should be able to answer where every certificate comes from, and Certificate Transparency monitoring should page when a certificate appears for your domains that no pipeline created. At this size the risk shifts from forgetting to renew toward not knowing what exists.
If you want a second pair of eyes on the inventory step, that is exactly the kind of thing a short cloud security review turns up quickly, usually alongside three other things nobody was watching. Open the free checklist and work through it against your own environment.
About the author
Avinash S is the founder of MatrixGard, a fractional DevSecOps practice that acts as the cloud, infrastructure and security team for early-stage startups. He works with pre-seed and seed companies across India, Singapore, the UAE, the US and the UK on cloud architecture, security hardening and compliance readiness.
Methodology note
Every date, validity period and validation reuse figure in this post comes from the CA/Browser Forum's SC-081v3 ballot page or from the primary vendor announcement linked inline: Let's Encrypt for short-lived certificates, ARI and the OCSP shutdown, AWS for the ACM validity change and ACME endpoint, Google Cloud for Certificate Manager, and the cert-manager project docs for renewal defaults. No client data, engagement outcomes or private figures are used anywhere in this post. Statements that reflect my own judgement rather than a cited source are labelled "Practitioner opinion" inline. Schedules published by standards bodies can change; confirm the current phase against the ballot page before you plan around a date.
