TL;DR: Expired TLS certificates and fragmented key governance still cause avoidable outages, according to Fortanix, because many enterprises rely on spreadsheets, siloed tools and manual renewals while certificate lifetimes shrink and cryptographic transition pressure grows. Visibility, automation and control discipline now determine whether digital trust holds under operational change.
At a glance
What this is: This is a Fortanix analysis of how poor enterprise key and certificate management turns routine expiry and rotation tasks into service outages and governance failures.
Why it matters: It matters because IAM, PAM and infrastructure teams need reliable inventory, renewal and access controls for certificates and keys before downtime exposes the same weaknesses that attackers and auditors can exploit.
Context
Enterprise key and certificate management is the operational layer that keeps digital trust from collapsing when credentials expire, rotate or are revoked. The failure mode is simple: if teams cannot see where keys and certificates live, they cannot renew, rotate or recover them in time, and the result is outage rather than resilience.
The article sits at the intersection of cryptographic hygiene, cloud operations and identity governance. Keys and certificates are not just technical assets; they are machine trust instruments that control service authentication, workload access and secure communications across hybrid environments. When lifecycle ownership is fragmented, the control problem becomes an identity problem as well as a reliability problem.
Key questions
Q: What breaks when SSL certificate lifecycle management is not in place?
A: When certificate lifecycle management is weak, services can fail at expiry, trust chains can degrade silently and users may lose confidence in the site or application. The issue is not just a browser warning. It is a governance gap that leaves ownership, monitoring and renewal undefined, which turns certificates into hidden operational risk.
Q: Why do expired certificates still cause outages in mature environments?
A: Expired certificates still cause outages because many environments rely on manual tracking, fragmented ownership, and renewal processes that do not match certificate growth. Mature teams often have policy, but not reliable execution. When the inventory is incomplete or the owner is unclear, the renewal event is missed and the service fails before remediation begins.
Q: What do security teams get wrong about manual key rotation?
A: They treat rotation as a periodic task instead of a lifecycle control. In reality, manual rotation depends on memory, low operational friction, and clear ownership, all of which degrade at scale. Without automation, rotation often happens too late or not at all.
Q: Should organisations prioritise automation before post-quantum cryptography planning?
A: Yes. Post-quantum planning matters, but without automated discovery and renewal, organisations cannot even see where their current keys and certificates live, let alone transition them safely. Inventory and automation create the control foundation that PQC migration depends on.
Technical breakdown
Why certificate expiry still causes outages
TLS certificates and related keys are time-bound trust objects. When discovery is incomplete or ownership is unclear, expiry events are missed and services fail closed, which can take down customer-facing applications, internal dependencies and even administrative access paths. The operational issue is not the certificate itself, but the lack of a governed lifecycle around inventory, renewal and revocation. As environments spread across cloud, on-premises and CI/CD pipelines, the number of places that can silently drift grows faster than manual tracking can keep up.
Practical implication: treat certificate inventory as a control surface, not a spreadsheet task, and automate discovery before renewal windows close.
How renewal and rotation automation reduces blast radius
Renewal automation shortens the window in which a certificate can expire unexpectedly, while rotation automation limits how long a compromised key remains useful. In practice, the two controls address different failure modes: expiry-driven downtime on one hand and prolonged exposure after compromise on the other. As certificate lifetimes shrink, manual workflows become brittle because they depend on perfect human timing across many systems. The same logic applies to cryptographic keys used by applications, workloads and services that authenticate to one another.
Practical implication: enforce policy-driven renewal and rotation so lifecycle events happen consistently without depending on individual operators.
Why access controls matter for key usage
A cryptographic control plane is only as strong as the permissions around it. If too many administrators can issue, export, duplicate or revoke keys without oversight, the risk is not only misuse by insiders or attackers but also accidental service disruption through misconfiguration. Strong governance uses role-based access control, multi-factor authentication, quorum approval for sensitive actions and anomaly monitoring to reduce both malicious abuse and operational error. That matters because valid credentials and valid keys often look the same at runtime, which makes privilege boundaries essential.
Practical implication: bind key operations to least privilege, step-up approval and monitoring so a single account cannot trigger avoidable disruption.
Threat narrative
Attacker objective: The practical objective in this failure pattern is not always theft, but disruption of digital trust so services fail, customers are locked out and operational confidence erodes.
- Entry begins when teams lose visibility into where certificates and keys are stored across cloud services, on-premises systems and internal applications.
- Escalation occurs when manual renewal and rotation processes fail, allowing expired certificates or stale keys to persist into production.
- Impact follows when valid trust material expires or is misused, taking critical services offline and exposing the organisation to repeat outages and audit findings.
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
Certificate lifecycle failure is an identity governance problem, not just an operations problem. Keys and certificates are machine trust credentials, so when their ownership, renewal and revocation are not governed, the organisation has created unmanaged non-human identity risk. The outage is only the visible symptom; the deeper issue is that no one can prove who owns each trust object, when it expires or how it is recovered. Practitioners should manage certificates with the same lifecycle discipline they apply to privileged access and service identities.
Automation is becoming the control that separates resilience from repeated downtime. Manual renewal models do not scale when certificate validity shrinks and deployments move through CI/CD at machine speed. The governance question is no longer whether automation is convenient, but whether human processes can still meet the operational tempo of modern trust infrastructure. Teams that cannot automate renewal are accepting outage as a predictable outcome.
Access to cryptographic operations deserves PAM-level scrutiny. The article correctly points to RBAC, multi-factor authentication and quorum approval because key usage is a high-impact control point. A single overpowered administrator or service account can create both security exposure and accidental service failure. In identity terms, this is a privilege boundary problem, and the right response is to make key administration a tightly bounded, auditable privilege domain.
Post-quantum readiness will expose hidden certificate inventory debt. The shift to PQC is not only an algorithm migration; it is a discovery problem that reveals where keys, certificates and dependent workloads actually live. Organisations that do not know their cryptographic estate today will struggle to transition it without disruption tomorrow. The practical conclusion is that crypto-agility starts with inventory, ownership and dependency mapping, not with algorithm selection.
What this signals
Enterprise certificate sprawl is now a resilience issue. As services multiply across cloud and on-premises environments, the governance burden shifts from periodic renewal to continuous lifecycle management. Teams should expect outages whenever ownership, discovery and automation remain fragmented.
Machine trust has to be governed like privileged access. Keys and certificates are not passive infrastructure artefacts; they are active control points for service authentication and secure communication. That means least privilege, approval boundaries and auditability belong in the design, not only in the incident response playbook.
For practitioners
- Implement continuous certificate discovery Build an authoritative inventory of certificates, keys and their owners across cloud, on-premises and application environments so expiry cannot hide in isolated systems.
- Automate renewal and rotation policies Remove manual renewal dates from operational dependence and enforce lifecycle actions through policy-driven workflows for both certificates and application keys.
- Tighten access to cryptographic operations Require least privilege, multi-factor authentication and quorum approval for key export, revocation and other high-impact operations.
- Test failover for certificate and CA loss Run recovery drills that assume a certificate authority outage, failed renewal or unexpected revocation so teams can restore service before production impact spreads.
- Map cryptographic dependencies for PQC transition Identify where RSA and ECC are used, which services depend on them and what breaks if those assets must be replaced without warning.
Key takeaways
- Expired certificates and unmanaged keys create preventable outages because operational trust depends on lifecycle control, not just encryption.
- The article ties downtime risk to poor visibility, manual renewal and weak governance across distributed cloud and on-premises environments.
- The practical lesson is to automate discovery, renewal, access control and recovery so cryptographic assets do not become single points of failure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key and certificate rotation is central to the article's outage and exposure risks. |
| AC-6 — Least Privilege | The article stresses limiting who can perform sensitive key operations. | |
| Recommendation — Apply IA-5 to govern issuance, rotation and revocation of cryptographic authenticators. Restrict key administration actions to the minimum privileges required for each role. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate and key ownership depends on disciplined account and lifecycle control. |
| Recommendation — Tie cryptographic operations to managed accounts and remove unused access paths promptly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece emphasises governing who may use, rotate or revoke trusted assets. |
| Recommendation — Review entitlements for cryptographic systems so only approved actors can exercise sensitive trust actions. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The core topic is lifecycle control for keys and certificates, including rotation and transition. |
| Recommendation — Use lifecycle governance to track, rotate, recover and retire cryptographic keys before they disrupt service. | ||
Key terms
- 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.
- Key Rotation: The process of replacing a credential with a fresh one before the old credential becomes too risky or stale. For SSH, rotation only reduces risk when the old key is actually removed everywhere it was trusted, not just reissued elsewhere.
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
- Machine Trust Chain: The linked set of credentials, APIs, services and permissions that allows an automated system or AI agent to operate. If any part of that chain is overbroad or hidden, compromise can propagate quickly because the surrounding controls assume the chain is trustworthy.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps identity and security practitioners translate lifecycle control into durable programme practice.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org