PKI in 2026: How to Survive the 47-Day TLS Certificate Era

The 47-day TLS certificate era is the CA/Browser Forum’s phased reduction of maximum public TLS certificate validity, approved as Ballot SC-081v3 on April 11, 2025, cutting the ceiling from 398 days to 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029, turning certificate renewal from an annual task into a continuous, automated one. For most of the last decade, a public TLS certificate was something you set up once and barely thought about for a year or more. That is changing fast. The CA/Browser Forum approved Ballot SC-081v3, a fixed schedule that cuts the maximum life of a public TLS certificate from 398 days down to 47 days by 2029. The first cut is already in effect: since 15 March 2026, no public Certificate Authority (CA) can issue a certificate that lasts longer than 200 days.

For security teams, PKI engineers, CISOs, cloud architects, and DevSecOps groups, this is not a small policy change. It turns certificate lifecycle management from a once-a-year task into a constant, automated one. In this blog we’ll look at what changed and why, where your certificates are actually hiding, how the automation works, and how all of it connects to the bigger move toward post-quantum cryptography.

Jump to: Executive Summary | Quick Checklist | Owner and Action Matrix | Policy Sources | What to Do Next

Executive Summary

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, is phasing maximum public TLS certificate validity down from 398 days to 200 days (effective March 15, 2026, already in force), 100 days (March 15, 2027), and 47 days (March 15, 2029), with Domain Control Validation reuse shrinking on the same schedule down to just 10 days. DigiCert’s Trust Pulse Survey found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage to an expired certificate, so the operational stakes are already real before the shortest windows even arrive. This guide lays out the exact dates, what changes at each one, who is impacted, a readiness checklist, an owner and action matrix for PKI, security, platform, and compliance teams, and a migration roadmap for closing the gap before manual certificate tracking becomes mathematically impossible.

Quick 47-Day Readiness Checklist

Use this checklist to gauge how close your organization is to 47-day TLS certificate readiness.

• Confirm you have a single, continuously updated certificate discovery inventory across on-prem, cloud, and hybrid environments.
• Confirm every certificate has a named, accountable owner on record.
• Confirm renewal, issuance, and revocation run through certificate automation rather than manual tracking.
• Confirm your ACME client is ARI-aware and checks for renewal windows more often than once a week.
• Confirm DNSSEC and CAA records are clean, since SC-085v2 can block automatic issuance if they are not.

Owner and Action Matrix by Team

Closing the 47-day readiness gap requires clear ownership across four teams. Here is how PKI, security, platform, and compliance teams should divide responsibility.

Team	Primary Responsibility	Key Action
PKI Team	Own certificate issuance policy and CA relationships	Pilot ACME automation now and confirm failover to a second CA before 2029
Security Team	Own key protection and cryptographic risk	Require HSM-backed key generation for every renewal and monitor Certificate Transparency logs for out-of-policy issuance
Platform and DevOps Team	Own automated renewal and deployment	Connect ARI-aware ACME clients to load balancers, Kubernetes, and CI/CD pipelines
Compliance Team	Own audit evidence for the certificate estate	Track automation coverage, inventory completeness, and policy compliance metrics for auditors

Policy Sources and Effective Dates

Every deadline in this guide traces back to a primary policy source, not a secondary summary. The CA/Browser Forum’s own ballot record is the authoritative source for the 47-day TLS certificates schedule: Ballot SC-081v3 was approved on April 11, 2025 and is published at cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods. A secondary industry summary of the same schedule is available from Sectigo at sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days. The related DNSSEC validation requirement is Ballot SC-085v2, which took effect on the same date as the 200-day cutover.

Update log: Originally published May 2026; most recently refreshed to add sourced downtime statistics, a fuller timeline table, an owner and action matrix, an FAQ block, and schema markup, and to confirm every date against the CA/Browser Forum’s primary ballot record rather than a secondary summary. This post is reviewed against the CA/Browser Forum’s public ballot log on a quarterly cadence, or immediately after any new CA/Browser Forum, browser root program, or Encryption Consulting product change affecting certificate validity.

What Is Changing in 2026

