Certificate lifecycle governance is becoming a trust-management problem

At a glance

What this is: This is a guide to automating certificate management across discovery, issuance, deployment, monitoring, renewal, and revocation, with the core finding that lifecycle visibility is now the main control gap.

Why it matters: It matters because certificates are NHI credentials in practice, and IAM teams need the same lifecycle discipline for keys and certs that they apply to human access, workload identity, and privileged access.

By the numbers:

• TLS certificate maximum lifetimes dropped to 398 days in 2020.
• The CA/Browser Forum has approved a roadmap that takes TLS certificate lifetimes to 47 days by 2029.

👉 Read Infisical's guide to automating certificate lifecycle management

Context

Certificate management is the lifecycle discipline for digital certificates, from discovery and issuance through renewal, revocation, and replacement. In identity terms, certificates are non-human credentials, so the same governance questions apply: where they exist, who owns them, how long they remain valid, and what happens when they are forgotten.

The problem is not abstract. Shorter certificate lifetimes, more distributed infrastructure, and more machine-to-machine authentication mean organisations can no longer rely on manual tracking or ad hoc renewal. For IAM and NHI programmes, certificate governance is now a visibility and accountability problem as much as a cryptography problem.

Key questions

Q: How should security teams automate certificate renewal across mixed environments?

A: They should automate renewal from a trusted inventory, not from ad hoc alerts. The process needs discovery, expiry tracking, pre-expiry renewal, validation, and replacement across every environment that consumes certificates. If any certificate still depends on a human noticing a warning in time, the programme has not removed manual risk, it has only hidden it.

Q: Why do unmanaged certificates create identity risk as well as availability risk?

A: Unmanaged certificates are identity risk because they are credentials that prove trust between systems. If they are forgotten, expired, or deployed without ownership, they can cause outages, weaken authentication, or remain trusted longer than intended. For IAM teams, that is a lifecycle failure, not just an infrastructure inconvenience.

Q: When should organisations prioritise certificate inventory over certificate renewal automation?

A: Inventory should come first whenever there is no authoritative view of what certificates exist or where they are deployed. Automation built on partial visibility will miss orphaned certificates, obsolete trust chains, and renewal exceptions. Once the inventory is reliable, automation can reduce expiry risk and operational load.

Q: Who should be accountable for certificate lifecycle failures?

A: Accountability should sit with the team that owns the trust boundary, not with the last person who noticed an expiry warning. In practice that means infrastructure, platform, or identity teams need explicit ownership for issuance, renewal, revocation, and retirement. Without named ownership, certificate governance becomes nobody’s problem until the outage happens.

Technical breakdown

Why certificate discovery is the starting control

Certificate management fails first when inventory is incomplete. Discovery means scanning servers, load balancers, Kubernetes clusters, internal services, and legacy devices to find every certificate in use. Without that baseline, teams cannot know what is expiring, what is still trusted, or what is orphaned after a system change. The article shows why discovery is not a reporting function but the prerequisite for every downstream lifecycle action. In NHI terms, certificates behave like dormant credentials until they are found, mapped, and assigned an owner.

Practical implication: build continuous certificate discovery before trying to automate renewal.

How certificate renewal and revocation work together

Renewal replaces a certificate before expiry, while revocation invalidates a certificate that is compromised or no longer authorised. These are not separate administrative chores. They are linked control points in the same trust chain because a certificate can be renewed but still deployed in the wrong place, or revoked but still trusted by a system that has not updated. The article’s key operational point is that lifecycle tooling must understand where certificates are deployed so replacement and invalidation happen together. That is the difference between governance and ticket handling.

Practical implication: tie renewal workflows to deployment maps and revocation status, not calendar reminders.

Why CA hierarchy changes blast radius

A certificate authority hierarchy reduces risk by separating the root CA from intermediate CAs that issue leaf certificates. If an intermediate key is compromised, the fallout is limited to the certificates it issued, but if one CA signs for development, staging, and production, the blast radius becomes much larger. This is the same structural pattern identity teams see with over-scoped privileged accounts: trust concentration creates failure amplification. The operational lesson is that certificate architecture is a governance decision, not just a cryptographic one.

Practical implication: segment CA responsibility by environment so one compromise cannot span every trust zone.

Threat narrative

Attacker objective: The objective is to exploit unmanaged trust or the resulting failure mode to disrupt services, weaken authentication, or create an opening for impersonation.

