Navigating Apple’s Proposal to Shorten TLS Certificate Lifespans

Quick answer: The CA/Browser Forum’s Ballot SC-081v3 cuts the maximum validity of public TLS certificates from 398 days to 47 days in three phases between March 2026 and March 2029. Domain validation reuse drops to 10 days on the same schedule, and OV/EV identity reuse drops from 825 days to 398 days starting March 15, 2026. Manual renewal will not scale at this frequency, so automation is now a requirement, not an option.

This is no longer a draft proposal. In April 2025, the CA/Browser Forum passed Ballot SC-081v3 by a unanimous 25 to 0 vote, approving a phased reduction in the maximum validity period for public TLS certificates down to just 47 days by March 2029. The measure was originally proposed by Apple and formally sponsored by Sectigo, and it now governs every publicly trusted certificate authority under the CA/Browser Forum.

The change is already in effect. As of March 15, 2026, no public certificate authority can issue a TLS certificate valid for more than 200 days. The next reduction lands March 15, 2027, and the final 47-day ceiling takes hold March 15, 2029. Alongside it, domain and identity validation windows are shrinking on a parallel schedule, which means the operational burden on security, platform, and compliance teams is arriving well before the 2029 deadline.

This article walks through why the CA/Browser Forum made this change, exactly what changes and when, who inside your organization needs to act, and a concrete readiness checklist and migration roadmap for public certificate management.

Key Takeaways

• Ballot SC-081v3 reduces maximum public TLS certificate validity from 398 days to 47 days across three phases: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029.
• Domain Control Validation (DCV) reuse falls on the same schedule, from 398 days down to 10 days by March 15, 2029.
• Subject Identity Information (SII) reuse for OV and EV certificates drops from 825 days to 398 days in a single cutover on March 15, 2026, not a gradual phase-in.
• DigiCert’s July 2025 Trust Pulse Survey found 45% of organizations had certificate-related downtime in the past year, and 37.5% traced outages directly to expired certificates.
• Manual certificate management, spreadsheets, calendar reminders, or ticket queues, cannot sustain renewal cycles that run every 47 days. Automation through ACME or a certificate lifecycle management (CLM) platform is the baseline requirement, not an upgrade.
• PKI, security, platform engineering, and compliance teams each carry distinct, overlapping responsibilities under this timeline; none of them can treat it as someone else’s problem.

Why the CA/Browser Forum Approved Shorter Certificate Lifespans

Shorter-lived certificates shrink the window an attacker has to exploit a stolen or misissued certificate. If a private key leaks today, the certificate built on it expires in weeks rather than months, so there is less need to lean on revocation mechanisms like CRLs and OCSP, which have never been reliably fast at internet scale.

The CA/Browser Forum’s own rationale, and the reasoning Sectigo published when it endorsed the ballot, breaks down into four drivers:

1. Reduced risk window: Shorter validity limits how long a compromised or mis-issued certificate can be exploited. Whether the cause is a leaked private key or a rogue issuance, the exposure is contained to a much narrower window.
2. Faster security agility: Shorter lifespans make it easier to roll out upgraded cryptographic algorithms or corrected configurations, since every certificate is already on a short replacement cycle.
3. Forced automation: Manual renewal does not scale once certificates expire every 47 or 100 days. The policy pushes organizations toward automated certificate lifecycle management, cutting the human error that causes most outages.
4. Post-quantum readiness: Frequent renewal cycles create a natural, recurring opportunity to swap in post-quantum cryptography as NIST-standardized algorithms roll out, instead of waiting for a disruptive, one-time migration.

The 47-Day TLS Certificate Timeline: What Changes and When

Ballot SC-081v3 does not drop certificate validity to 47 days overnight. It phases the reduction in over roughly three years, giving organizations a runway to automate before the shortest cycle takes effect. The table below lists every effective date, what it requires, who it affects, and the primary source for each milestone.

