TL;DR: Manual certificate management in Kubernetes creates renewal risk, operational drag, and authentication gaps, while ACME plus cert-manager automates issuance and renewal for cluster workloads according to GlobalSign. The governance issue is not whether automation is useful, but whether teams can prove lifecycle control over the secrets and workload identities behind it.
At a glance
What this is: GlobalSign describes how ACME and cert-manager automate Kubernetes certificate issuance and renewal, while exposing the governance burden around workload identities and Kubernetes Secrets.
Why it matters: This matters because Kubernetes teams can remove renewal toil without removing the need to inventory, scope, and govern the non-human identities and secrets that certificates represent.
Context
Kubernetes certificate automation is a control problem, not just an operations problem. When clusters scale quickly, manual certificate handling becomes brittle because renewal timing, secret placement, and service authentication all depend on human process staying ahead of machine pace.
In this case, the identity angle is real: certificates, Secrets, issuers, and workload authentication are all part of the trust chain. Automation can improve reliability, but it also makes it easier to lose sight of who or what holds authority in the cluster unless lifecycle governance is explicit.
Key questions
Q: What breaks when Kubernetes certificate automation is not tied to ownership?
A: Renewal can still succeed while the wrong workloads, namespaces, or service accounts keep valid trust material. That creates lifecycle drift, where certificates outlive the operational need for access. The result is not just expiry risk but ambiguous accountability for revocation, audit, and offboarding.
Q: Why do workload certificates create NHI governance risk in Kubernetes?
A: Because the certificate is acting as a non-human identity credential, not just a transport-security artifact. If its issuance, storage, and revocation are not tied to an owned workload, the certificate can outlive the service it was meant to protect. That creates persistent trust without clear accountability.
Q: How do teams know whether certificate automation is actually working?
A: Look for fewer human-mediated renewals, cleaner ownership records, lower expiry-driven outage rates, and reliable reporting across hybrid systems. If certificate work still depends on spreadsheets, ad hoc tickets, or last-minute interventions, the automation layer has not replaced the underlying operational risk.
Q: Should security teams treat Kubernetes Secrets as identity assets?
A: Yes. In this context, the Secret is the runtime container for a workload credential, so it belongs in identity governance as well as platform operations. If teams manage Secrets only as infrastructure objects, they miss ownership, revocation, and offboarding obligations that determine whether the workload can still be trusted.
Technical breakdown
ACME certificate automation in Kubernetes
ACME automates the certificate lifecycle by letting a client request issuance, complete a challenge, and renew before expiry without a human re-issuing the certificate each time. In Kubernetes, cert-manager acts as the controller that watches resources such as Issuer, ClusterIssuer, and Certificate, then creates or refreshes the certificate Secret that workloads consume. That removes a common source of outage risk, but it also centralises trust in the automation path. The security question becomes whether the automation actor is correctly scoped, whether the challenge method is appropriate, and whether renewal events are observable in operations.
Practical implication: Treat ACME automation as a governed control path and review who can create issuers, certificates, and secrets.
Workload identity and Kubernetes Secrets
A certificate in Kubernetes is not just a file. It is evidence of a workload identity that can authenticate to other services, gateways, or the API server, and it is usually stored in a Secret that becomes part of the cluster trust boundary. If that Secret is overexposed, reused, or copied into the wrong namespace, automation can scale the blast radius just as efficiently as it scales delivery. This is why certificate automation has an NHI dimension: the service account, workload, or application presenting the certificate is a non-human identity with governed access obligations.
Practical implication: Map each certificate-backed workload to an owned identity, a namespace boundary, and a clear revocation path.
Why renewal automation can hide governance gaps
Automation reduces expiry failures, but it does not prove that the right certificate is attached to the right workload, or that old identities were removed after redeployment. In fast-moving clusters, expired certificates are only one failure mode; stale Secrets, duplicate certificates, and orphaned issuers are equally important because they leave dormant trust material behind. The result is a governance gap where the infrastructure appears healthy while the underlying identity estate keeps growing. For NHI programmes, that is the key lesson: automation must be paired with inventory, ownership, and offboarding controls.
Practical implication: Build certificate inventory and offboarding checks into cluster governance so renewal automation does not leave stale trust behind.
Threat narrative
Attacker objective: The objective is to exploit or retain non-human trust material so a workload identity can be impersonated, reused, or left ungoverned inside the cluster.
- Entry occurs through the normal Kubernetes certificate issuance path, where cert-manager requests a certificate and stores it as a Secret for workload use.
- Credential access follows if the Secret, certificate, or issuer configuration is exposed beyond its intended namespace or reused by an unintended workload.
- Impact is operational and governance-related: the cluster can retain stale or mis-scoped trust material that keeps authenticating workloads after ownership has changed.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
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 automation is now a workload identity governance issue. In Kubernetes, the certificate lifecycle is inseparable from the identity of the service that presents it. Once issuance and renewal are automated, the operational question shifts from whether certificates expire on time to whether every certificate-backed workload has an owned identity, bounded scope, and revocation path. Practitioners should treat certificate automation as part of NHI governance, not a sidecar to infrastructure operations.
Secret visibility is the real control boundary. cert-manager may automate the mechanics, but the Secret that stores the certificate remains the object that extends trust into runtime. If Secrets are copied, reused, or left orphaned after workload changes, the organisation has automated credential distribution without automating credential governance. The practical conclusion is that inventory and offboarding matter as much as issuance.
Automation reduces expiry risk but can increase governance debt. Teams often measure success by fewer certificate outages, yet that misses the deeper failure mode: hidden accumulation of stale issuers, duplicated certificates, and unowned workload identities. This is a classic case where operational resilience improves while governance observability degrades. Practitioner teams should measure trust material by ownership and lifecycle state, not just renewal success.
Named concept: certificate lifecycle drift. This is the gap between successful automated renewal and actual control over where a certificate lives, who uses it, and when it should be retired. In Kubernetes, drift appears when the issuance process is healthy but the identity estate is not reconciled. That makes certificate automation a governance capability only when paired with continuous inventory and enforced offboarding.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
- Read next: Kubernetes NHI Security Guide
What this signals
Certificate lifecycle drift: automated renewal can hide the more important question of whether a workload credential is still needed, still owned, and still limited to the right namespace. For Kubernetes teams, the control gap is not expiry but lifecycle reconciliation, which is where identity governance has to meet platform operations.
Where Kubernetes runs at scale, certificate automation should be measured by the quality of the identity inventory it produces. If owners cannot map certificates back to workloads and secrets back to their consumers, automation is reducing toil while increasing untracked trust.
Teams should expect certificate automation to broaden the scope of NHI governance rather than shrink it. The more issuance is automated, the more important it becomes to enforce offboarding, revocation, and namespace-level separation of trust material.
For practitioners
- Define certificate ownership for every workload Assign each certificate to a named workload owner, namespace, and renewal authority so the identity behind the Secret is always accountable.
- Inventory Kubernetes Secrets that carry trust Track every Secret created through cert-manager, including issuer source, workload consumer, and expiry date, so stale trust material is visible.
- Separate issuance from consumption privileges Restrict who can create Issuer and ClusterIssuer objects, and limit which workloads can read the resulting certificate Secrets.
- Add offboarding checks for retired workloads Revoke and remove certificates, Secrets, and issuer references when a workload is decommissioned or redeployed under a new identity.
Key takeaways
- Kubernetes certificate automation removes manual renewal work, but it does not remove the need to govern workload identities and the Secrets that hold them.
- The main risk is lifecycle drift, where certificates renew successfully while ownership, scope, and revocation controls fall behind.
- Teams should measure certificate automation by inventory, accountability, and offboarding quality, not just by whether renewals complete on time.
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 and MITRE ATT&CK address the attack and risk surface, while CSA Cloud Controls Matrix sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on certificate Secrets that store workload trust material in Kubernetes. |
| NHI-05 — Overprivileged NHI | Automated certificate workflows can grant workload credentials broader use than intended. | |
| NHI-07 — Long-Lived Secrets | Renewal automation can leave certificates and Secrets alive well beyond operational need. | |
| Recommendation — Scan certificate Secrets for exposure and revoke any leaked trust material immediately. Limit certificate-backed workload access to the smallest namespace and service scope possible. Rotate and retire certificate-backed credentials on a defined lifecycle rather than letting them persist. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Kubernetes certificate automation governs non-human access and trust in a cloud runtime. |
| Recommendation — Map certificate issuance and revocation into cloud IAM governance for workload identities. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed certificates and Secrets can enable credential abuse and movement across workloads. |
| Recommendation — Hunt for exposed certificate Secrets as potential credential-access and lateral-movement paths. | ||
Key terms
- Certificate Lifecycle Drift: Certificate lifecycle drift is the gap between a certificate's current validity and the organisation's ability to renew or replace it reliably before expiry. It usually appears when ownership, monitoring, or renewal testing is incomplete.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
- Kubernetes Secret: A Kubernetes Secret is an object used to store sensitive data such as passwords, tokens, certificates, and API keys outside application code. It simplifies delivery to Pods, but it does not automatically protect the data. Security depends on storage encryption, access control, and monitoring of how the secret is used.
- 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.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners turn identity control principles into operational practice across modern environments.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org