TLS certificate lifetimes fall to 47 days: automation becomes mandatory

At a glance

What this is: The CA/Browser Forum has set a timeline that compresses TLS certificate validity and validation reuse windows, making certificate lifecycle automation a core requirement.

Why it matters: IAM, NHI, and platform teams now need certificate governance that can keep pace with shorter lifetimes, tighter validation reuse, and lower tolerance for manual renewal failure.

By the numbers:

• From today until March 15, 2026, the maximum lifetime for a TLS certificate is 398 days.
• As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.
• As of March 15, 2029, the maximum period during which domain validation information may be reused is 10 days.

👉 Read DigiCert's explanation of the 47-day TLS certificate lifetime changes

Context

TLS certificate lifetimes are being shortened because the trust value of certificate data decays faster than many enterprises can manually reissue and validate it. In practical identity terms, that pushes certificate management further into the same lifecycle discipline used for other non-human identities: inventory, ownership, renewal, and revocation all have to be repeatable.

The key governance problem is not the number 47 itself. It is the collapse of manual operating margins, especially where certificates are spread across clouds, applications, and platforms with inconsistent ownership. Teams that still treat certificate renewal as an occasional admin task will run into avoidable outages and audit gaps.

Key questions

Q: How should security teams prepare for shorter TLS certificate lifetimes?

A: Security teams should treat shorter TLS lifetimes as a lifecycle automation project, not just a renewal-date change. The immediate priorities are complete inventory, named ownership, automated issuance and renewal, and continuous expiry monitoring. Any environment that still relies on manual revalidation will accumulate outage risk as validity windows shrink.

Q: Why do shorter certificate lifetimes increase operational risk before they reduce trust risk?

A: Shorter lifetimes reduce the time a stale certificate can remain in circulation, but they also compress the window for human action. If teams do not have automation, they gain less trust assurance and more failure probability. The risk comes from process latency, not from the shorter lifetime itself.

Q: What breaks when certificate lifecycle management is still manual?

A: Manual certificate management breaks when ownership, validation evidence, and renewal timing are spread across people and tools that do not share a single control plane. The result is missed renewals, inconsistent revalidation, and service outages. In practice, manual handling is incompatible with tight expiry windows at production scale.

Q: Which controls matter most when certificate validation reuse is shortened?

A: The most important controls are authoritative inventory, automated revalidation, and alerting that triggers before reuse windows expire. Teams also need exception handling for systems that cannot be changed quickly. Without those controls, validation data becomes stale faster than operators can safely rely on it.

Technical breakdown

Why shorter TLS certificate lifetimes change certificate governance

TLS certificates are anchors for server identity, but the assurance behind them weakens as validation data ages. The CA/Browser Forum ballot shortens both certificate validity and the reuse window for validated information, which means the lifecycle of trust is now shorter than many traditional operational cadences. In effect, the certificate is no longer a long-lived object with infrequent renewal; it becomes a fast-expiring identity artefact that must be continuously revalidated, reissued, and observed. That shifts the control plane from exception handling to lifecycle orchestration.

Practical implication: move certificate management into automated lifecycle workflows with explicit ownership, renewal triggers, and expiry monitoring.

Why manual revalidation becomes an outage risk

Manual renewal breaks down when the time allowed for revalidation is measured in days rather than months. The article notes that manual revalidation may still be possible, but it becomes a recipe for failure as deadlines tighten. From an operational standpoint, the failure mode is not just missed renewal. It is inconsistent execution across environments, where teams discover certificates only when they are close to expiry and validation evidence has already gone stale. That creates a trust mismatch between what the certificate says and what the organisation can actually prove.

Practical implication: remove manual revalidation from critical paths and tie certificate issuance to policy-driven automation.

How ACME and renewal automation support high-frequency rotation

Automation protocols such as ACME reduce the human burden of repetitive certificate issuance by allowing systems to request, validate, and renew certificates programmatically. In a shorter-lifetime model, automation is not a convenience layer. It becomes the mechanism that preserves service continuity while reducing exposure to expired or weakly validated certificates. Support for renewal workflows such as ACME Renewal Information also helps organisations time replacement before expiry windows become operationally dangerous. The architectural point is simple: if trust must be refreshed frequently, the refresh process must be machine-executable.

Practical implication: standardise on automated issuance and renewal for DV, OV, and EV certificates wherever production uptime depends on them.

Threat narrative

Attacker objective: The objective is to exploit weak certificate lifecycle governance so that trust breaks down before defenders can renew or revalidate it.

1. entry via stale or manually renewed TLS certificate infrastructure that outlives its safe validation window.
2. escalation occurs when renewal and revalidation depend on human tracking, spreadsheets, or ad hoc reminders instead of automated lifecycle controls.
3. impact appears as expired certificates, failed service trust checks, and preventable outages across applications and internal services.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate lifecycle discipline is becoming a non-human identity control plane, not a back-office task. When TLS lifetimes drop from hundreds of days toward 47 days, certificate management stops being periodic maintenance and becomes continuous governance. That change matters because the operational unit is no longer the individual certificate, but the repeatable process that provisions, renews, and retires trust artifacts across environments. Practitioners should treat certificate governance as a core NHI lifecycle function, not a support function.

