Notifications
Clear all
Topic starter
08/07/2026 6:56 pm
TL;DR: Certificate lifecycles are shortening, manual renewal is becoming untenable, and expired or unmanaged certificates are already causing outages and trust failures across internet-facing and internal services, according to Infisical. The governance problem is not just renewal speed but discovery, accountability, and blast-radius control across the full certificate lifecycle.
NHIMG editorial — based on content published by Infisical: Certificate Management: The Complete Guide to Automating PKI and TLS/SSL Certificates Across The Lifecycle
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Infisical's guide to automating certificate lifecycle management →
Certificate expiry and lifecycle gaps: what IAM teams need to know?
Explore further
08/07/2026 7:18 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Certificate lifecycle governance is becoming a trust-management problem
