PKIaaS for Shorter Certificate Lifetimes: Preparing for 47-Day TLS Certificates

On March 15, 2029, the maximum validity period for publicly trusted TLS certificates drops to 47 days. This is not a proposal or a discussion draft. CA/B Forum Ballot SC-081v3 was approved in April 2025. Every publicly trusted certificate authority is already operating on this schedule. The 200-day limit took effect March 15, 2026. The 100-day limit takes effect March 15, 2027. The 47-day limit arrives on March 15, 2029.

For organizations that still renew TLS certificates manually, the 47-day limit is not a compliance requirement to prepare for — it is an operational crisis to prevent. At 47-day validity, renewing a certificate every 31 days (the two-thirds renewal window) means an organization with 1,000 internet-facing TLS certificates faces roughly 33 manual renewal operations per day, every day of the year. Miss one, and the certificate expires. An expired certificate on a public-facing service produces a browser warning that most users treat as a hard stop. Miss several, and the operations team is dealing with outages, incident tickets, and escalations while also trying to catch up on the backlog of overdue renewals.

The only viable operational model for 47-day certificates is full automation: PKI as a Service providing the ACME issuance endpoint, automation clients handling renewal without human interaction, CLM monitoring catching any renewal failure before the certificate expires, and escalation workflows that page the right team when automation breaks down. This post covers how to build that stack.

Quick Answer: What Does the 47-Day Schedule Require?

The 47-day schedule requires three things that together constitute a certificate automation program: an ACME-capable PKIaaS endpoint that can issue renewed certificates without human interaction; automation clients (cert-manager, certbot, acme.sh, or equivalent) deployed on every system that holds a publicly trusted TLS certificate; and a CLM layer that monitors renewal success, catches failures before expiry, and escalates to the right team when automation cannot resolve the failure automatically. Organizations that have all three in place before March 15, 2029 will handle the 47-day schedule as a routine operational matter. Organizations that do not will face the outages that come from certificates expiring faster than manual processes can keep up with.

Key Takeaways

• CA/B Forum SC-081v3, approved April 2025, establishes: 200 days from March 15, 2026; 100 days from March 15, 2027; 47 days from March 15, 2029. These are hard limits for publicly trusted TLS certificates. The schedule is already in effect at the 200-day step. Organizations that have not begun their automation program are already one step behind.
• At 47-day validity with a 14-day renewal window, each certificate renews approximately every 33 days, roughly 11 times per year per certificate. An estate of 1,000 publicly trusted TLS certificates generates approximately 11,000 renewal operations per year. Manual processes cannot sustain this volume reliably; a single missed renewal causes a production outage.
• PKIaaS ACME endpoint support is the issuance backbone. The ACME protocol (RFC 8555) is the standard for automated certificate issuance and renewal. PKIaaS deployments that expose an ACME endpoint with External Account Binding allow any ACME-compatible client to request and renew certificates automatically. The PKIaaS CA issues the certificate; the automation client handles the renewal trigger, domain validation, and certificate delivery.
• The renewal window design is the most critical operational decision in a 47-day automation program. A 14-day renewal window means the automation system has two weeks to detect and resolve any renewal failure before the certificate expires. A 7-day window leaves one week. A 3-day window leaves almost no time for human intervention when automation fails. The renewal window must be sized to the failure recovery time the operations team can actually achieve, not to the shortest technically possible window.
• CLM monitoring is what separates an automation program from an automation assumption. Automation clients can fail: ACME endpoint unreachability, DNS challenge propagation delays, misconfigured challenge solvers, revoked EAB credentials. A CLM platform connected to the PKIaaS CA detects these failures by monitoring certificate expiry dates against the expected renewal schedule, and alerts the operations team before the failure becomes an outage.

The Operational Math of 47-Day Certificates

The operational impact of the 47-day schedule is easier to understand as arithmetic than as policy language. At current 1-year certificate validity, a certificate renews once per year. At 90-day validity (the Let’s Encrypt model most DevOps teams are familiar with), a certificate renews roughly 4 times per year. At 47-day validity, the renewal frequency changes significantly:

Validity period	Renewal window (2/3 point)	Renewals per certificate per year	Renewals per year for 1,000 certs	Manual renewals per day (365 days)
365 days (current)	~243 days	~1.5	~1,500	~4
200 days (from March 2026)	~133 days	~2.7	~2,700	~7
100 days (from March 2027)	~67 days	~5.5	~5,500	~15
47 days (from March 2029)	~31 days	~11.8	~11,800	~32

An organization with 1,000 publicly trusted TLS certificates that is still handling renewals manually will face 32 renewal operations per day by 2029. The DigiCert Trust Pulse Survey (July 2, 2025) found that 45% of enterprises had experienced certificate-related downtime and 37.5% traced it to an expired certificate. Those outages occurred when certificate validity was measured in years. At 47-day validity, the probability of a missed manual renewal causing an outage does not just increase; it becomes near-certain across any estate of meaningful size within a few months of operating at 47-day scale.

The 47-Day Certificate Lifecycle

The following diagram shows the complete lifecycle of a 47-day publicly trusted TLS certificate, from initial issuance through automated renewal and escalation handling.

The diagram illustrates the two paths through a 47-day certificate lifecycle. The green path is successful automation: PKIaaS issues the certificate on Day 0, CLM begins monitoring, the automated ACME client renews the certificate when 14 days remain (around Day 33), and the new certificate is deployed before the old one expires. The orange and red paths are the failure scenarios: automated renewal fails, CLM escalates to the operations team with 7 days remaining (Day 40), and if the team cannot manually resolve the renewal failure in time, the certificate expires on Day 47 and the service goes down.

Building the ACME Automation Layer

ACME (Automated Certificate Management Environment, RFC 8555) is the protocol that makes automated certificate renewal technically feasible at 47-day scale. An ACME client runs on or near the system holding the certificate, monitors the certificate’s validity, initiates renewal when the renewal threshold is reached, completes the domain ownership validation challenge, retrieves the signed certificate from the PKIaaS ACME endpoint, and deploys it to the service. The entire flow requires no human interaction when all components are correctly configured.

The PKIaaS ACME endpoint is the issuance backend for all ACME-based renewal. The platform team configures an ACME account with External Account Binding (EAB) credentials issued by the PKIaaS CA, which authenticates the ACME client to the PKIaaS CA and associates certificate requests with the correct certificate profile. The ACME client presents the EAB credentials on each renewal request; the PKIaaS CA validates the credentials and issues the certificate under the configured profile without requiring further authentication steps.

For different deployment contexts, different ACME clients handle the automation:

• Kubernetes workloads: cert-manager is the standard Kubernetes ACME client. The platform team configures a cert-manager ClusterIssuer pointed at the PKIaaS ACME endpoint with EAB credentials. For 47-day certificates, the Certificate resource’s renewBefore field should be set to 14d (renewal triggered 14 days before expiry). cert-manager monitors all Certificate resources and initiates renewal when the threshold is reached, handling DNS-01 or HTTP-01 challenge completion and certificate delivery to the Kubernetes Secret automatically;
• Linux servers and VMs: certbot or acme.sh pointed at the PKIaaS ACME endpoint. Both tools support cron-based or systemd-timer-based renewal scheduling. For 47-day certificates, a daily cron job that runs certbot renew checks all managed certificates and renews those within the renewal window. The renewal hook (a script that reloads the web server or application after the certificate is deployed) handles service update without downtime;
• Web servers with native ACME support: Caddy Server has native ACME client functionality and can be configured to use the PKIaaS ACME endpoint directly, handling all certificate lifecycle operations as part of its normal operation. No separate ACME client process is required;
• Load balancers and API gateways: For infrastructure components that manage TLS termination (AWS ALB, Azure Application Gateway, F5, Nginx Plus, HAProxy), the ACME client typically runs as a sidecar process or as part of a certificate management agent that pushes renewed certificates to the load balancer’s certificate store through its management API.

Renewal Window Design: The Critical Operational Decision

The renewal window is the period before a certificate’s expiry during which automated renewal is triggered. For 47-day certificates, the renewal window design is the single most important operational decision in the automation program because it determines how much time the operations team has to resolve renewal failures before they become outages.

The renewal window calculation must account for two failure types:

• Transient failures are temporary conditions that resolve without human intervention: a brief PKIaaS ACME endpoint unavailability, a DNS challenge propagation delay, or a temporary network connectivity issue. These failures are typically resolved within hours to a day. A renewal window of 14 days gives the automation system 14 days of retry attempts before the window closes; most transient failures resolve within the first few retries;
• Persistent failures require human intervention: a misconfigured challenge solver, revoked EAB credentials, a certificate profile configuration change that the automation client is not aware of, or a system-level issue on the host running the ACME client. The renewal window must be long enough that the CLM platform can detect a persistent failure, alert the operations team, and allow the team time to diagnose and resolve the issue before the certificate expires.

For 47-day certificates with a typical operations team response time of 24 to 72 hours during business hours, the recommended renewal window is 14 days. This provides:

• Day 33 (14 days before expiry): Automated renewal first attempted. CLM records the renewal attempt;
• Day 33 to Day 40: Automatic retry if first attempt fails. CLM monitors renewal success;
• Day 40 (7 days before expiry): CLM escalation alert fires if renewal has not succeeded. Operations team is paged. Manual intervention window: 7 days;
• Day 44 (3 days before expiry): Critical alert fires if renewal still has not succeeded. Emergency escalation to senior on-call;
• Day 47: Certificate expires. Service outage if renewal has not been completed.

A 7-day renewal window (triggering renewal at Day 40 instead of Day 33) leaves only 7 days for failure detection, escalation, and resolution. For an operations team that works business hours with a 24-hour pager response time, a failure detected on a Friday afternoon leaves roughly 5 business-hours before the Monday morning deadline. That is not a comfortable recovery window for a production TLS certificate outage.

CLM Monitoring: What Automation Without Monitoring Gets Wrong

Automation without monitoring is an assumption that automation is working. For 47-day certificates, that assumption is not safe: automation can silently fail in ways that are not visible until the certificate expires. The ACME client stops running because its container was restarted without the ACME client sidecar being restarted. The EAB credential used for the PKIaaS ACME endpoint was rotated by the security team but the new credential was not updated in the ACME client configuration. The DNS challenge solver’s service account lost its DNS record management permission after an IAM policy update. None of these failures produce an immediate error visible to the operations team; they produce a certificate that stops being renewed until someone notices the certificate is approaching expiry.

CLM monitoring provides the visibility layer that catches these silent failures. Connected to the PKIaaS CA, the CLM platform knows when each certificate was issued, what its validity period is, and when it is expected to expire. Connected to the certificate’s deployed locations (via network scanning or agent-based discovery), the CLM platform knows whether the deployed certificate matches the most recently issued certificate. If the certificate on the live service has not changed after a renewal should have occurred, the CLM platform knows the renewal failed even if the ACME client produced no error log.

For 47-day certificates, the CLM monitoring configuration should include:

• Renewal success confirmation: After an expected renewal window (when the certificate should have been renewed based on the 14-day threshold), the CLM checks whether the certificate on the live service has been updated. If the same certificate is still deployed past the expected renewal date, the CLM flags the renewal as failed and initiates the escalation path;
• Expiry alert tiers: Configurable alert thresholds at 14 days, 7 days, 3 days, and 1 day before expiry. Each tier routes to a different notification channel (SIEM for 14 days, email/Slack for 7 days, PagerDuty/on-call for 3 days, critical escalation for 1 day);
• Inventory completeness check: The CLM should continuously compare the certificate inventory to known service endpoints. A TLS endpoint that exists in the service registry but is not in the CLM certificate inventory is a gap: the service is running a certificate that is not being monitored. At 47-day validity, an unmonitored certificate is an outage waiting to happen;
• Issuance rate monitoring: The PKIaaS ACME endpoint’s issuance logs should be monitored for unexpected gaps. If the expected renewal rate for a given ACME account drops to zero for 48 hours, that is a signal that the ACME client is not submitting renewal requests as expected.

Governance Controls for High-Frequency Issuance

At 47-day scale, the PKIaaS ACME endpoint issues certificates for each managed domain roughly 11 times per year instead of once. This increase in issuance frequency has governance implications that organizations often overlook when planning for the 47-day schedule:

• Audit log volume increases proportionally: Every ACME renewal generates an audit log entry in the PKIaaS CA. An organization that previously saw 1,000 issuance events per year in their PKI audit log will see 11,000 events per year from the same certificate estate at 47-day validity. The CLM’s audit log ingestion, storage, and retention configuration must be sized for this increased volume. SIEM integrations that receive PKI issuance events must also be evaluated for the increased event rate to confirm they do not drop events under load;
• Certificate profile policy applies to every renewal, not just initial issuance: Each ACME renewal is a new certificate request that goes through the PKIaaS CA’s profile validation. If the certificate profile is updated (for example, to enforce a stronger key algorithm or a shorter validity period) during the certificate’s operational lifetime, the next renewal under the new profile may produce a certificate that differs from the previous one in ways the application must accept. Applications that pin certificates or pin public keys by value (rather than verifying against the CA trust chain) will break when the pinned value changes at renewal. At 47-day validity, this happens 11 times per year; certificate or public key pinning is incompatible with high-frequency renewal;
• SAN allowlist changes require immediate rollout coordination: If the PKIaaS CA’s SAN allowlist for a certificate profile is updated (to add or remove permitted domain names), the change affects all subsequent renewals for certificates that reference that profile. At annual renewal, a SAN allowlist change can be coordinated with the certificate renewal event. At 47-day renewal, the next renewal may be only days away, leaving very little time for coordination between the allowlist change and the renewal. Platform teams should establish a coordination window for SAN allowlist changes that accounts for the upcoming renewal schedule of all certificates using the affected profile.

Preparing Now: The Steps Before March 2027

The 47-day limit does not take effect until March 15, 2029, but the 100-day limit takes effect March 15, 2027. Organizations that build their automation stack for 100-day certificates before March 2027 are building the foundation that 47-day certificates will run on. The operational difference between 100-day and 47-day automation is the renewal window sizing and the monitoring sensitivity, not the fundamental architecture. An ACME automation stack that reliably handles 100-day renewals with CLM monitoring and escalation workflows will handle 47-day renewals with configuration adjustments rather than architectural changes.

The preparation steps in priority order:

• Step 1: Inventory every publicly trusted TLS certificate in the estate. Run CLM network discovery to find all TLS endpoints. Confirm which certificates are publicly trusted (issued by a CA in browser trust stores) versus privately trusted. Only publicly trusted certificates are subject to the SC-081v3 schedule, but any certificate without automated renewal is a future outage risk regardless;
• Step 2: Confirm PKIaaS ACME endpoint availability and EAB configuration. Every certificate that must comply with the 47-day schedule needs an ACME client connected to a PKIaaS ACME endpoint (or a publicly trusted CA’s ACME endpoint). Confirm EAB credentials are provisioned, stored securely, and accessible to the ACME clients that will use them;
• Step 3: Deploy ACME clients for every certificate without one. Map each certificate to its renewal mechanism: cert-manager for Kubernetes, certbot/acme.sh for Linux, native ACME for Caddy, management agent for load balancers. Every certificate that lacks an ACME client is a gap that requires either deployment of an ACME client or migration of the certificate to a service that already has one;
• Step 4: Configure CLM monitoring with 14-day, 7-day, and 3-day alert tiers. Connect the CLM platform to the PKIaaS CA for issuance event feeds and to the certificate discovery layer for deployed certificate status. Configure alert routing for each tier (SIEM, Slack/email, PagerDuty). Test the escalation path by manually triggering a mock failure alert;
• Step 5: Run the 100-day schedule as a pilot. When the 100-day limit takes effect March 2027, let the automation run for 3 full renewal cycles (approximately 200 days) before the 47-day limit arrives. This validates the automation stack under real operational conditions, surfaces any silent failure modes, and builds the operations team’s familiarity with the monitoring and escalation workflows that 47-day certificates will depend on.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the ACME endpoint infrastructure for 47-day certificate automation: ACME with External Account Binding, certificate profiles with 47-day (and shorter) validity configuration, high-throughput issuance capacity for large certificate estates, and per-enrollment-channel audit logging that supports the increased issuance volume of short-validity certificate programs. Contact us at Encryption Consulting to configure your ACME endpoint for the SC-081v3 schedule.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM monitoring layer that makes 47-day automation operationally safe: continuous certificate discovery across all TLS endpoints, configurable expiry alert tiers (14-day, 7-day, 3-day, 1-day), renewal success confirmation monitoring, issuance rate monitoring from the PKIaaS ACME endpoint, SIEM integration for audit log volume at short-validity scale, and escalation workflow configuration that routes alerts to the correct team at each severity tier.
• PKI Assessment Service: For organizations that have not yet inventoried their publicly trusted TLS certificate estate or mapped each certificate to its renewal mechanism, Encryption Consulting’s PKI Assessment Service produces the certificate inventory, gap analysis, and automation readiness assessment needed to plan the SC-081v3 compliance program. The assessment identifies which certificates have no ACME automation, which have automation gaps, and which are already compliant.
• PKI Services: For organizations that need hands-on implementation support for cert-manager ClusterIssuer configuration, ACME client deployment across VM and bare-metal estates, CLM monitoring setup, or escalation workflow design, Encryption Consulting’s PKI Services provide advisory and implementation support through each step of the 47-day automation program.

