The 47-Day Certificate Timeline: What Every DevOps Team Needs to Know

In April 2025, the CA/Browser Forum passed ballot SC-081v3. If you haven't read it, the short version is: TLS certificate maximum lifetimes are going from 398 days down to 47 days, in stages, between now and March 2029.

The first phase hit in March 2026 (this month). Maximum certificate lifetime dropped from 398 days to 200 days. If you're reading this and didn't notice, that probably means your auto-renewal is working. For now.

The next drops come faster and hit harder. By March 2029, your certificates will need to be renewed every 47 days. Your domain validation records will expire every 10 days.

I want to lay out the full timeline, explain what breaks at each stage, and talk about what you should actually be doing right now to prepare. There's a lot of bad information out there about this topic, so I'm going to try to be precise.

What is SC-081v3?

SC-081v3 is a ballot that was approved by the CA/Browser Forum, the industry body that sets rules for Certificate Authorities (CAs) and browser vendors. The ballot amends the Baseline Requirements, which are the rules every publicly trusted CA must follow.

Apple proposed the original version. Google backed it. Mozilla backed it. The major CAs voted in favor. It passed with overwhelming support. This is happening.

The stated goals: reduce the window of exposure when a private key is compromised, push the ecosystem toward full automation, and shorten the time that stale or incorrect certificate information (like organization names and domain ownership) stays trusted.

Those are reasonable goals. Whether the transition will be smooth is a different question.

The full timeline

Here is the phased reduction schedule as specified in SC-081v3. I've added the DCV (Domain Control Validation) reuse period because it's just as important as the certificate lifetime change, and most people miss it.

Effective date	Max cert lifetime	DCV reuse period	Status
Before March 2026	398 days	398 days	Expired
March 15, 2026	200 days	200 days	Active now
March 15, 2027	100 days	100 days	12 months away
March 15, 2029	47 days	10 days	3 years away

Read that last row carefully. 47-day certificate lifetime. 10-day DCV reuse. That means your domain validation needs to be re-verified every 10 days, and your certificates need to be replaced roughly every 6 weeks.

200 days (now): what changed

We are in the first phase right now. As of March 15, 2026, no publicly trusted CA will issue a certificate valid for more than 200 days. The previous limit was 398 days (roughly 13 months).

For most teams running ACM, Let's Encrypt, or any ACME-based auto-renewal, this changed nothing operationally. Let's Encrypt already issues 90-day certs. ACM issues certs with 13-month lifetimes but auto-renews them at 60 days before expiry; now it just issues shorter ones. If your automation is working, you didn't feel this.

The teams that felt it: anyone still buying annual certs from DigiCert, Sectigo, GlobalSign, or any other commercial CA. "Buy a cert once a year and forget about it" just became "buy a cert every 6 months." And it's about to get worse.

The DCV reuse period also dropped to 200 days. This matters more than people think. DCV reuse is the window during which your CA can issue new certificates for a domain without re-verifying that you own it. At 398 days, you could validate once and get certs for over a year. At 200 days, that window halved. At 10 days (the March 2029 target), your CA needs fresh proof of domain ownership every week and a half.

100 days (March 2027): where things get uncomfortable

At 100-day lifetimes, the math changes.

A certificate that lives for 100 days needs to be renewed roughly 3.5 times per year. If you're renewing 30 days before expiry (standard practice), you're hitting your CA every 70 days. Per certificate.

If you manage 500 certificates, that's about 2,600 renewal operations per year. At 398 days, it was 500. That's a 5x increase in renewal volume, and every one of those is a potential failure point.

This is the phase where manual certificate management becomes impossible. Not impractical. Impossible. No human is going to track 500 certificates that each need renewal every 70 days. The spreadsheet that "kind of works" today will be underwater by March 2027.

Teams still buying commercial certs manually will need to either switch to ACME-based automation or accept that they'll be doing cert renewals every quarter for every single cert. I've talked to teams that manage 200+ commercial certs. They do not have the headcount for quarterly manual renewals across all of them.

47 days (March 2029): the end state

47 days. That means certificates expire in about 6.5 weeks. If you renew 30 days before expiry, you are renewing every 17 days. Some teams will lower that buffer and renew at, say, 14 days, which means a renewal cycle of 33 days.

Either way: every certificate in your estate is getting replaced roughly once a month.

And the DCV reuse period drops to 10 days. This is the part that I think is going to cause the most problems. Every DNS-based domain validation (the CNAME records that prove you own a domain) needs to be re-verified every 10 days. If the validation record gets deleted, the renewal fails.