Effective Date	Requirement	Who Is Impacted	Action Needed	Source
Until 14 Mar 2026	Max validity and DCV reuse: 398 days	All public TLS certificate holders	Baseline; no action required beyond standard renewal	CA/Browser Forum Ballot SC-081v3
15 Mar 2026 (in effect)	Max validity and DCV reuse cut to 200 days	All public TLS certificate holders; OV/EV holders also see Subject Identity Information reuse cut from 825 to 398 days	Confirm renewal automation exists for every public-facing certificate; complete certificate discovery of the full estate	CA/Browser Forum Ballot SC-081v3
15 Mar 2027	Max validity and DCV reuse cut to 100 days	All public TLS certificate holders; teams still relying on manual issuance	Remove manual issuance from production; connect automation to load balancers, Kubernetes, and CI/CD	CA/Browser Forum Ballot SC-081v3
15 Mar 2029	Max validity cut to 47 days; DCV reuse cut to 10 days	All public TLS certificate holders	Run fully automated, repeatable renewals end to end; treat any manual renewal as an exception	CA/Browser Forum Ballot SC-081v3
15 Mar 2026 (in effect)	DNSSEC signature validation required during CAA and domain-validation lookups	Domains with DNSSEC deployed	Confirm DNSSEC and CAA records are clean before relying on automated issuance	CA/Browser Forum Ballot SC-085v2

Source citations for this timeline: CA/Browser Forum Ballot SC-081v3, approved April 11, 2025 (cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods); secondary summary via Sectigo (sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days).

A couple of points often get missed. First, this only applies to public CAs that browsers trust. Your own internal or private PKI is not bound by these rules, but it is still smart to follow the same path, because the manual habits that break public renewals will break internal ones too. Second, the figures in this schedule are ceilings, not typical issuance lengths. CAs issue slightly under each cap to keep a safety buffer. A certificate issued even one second over the limit is treated as mis-issued and must be revoked, so no CA cuts it close.

There is also a related change worth noting. A separate CA/B Forum ballot, SC-085v2, took effect on the same day. Where a domain has DNSSEC (Domain Name System Security Extensions) deployed, it requires CAs to validate those signatures during the CAA and domain-validation DNS lookups they run before issuance. So clean DNS and CAA records now matter more than ever. Before deciding how to react, it helps to understand why the industry chose this path, because the reason points to the right fix.

Why Certificates Are Getting Shorter

The goal is to reduce risk before it becomes a problem. A certificate is a snapshot of trust at the moment it is issued. The longer it stays valid, the greater the chance that what it records, such as who owns the domain or whether the key is still safe, no longer matches reality. Shorter lifetimes keep that information fresh and shrink the window in which a stale or wrongly issued certificate stays trusted.

There is a second reason. Revocation has never worked well at internet scale. Revocation lists are large, the status-check protocol (OCSP) adds delay and privacy concerns, and browsers often let a connection through when a status check times out. A short lifetime works like revocation that always succeeds, because a risky certificate simply expires within weeks. Shorter certificates also make it much easier to retire weak algorithms quickly, which matters a great deal for the move to post-quantum cryptography.

Those are real benefits, but they push the work onto whoever owns the certificate. To see why automation is now a must, it helps to turn the schedule into the actual workload your team will carry.

What This Means for Your Workload

The math is simple. A certificate that used to renew once a year at 398 days will now renew about every 47 days, which is roughly eight times a year. A small set of 100 public certificates jumps from about 100 renewals a year to around 800. That is roughly an eightfold increase, but the bigger problem is the vanishing room for error. On a yearly cycle, a missed renewal left days or weeks to fix things. At 47 days the cushion is only hours, and the 10-day DCV window means you have to re-prove domain control on almost every renewal.

Teams using OV or EV certificates carry an extra load: SC-081v3 also cuts the reuse window for Subject Identity Information (SII), the organisational identity data behind those certificates, from 825 days to 398 days, forcing more frequent re-validation of business credentials.