Effective Date	Requirement	Who Is Impacted	Action Needed	Source
March 15, 2026	Maximum public TLS certificate validity drops to 200 days. DCV reuse drops to 200 days.	All organizations running publicly trusted TLS certificates	Confirm CA and CLM tooling supports 200-day issuance; begin ACME rollout	CA/Browser Forum, Ballot SC-081v3
March 15, 2026	Subject Identity Information (SII) reuse for OV/EV certificates drops from 825 days to 398 days	Organizations using OV or EV certificates	Plan for organizational revalidation roughly every 398 days going forward	Sectigo, CA/Browser Forum passes ballot (April 14, 2025)
March 15, 2027	Maximum validity drops to 100 days. DCV reuse drops to 100 days.	All organizations running publicly trusted TLS certificates	Automation must be production-ready; manual renewal is no longer viable at this cadence	CA/Browser Forum, Ballot SC-081v3
March 15, 2029	Maximum validity drops to 47 days. DCV reuse drops to 10 days.	All organizations running publicly trusted TLS certificates	Full ACME-based issuance and renewal, with DNS or HTTP validation automated end to end	CA/Browser Forum, Ballot SC-081v3; Sectigo endorsement (April 14, 2025)

Domain Control Validation (DCV) Reuse Changes

Domain Control Validation, or DCV, is how a certificate authority confirms you actually control the domain you are requesting a certificate for. Today, a CA can reuse that proof of ownership for up to 398 days before requiring fresh validation. Under Ballot SC-081v3, the DCV reuse window falls on the same three-phase schedule as certificate validity itself, not on a separate timeline: 200 days from March 15, 2026, 100 days from March 15, 2027, and 10 days from March 15, 2029. At a 47-day certificate lifespan with a 10-day DCV reuse window, a domain needs to be revalidated roughly 35 times a year. Manual, email-based, or one-off file-based DCV cannot realistically keep pace with that; DNS-01 or HTTP-01 validation through an ACME client is the practical path forward.

Subject Identity Information (OV/EV) Reuse Changes

Organizations using Organization Validation (OV) or Extended Validation (EV) certificates face a related but separate change. Subject Identity Information, the verified legal name, registration number, address, and other organizational details behind an OV or EV certificate, currently has a reuse window of 825 days. Under the ballot, that window drops to 398 days, but unlike certificate validity and DCV reuse, this is a single cutover rather than a phased reduction:

• Certificates issued before March 15, 2026: the prior 825-day SII reuse period still applies.
• Certificates issued on or after March 15, 2026: SII reuse is capped at 398 days.

In practice, OV and EV customers will need to redo organizational validation roughly once a year, on top of the shortened certificate renewal cycle itself. Both changes stack, so an OV certificate issued after March 15, 2026 is subject to both the new validity ceiling and the tighter identity reuse window.

Why This Matters for Enterprise Certificate Lifecycle Management

This ballot promises better security, but it also demands speed and automation that most certificate management programs were never built for. DigiCert’s July 2025 Trust Pulse Survey found that 45% of organizations experienced service downtime from certificate-related incidents in the past year, and 37.5% traced that downtime specifically to expired certificates, one of the most preventable causes of outages in enterprise environments. Nearly 60% of respondents already manage between 1,000 and 10,000 certificates, and more than half said they were not confident in their ability to track expiration dates even under today’s slower renewal cadence.

At a 47-day validity period, that same organization will need roughly eight renewals per certificate per year instead of one. A fleet of 1,000 certificates goes from about 1,000 renewals a year to close to 8,000. The financial exposure is not abstract either: DigiCert’s survey found 31% of organizations reported losses of $50,000 to $250,000 tied to certificate incidents, and 18.5% reported losses above $250,000.

• Renewal frequency multiplies: Certificates that renewed once a year will renew roughly eight times a year by 2029, with no realistic margin for a missed deadline.
• OV/EV revalidation becomes an annual task: Organizations must redo Subject Identity Information validation roughly every 398 days starting March 15, 2026, adding recurring administrative work on top of certificate renewal itself.
• DCV checks become nearly continuous: By 2029, domain ownership must be reconfirmed roughly every 10 days, which is unworkable without automated DNS or HTTP validation.
• Manual tracking breaks down: Spreadsheets and calendar reminders were already failing at annual renewal cadences per DigiCert’s survey; they cannot hold up at monthly or bi-monthly renewal frequency.
• Outage surface expands: Certificates secure more than websites; they underpin APIs, microservices, VPNs, and mobile apps. A missed renewal or failed DCV check on any of these can take a business-critical service offline.

Impact by Date and Role

