cert-manager handles in-cluster issuance and renewal for Kubernetes-native resources. Enterprise certificate governance is broader, covering trust policy, ownership, inventory, auditability, and certificates that live outside one cluster. Teams need both layers. Automation keeps certificates fresh inside Kubernetes, while governance provides the control model across clusters, clouds, and adjacent systems.
How cert-manager and enterprise certificate governance differ in scope
cert-manager is an in-cluster automation controller. It issues, renews, and manages certificates for Kubernetes-native resources, so teams can keep workloads supplied with valid certificates without hand-built renewal jobs. Enterprise certificate governance is the broader operating model around certificates: who owns them, where they are issued, which trust chains are allowed, how they are inventoried, and how exceptions are audited across platforms.
The practical difference is that cert-manager solves the lifecycle problem inside Kubernetes, while governance solves the policy and accountability problem across the estate. A certificate can be technically healthy in-cluster and still fail governance expectations if ownership is unclear, if it is issued from an unapproved CA, or if nobody can prove where else the same trust material is used.
That is why the two are complementary rather than competing. cert-manager reduces renewal toil and expiry risk for cluster workloads, but it does not by itself answer enterprise questions about trust standards, segregation of duties, evidence retention, or certificate sprawl outside the cluster boundary.
What enterprise certificate governance adds beyond automation
Enterprise governance extends the view from “is the certificate renewed?” to “is the certificate appropriate, approved, and attributable?” That means defining ownership, minimum key protection requirements, approved issuance sources, acceptable validity periods, inventory coverage, and audit trails that survive changes in platforms or teams. It also covers non-Kubernetes use cases such as internal services, edge systems, legacy applications, and externally facing endpoints.
In practice, governance is the control layer that lets certificate automation scale safely. Without it, automation can multiply inconsistent patterns, such as multiple CAs, duplicated certificates, long-lived keys, or unmanaged exceptions that nobody can reconcile later. With it, teams can separate operational automation from policy decisions and still keep a single view of trust posture.
For certificate-heavy environments, the strongest governance questions are usually about source of truth and lifecycle ownership. If a certificate is renewed automatically but not inventoried, or inventoried but not tied to a business owner, the organisation still has an exposure that automation alone cannot close.
Where the boundary becomes important in real environments
The boundary matters most when Kubernetes is only one part of the trust landscape. Machine Identity, PKI and Certificate Lifecycle Guide is relevant here because it frames certificates as a lifecycle problem, not just a deployment convenience, and that distinction becomes critical when certificates need consistent policy across multiple environments.
It also matters when certificates are used as machine identity or tied into service-to-service trust. Guide to SPIFFE and SPIRE helps illustrate the broader pattern: identity and trust need a system-level model, not just a local renewal mechanism. In Kubernetes, that often means linking workload identity, trust bundles, and certificate issuance to a governance process that can be explained outside the cluster.
When the scope includes vendor systems, externally managed PKI, or certificates embedded in applications, enterprise governance becomes the deciding layer. It gives security and platform teams a way to answer whether cert-manager is the right operational tool for one environment, while still enforcing enterprise-wide trust rules everywhere else.
Risk and Threat Considerations
The main risk is assuming automation equals governance. cert-manager can prevent avoidable expiry incidents, but it can also hide certificate sprawl if teams treat “automated renewal” as evidence that the certificate estate is under control. That creates blind spots around ownership, reuse, weak trust boundaries, and certificates that sit outside the Kubernetes control plane.
Failure mechanism: Renewal succeeds in-cluster while policy drift, unmanaged issuance paths, or missing inventory leaves other certificates uncontrolled, creating untracked trust relationships and inconsistent assurance.
Impact: Expired services, unapproved trust anchors, weak accountability, and harder incident response when a certificate or private key must be rotated, revoked, or explained during audit.
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 surface, NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | 1 — Key Management Planning | Certificate governance depends on lifecycle rules for cryptographic keys and certificates. |
| Recommendation — Define cryptoperiods, renewal, and destruction rules for certificate keys. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate renewal and rotation are authenticator lifecycle controls. |
| Recommendation — Manage certificate issuance, rotation, and revocation as tracked authenticators. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Certificate governance establishes approved trust and access boundaries. |
| Recommendation — Set and enforce certificate trust and access rules across systems. | ||
| CIS Controls v8 | 5 — Account Management | Certificate ownership and inventory are part of controlling identities and access paths. |
| Recommendation — Inventory and govern certificate-bearing accounts and service identities. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Certificate governance must ensure stale certificates are retired when ownership changes. |
| Recommendation — Revoke and retire certificates when the owning workload or service changes. | ||
Practitioner Guidance
What to prioritise: Treat cert-manager as the workload execution layer and governance as the ownership layer. Decide which certificates are Kubernetes-native, which are enterprise-managed, and which require exception handling before you standardise automation.
What to verify: Confirm that every automated certificate has an owner, an approved issuance path, a known trust anchor, and an inventory record outside the cluster. If you cannot produce those four items, the control is operationally incomplete even if renewals are working.
Common mistake: Teams often roll out cert-manager and stop there. That is enough for renewal hygiene, but not enough for policy, auditability, or trust consistency across clusters, clouds, and adjacent systems.
Practitioner takeaway: Use automation to keep certificates alive, but use governance to keep them trustworthy, attributable, and measurable across the whole estate.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
