47-Day SSL Certificates: What IT Teams Need to Track Before 2029

Public TLS certificate lifetimes are being cut to a maximum of 47 days by 2029. For a lean IT team, the headline number is not the hard part. The hard part is answering a quieter question for every domain you are responsible for: is this certificate renewed automatically, manually, by a vendor, or by nobody we can name? Expiry monitoring tells you when a certificate runs out. Readiness tracking tells you whether the renewal will actually happen.

This guide explains the official timeline, what changes operationally for internal IT, and how to keep a per-domain record of SSL readiness so the move to shorter certificates is boring instead of an incident. CertPilot supports this with public SSL/DNS/RDAP checks plus customer-entered SSL readiness metadata — it is not a certificate automation tool and does not issue, install, or renew certificates.

Use the 47-Day Renewal Pre-Flight to check readiness on a domain, the single-domain health check for a quick public SSL/DNS review, and the External Footprint Monitoring page to see how SSL checks and readiness metadata fit together. For the deeper cluster on ACME, CAA, and validation methods, start at the 47-day SSL readiness hub.

The official 47-day timeline

The reduction in maximum public TLS certificate validity was approved by the CA/Browser Forum in Ballot SC-081v3. It applies to publicly trusted TLS certificates — the certificates browsers validate for HTTPS — and it reduces the maximum validity in steps rather than all at once:

| Effective date | Maximum certificate lifetime | |---|---| | Until March 2026 | 398 days | | March 2026 | 200 days | | March 2027 | 100 days | | March 2029 | 47 days |

By March 2029, the maximum validity of a public TLS certificate reaches 47 days. The schedule is a ratified change to the CA/Browser Forum Baseline Requirements, not a proposal. You can read the formal ballot record here: CA/Browser Forum Ballot SC-081v3.

Two things worth being precise about:

• Not every certificate is 47 days today. The maximum lifetime shortens in phases. Certificates issued now can still carry longer validity up to the current cap; the new maximum applies to certificates issued on or after each phase boundary.
• The change applies at renewal, not retroactively. A certificate issued before a phase boundary is not shortened mid-life. But when it next renews after the boundary, the new certificate is bound by the new maximum.

What actually changes for a lean IT team

Most internal IT teams already monitor certificate expiry. Shorter lifetimes do not change what you monitor so much as how often a renewal can fail.

• Renewal frequency multiplies. A certificate that renewed roughly once a year will renew several times a year at 47-day lifetimes. Any renewal path that quietly failed once a year now has many more chances to fail.
• The gap between "renewal failed" and "site shows a warning" collapses. At 398 days, a broken renewal could sit unnoticed for weeks. At 47 days, the buffer is days.
• Manual and vendor-controlled certificates become the risk. Fully automated ACME renewals scale fine. The dangerous domains are the ones where renewal depends on a person remembering, or a vendor you assume is handling it.
• "Unknown" is the worst category. A domain where nobody can say how the certificate renews is an outage waiting for a date.

This is why the operational job is readiness classification, not just an expiry calendar.

Track readiness, not just expiry

For each public-facing domain, record how its certificate is actually renewed and who is accountable. CertPilot stores this as customer-entered SSL readiness metadata on the domain record — it sits alongside the automated checks but does not affect technical health scoring. The fields map to the questions that matter:

• SSL management method — how this certificate is renewed (for example: ACME/automated on the host, a CDN or platform that manages it, a vendor, or manual issuance).
• SSL automation status — automated, partially automated, manual, or unknown.
• SSL readiness notes — anything a future colleague needs: which ACME client, which validation method, which vendor contact, known gotchas.
• SSL reviewed date — when a human last confirmed the renewal path actually works.

A simple four-way classification

Sort every domain into one of four buckets and you will instantly see your real exposure:

| Bucket | What it means | Pre-47-day action | |---|---|---| | Automated | ACME or platform renews it without human action | Verify the last renewal actually ran; confirm CAA allows the issuer | | Manual | A person requests/installs the certificate | Plan to automate, or accept a much tighter manual cadence | | Vendor-controlled | A CDN, host, or third party renews it | Confirm the vendor's process and a named contact | | Unknown | Nobody can say how it renews | Investigate first — this is your highest risk |

