Certificate lifetimes are shrinking to 47 days: IAM implications

At a glance

What this is: Public SSL/TLS certificate validity is being shortened to 47 days, with domain control validation reuse also tightening to 10 days, creating a much narrower certificate lifecycle for enterprises to manage.

Why it matters: IAM, PAM, and NHI teams should treat certificates as governed identities because shorter lifetimes expose inventory gaps, weak ownership, and manual renewal failure modes that can affect human and non-human access alike.

By the numbers:

• The CA/B Forum approved a phased reduction in public SSL/TLS certificate validity from 398 days to 47 days by 2029.
• Domain control validation reuse will shrink from 398 days to 10 days by 2028.

👉 Read GlobalSign's analysis of the move to 47-day SSL/TLS certificates

Context

Public SSL/TLS certificates are moving from long-lived artefacts to short-cycle identities that must be issued, validated, rotated, and tracked much more often. That changes the operational burden around certificate lifecycle management, and it brings the problem closer to identity governance than to one-off infrastructure maintenance.

For identity and security teams, the key issue is not the date itself but the control model behind it. Shorter lifetimes expose whether organisations have inventory, ownership, automation, and revocation discipline for machine identities, service endpoints, and other certificate-backed trust relationships.

Key questions

Q: How should security teams implement certificate automation in mixed environments?

A: Start with a full inventory of certificate-bearing systems, then group them by renewal method, ownership, and expiry criticality. Automate issuance and renewal where protocols such as ACME are supported, but add approval, revocation, and exception handling for systems that need custom workflows. The goal is consistent lifecycle control, not just faster renewal.

Q: Why do shorter certificate lifetimes matter for identity governance?

A: Shorter lifetimes matter because they reveal whether identity governance is actually operational or only documented. If an organisation cannot track certificate ownership, renewal timing, and revocation state, it will struggle to manage service trust, machine identities, and related access paths before outages or exposure occur. Lifecycle discipline becomes the control, not the calendar.

Q: What breaks when certificate renewal is still handled manually?

A: Manual renewal breaks first at scale, then at speed. Teams miss expiry dates, duplicate validation work, and create outages when certificates are not replaced before they lapse. The problem gets worse in environments with many domains, distributed applications, or non-browser clients because the human coordination burden outpaces the trust window.

Q: Who is accountable when certificate expiry causes an outage or exposure?

A: Accountability should sit with the service owner, security owner, and platform owner together, because certificate failure is usually a shared governance problem. Frameworks such as NIST SP 800-53 Rev 5 align well here, especially controls around access management, identification, authentication, and monitoring. Clear ownership prevents certificate risk from becoming everyone’s problem and therefore nobody’s job.

Technical breakdown

Why certificate lifetime and DCV reuse are being compressed

Certificate lifetime is the period a public SSL/TLS certificate remains valid after issuance. Domain control validation reuse is the period a certificate authority can rely on prior proof of domain ownership before rechecking it. Compressing both windows reduces the time a compromised certificate can be abused and forces organisations to prove ongoing control more frequently. The architectural effect is simple: trust becomes more ephemeral, and lifecycle automation becomes part of the security baseline rather than an efficiency project.

Practical implication: treat certificate issuance and validation as continuous controls, not quarterly admin tasks.

Why shorter lifetimes expose machine identity governance gaps

Certificates are a form of machine identity because they bind a system, service, or workload to a cryptographic trust relationship. When lifetimes shrink, weak inventory, unclear ownership, and manual renewal processes become visible very quickly. This is where IAM and NHI governance intersect. If a team cannot answer which certificates exist, who owns them, and where they are installed, it cannot reliably revoke, rotate, or audit them before expiry creates outage or exposure.

Practical implication: connect certificate inventory to ownership and remediation workflows before renewal deadlines tighten further.

Why automation is now the real control plane for certificate security

Automation is not just a convenience here. It is the mechanism that makes frequent renewal technically feasible across browsers, APIs, VPNs, IoT devices, and internal systems. Protocols such as ACME handle issuance and renewal for many domain-validated certificates, but they do not replace broader lifecycle management, reporting, or policy enforcement. Organisations still need control over approval, distribution, revocation, and exception handling across mixed environments.

Practical implication: standardise renewal automation, but pair it with policy, reporting, and exception governance.

Threat narrative

Attacker objective: The attacker objective is to preserve or exploit trusted access through a certificate-backed identity long enough to impersonate services, disrupt operations, or maintain unauthorised trust.

1. Entry occurs when a long-lived certificate or its associated validation process is exposed, mismanaged, or left untracked across systems and environments.
2. Escalation follows when the same certificate can be reused longer than intended, allowing a compromised trust artefact to persist past its safe operational window.
3. Impact appears as impersonation, service abuse, outage, or prolonged trust in a certificate that should have been rotated or revoked earlier.

NHI Mgmt Group analysis

Certificate lifecycle is becoming an identity governance problem, not just a browser policy issue. Once validity windows fall to 47 days, teams that treat certificates as static infrastructure assets will lose operational control. The real challenge is proving ownership, enforcing renewal, and linking certificates to accountable workflows across human and machine identity programmes. Practitioners should manage certificates as governed identities with lifecycle states, not as background plumbing.