Effective Date	Role Most Affected	Primary Impact	Immediate Action
March 15, 2026	PKI and Security teams	200-day validity ceiling; SII reuse cut to 398 days for OV/EV	Audit CA and CLM platform support for shorter issuance; inventory all OV/EV certificates
March 15, 2026 to 2027	Platform and DevOps teams	Renewal cadence moves from annual to roughly semiannual	Pilot ACME-based issuance on non-critical services
March 15, 2027	Platform and Compliance teams	100-day validity ceiling; manual renewal becomes operationally unsustainable	Move all public-facing certificates to automated issuance and renewal
March 15, 2029	All teams (PKI, Security, Platform, Compliance)	47-day validity ceiling; 10-day DCV reuse; roughly eight renewals per certificate per year	Full automation must already be in production; no manual fallback is realistic at this frequency

Readiness Checklist and Migration Roadmap

2029 sounds distant, but the 200-day ceiling has already been in force since March 2026, and the 100-day ceiling arrives in 2027. Organizations that start automating now will not be scrambling when the 47-day requirement lands. Here is the quick checklist, followed by the detail behind each step.

• Build a complete, centralized inventory of every public TLS certificate.
• Deploy ACME-based automation for issuance, renewal, and revocation.
• Automate DCV through DNS-01 or HTTP-01 challenges, not manual file placement or email.
• Run a pilot at 60 or 90-day renewal intervals before the mandate forces it.
• Train DevOps, security, IT infrastructure, and compliance teams together, not in silos.
• Audit vendor and cloud platform SLAs for automation and API support.

Build a Centralized Certificate Inventory

You cannot automate or secure what you cannot see. Most organizations have public TLS certificates scattered across websites, APIs, VPNs, load balancers, and internal services, and an expired certificate in any of those locations can cause an outage, break internal operations, or expose customer-facing systems.

Action plan:

• Use certificate discovery tooling (Qualys SSL Labs, Censys, or a CLM platform) to find every certificate across your PKI environment.
• Document certificate type (DV, OV, EV), issuing CA, expiration date, and a named owner for each one.
• Consolidate everything into a single inventory that PKI, security, and platform teams all reference.

Implement Certificate Lifecycle Automation

As validity shrinks from 200 to 100 to 47 days, manual renewal stops being a nuisance and becomes a liability. Teams cannot reliably track, renew, validate, and deploy certificates every few weeks by hand.

Action plan:

• For DV certificates, use ACME-based protocols to automatically issue, renew, and deploy without manual intervention.
• For enterprise TLS certificate fleets, invest in a certificate lifecycle management platform, such as CertSecure Manager.
• Make sure automation covers the full lifecycle: request generation, CSR creation and signing, deployment, and renewal or revocation.
• Integrate the CLM platform with your DevOps or cloud infrastructure tooling (Ansible, Terraform, Jenkins, or equivalent).

Rework DCV and Validation Workflows

Today, DCV can be reused for up to 398 days. By March 2029, that window drops to 10 days, meaning certificates issued after that point require near-continuous domain revalidation.

Action plan:

• Use ACME clients to automate DNS-based or HTTP-based DCV through TXT records or web server tokens.
• Pre-validate domains with your certificate authority where possible to reduce real-time overhead during renewal.
• Plan DCV rotation specifically for wildcard and multi-SAN certificates, which have more moving parts to revalidate.

Test Shorter Renewal Cycles Now

Waiting until the 47-day requirement is enforced is the wrong time to discover gaps in your process. Simulate the future environment now, under controlled conditions, and fix what breaks before it is mandatory.

Action plan:

• Set internal renewal intervals to 60 or 90 days, well ahead of what the current phase requires.
• Run these test cycles end to end, including issuance, validation, deployment, and alert handling.
• Track renewal success rate, downtime from failed deployments, and how long human intervention takes when automation fails. This surfaces bottlenecks before you are actually on a 47-day clock.

Train Cross-Functional Teams

Certificate lifecycle management touches more than the security team. If DevOps is not aware of the new cadence, IT is not aligned, or developers do not understand the limits of the automation in place, the result is internal friction and preventable outages.

Action plan:

• Run joint workshops with DevOps, security, IT infrastructure, and compliance teams so everyone understands the same timeline.
• Update internal SOPs and onboarding materials to reflect the new expiry cadence, DCV and OV/EV requirements, and emergency renewal steps.
• Assign named owners or service leads for every certificate group so accountability does not fall through the cracks.

Review Policies, Contracts, and SLAs

Not every vendor, load balancer, or SaaS platform is ready for short-cycle certificate management. Some lack the API integration or automation support this timeline requires.

Action plan:

• Audit third-party tools and cloud platforms for their level of certificate renewal and deployment automation.
• Update vendor SLAs to explicitly reflect the shortening certificate validity requirements.
• Negotiate for ACME integration or automation tooling as a standard part of your security requirements going forward.

The shift to 47-day TLS certificates and 398-day OV/EV validation is a new operating model, not a one-time policy update. Meeting it requires automation, cross-team coordination, and systems that are ready well before the deadline forces the issue.

Owner and Action Matrix: What Each Team Should Do Next

No single team owns this transition end to end. PKI, security, platform, and compliance functions each carry a distinct slice of the work, and the handoffs between them are usually where outages happen.

Team	Primary Responsibility	What to Do Next	Metric to Track
PKI team	Certificate authority relationships, issuance policy, and internal PKI hierarchy design	Confirm every CA in use supports sub-100-day and eventually sub-47-day issuance and ACME enrollment	Percentage of certificates issued through automated, ACME-based workflows
Security team	Risk ownership for certificate compromise, key exposure, and revocation policy	Set a hard internal renewal buffer (for example, renew at 75% of validity, not at expiry) and monitor for stale or orphaned certificates	Number of certificates renewed manually versus automatically, tracked monthly
Platform and DevOps	Deployment of certificates into load balancers, service meshes, APIs, and CI/CD pipelines	Integrate CLM or ACME tooling directly into deployment pipelines so renewal does not require a manual release	Mean time to deploy a renewed certificate across the fleet
Compliance	Audit evidence, SLA enforcement, and regulatory alignment (PCI DSS, HIPAA, DORA)	Update internal policy documents and vendor SLAs to reflect the new validity and revalidation cadence	Number of vendor contracts updated to reference the current CA/Browser Forum schedule

Once automation is in place, the metrics worth watching month over month are straightforward: renewal success rate, count of expired-in-production incidents, mean time to renew, and the share of certificates still requiring a human step. A rising failure rate on any of these is usually the earliest signal that an integration is breaking before it causes an outage.

Handling Multi-Cloud and Hybrid PKI Environments

Organizations running certificates across AWS, Azure, Google Cloud, and on-premises infrastructure face a compounding problem: each environment has its own native certificate tooling, none of which was built with a single, unified view of the other two in mind. A certificate issued through a cloud-native service in one provider is invisible to the discovery tooling running in another, which is exactly how shadow certificates accumulate.

For multi-cloud and hybrid PKI, three practices matter more than in a single-environment setup:

• Use a vendor-neutral CLM layer: A platform that sits above individual cloud-native certificate managers gives you one inventory and one renewal policy instead of three disconnected ones.
• Standardize on ACME across environments: Consistent DNS-01 or HTTP-01 validation logic, rather than provider-specific validation methods, keeps DCV automation working the same way regardless of where a certificate is issued.
• Centralize discovery, not just issuance: Automated issuance in each cloud does not solve the visibility gap between them. Certificate discovery needs to run across all environments, including on-premises PKI, to catch certificates issued outside the primary automation path.

This is also where the 47-day certificate mandate and post-quantum readiness planning overlap. A hybrid environment that lacks a consolidated cryptographic inventory cannot answer where it stands on either initiative, since both depend on knowing exactly what certificates and algorithms exist across every environment in use.

How Can Encryption Consulting Help?

CertSecure Manager is a vendor-neutral certificate lifecycle management platform that automates discovery, issuance, deployment, renewal, revocation, and CA migration from a single dashboard. It is built for exactly the operating model this ballot requires: continuous visibility across every public and private certificate, automated renewal through ACME, SCEP, and EST, and integration into the DevOps and cloud tooling your teams already run, so a 47-day renewal cycle does not mean a 47-day fire drill.