The cost of getting this wrong is well documented. In a 2023 study, 77% of organizations said they had at least two major outages from expired certificates in the previous two years, and more than half said those outages hit customer-facing services. More recently, DigiCert’s Trust Pulse Survey, published July 2, 2025, found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage specifically to an expired certificate. Source: digicert.com/news/digicert-survey-finds-manual-processes-expose-organizations.

These are not rare events. In February 2020, Microsoft Teams went down worldwide after an expired certificate. The fallout is not always so visible, either. During the 2017 Equifax breach, an expired certificate left a security device unable to spot attackers for a long stretch. At a yearly pace these slips were rare enough to survive. At 47 days, one missed manual renewal becomes a much more frequent and very public risk.

Before you can automate renewals, though, you have to know what you are renewing. The hardest part of getting ready is usually not the renewal itself. It is finding every certificate that needs one.

Where Your Certificates Are Hiding

Most companies have far more certificates than they think, and that gap is not harmless. You cannot renew what you cannot see, and an unknown certificate on a 47-day clock is an outage waiting to happen. Certificates pile up well beyond the obvious web servers:

• Load balancers (F5 BIG-IP, NetScaler, HAProxy), where a renewed certificate also has to be re-attached to the right virtual server or profile.
• Kubernetes and service meshes, where ingress controllers, and service-to-service mTLS issue and rotate certificates all the time.
• CI/CD pipelines and secrets stores (Azure Key Vault, AWS Secrets Manager), where keys and certificates get pulled into builds and apps.
• Cloud-native and short-lived workloads such as containers and serverless functions, whose addresses come and go faster than any spreadsheet can track.
• Devices and IoT, internal mTLS APIs, email (S/MIME), and code-signing systems, each with its own setup and owner.

A real inventory needs more than a one-time scan. Good CLM platforms combine several discovery methods: agentless network scanning, agent-based scanning on hosts, direct connections into your CAs and cloud providers, and Certificate Transparency (CT) log monitoring. NIST’s guidance on TLS certificate management treats this kind of always-current inventory, with a clear owner for every certificate, as the first step of any managed program.

Once you can see the whole picture of your organization, the next question is how to manage it at scale. That comes down to three capabilities that depend on each other.

The Three Pillars of Readiness

Getting ready is less about one tool and more about three capabilities that work together. Weaken one and the other two cannot make up for it.

1. Discovery and Inventory

Continuous discovery feeds one central, clean list where every certificate has a known location, expiry date, key type, issuing CA, and owner. This is the single source of truth that everything else depends on. Without it, automation only renews the certificates you already know about while the unknown ones fail quietly.

2. Governance and Ownership

A good inventory is useless if no one owns each certificate. This is where many teams have a real gap. A 2024 Gartner survey of 335 IAM leaders found that identity teams are responsible for only 44% of an organization’s machine identities. The rest sit with app teams, DevOps, or no one. Governance fixes this by setting clear rules for issuance (approved key types and algorithms, which CA to use, maximum validity, and naming), enforcing those rules in the request process, giving every certificate an owner, and using role-based access and multi-person (M of N) approvals for sensitive certificates.

3. Automation

Automation is what makes the new pace survivable. The ACME protocol lets software request, validate, and renew certificates, while the ACME client handles deploying them to the target system. Self-service lets developers get approved certificates on demand without opening tickets. But at 47 days, basic automation is necessary, not enough, and how it is built matters a lot.

That build detail is where many programs quietly fail, so it is worth a closer look at the tools that keep automation reliable at this pace.

What a 47-Day-Ready Setup Looks Like

A strong setup links the three pillars into one continuous loop. Discovery keeps the central inventory current. A policy check reviews every request against your rules before issuance. An ACME (or SCEP and EST) client creates a fresh key pair, ideally with the private key generated inside or protected by an HSM or cloud key store and never copied in plain text, and the CA issues after automatic validation. The new certificate and key then deployed in a repeatable way to wherever they belong, whether that is a load balancer profile, an ingress controller, a service-mesh sidecar, or a secrets store, and the old material is rotated out cleanly.