Shorter certificate lifetimes expose the same weak points that drive NHI risk. Missing inventory, unclear ownership, and manual tracking are familiar failure modes in machine identity management, and they become more dangerous when renewal windows collapse. This is where the certificate model intersects directly with service accounts, API keys, and other non-human identities that also depend on reliable rotation discipline. Practitioners should unify certificate governance with broader NHI oversight.

Automation becomes mandatory because the trust model is now too fast for spreadsheet governance. The operational answer is not more ad hoc renewal effort but stronger policy, better telemetry, and predictable workflow orchestration. That same pattern applies to identity governance more broadly: when trust windows get shorter, the control plane must become more precise. Practitioners should move renewal into automated lifecycle management with clear exception handling.

Post-quantum readiness is a governance issue as much as a cryptographic one. The article correctly links shorter lifetimes to future cryptographic change, because organisations that can rotate certificates quickly will absorb algorithm transitions more cleanly. The broader signal is that certificate resilience now depends on lifecycle speed, not only key strength. Practitioners should use this shift to test how quickly identity-backed trust can be reissued, replaced, and audited.

Named concept: certificate lifecycle compression. This is the shrinking gap between issuance, validation reuse, and expiry that turns certificate management into a high-frequency operational control. It matters because compressed trust windows punish weak ownership models and reward disciplined automation. Practitioners should use the concept to prioritise lifecycle visibility over one-off renewal success.

What this signals

Certificate lifecycle compression will force organisations to collapse the gap between identity governance and operations. The teams that still separate certificate ownership, renewal, and revocation from IAM will struggle first, because shorter trust windows leave less room for manual coordination. The practical response is to align certificate workflows with the same controls used for non-human identities and privileged access, then measure whether lifecycle events are fully traceable.

Machine identity visibility is the real readiness test. If an organisation cannot inventory certificates, service accounts, and other machine identities together, it will keep solving expiry symptoms rather than governance causes. Our research shows 57% of organisations still lack a complete machine identity inventory, which is a warning sign for any programme trying to absorb tighter certificate windows.

Certificate automation should now be assessed as a resilience capability. The question is not whether renewal can happen, but whether it can happen consistently across public web services, internal applications, and non-browser clients. Teams should use this change to review [NIST SP 800-53 Rev 5 Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) for lifecycle management, access control, and monitoring coverage.

For practitioners

• Map every certificate to an owner and service path Build a complete inventory of public and internal certificates, then attach each item to a named business owner, technical owner, and deployment location. This is the only practical way to manage tighter expiry windows without missed renewals or orphaned trust.
• Automate issuance, renewal, and revocation together Do not automate renewal in isolation. Use lifecycle workflows that cover issuance, validation, installation, replacement, and revocation so the same control path handles normal expiry and emergency response.
• Segment public certificates from internal PKI exceptions Separate Internet-facing certificates that follow CA/B Forum timing from internal PKI assets that use different policies. That prevents mixed governance models from hiding renewal risk inside shared tooling or inconsistent exception handling.
• Test non-browser renewal paths now Inventory VPNs, IoT devices, internal apps, and legacy systems that rely on TLS certificates, then verify which ones support ACME or equivalent automation. Where they do not, define API-based or scheduled renewal workflows before expiry pressure rises.

Key takeaways

• Certificate validity is shrinking fast enough that manual renewal is becoming an operational liability.
• The real risk is not only expiry, but the visibility and ownership gaps that expiry exposes across machine identity estates.
• Organisations that automate issuance, validation, and revocation now will be better placed to handle both certificate churn and future cryptographic change.

Key terms

• Certificate lifetime: Certificate lifetime is the period a public or private certificate remains valid after issuance. In practice it defines how long a trust assertion can be relied on before it must be replaced, renewed, or revalidated. Shorter lifetimes reduce exposure but increase lifecycle management pressure.
• Domain control validation reuse: Domain control validation reuse is the period during which a certificate authority can rely on prior proof of domain ownership without rechecking it. When this window shrinks, organisations must repeatedly prove control, which increases operational frequency and makes automation and ownership tracking more important.
• Machine identity: A machine identity is a cryptographic identity used by a non-human system such as a service, workload, API, certificate, token, or certificate-backed client. These identities authenticate systems to other systems, so governance has to cover inventory, ownership, lifecycle, and revocation, not just issuance.
• Certificate lifecycle management: Certificate lifecycle management is the set of processes that govern discovery, issuance, validation, renewal, distribution, replacement, and revocation of certificates. Strong lifecycle management turns certificate handling into a repeatable control rather than a manual task that depends on memory and spreadsheets.

What's in the full article

GlobalSign's full article covers the operational detail this post intentionally leaves for the source:

• A phased implementation timeline for the 398-day, 200-day, and 47-day certificate validity changes.
• Comparisons of ACME, managed PKI, and internal PKI approaches for different infrastructure patterns.
• Special-case handling for OV and EV certificates, including annual subject identity validation.
• Practical guidance for non-browser clients such as VPNs, IoT devices, and legacy applications.

👉 GlobalSign's full article covers the timeline, automation options, and special cases in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, workload identity, and secrets management. It gives practitioners a practical baseline for connecting certificate lifecycle control to broader identity governance.