200-Day SSL Certificate Timeline: What Changed in 2026

The 200 day ssl certificate timeline is the first operational deadline in the move from long-lived public TLS certificates to 47-day certificates. Under CA/Browser Forum Ballot SC-081v3, public SSL/TLS certificate lifetimes move from the old 398-day maximum to 200 days in 2026, then 100 days in 2027, then 47 days in 2029.

For a single website owner, that means renewals happen more often. For an agency managing 30, 100, or 300 client websites, it changes the rhythm of client-domain operations. Renewal tracking can no longer be an annual spreadsheet task. It needs a repeatable workflow that covers SSL expiry, DNS readiness, domain registration expiry, and client communication.

This article explains the timeline, what changed in 2026, and how agencies should prepare before the 100-day and 47-day phases arrive.

The 200 day SSL certificate timeline

CA/Browser Forum Ballot SC-081v3 introduced a staged reduction in maximum public TLS certificate validity. The important point for agencies is that the change is phased, not theoretical.

| Phase | Effective date | Maximum public TLS certificate lifetime | What agencies should do | |---|---:|---:|---| | Previous baseline | Before March 15, 2026 | 398 days | Inventory every client certificate and owner | | First reduction | March 15, 2026 | 200 days | Move renewal tracking from annual to twice-yearly | | Second reduction | March 15, 2027 | 100 days | Treat certificate monitoring as a recurring operations process | | Final target | March 15, 2029 | 47 days | Depend on automation plus independent monitoring |

The 200-day phase matters because it is the first point where teams feel the workload increase. A certificate that used to be renewed roughly once per year now has to be renewed about twice per year. That is still manageable for one domain. It is not manageable by memory across a full agency portfolio.

What changed in 2026

The 2026 change reduces the maximum lifetime for newly issued public TLS certificates to 200 days. It does not mean every certificate immediately expires in 200 days on the same date. It means certificates issued after the effective date must follow the new maximum.

That distinction matters for planning. Your agency may have a mix of:

• Older certificates still running under the previous maximum.
• Newly issued certificates capped at 200 days.
• Client domains using managed hosting that renews automatically.
• Client domains using manual or registrar-managed workflows.
• CDN certificates that are managed separately from the origin server.

The risk is unevenness. One client might be on a stable Let's Encrypt setup. Another may rely on a hosting panel. Another may have a paid certificate renewed manually by the client. When every domain has a different owner and renewal path, shorter certificate lifetimes expose weak process.

Why this hits agencies harder than single-site owners

Agencies do not manage certificates in isolation. They manage client relationships, ownership boundaries, DNS delegation, registrar access, hosting providers, and account managers who need plain-English status.

The renewal math is simple:

| Client domains monitored | Approx renewals at 398 days | Approx renewals at 200 days | Approx renewals at 47 days | |---:|---:|---:|---:| | 30 | 30 per year | 60 per year | 240 per year | | 100 | 100 per year | 200 per year | 800 per year | | 300 | 300 per year | 600 per year | 2,400 per year |

The numbers are approximate because certificates can renew before expiry, and managed platforms may rotate certificates on their own schedule. But the direction is clear. Renewal events multiply.

The more clients you manage, the less useful a calendar reminder becomes. The agency needs a live view of which certificates are healthy, which are approaching the warning window, and which clients need action.

The agency problem is not just expiry

SSL expiry is the visible failure. The operational failure often happens earlier.

DNS validation can block renewal

Many automated certificate renewals depend on domain validation. If the renewal uses DNS validation, the certificate authority needs to verify a DNS record. If the client moved DNS providers, removed an API token, or changed nameservers, the renewal can fail even though the current certificate still looks healthy.

This is why agencies should monitor DNS records alongside SSL expiry. A DNS change is not always bad. But unexpected DNS drift can explain why a future renewal will fail.

Client ownership can block action

Agencies often do not control the registrar or DNS provider. A client may own the domain, a previous vendor may control DNS, and the current agency may only manage the website. When a certificate enters a warning window, the first question is not always technical. It is operational: who can approve or perform the change?

Auto-renewal can fail quietly

Auto-renewal is necessary in the 47-day era, but it is not enough. Hosting accounts expire. DNS APIs change. HTTP validation paths break during migrations. CDN settings get overwritten. Independent monitoring catches the result before the client sees a browser warning.

What agencies should track before the 100-day phase

The 200-day phase is the right time to build the habit. Waiting until 47-day certificates arrive creates too much pressure.

Use this renewal readiness checklist:

| Area | Question to answer | Why it matters | |---|---|---| | SSL expiry | When does the live certificate expire? | Confirms the actual certificate browsers see | | Certificate owner | Who renews it: agency, host, CDN, client, registrar? | Prevents last-minute responsibility confusion | | DNS owner | Who controls nameservers and validation records? | Renewal often depends on DNS access | | Domain expiry | When does the domain registration expire? | A lapsed domain can break web and email | | CAA records | Are certificate authorities restricted? | Incorrect CAA can block issuance | | Client contact | Who approves registrar or DNS changes? | Reduces delays when action is needed | | Reporting | Is the status documented for the client? | Turns invisible maintenance into visible work |