Around that core, two loops run all the time. ACME Renewal Information (ARI, RFC 9773) lets ACME clients retrieve the CA’s suggested renewal window and renew early within it. Meanwhile, CT-log monitoring raises alerts for certificates issued outside organizational policy. Dashboards and ITSM integrations (for example, ServiceNow) give certificate owners visibility and a complete audit trail. A good rule of thumb is to start the renewal at about one-third of the certificate’s life, or whenever ARI suggests, so there is room for two full tries before it expires. That single habit prevents most same-day failures.

Knowing what the setup looks like is one thing. Knowing when to do each part is another, and because the change happens in stages, the smart move is to line up the work with the deadlines.

A Simple Plan for 2026 to 2029

Each phase removes another layer of manual errors, so what you focus on changes with each milestone. Treat the dates as deadlines to build capability, not just boxes to tick.

Phase	Max validity	What to focus on
Now to March 2027	200 days	Finish discovery and build the master inventory, assign owners, pilot ACME automation on a busy domain, and check DNSSEC and CAA records.
March 2027	100 days	Remove manual issuance from production, roll out ARI-aware clients, connect the platform to load balancers, Kubernetes, and CI/CD, and enforce policy in the pipeline.
March 2029	47 days	Run fully automated, repeatable renewals end to end, confirm failover to a second CA, test urgent early renewal through ARI, and treat any manual renewal as an exception.

A plan only means something if you can show progress against it, and that is where a few simple numbers turn good intentions into proof.

How to Measure Your Progress

These numbers give PKI leads a clear view of where they stand and what to fix next:

• Automation coverage: the share of certificates renewed with no human help. This is the most important number, and it should be near total before 2029.
• Inventory completeness: known certificates versus the ones found by discovery and CT-log monitoring. The gap is your unmanaged risk.
• Time to renew or replace: how fast you can reissue and deploy a certificate, which sets your worst-case outage and your speed to react to a forced revocation.
• Outages and near-misses from expiry: the goal is zero, and near-misses are an early warning.
• Policy compliance: the share of certificates that follow your approved key types, algorithms, and validity, plus the count issued outside policy.

These same numbers do double duty because they are exactly the evidence auditors ask for, which ties certificate operations straight to your compliance work.

How This Maps to Compliance

A 47-day program is easier to explain and fund when you tie it to the standards your organization already follows. The links are direct:

Standard	Why it matters for 47-day certificates
NIST SP 1800-16	Enterprise guide for TLS certificate management: inventory, ownership, automation, and fast replacement.
NIST FIPS 203/204/205	Post-quantum standards that the same automation and crypto-agility will help you deploy.
PCI DSS v4.0.1	Requires the use of strong cryptography and sound cryptographic key management.
IETF RFC 8555 and RFC 9773	The automation and renewal-timing standards behind the whole pipeline.

Even with standards and metrics in place, the same handful of mistakes trip up most teams. Knowing them ahead of time is the cheapest insurance you can get.

Common Mistakes to Avoid

• Renewing too late. Aiming for the last few days leaves no room for a failed check or deployment. Renew early, at about one-third of the certificate’s life.
• Treating private keys as portable. Create a new key for each renewal and protect it with an HSM or key store. Reusing one key across many renewals makes any leak far more damaging, while frequent rotation limits it.
• Relying on a single CA. Supporting more than one CA protects you from a CA outage or a forced mass revocation.
• Ignoring non-web certificates. Internal services, mTLS, devices, and code signing feel the same pressure, even where the public rules do not apply.
• Using ARI-aware clients that only run weekly. How often the client runs is the real requirement, not a checkbox.
• Forgetting DNSSEC and CAA hygiene, now that DNSSEC checks are required and can block automatic issuance.

Avoiding these mistakes does more than prevent outages. It builds the exact skill the next big cryptographic change will need.

Getting Ready for Post-Quantum, Too

Shorter lifetimes are good practice for a bigger change ahead. In August 2024, NIST released its first post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), and is urging organizations to start moving now.

