TL;DR: The move to 47-day TLS certificates turns certificate management into a governance problem, according to AppViewX, because organisations need live inventory, central policy and automated renewal before manual processes break under near-continuous rotation. Leadership now has to fund the operating model, not just the PKI tooling.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AppViewX's blog post: 47-day TLS certificate lifecycles push certificate management from a PKI task into an executive governance and automation problem.
Why it matters: Identity, infrastructure and security teams must align on inventory, issuance policy and automated renewal before shorter certificate lifetimes turn missed renewals into outages.
Context
A short-lived certificate regime changes the operating assumption behind PKI. When certificates expire far more often, the real question is no longer whether renewal can be completed, but whether the organisation can even see every certificate that exists across cloud, on-prem, Kubernetes and partner-facing services.
That visibility problem is a governance issue as much as a technical one. Without a live inventory, central policy and ownership across application, infrastructure and security teams, automation cannot be trusted to keep pace with certificate churn.
Key questions
Q: How should teams build a certificate lifecycle inventory?
A: Teams should build a live certificate inventory that spans cloud, on-prem, Kubernetes, SaaS and partner-facing services, with ownership, expiry and issuing CA data attached to each record. The inventory has to update continuously, because certificate sprawl and short validity periods make periodic scans too slow to support reliable renewal and incident response.
Q: Why do shorter certificate lifespans increase outage risk?
A: Shorter lifespans compress the time available for discovery, approval, renewal, and validation. Any gap in ownership, tooling, or coordination is more likely to surface as an outage because the renewal cycle happens more often and leaves less room for human delay. The risk is operational drift, not the certificate format itself.
Q: How does ACME support automated certificate renewal?
A: ACME supports automated certificate renewal by letting a certificate authority issue or reissue certificates through a protocol exchange that proves control of the requested domain or identifier. A client can complete renewal, replacement, or revocation workflows without manual intervention, using tokens and challenge responses. It is commonly used to reduce expired certificates caused by missed manual renewals.
Q: What is the difference between central issuance and local certificate requests?
A: Central issuance means certificates are requested and approved through one governed process, usually with policy, logging, and certificate authority oversight. Local certificate requests are generated and handled on the target system or by a local service, with less central control over enrolment, naming, and renewal. The main difference is where authority and policy enforcement sit.
Technical breakdown
Why certificate inventory becomes the control plane
Certificate lifecycle management only works when every certificate is discoverable before it expires. In practice, certificates are scattered across load balancers, clusters, application stacks, SaaS integrations and internal services, so discovery has to be continuous rather than periodic. A live inventory is the base layer for expiry tracking, issuing CA visibility and owner attribution. Without it, renewal automation only covers the certificates already known to the platform, which leaves the most fragile assets outside the process. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Build continuous discovery for all certificate-bearing assets before you try to automate renewal at scale.
How ACME changes renewal from a ticket to a protocol
ACME is the protocol that lets systems request and renew certificates automatically without a human approval step in the middle. That matters because the renewal problem is not simply volume, but timing: at 47-day validity, waiting on tickets or manual approvals becomes operational debt. Self-service portals and APIs help, but ACME is what allows server and container identities to renew on their own while policy remains centrally enforced. The protocol shifts certificate handling from a people process to a machine process.
Practical implication: Expose ACME for any workload that can renew itself, and keep policy enforcement central.
Why deployment automation matters more than issuance automation
Issuing a renewed certificate is only half the job. If the new certificate still has to be pushed manually to servers, load balancers and platform services, the risk simply moves downstream into the deployment window. Automation has to include validation after rollout so the organisation knows the trusted certificate is active before the old one expires. That is why certificate lifecycle programmes fail when they stop at request automation and ignore the last mile. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Practical implication: Automate deployment and post-change validation wherever certificates terminate in production.
Threat narrative
Attacker objective: The operational objective is to trigger trust failures and service outages by exploiting certificate lifecycle gaps, whether through expiry or distrust events.
- Entry occurs through unmanaged certificates that were never brought into a live inventory, leaving renewal paths invisible.
- Escalation follows when manual renewal cannot keep pace with shrinking validity periods, so expired certificates create service disruption.
- Impact appears as hard outages and emergency replacement work when systems stop trusting certificates that were not renewed in time.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
47-day TLS makes certificate inventory a governance prerequisite: the decisive control is no longer renewal speed alone, but whether every certificate is visible, owned and tied to a policy path. Without that inventory, automation only covers the known edge of the estate and misses the assets most likely to fail under short validity windows. The implication is that certificate governance now sits across infrastructure, application and security ownership, not inside PKI alone.
Central policy matters more than isolated team automation: shorter lifecycles expose the weakness of fragmented issuance models, where teams choose different CAs and maintain separate renewal habits. A central policy model is what makes distrust events and mass replacement manageable at speed. CA/Browser Forum Baseline Requirements matter here because public certificate rules are no longer a background constraint; they shape operating cadence.
Self-service and deployment are the same control in different forms: issuance automation without deployment automation still leaves humans on the critical path. That is why certificate programmes stall at the point where renewal is technically possible but operationally brittle. The field should treat automated deployment validation as part of certificate governance, not as a downstream implementation detail.
Certificate lifecycle discipline is now rehearsal for crypto-agility: the same inventory, policy and automation stack needed for 47-day compliance is the stack future certificate migrations will require. Organisations that solve the short-validity problem are building the response model for larger reissuance events later. Practitioners should treat the current deadline as a design test for broader identity and cryptographic change.
Certificate automation is a cross-functional operating model, not a PKI project: application owners, infrastructure teams, DevSecOps and security leadership all have to share the same request-to-deployment flow. That changes how accountability is assigned, because the failure mode is organisational drift as much as technical lag. Teams that do not formalise ownership across those boundaries will keep re-creating manual exceptions.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Certificate Expiry Outages and 47-Day TLS Certificates Guide
What this signals
Certificate inventory is now the first control to harden: the 47-day model makes discovery and ownership the point where most programmes will either stabilise or fragment. Once validity shortens further, organisations that still rely on periodic checks will be forced into reactive renewal work that obscures risk instead of reducing it. The practical shift is toward continuous inventory, not annual housekeeping.
Automation has to absorb both request and deployment paths: a renewal workflow that stops at issuance still leaves humans exposed at the moment of change. The teams that will cope best are the ones that treat certificate deployment, validation and exception handling as one governed lifecycle. That is where certificate operations start to look like identity lifecycle management rather than infrastructure maintenance.
For practitioners
- Map the full certificate estate Create a live inventory that covers cloud, on-prem, Kubernetes, SaaS and partner-facing endpoints, then assign ownership to every certificate record.
- Centralise certificate issuance policy Route public and private certificate requests through one governed process that enforces validity, key size, SAN and ownership rules.
- Enable ACME for self-service renewal Expose automated renewal paths for workloads, containers and application teams so routine certificate changes do not depend on tickets.
- Automate certificate deployment and validation Push renewed certificates into production systems automatically and confirm the new certificate is trusted before the previous one expires.
- Assign joint accountability across teams Name application, infrastructure and security owners for each stage of the request-to-deployment flow so automation does not stall at handoff points.
Key takeaways
- The main risk is not just expiry, but the loss of control that comes when certificate volume outruns manual governance.
- The article ties 47-day readiness to live inventory, central policy and automated deployment, not to isolated PKI tuning.
- The practical implication is a shift in ownership: certificate lifecycle management becomes a cross-functional operating model.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Certificate Expiry Outages and 47-Day TLS Certificates Guide · CA/Browser Forum Baseline Requirements Guide · Guide to SPIFFE and SPIRE
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Expired and replaced certificates must be removed from service cleanly to avoid trust failures and residue. |
| NHI-07 — Long-Lived Secrets | Shorter validity periods are the direct opposite of long-lived certificate credentials. | |
| Recommendation — Track certificate replacement and retirement so stale credentials do not remain active after renewal. Shorten certificate lifetimes and automate renewal before expiry becomes a recurring outage risk. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance, renewal and replacement are authenticator lifecycle functions. |
| Recommendation — Apply IA-5 to govern certificate issuance, renewal, replacement and revocation across the estate. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificate-driven access must be governed consistently when renewal and ownership are distributed. |
| Recommendation — Standardise certificate access and ownership rules so renewal workflows stay authorised and auditable. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate-bearing service identities require account-style lifecycle control and revocation discipline. |
| Recommendation — Maintain authoritative certificate ownership and revoke unused or stale identities as part of account management. | ||
Key terms
- TLS Certificate: A TLS certificate is a machine credential used to prove a server or service is authentic during encrypted communication. In practice, it is a non-human identity artifact with a fixed expiration date, ownership requirement, and renewal workflow that must be governed like any other sensitive credential.
- ACME: ACME is a protocol used to automate certificate issuance and renewal between a client and a certificate authority. For practitioners, it reduces manual renewal work, but it also introduces a dependency on correct client configuration, credential handling, and monitoring of the automation path.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org