It should be shared, because certificates are both operational dependencies and trust controls. Infrastructure teams usually own deployment and service continuity, while security teams care about inventory, policy and exception handling. The governance model matters most when ownership is explicit, because unclear accountability is where renewals and audits fail.
Why certificate governance belongs to both infrastructure and security
Certificate governance is not just an operations problem or just a control problem. Certificates keep services available, but they also prove trust, bind identities, and constrain who can talk to what. That means the right model is shared ownership: infrastructure teams manage deployment realities, while security teams define policy, exception handling, and oversight for risk-sensitive use.
The split only works when responsibilities are explicit. If infrastructure owns the runtime and security owns the rules, then renewals, revocations, and audit evidence have clear paths. If neither side owns the full lifecycle, certificates become one of the easiest places for drift, expired trust, and unapproved exceptions to accumulate.
For the operational side, certificate governance includes inventory, placement, renewal timing, chain trust, and service impact when a certificate changes. A certificate outage is often a service continuity issue first, which is why infrastructure teams usually need the tools and procedures to renew at scale. The machine identity and lifecycle view in the Machine Identity, PKI and Certificate Lifecycle Guide is useful here because governance fails fastest when lifecycle management is treated as an occasional administrative task rather than a continuously managed control.
For the security side, certificates are also trust material, so policy has to cover issuance standards, key protection, acceptable exceptions, and exposure review. That is where control over cryptographic lifecycle matters, especially for rotation, cryptoperiods, and the conditions under which certificates should be renewed or replaced. NIST SP 800-57 is the clearest anchor for that lifecycle thinking, while the CA/Browser Forum baseline requirements shape how publicly trusted certificates are issued and revoked in practice.
Shared governance also matters because certificates sit at the point where service availability and security assurance meet. Infrastructure may know the service owner and the deployment path, but security should know which certificates represent privileged trust, cross-environment access, or externally trusted endpoints. The governance model should therefore distinguish routine operational certificates from higher-risk certificates that deserve tighter policy, approval, and exception handling.
Where certificate ownership breaks down
The most common failure mode is ambiguity. Teams assume someone else is tracking expiry, someone else owns revocation, or someone else will notice a certificate embedded in an application, appliance, or automation workflow. The result is predictable: renewals happen late, emergency changes break services, and audits reveal certificates that are neither inventoried nor clearly owned.
A second failure mode is treating certificates as static assets instead of managed trust objects. Once that happens, teams accept long-lived certificates, weak exception processes, and manual renewal paths that do not scale. The governance question is less about which team “possesses” the certificate and more about which team can prove it is current, protected, and accountable.
Certificates also create hidden dependency risk because they often support service-to-service trust. When a certificate expires or is replaced without a coordinated rollout, the failure can cascade across systems that depend on it. For workload and service identity patterns, Guide to SPIFFE and SPIRE shows why trust bundles, attestation, and automated rotation reduce the governance burden compared with ad hoc certificate sprawl.
What a workable governance model looks like
A practical model assigns infrastructure teams operational ownership and security teams policy ownership, with a named business or service owner accountable for exceptions and risk acceptance. That structure avoids the two classic mistakes: centralising every decision so renewals slow down, or decentralising everything so no one can answer for risk.
Decision rule: If the certificate directly affects service uptime, platform teams should own implementation and renewal execution. If the certificate changes trust boundaries, external exposure, or exception status, security should approve the policy and review the risk.
What to verify: Every certificate should have a named owner, an expiry date, a renewal path, and a documented fallback if renewal fails. For higher-risk certificates, verify who can issue them, who can revoke them, and who is authorised to approve exceptions.
When governance is mature, the organisation can answer three questions quickly: what certificates exist, who owns each one, and what happens when one fails. That is the standard that keeps operational dependency from becoming unmanaged trust debt. Where public trust is involved, the CA/Browser Forum and the RFC 8705 mutual-TLS model are useful reference points for binding certificates to controlled client authentication rather than treating them as generic credentials.
Practitioner takeaway: Certificate governance should not be split by team boundaries alone; it should be split by control responsibility. Infrastructure should run the lifecycle, security should govern trust and exceptions, and both should be able to prove ownership before expiry or audit pressure exposes the gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Certificate governance depends on cryptographic key lifecycle and renewal discipline. |
| Recommendation — Apply key-lifecycle controls to set cryptoperiods, rotation rules, and retirement timing for certificate-backed keys. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates require lifecycle control over issuance, renewal, replacement, and revocation. |
| IA-9 — Identification and Authentication (Service and Device Users) | Certificate-backed service and device trust is central to machine and workload authentication. | |
| Recommendation — Manage certificates as authenticators with defined issuance, rotation, and revocation processes. Use service and device authentication controls to govern certificate-backed trust relationships. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Certificate governance needs clear rules for who may issue, approve, and override trust decisions. |
| A.8.24 — Use of cryptography | Certificates are cryptographic trust artefacts whose handling affects security and availability. | |
| Recommendation — Define access and approval boundaries for certificate issuance, renewal, and exception handling. Specify how certificates and related cryptographic material are protected, rotated, and retired. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org