If you want to see the current status of real domains, run the free 10-domain agency audit. For a single domain, use the free one-domain health check.

A simple operating model for 200-day certificates

The goal is not to turn every account manager into a certificate engineer. The goal is to make renewal risk visible early enough that the right person can act.

Step 1: Build a complete client-domain inventory

Start with domains, not certificates. Agencies usually think in client accounts. A client may have a main domain, staging domains, country domains, redirect domains, email-only domains, and old campaign domains.

For each domain, record:

• Client name.
• Website owner.
• Registrar owner.
• DNS provider.
• Hosting or CDN provider.
• SSL issuer.
• Live SSL expiry date.
• Domain registration expiry date.

This does not need to be perfect on day one. It does need to exist.

Step 2: Separate urgent SSL risk from limited data

Not every missing data point is an emergency. Some registries do not publish expiry through RDAP. Some DNS records are intentionally minimal. A useful monitoring process separates:

• Critical: expired or nearly expired certificate.
• Warning: certificate inside the renewal window.
• Limited data: public data source could not return complete information.
• Healthy: no immediate action.

That distinction prevents false alarms while still keeping uncertainty visible.

Step 3: Review DNS changes before renewal windows

DNS records are not static. Clients change email providers. Developers add verification records. Hosts move IP addresses. CDNs add records. Most changes are legitimate, but agencies need to know when they happened.

If A, AAAA, MX, NS, TXT, or CAA records change before a renewal window, review whether the change was expected. For deeper guidance, read how agencies can handle DNS drift.

Step 4: Report status monthly

A monthly report is not only for emergencies. It shows the client that maintenance is happening. Include SSL expiry, domain expiry, DNS changes, issues needing attention, and recommended actions. See the client website health report template for a practical reporting structure.

Decision framework: when to act

Use this simple framework during the 200-day phase:

| Signal | Suggested action | |---|---| | SSL expires in more than 60 days | Monitor normally | | SSL expires in 31-60 days | Confirm auto-renewal path and ownership | | SSL expires in 15-30 days | Open an internal task and verify renewal path | | SSL expires in under 14 days | Treat as urgent and contact the responsible owner | | DNS changed recently | Verify whether the change was intentional | | CAA exists and is restrictive | Confirm it allows the intended certificate authority | | Domain expiry is close | Confirm registrar renewal with the client |

The exact thresholds can vary by agency, but the discipline should not. Every domain should have an owner, a status, and a next step.

What not to overbuild

Agencies sometimes respond to SSL changes by looking for enterprise certificate lifecycle management systems. Those tools can be valuable for large internal infrastructure teams, but many web agencies need something simpler: visibility, client grouping, alerts, and reports.

For agency work, avoid overfocusing on:

• Deep TLS grading for every client site.
• Vulnerability scanning.
• Page speed scoring.
• Uptime monitoring.
• Legal compliance scoring.

Those are separate jobs. The 200-day SSL certificate timeline is primarily an operations problem: know what expires, who owns it, what changed, and what to do next.

How CertPilot fits

CertPilot is built for agencies managing client domains, not for generic server monitoring. It monitors SSL expiry, domain registration expiry, DNS records, and DNS changes across client websites. It also produces client-ready reports so your team can show the work instead of only reacting when something breaks.

Use the 200-day phase to build the habit now. By the time 100-day and 47-day certificates arrive, your agency should already have the workflow running.

Related resources

• 47-day SSL certificates agency guide
• 47-Day Renewal Pre-Flight
• SSL certificate renewal workload calculator
• How CertPilot checks domains

Frequently Asked Questions

What is changing with SSL certificate lifetimes?

Public SSL/TLS certificate lifetimes are being reduced in phases. The 200 day ssl certificate timeline starts with the March 15, 2026 limit, followed by 100-day certificates in 2027 and 47-day certificates in 2029.

For agencies, the important change is operational frequency. Client domains that were checked once a year now need a repeatable renewal and monitoring process.

Why do shorter SSL lifetimes matter for agencies?

Shorter lifetimes multiply SSL renewal workload across the whole client portfolio. A single renewal failure may be easy to fix, but dozens of clients across different hosts, CDNs, registrars, and DNS providers create coordination risk.

Agencies also need to know who owns the next action. Some renewals belong to the host, some to the client, and some depend on agency-controlled DNS.

Does automation remove the need for monitoring?

No. Automation is necessary, but it can still fail when DNS validation breaks, CAA records block issuance, hosting accounts lapse, or HTTP validation paths change during a migration.

Independent monitoring helps the agency see the live certificate and domain health signals before a client sees a browser warning.

Should agencies still keep a manual renewal spreadsheet?

A spreadsheet can be useful as a transition inventory, especially for ownership notes and client contacts. It should not be the only source of truth for expiry dates once certificates begin renewing more often.

Use the spreadsheet to document agency operations, then rely on live checks, reports, and alerts for current SSL, DNS, and domain expiry status.