The goal of the 47-day transition for a lean IT team is to move every domain out of Unknown and to shrink the Manual column.

A 90/60/30 readiness checklist

A practical cadence before each shortening step (March 2026, March 2027, March 2029):

• 90 days out. Inventory every public-facing domain you own. For each, record the SSL management method, automation status, the validation method where known, and an accountable owner. Mark anything you cannot explain as Unknown.
• 60 days out. Run the 47-Day Renewal Pre-Flight across the portfolio. Resolve domains flagged Action needed or Review — commonly a CAA record that excludes the active issuer, a closed port 80 for HTTP-01 validation, or a missing HTTPS redirect.
• 30 days out. Confirm each automated renewal actually ran in the last cycle, confirm vendors for vendor-controlled domains, and update the SSL reviewed date so the record reflects a real check, not an assumption.
• Every cycle. Re-check exceptions and keep the readiness notes current as hosts, CDNs, and vendors change.

What CertPilot can help with

CertPilot keeps the public signals and the readiness record in one place so a small team can show its work:

• Public SSL checks — certificate expiry, issuer, and validity read from the public TLS handshake, checked daily.
• DNS and CAA visibility — public A/AAAA, MX, NS, TXT, and CAA records, with change detection between checks, so you can see the records a renewal depends on.
• Customer-entered SSL readiness metadata — management method, automation status, readiness notes, and reviewed date per domain.
• Pre-Flight readiness checks — the 47-Day Renewal Pre-Flight surfaces per-domain readiness signals (SSL expiry, DNS basics, CAA, port 80, HTTPS redirect) before a renewal window opens.
• Domain Health evidence — the readiness record and check results land in the Domain Health Report. See the sample report gallery for what that looks like.

What CertPilot does not do

CertPilot stays on the evidence side of the line:

• It is not a certificate automation tool. It does not issue, install, renew, or rotate certificates, and it has no ACME/Certbot integration.
• It does not replace your certificate management tooling. The CA, ACME client, host, CDN, or vendor that renews your certificates today keeps doing so.
• The SSL readiness fields are customer-entered metadata. They are not derived from RDAP/WHOIS data, and they do not change technical SSL, DNS, or domain scoring.
• No vulnerability scanning, penetration testing, uptime monitoring, or compliance certification.

Frequently Asked Questions

Are all SSL certificates already 47 days?

No. The maximum lifetime drops in phases — 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029. Certificates issued today can still carry longer validity up to the current maximum. The 47-day cap applies to certificates issued on or after the final phase boundary.

Does CertPilot renew or issue SSL certificates?

No. CertPilot monitors public SSL, DNS, and domain signals and lets your team record SSL readiness metadata. It is not a certificate authority or an ACME client, and it does not issue, install, renew, or rotate certificates. Renewals stay with the host, ACME client, CDN, or vendor that owns them today.

Why does the 47-day change matter more for IT teams than individuals?

A single site owner renews one certificate occasionally. A lean IT team is responsible for many public-facing domains, each renewing several times a year under shorter lifetimes. The volume of renewal events — and the chance that one silently fails — is what makes per-domain readiness tracking worthwhile.

What is the difference between expiry monitoring and SSL readiness?

Expiry monitoring tells you when a certificate runs out. Readiness tells you whether the renewal will succeed — whether it is automated, manual, or vendor-controlled, whether CAA records allow the issuer, and whether anyone owns it. A certificate can have weeks of validity left and still be heading for a failed renewal.

Does the SSL readiness metadata change my domain's health score?

No. SSL readiness fields are customer-entered planning metadata. They are displayed alongside the automated checks but do not affect technical SSL, DNS, or domain-expiry scoring.

Where should I start?

Run the 47-Day Renewal Pre-Flight across your public-facing domains, then classify each one as automated, manual, vendor-controlled, or unknown. Resolve the unknowns first — they carry the most risk as lifetimes shorten.

Related resources

• 47-day SSL readiness hub — the cluster hub covering ACME, CAA, validation methods, and CA fallback.
• 47-day SSL certificates: the complete agency guide — the agency-portfolio view of the same change.
• 200-day SSL certificate timeline — the phase-by-phase calendar.
• External Footprint Monitoring — how SSL checks, DNS evidence, and readiness metadata fit together.
• Sample reports — see the Domain Health Report format.