Conclusion

The 47-day certificate validity schedule is not a distant regulatory requirement to plan for eventually. The schedule is already running: 200-day certificates are required from March 2026, 100-day from March 2027, 47-day from March 2029. Organizations that build their automation stack now, validated against the 100-day schedule before the 47-day limit arrives, will handle 2029 as a configuration update. Organizations that wait until 2029 will be deploying automation under deadline pressure across a certificate estate that has been renewing manually for years, with all the gaps and undocumented certificates that manual management accumulates.

PKIaaS is the right CA infrastructure for the 47-day schedule because it provides the ACME endpoint that automation clients need, the certificate profiles that define the valid parameters for short-validity certificates, and the audit logs that give the CLM layer the issuance data it needs to monitor renewal success. The automation clients, CLM monitoring configuration, and escalation workflows are the organization’s responsibility to build and operate. The sooner they are built and tested against the 100-day schedule, the more confident the operations team will be that they work at 47-day scale.

If your organization is preparing for the SC-081v3 certificate validity schedule and needs help inventorying your certificate estate or building the automation stack, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when the CA/B Forum publishes updates to the SC-081v3 schedule or ballot amendments that affect the 47-day implementation timeline.

Frequently Asked Questions

What is the CA/B Forum SC-081v3 47-day certificate validity schedule?

CA/B Forum Ballot SC-081v3, approved April 2025, reduces maximum publicly trusted TLS certificate validity in three steps: 200 days from March 15, 2026; 100 days from March 15, 2027; 47 days from March 15, 2029. All publicly trusted CAs must comply. Organizations with publicly trusted TLS certificates must have automated renewal processes in place before March 15, 2029.

Why does 47-day certificate validity make manual renewal impossible?

At 47-day validity with renewal at the 14-day window, each certificate renews approximately every 33 days, roughly 11 times per year. An estate of 1,000 publicly trusted TLS certificates generates approximately 11,000 renewal operations per year, or about 30 per day. Manual renewal at this frequency is operationally infeasible; a single missed renewal causes a service outage. Automated ACME renewal is the only viable model.

Does the 47-day limit apply to internally trusted private CA certificates?

No. SC-081v3 applies only to publicly trusted TLS certificates issued by CAs in browser and OS trust stores. Privately trusted certificates issued by a private PKIaaS CA for internal services, Kubernetes workloads, or device authentication are not subject to the CA/B Forum validity limits. Many organizations apply similar short validity periods to internal certificates as a security practice, and PKIaaS with cert-manager automation makes this operationally sustainable.

What is the recommended renewal window for 47-day TLS certificates?

14 days before expiry (renewal triggered when approximately 14 days remain). This gives the automation system two weeks of retry attempts for transient failures, 7 days for CLM escalation and manual intervention if automation persistently fails, and a 3-day critical alert window for emergency escalation. A shorter renewal window reduces the time available for failure recovery; for operations teams with 24-hour pager response times, 14 days is the minimum recommended window for 47-day certificates.

How does PKIaaS support automated renewal for 47-day certificates?

PKIaaS provides an ACME endpoint with External Account Binding (EAB) that ACME clients use to request and renew certificates automatically. The ACME client (cert-manager for Kubernetes, certbot/acme.sh for Linux, or native ACME for compatible web servers) submits the renewal request when the renewal window opens; the PKIaaS CA validates the request against the certificate profile and issues the renewed certificate without human interaction. High-throughput PKIaaS ACME endpoints handle the renewal volume of large certificate estates at 47-day scale without rate-limiting constraints that would require manual fallback.