Certificate automation is only half the picture. Because shorter certificate lifespans and post-quantum migration are running on overlapping timelines, CBOM Secure gives you the underlying cryptographic inventory both initiatives depend on, discovering every certificate, algorithm, and key across your environment and turning that inventory into an actionable, continuously maintained record rather than a one-time spreadsheet. For teams building a broader crypto-agility and quantum-readiness program alongside this certificate transition, the PQC Center of Excellence provides hands-on guidance and a sandbox for testing quantum-safe algorithms before they become mandatory.

If you are still managing certificates manually, or you are not confident your current tooling can handle sub-100-day renewal cycles, now is the time to find out, not in 2027 when the next phase forces the question. Request a demo to see how CertSecure Manager handles automated certificate lifecycle management at scale.

Conclusion

The reduction of TLS certificate lifespans to 47 days is no longer theoretical. It is an approved, industry-backed policy that is already reshaping how digital trust is issued and maintained, and the first phase has been in force since March 2026.

What started with Apple’s unilateral move to 398-day certificates in 2020 has become a coordinated, multi-year industry standard, one that trades manual oversight for automation and treats short-lived credentials as the default rather than the exception. By March 2029, every public TLS certificate will expire in under two months, and by March 2026, OV and EV validation reuse had already been cut to 398 days. These are operational requirements, not suggestions. Organizations that do not adapt risk more than inconvenience: they risk outages, lost customer trust, and compliance failures that are entirely preventable with the right automation in place today.

Frequently Asked Questions

What is the main takeaway from Apple’s proposal to shorten TLS certificate lifespans?

The CA/Browser Forum approved Ballot SC-081v3 in April 2025, cutting maximum public TLS certificate validity from 398 days to 47 days in three phases: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Domain validation reuse falls on the same schedule, and OV/EV identity reuse drops from 825 to 398 days starting March 2026. Manual certificate management cannot keep pace, so automation is now required.

Why does this matter for enterprise certificate lifecycle management?

Renewal frequency jumps roughly eightfold by 2029, and DigiCert’s July 2025 Trust Pulse Survey found 45% of organizations already had certificate-related downtime in the past year, with 37.5% tracing it to expired certificates. At the new cadence, spreadsheets and manual tracking that already struggled at annual renewal will fail outright, turning a routine task into a recurring source of outages and compliance gaps.

What teams are responsible for acting on this guidance?

PKI teams own certificate authority relationships and issuance policy. Security teams own risk, renewal buffers, and revocation. Platform and DevOps teams own deploying renewed certificates into live infrastructure. Compliance teams own updating SLAs and audit evidence to reflect the new schedule. None of these can be treated as a single owner’s problem; the handoffs between them are where most certificate outages actually happen.

What risks increase if this is handled manually?

Manual renewal increases the risk of missed deadlines, expired production certificates, and failed domain revalidation, especially once DCV reuse drops to 10 days by 2029. Certificates secure more than websites, they underpin APIs, VPNs, and mobile apps, so a single missed manual renewal on a critical service can take that service offline with little warning.

How does automation reduce certificate outage risk?

ACME-based automation and a certificate lifecycle management platform remove the human step from issuance, renewal, deployment, and revocation, so certificates renew on schedule regardless of holidays, staff turnover, or competing priorities. Automation also gives teams a single, accurate inventory instead of certificates tracked across disconnected spreadsheets, which closes the visibility gap that causes most preventable expirations.

What metrics should teams track after implementation?

Track renewal success rate, the count of certificates still requiring a manual step, mean time to deploy a renewed certificate, and the number of expired-in-production incidents. A rising failure rate in any of these usually signals an integration problem worth fixing before it causes a customer-facing outage.

How does this connect to 47-day TLS certificate readiness?

The 200-day and 100-day phases are not separate from the eventual 47-day requirement, they are the same schedule arriving in stages. Organizations that build automated issuance, renewal, and DCV workflows now, ahead of the 2029 deadline, are simply implementing 47-day readiness early, while the operational pressure is still manageable.

How should this be handled in multi-cloud or hybrid PKI environments?

Multi-cloud and hybrid environments need a vendor-neutral certificate lifecycle management layer that provides one inventory and one renewal policy across every cloud and on-premises PKI, rather than relying on each provider’s native, siloed tooling. Standardizing on ACME for validation and centralizing discovery across all environments closes the visibility gaps where shadow certificates and missed renewals typically originate.