Think about what that means in practice. You have a DNS zone managed by one team. Your certificates are managed by another team. Someone cleans up "stale" DNS records. A CNAME record that looks like line noise (_acme-challenge.api.example.com) gets deleted. 10 days later, your certificate renewal fails. 30 days after that (or less), your cert expires. Your users see a browser warning. Your API clients start throwing TLS errors.

This will happen to someone. Probably a lot of someones.

Why "we have auto-renewal" is not a complete answer

I hear this constantly. "We use ACM, auto-renewal handles it." Or "Everything is Let's Encrypt with certbot." And yes, auto-renewal is the right foundation. But it is not sufficient by itself. Here is why.

Auto-renewal fails silently

When ACM fails to renew a certificate, it does not page you. It sets the renewal status to PENDING_VALIDATION and waits. If you are not actively watching that status field, you will not know until the cert expires. AWS added CloudWatch metrics for ACM renewal status, but you have to set up the alarm yourself, per account, per region. Most teams don't.

Imported certs don't auto-renew at all

Any certificate you imported into ACM (rather than requesting it through ACM) is not eligible for auto-renewal. ACM will send expiration notifications if you set up EventBridge rules, but it will not renew the cert. You have to do it yourself. I have seen organizations with 40% of their ACM certs being imported, and nobody realized those were manual-renewal-only until one expired in production.

DNS validation records get deleted

ACM uses CNAME records to validate domain ownership. These records need to stay in DNS for the lifetime of the certificate. But they look like garbage to anyone who doesn't know what they are:

Name:  _8f12ab90d6c8e44f2b1c.api.example.com
Type:  CNAME
Value: _a7d93c42b8.hnqfvsfwjl.acm-validations.aws.

Someone migrates your DNS from Route 53 to Cloudflare and doesn't copy the validation records. Someone does a "cleanup" of records they don't recognize. Someone runs a Terraform apply that manages DNS zone records and doesn't include them. I've seen all three.

With 200-day DCV reuse, you might not notice for months. With 10-day DCV reuse, you'll notice in about two weeks, when the next renewal attempt fails and nobody catches it because auto-renewal failures are silent by default.

IAM permissions change

ACM needs certain IAM permissions to perform auto-renewal. If someone tightens permissions on the service-linked role, or if an SCP (Service Control Policy) at the organization level blocks the required actions, auto-renewal breaks. This is surprisingly common in large organizations where security teams adjust IAM policies regularly.

Let's Encrypt has rate limits

Let's Encrypt limits you to 50 certificates per registered domain per week. That sounds generous until you have a microservices environment with 80 subdomains of example.com and they all try to renew in the same window. At 47-day lifetimes with 30-day-early renewal, you have a 17-day renewal window. If certbot on 80 servers all fire within the same few days, you might hit the rate limit and some renewals will fail.

You can work around this with wildcard certs or by staggering renewal times. But you have to think about it. Most teams don't think about it until it breaks.

Azure Key Vault has its own failure modes

If you're on Azure, Key Vault certificate lifecycle policies handle auto-renewal, but only if: the Key Vault contact email is configured, the certificate issuer integration is set up correctly, and the cert was originally created through Key Vault (not imported). I have audited Azure environments where half the Key Vault certs were imported and nobody had configured the auto-renewal policy for them.

What to do now

You have about 12 months before the 100-day deadline. That sounds like a lot. It is not, if you have a large certificate estate spread across multiple cloud accounts. Here is what I would prioritize.

1. Build a complete inventory

You cannot fix what you cannot see. Most organizations I talk to do not have a single view of all their certificates. They have ACM certs in 20 AWS accounts, Key Vault certs in 50 Azure subscriptions, Let's Encrypt certs on bare-metal servers, commercial certs from DigiCert that someone bought three years ago, and a wildcard cert in a shared S3 bucket that six services depend on.

Get them all in one place. All of them. Cloud-managed certs, imported certs, certs on load balancers, certs on servers, certs in Kubernetes secrets. If it terminates TLS, you need to know about it.

2. Identify every manual certificate

Go through your inventory and tag every cert that requires manual renewal. Imported ACM certs. Certs from commercial CAs that don't support ACME. Internal PKI certs that someone generates with openssl on their laptop. Old certs that predate your automation setup.

