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

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. In April 2025, 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.

What Is Changing in 2026

Effective date	Max certificate validity	Max DCV reuse
Until 14 Mar 2026	398 days	398 days
15 Mar 2026 (in effect)	200 days	200 days
15 Mar 2027	100 days	100 days
15 Mar 2029	47 days	10 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.

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 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 change to a quantum-safe future.

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.

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.