Moving a whole PKI to quantum-safe algorithms means swapping algorithms across thousands of certificates on a deadline, which is exactly what 47-day certificate automation forces you to build today. A team that can rotate every certificate every six weeks, with a full inventory and clear rules, is a team that can run a post-quantum migration. Crypto agility, the ability to change algorithms quickly and safely, backed by a cryptographic bill of materials (CBOM) that records where every algorithm and key lives, is the thread that connects the 47-day TLS certificates change to a quantum-safe future. Our CBOM: from inventory to intelligence post explains how that inventory becomes an actionable remediation plan.

To assess exactly where your organization stands, our PQC Center of Excellence centralizes research, tooling, and guidance for the migration ahead, and our PQC readiness assessment maps your certificate and cryptographic estate against that transition, so crypto agility is built in before the 47-day schedule and post-quantum deadlines converge.

Building all of this, from discovery to governance to automation to key protection to a crypto-agility plan, is a big job, and it is where our certificate lifecycle manager helps most.

How Encryption Consulting Can Help

CertSecure Manager by Encryption Consulting LLC is built to tackle the challenges of shifting to shorter certificate lifespans, like 47 days. With these changes, automation becomes essential for efficiently managing the new certificate environment.

1. Implement a CLM Solution

A CLM solution is key to efficiently handling internal and external certificates, ensuring cryptographic compliance, and streamlining certificate inventory and reporting. CertSecure Manager, for example, provides a comprehensive solution that automates the entire certificate lifecycle from discovery to deployment, renewal, and revocation, minimizing the manual effort involved in managing certificates.

It also automates compliance checks to ensure all certificates meet industry standards like PCI-DSS, GDPR, and ISO. Comprehensive reports are generated for audits, simplifying compliance processes.

2. Automated Certificate Discovery and Inventory

CertSecure Manager automatically discovers all certificates across your infrastructure, whether on-premises, in the cloud, or in hybrid environments. It provides a complete certificate inventory, ensuring no certificate is left unmanaged, including self-signed certificates that may pose a security risk. With this centralized inventory, you can quickly identify certificates due for renewal, significantly reducing the risk of expired certificates causing issues.

3. Advanced ACME Protocol Integration

By leveraging the ACME protocol, CertSecure Manager automates the issuance and renewal of certificates in a secure, standardized manner. This eliminates manual intervention, ensuring certificates are always renewed on time, even with the frequent renewal cycles required by shorter validity periods like 47 days.

4. Automated Renewal, Re-Issuance, and Revocation

CertSecure Manager automates certificate renewal and reissuance, ensuring certificates are always up to date. It also revokes compromised or unnecessary certificates, reducing security risks and ensuring compliance.

This automation ensures uninterrupted operations within an organization and enhances security by quickly addressing compromised or unnecessary certificates. It makes meeting compliance requirements easier by managing certificates on time, keeping clear records, and improving security, while reducing workload and building trust.

5. Compliance and Reporting

CertSecure Manager automates compliance checks, ensuring your certificates meet industry standards like NIST, HIPAA, and GDPR. It generates comprehensive reports for audit purposes, making it easier to comply with regulatory requirements. These reports also help you assess your certificate infrastructure and identify potential weaknesses before they become problematic.

6. Seamless Integrations and Renewal Agents for Enhanced Certificate Management

CertSecure Manager integrates with various tools and platforms, including Terraform, Ansible, Azure Key Vault, and Splunk, to ensure streamlined certificate management. It automates certificate provisioning, renewal, and deployment within CI/CD pipelines across databases, web servers (Apache, IIS, NGINX), and more. Renewal agents are customized for these services, ensuring that certificates are consistently updated and secure.

As the industry is now shifting to 47-day certificate validity periods, CertSecure Manager’s integrations and automated processes help maintain security, compliance, and uptime by handling renewals and managing certificates across diverse environments with minimal manual effort.

What to Do Next

Reaching 47-day TLS certificate readiness is a cross-team effort. Here is where each team should start.

• PKI Team: Confirm certificate discovery covers cloud, on-prem, and hybrid environments equally, and pilot ACME automation on a high-volume domain now, ahead of the March 2027 cutover.
• Security Team: Require HSM-backed key generation on every renewal, monitor Certificate Transparency logs for out-of-policy issuance, and confirm failover to a second CA is tested.
• Platform and DevOps Team: Move certificate automation onto ARI-aware ACME clients and connect them to load balancers, Kubernetes ingress, and CI/CD pipelines before manual issuance becomes unsustainable at 100-day and 47-day validity.
• Compliance Team: Track automation coverage, inventory completeness, and policy compliance metrics now so audit evidence is already in place when the 47-day deadline arrives in March 2029.