These are the certs that will expire first when lifetimes compress. They are your highest-risk items and they need a plan: either migrate them to auto-renewal or set up monitoring and alerting for each one.

3. Verify that auto-renewal is actually working

Don't assume. Check. Go look at the renewal status of every auto-managed certificate. In ACM, look for certs with renewal status PENDING_VALIDATION or FAILED. In Key Vault, look at the lifecycle policy status. For Let's Encrypt, check that certbot cron jobs are still running and that the last renewal actually succeeded.

I guarantee you will find at least one cert that should be auto-renewing but isn't. Everybody does.

4. Protect your DNS validation records

Audit your DNS zones. Find every ACM validation CNAME, every ACME challenge record, every domain verification TXT record. Document them. Make sure your DNS-as-code (Terraform, Pulumi, whatever) includes them. Add comments explaining what they are and why they cannot be deleted.

At 10-day DCV reuse, a deleted validation record will cause a renewal failure within days. This is the single most common cause of unexpected auto-renewal failures that I have seen, and it is going to get much more painful.

5. Set up monitoring and alerting

Auto-renewal is your first line of defense. Monitoring is your second. You need something that watches every certificate and tells you when renewal fails, when a cert is approaching expiry without being renewed, and when a new cert appears that you didn't expect.

This can be as simple as a script that calls the ACM API across all your accounts and checks renewal status, or as sophisticated as a dedicated monitoring tool. What matters is that it exists, it covers your entire estate, and it alerts the right people.

6. Plan your ACME migration

If you still have commercial certs that are renewed manually, the 100-day deadline in March 2027 is your forcing function. Start migrating them to ACME now. Most major CAs support ACME at this point (DigiCert, Sectigo, GlobalSign all have ACME endpoints). If your CA doesn't support ACME, switch to one that does, or use Let's Encrypt for DV certs and keep the commercial CA only for EV/OV certs where you need the organization name in the cert.

The real problem is visibility

Shorter certificate lifetimes are, on the whole, a good thing for security. A compromised private key is dangerous for 47 days instead of 398 days. Stale certificate data gets corrected faster. And the push toward automation means fewer manual processes that depend on someone remembering to do something.

But the transition is going to be painful for teams that don't have visibility into their certificate estate. You can't automate what you can't see. You can't monitor what you don't know about. And you can't fix a renewal failure if nobody tells you it happened.

The teams that will handle this well are the ones that already have a complete certificate inventory, working auto-renewal, and monitoring that catches failures. The teams that will get burned are the ones running on a combination of manual processes, optimistic assumptions about auto-renewal, and a spreadsheet that someone last updated four months ago.

Common questions

Does this apply to internal/private CA certs?

No. SC-081v3 applies to publicly trusted certificates only, i.e., certificates issued by CAs that are in browser trust stores. Internal CAs (AWS Private CA, HashiCorp Vault PKI, step-ca, EJBCA) can issue certs with whatever lifetime they want. That said, if you're already running internal PKI, shorter lifetimes are best practice there too, and many organizations are converging on 24-hour or even shorter lifetimes for internal mTLS certs.

Will browsers enforce the new limits, or just CAs?

Both, eventually. CAs are required to stop issuing certs that exceed the new limits. Browsers may also start rejecting certs that violate the timeline, which would affect certs issued by non-compliant CAs. Apple and Google have both indicated they will enforce on the client side. So even if a rogue CA issues a 400-day cert after March 2026, browsers may reject it.

What about EV and OV certificates?

Same rules. EV and OV certs are subject to the same maximum lifetime reductions. The organization validation data can be reused for a longer period than DV data, but the certificate itself still has the same maximum lifetime. EV certs at 47-day lifetimes with the current manual verification process are going to be interesting, to put it mildly.

Can I just use wildcard certs to reduce the number of renewals?

Wildcards reduce the total number of certificates, which reduces total renewals. But they concentrate risk: one failed wildcard renewal takes down every service using that wildcard. And the private key for a wildcard cert is more valuable to an attacker than a single-domain key. It is a tradeoff. I generally recommend wildcards for dev/staging environments and specific-domain certs for production, but that depends on your threat model.

We have 2,000 certificates. Is this going to be a problem?

At 47-day lifetimes with 30-day-early renewal, 2,000 certs means about 43,000 renewal operations per year (roughly 117 per day). If every one of those is automated, you are fine. If even 5% of them are manual, that is 100 manual renewals per month. You need to figure out which of your 2,000 certs are manual and fix them before March 2029. Preferably before March 2027.