1. Entry occurs when a certificate is missed in discovery, left unmanaged on a gateway, or deployed without an owner who tracks its expiry.
2. Credential access or abuse happens when the certificate remains trusted longer than intended, or when expired trust triggers unintended service shutdowns and authentication failure.
3. Impact follows when customers, internal services, or mobile networks lose connectivity because certificate trust was not renewed, revoked, or replaced in time.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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 governance is now NHI governance by another name. A certificate is a non-human credential with an expiry date, an owner, a trust boundary, and a revocation path. That makes lifecycle controls, discovery, and offboarding as relevant to certs as they are to service accounts and API keys. The implication is that IAM and security teams should stop treating PKI as a separate technical silo.

Certificate discovery and ownership are the real control plane. The article’s strongest operational point is that renewal cannot be managed well when organisations do not know where certificates live or who is responsible for them. Visibility determines whether expiry becomes a routine event or an outage. Practitioners should treat unknown certificates as unmanaged identities, because that is what they are in governance terms.

Blast-radius control is a design choice, not an incident response activity. Root and intermediate CA segmentation limits how far a compromise or operational failure can spread, but only if certificate hierarchy is intentionally scoped. When one intermediate CA covers multiple environments, the trust model itself amplifies incident impact. Practitioners should review whether their certificate architecture matches their segregation model.

Shorter validity windows make manual lifecycle governance structurally obsolete. The move from 398-day certificates to a 47-day roadmap removes the safety margin that once made human-run renewal plausible. This is not just a tooling problem, it is a governance timing problem across inventories, approvals, and replacement windows. Practitioners should expect certificate operations to converge with broader machine identity lifecycle management.

Interoperability matters because legacy protocols keep lifecycle debt alive. SCEP and EST still sit beside ACME in many estates, which means certificate governance often has to span modern cloud services and older network or mobile-device infrastructure. That creates policy drift if the lifecycle model is different by protocol. Practitioners should standardise lifecycle intent even when the enrollment mechanics vary.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For the lifecycle angle, see NHI Lifecycle Management Guide for the ownership and rotation model that certificate programmes usually need next.

What this signals

Certificate programmes are converging with machine identity governance. As certificate lifetimes shrink and manual renewal windows disappear, the operational boundary between PKI and NHI management keeps narrowing. Teams that already govern workload identity, secrets, and service accounts should expect certificates to join the same lifecycle controls, ownership models, and review cadence.

The practical signal is that inventory quality will become the deciding factor in uptime and audit readiness. Organisations that cannot map every certificate to an owner will keep discovering trust failures at the point of outage, not in advance.

For practitioners

• Implement continuous certificate discovery Scan servers, load balancers, Kubernetes clusters, internal services, and legacy endpoints on a recurring basis so you can maintain an authoritative inventory of every certificate in use.
• Link renewal to deployment state Trigger renewal workflows from live expiry and deployment data, not manual calendars, so replacement happens before expiry and the new certificate is validated in the correct environment.
• Separate CA scope by environment Keep production, staging, and development issuance boundaries distinct so compromise or revocation in one trust zone does not force broad reissuance across the rest of the estate.
• Treat certificates as owned identities Assign accountable owners for issuance, renewal, revocation, and retirement so forgotten certificates do not become permanent trust exceptions.

Key takeaways

• Certificate expiry is now a lifecycle governance problem, not a one-off operational mistake.
• Discovery, ownership, and deployment mapping determine whether certificates are managed or merely monitored.
• Automation only reduces risk when renewal, revocation, and segmentation are designed as one control system.

Key terms

• Certificate Lifecycle Management: Certificate lifecycle management is the practice of discovering, issuing, deploying, monitoring, renewing, and revoking digital certificates across an environment. In governance terms, it is the control system that prevents expired or misplaced certificates from becoming outages, trust failures, or unowned credentials.
• Certificate Authority Hierarchy: A certificate authority hierarchy is the chain of root and intermediate authorities used to issue and validate certificates. The hierarchy limits trust blast radius by separating high-value signing keys from operational issuance, but it only works when each layer is intentionally scoped and owned.
• Non-Human Credential: A non-human credential is any secret or certificate used by a system, workload, or service rather than a person. Certificates belong in this category because they authenticate machines and services, carry validity windows, and require lifecycle governance just like other NHI assets.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step certificate lifecycle workflow for discovery, issuance, deployment, monitoring, renewal, and revocation
• Protocol-level guidance for ACME, SCEP, EST, and legacy PKI environments
• Tooling trade-offs for public CAs, private CAs, and CA hierarchy management
• Implementation detail for HSM-backed root key protection and certificate automation

👉 The full Infisical post covers certificate discovery, renewal automation, and PKI architecture details.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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.