Conclusion

The shift to 47-day certificates is set, it is happening in stages, and it is already underway. The 200-day phase is live, 100 days arrives in March 2027, and the 47-day limit lands in 2029, along with a 10-day DCV window that makes manual work impossible to sustain.

The teams that handle this well will treat it as a design problem, not a renewal problem: see every certificate, give each one an owner, set clear rules, automate with ARI in mind, protect your keys, follow the schedule, and track your progress with real numbers. Build that base now, and the same setup will carry you into the post-quantum era. If you are mapping out a 47-day-ready, crypto-agile PKI, the best time to start is before the next phase arrives.

What Is the Main Takeaway from PKI in 2026: How to Survive the 47-Day TLS Certificate Era? Public TLS certificate validity is on a fixed, already-active countdown set by CA/Browser Forum Ballot SC-081v3: 200 days now, 100 days by March 2027, and 47 days by March 2029. Surviving it requires treating certificates as a continuous, automated discipline rather than an annual renewal task, built on complete certificate discovery, clear ownership, and certificate automation.

Why Does This Matter for Enterprise Certificate Lifecycle Management? As renewal frequency rises roughly eightfold between the 398-day baseline and the 47-day floor, every gap in visibility or ownership turns into a proportionally more frequent risk of an outage, a failed audit, or a missed Domain Control Validation window. DigiCert’s Trust Pulse Survey found that 45% of organizations already experienced certificate-related downtime in the past year, before the shortest windows even take effect.

What Teams Are Responsible for Acting on This Guidance? Four teams share ownership: the PKI team, which owns issuance policy and CA relationships; the security team, which owns key protection and cryptographic risk; the platform and DevOps team, which owns automated renewal and deployment; and the compliance team, which owns audit evidence for the certificate estate. The owner and action matrix in this post details each team’s specific responsibilities.

What Risks Increase If This Topic Is Handled Manually? Manual certificate handling raises the odds of missed renewals causing outages, since the room for error shrinks from days or weeks at an annual cadence to hours at 47 days, and the 10-day Domain Control Validation reuse window means domain control must be re-proven on almost every renewal. It also increases the odds of reused private keys, single-CA dependency, and DNSSEC or CAA misconfiguration blocking automatic issuance entirely.

How Does Automation Reduce Certificate Outage Risk? Certificate automation removes the missed deadlines and manual errors that cause the overwhelming majority of certificate outages by handling issuance, renewal, and revocation on a policy-driven schedule, using ACME Renewal Information (ARI) to renew early within the CA’s suggested window. It is also the only practical way to keep pace with the roughly eightfold increase in renewal volume the 47-day schedule creates.

What Metrics Should Teams Track After Implementation? Track automation coverage (the share of certificates renewed with no human help, which should be near total before 2029), inventory completeness (known certificates versus those found by discovery and Certificate Transparency log monitoring), time to renew or replace, outages and near-misses from expiry, and policy compliance across key types, algorithms, and validity periods.

How Does This Connect to 47-Day TLS Certificate Readiness? This entire guide is the 47-day TLS certificate readiness roadmap: the CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, sets the fixed schedule, and readiness means having certificate discovery, governance, and certificate automation fully in place before the 47-day, 10-day-DCV floor lands in March 2029, rather than scrambling once the deadline is on top of you.

How Should This Be Handled in Multi-Cloud or Hybrid PKI Environments? Multi-cloud and hybrid environments need a single, continuously updated certificate inventory spanning every cloud provider, on-prem system, and hybrid connection point, since fragmented visibility is exactly how certificates get missed on a 47-day clock. Centralized discovery, policy enforcement, and ARI-aware automation across all environments, rather than per-cloud point solutions, keeps renewal timing and ownership consistent regardless of where a certificate lives.