From Annual to Automatic: An Executive’s Step-by-Step Guide to 47-Day TLS Certificate Compliance

Key takeaways

• Meeting the CA/Browser Forum’s 47-day TLS certificate rule requires a live inventory of every certificate, centralized issuance under one policy, and automated renewal and deployment. With validity shrinking toward 47 days by 2029, automating now is what keeps renewals from turning into constant manual work.
• When certificates renew far more often, certificate management stops being a background task and becomes something leadership has to plan for and fund.
• Automating certificate management happens in four stages: inventory every certificate, centralize issuance under policy, open up self-service requests, then automate deployment and renewal.
• Most organizations already have pieces in place. What matters is knowing which of the four stages you have reached and closing the next gap, instead of rebuilding everything.
• The same setup that handles 47-day renewal is what a future post-quantum migration will need, so the work pays off more than once.
• Full automation takes more than the PKI team. Application, infrastructure, DevSecOps, and security all have to work from one agreed-upon process.

The headline you cannot ignore

The CA/Browser Forum has permanently ended annual TLS certificates. As a binding industry rule, phased in across three hard dates. If your organization issues public TLS certificates, and every organization does, this change is already in effect and will tighten twice more before 2029.

This is an infrastructure risk that belongs on the executive agenda.

Why executives should own this

Short certificate lifespans are a forcing function for security maturity. Every expired certificate is a potential outage. Every manual renewal at scale is a human error waiting to happen. And every organization that cannot rotate certificates reliably today will face the same gap magnified when post-quantum migration forces a full re-issuance of every certificate in the estate.

The leaders who treat this as a PKI upgrade miss the point. The ones who treat it as an automation and governance program get ahead of it.

The timeline: three dates that define your runway

The CA/Browser Forum SC-081v3 ballot, passed in April 2025, set the schedule. There is no opt-out for publicly trusted TLS certificates.

Date	Maximum Validity	Practical Impact
March 15, 2026	200 days	Already in effect. Annual renewal is no longer valid.
March 15, 2027	100 days	Roughly quarterly renewal, the point where manual processes break.
March 15, 2029	47 days	Renewal every 6-7 weeks. Near-continuous rotation.

Any certificate issued today has a 200-day maximum life. The question is whether your preparation keeps pace with what comes next.

The critical window is now through March 2027. Teams that automate during this stretch absorb the 2029 cut as a background process.

The hidden scale problem

Consider the math. A mid-sized enterprise with 5,000 TLS certificates that once required ~5,000 renewals per year will need:

• ~9,000 renewals/year at 200-day validity (today)
• ~18,000 renewals/year at 100-day validity (2027)
• ~39,000 renewals/year at 47-day validity (2029)

No team scales headcount to match that curve. Automation is the only path that does not end in outages.

What “automation” actually means: the four stages

Most organizations are not starting from zero. Most are somewhere in the middle, with partial visibility and pockets of automation. The practical move is to find your position and close gaps in order.

Stage 1: Build a live certificate inventory

What it is: A complete, continuously updated picture of every certificate in your environment: cloud, on-prem, Kubernetes, SaaS, partner-facing endpoints, and internal services.

Why it matters: You cannot automate what you cannot see. The certificates that cause outages are almost always the ones nobody was tracking. Discovery is not a one-time scan. New certificates appear constantly, especially as non-human identities proliferate across the environment.

What good looks like:

• Automated discovery across all environments, no manual input required
• Real-time inventory with expiry alerts, owner attribution, and issuing CA visibility
• Coverage of non-human identities: service accounts, containers, CI/CD pipelines, API clients

Executive signal: If your team cannot produce a complete certificate count in under an hour, you are at Stage 1. Start here.

Stage 2: Centralize issuance and policy

What it is: All certificate requests, regardless of team, environment, or CA, flow through a single platform that enforces policy, tracks ownership, and provides audit trails.

Why it matters: Scattered issuance means scattered accountability. When a certificate authority is distrusted (it happens, as with DigiCert 2023 and Let’s Encrypt OCSP changes), you need to know in minutes what is affected and replace it in hours, not weeks. That response speed is only possible with centralized control.

What good looks like:

• All approved CAs (public and private) are accessible through one platform
• Policy enforcement: key size, algorithm, validity period, SANs, domain ownership
• Revocation response capability, bulk replacement within hours, not days
• Full audit log for compliance reporting

Executive signal: If different teams use different CAs with no central oversight, a single CA distrust event becomes an organization-wide incident.

Stage 3: Enable self-service via ACME and APIs

What it is: Developers and infrastructure teams can request, receive, and renew certificates instantly through an API, a portal, or native integrations with tools like ServiceNow, Terraform, or Vault without waiting on the PKI team.

Why ACME matters here: The ACME protocol (RFC 8555) is the industry standard for automated certificate issuance and renewal. It is what Let’s Encrypt runs on, and it is what modern certificate management platforms expose to clients. Supporting ACME means any tool, any server, any container that speaks the protocol can renew its own certificate automatically, no ticket, no human approval required.

At 47-day validity, ACME is the mechanism that makes renewal invisible.

What good looks like:

• ACME endpoint exposed by your CLM platform for automated clients
• REST API for programmatic certificate requests from CI/CD and infrastructure-as-code
• Portal for application owners who need certificates without writing code
• ServiceNow / ITSM integration for teams operating within existing ticketing workflows
• Policy is still enforced centrally, so self-service does not mean ungoverned

Executive signal: If getting a certificate requires a manual ticket and a three-day wait, your developers will work around the process. Self-service eliminates the incentive to bypass governance.

Stage 4: Automate deployment and renewal

What it is: Certificates are automatically pushed to the systems that need them, renewed before expiry, and validated with no human in the loop.

Why it matters: Deployment automation is what converts 47-day validity from a crisis into background noise. Without it, the renewal cycle runs at human speed. With it, renewal frequency is irrelevant because the process simply runs on its own.

What good looks like:

• Native connectors to F5 BIG-IP, NGINX, Apache, IIS, Kubernetes, AWS ACM, Azure Key Vault, HashiCorp Vault
• ACME clients on servers and containers are handling their own renewal without orchestration overhead
• Automated validation post-deployment confirms the new certificate is live and trusted before the old one expires
• Alerting only on exceptions, with the system handling routine renewal and humans responding to failures

Executive signal: If your team is manually deploying renewed certificates to load balancers and web servers, that process will break under a 47-day rotation. Automate deployment before the 2027 cut.

The readiness roadmap: what to do by when

Stage	Action	Priority
Visibility	Discover certificates across cloud, Kubernetes, on-prem	Now
Visibility	Consolidate into a single live inventory	Now
Control	Route all issuance through a central CLM platform	Before March 2027
Control	Define and enforce policy for approved CAs, algorithms, owners	Before March 2027
Self-service	Enable ACME protocol for automated client renewal	Before March 2027
Self-service	Deploy API and portal access for developer self-service	Before March 2027
Self-service	Integrate request intake with existing ITSM tools	Before March 2027
Deployment	Automate deployment to all target systems	Before March 2029
Deployment	Enable end-to-end automated renewal with validation	Before March 2029

Three risks executives need to price in

1. Expired certificates are business failures

An expired certificate does not degrade gracefully. It breaks trust instantly. Every system relying on that certificate stops accepting it at once. The failure mode is a hard outage: customer-facing endpoints go dark, internal services lose connectivity, partner integrations fail. At high renewal volumes, the probability of a missed renewal under manual processes approaches certainty.

2. CA distrust events are increasing

The past three years have seen multiple public CAs face compliance failures, resulting in distrust announcements from browser vendors. Each event requires immediate mass replacement of affected certificates. Organizations with centralized inventory and automated deployment can respond in hours. Organizations without them spend days or weeks in manual triage, often discovering certificates mid-outage rather than proactively.

3. This is your post-quantum rehearsal

NIST finalized FIPS 203, 204, and 205 in 2024, the first post-quantum cryptography standards. Every certificate in your estate that relies on RSA or ECDSA will eventually be replaced with a quantum-resistant equivalent. That migration will require the same capabilities as 47-day compliance: complete inventory, centralized control, automated deployment, and the ability to replace certificates at scale on a deadline.

Teams that build crypto-agility for a 47-day rotation are building the exact infrastructure PQC migration will demand. The investment pays off twice.

The coordination challenge: this is not a PKI project

Reaching Stage 4 requires people who do not report to the PKI team:

• Application owners who must consume certificates via self-service rather than ad hoc requests
• Infrastructure teams who own the load balancers, web servers, and Kubernetes clusters where certificates land
• DevSecOps who need to embed certificate provisioning into CI/CD pipelines
• Security leadership must approve CA policy and sign off on automation scope

The certificate work is well understood. The coordination is where programs stall.

What executives should do:

• Name an accountable owner for each stage, not just a PKI lead, but the infrastructure and application owner counterparts
• Define the certificate request-to-deployment flow across team boundaries before automation work begins
• Set a March 2027 readiness milestone for Stages 1–3 as a program checkpoint, not a PKI team deliverable

The business case

Unplanned outages from expired certificates cost organizations an average of $5,600 per minute in downtime. At a 47-day rotation across thousands of certificates with manual processes, the expected number of missed renewals per year approaches several. The cost of a CLM platform is a fraction of a single P1 incident. The cost of not having one is measured in outages, compliance gaps, and a PQC migration that starts from scratch.

Where AppViewX fits

AppViewX brings the four stages together on a single platform built for the 47-day reality. Discovery surfaces every certificate across every environment. A live inventory stays current as new certificates appear. Issuance runs through central policy with ACME support for automated clients and REST APIs for developer self-service. Automated deployment covers the full stack across network, cloud, Kubernetes, and on-prem, with validation built in.

The result is a certificate program that scales with the timeline instead of straining against it. Teams replace, renew, and govern certificates at any frequency without the manual effort that creates risk.

Your next move

Take the 47-day readiness assessment. It maps your current position across the four stages, identifies your gaps against the 2027 and 2029 deadlines, and surfaces the fastest path forward.

The 200-day limit is already in force. The window to prepare for the next one is open now.

[Request your complimentary readiness assessment →]