Manual renewal is the control gap this ballot exposes. The industry has been relying on human-paced processes for an artefact whose trust window is now shrinking faster than most teams can review. The problem is not just scale. It is that the control model assumes people will notice, validate, and replace certificates before expiry, while the new lifecycle makes that assumption brittle. The implication is that certificate ownership, renewal timing, and validation evidence need to be machine-enforced, not just documented.

Validation reuse is becoming the real trust boundary. The schedule does not only shorten certificate validity, it also compresses how long domain and identity validation can be reused. That means organisations must think about certificate trust as a dynamic evidence chain, not a static approval event. In NIST CSF terms, identity and protection functions now depend on continuous evidence freshness, while OWASP NHI concerns around lifecycle and rotation become more operationally important. Practitioners should map every production certificate to an automated revalidation path.

47-day certificates will expose hidden ownership debt. The organisations most at risk are not necessarily the most immature, but the ones with unclear certificate ownership across apps, teams, and platforms. A short lifetime reveals whether there is a real inventory, a real renewal owner, and a real exception process. Where those elements are missing, the issue is no longer certificate management alone. It is identity governance for machine-held trust at enterprise scale. Teams should use the deadline to surface and close ownership gaps now.

Automated issuance is now a governance assumption, not a maturity goal. The article makes clear that the ecosystem is moving toward a place where automation is effectively mandatory for certificate lifecycle management. That means certification, renewals, and revocation workflows should be judged on whether they can run without manual intervention in production conditions. Practitioners should stop treating automation as optional optimisation and start treating it as the minimum viable control for trust continuity.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• 61% rely on spreadsheets or manual tracking for machine identity management, which helps explain why tighter certificate lifetimes expose governance debt so quickly.
• For lifecycle remediation, review NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding controls that certificate automation now depends on.

What this signals

Certificate automation is becoming a governance baseline, not a specialist project. As validation windows compress, teams that still rely on tickets and spreadsheets will find their certificate programmes turning into incident response functions. The practical signal is that ownership, renewal policy, and expiry detection now belong in the same operating model as broader NHI lifecycle controls, not in a separate infrastructure queue.

Machine identity growth changes the meaning of trust freshness. With 69% of organisations now having more machine identities than human ones, the pressure on certificate governance is no longer theoretical, according to The Critical Gaps in Machine Identity Management report. That scale means expired or stale trust artefacts will increasingly surface as business availability problems, not isolated admin misses.

Trust decay is now faster than many teams' review cycles. The new certificate schedule forces practitioners to re-evaluate how often they can observe, validate, and rotate identity artefacts. If renewal is still owned by ad hoc teams, the programme will lag the new trust cadence, and the result will be avoidable exceptions, not just more work.

For practitioners

• Inventory every production certificate and its owner Build a complete inventory that maps each certificate to a business owner, technical owner, renewal path, and dependency chain. Without ownership, shorter lifetimes simply accelerate uncertainty into outages.
• Automate issuance and renewal workflows Use policy-driven automation for certificate request, validation, issuance, and renewal so that production systems do not depend on manual revalidation before expiry.
• Eliminate spreadsheet-based tracking Replace manual trackers with authoritative lifecycle tooling that can alert, renew, and audit certificate status across environments before validation windows close.
• Align renewal cadence to service criticality Set more aggressive monitoring for certificates that protect customer-facing or high-availability services, and require exception handling for anything that cannot be automated.

Key takeaways

• TLS certificate governance is moving from periodic maintenance to continuous lifecycle control.
• The scale problem is already visible: machine identities outnumber human identities in most organisations.
• Teams that cannot automate issuance, validation, and renewal will face outages long before the 47-day deadline arrives.

Key terms

• TLS certificate lifecycle: The TLS certificate lifecycle is the end-to-end process of requesting, validating, issuing, renewing, and retiring a certificate. In practice, it is a governance process for machine-held trust that only works when ownership, automation, and expiry monitoring are defined before production deadlines arrive.
• Validation reuse window: The validation reuse window is the period during which previously verified domain or identity information can be reused to issue or renew a certificate. When that window shrinks, organisations have less time to rely on old proof and more need for fresh, automated revalidation.
• ACME: ACME is a protocol for automating certificate issuance and renewal between a client and a certificate authority. It matters because short-lived certificates are difficult to manage safely by hand, so production environments need machine-executable renewal workflows rather than ticket-driven operations.
• Machine identity: A machine identity is a non-human identity used by software, services, workloads, or devices to authenticate and communicate. Certificates, tokens, keys, and service accounts are common forms, and they need the same governance discipline as human identities when scale and lifecycle speed increase.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by DigiCert: TLS Certificate Lifetimes Will Officially Reduce to 47 Days. Read the original.