It should be shared, with PKI setting policy and automation standards while workload owners retain service accountability. Certificates support machine identities embedded in applications and infrastructure, so renewal cannot remain a central team’s isolated task. The best model combines central governance with local ownership of service impact.
How certificate governance should be split between central policy and local ownership
certificate governance works best as a shared operating model, not a handoff. PKI teams should own policy, trust hierarchy, issuance standards, renewal automation patterns, and certificate inventory rules, while workload owners own the service impact, dependency mapping, and remediation when renewal fails. That split keeps the control plane consistent without divorcing certificates from the systems that actually break when they expire.
That model matters because certificates are not just security artifacts, they are operational dependencies embedded in applications, APIs, service meshes, and infrastructure. A central team can define the rules, but the workload owner is usually the only party that can judge blast radius, maintenance windows, and whether a renewal path is safe for a particular service.
For workload identity patterns, the governance split is even clearer: the certificate may be centrally governed, but the service that presents it is locally accountable for uptime and correct integration. Guidance on workload identity and trust bundles reinforces that certificates often function as SPIFFE workload identity material rather than a generic security asset, so the owner of the workload must remain part of the control loop.
Why renewal and lifecycle cannot live only inside a PKI team
Centralised PKI control is necessary, but it is not sufficient. Renewal failures are rarely just certificate events; they are service events. If the certificate is tied to deployment pipelines, load balancers, sidecars, client authentication, or mutual TLS, the team that owns the application or platform usually controls the dependencies needed to rotate safely.
A useful way to think about this is that PKI teams own the rules for issuing and renewing, while workload owners own the operational readiness of each certificate-bearing service. That includes knowing which endpoints consume the certificate, what breaks when a chain changes, and whether automation can be trusted without a rollback path. The Machine Identity, PKI and Certificate Lifecycle Guide is a good fit for this division because it treats certificates as part of machine identity lifecycle, not a one-time setup task.
In practice, this means central teams should publish standards for key protection, certificate templates, cryptoperiods, renewal thresholds, and approved automation methods, while workload owners should maintain service-specific runbooks and validate that renewal does not change authentication behavior, hostname matching, or client trust assumptions. The most common mistake is assuming that “automated renewal” removes the need for ownership, when it actually increases the need for clear accountability.
What good certificate governance looks like in practice
Good governance has a few observable traits. There is a single policy source for issuance and renewal standards, but there are named owners for each service or certificate chain. There is a shared inventory that shows where certificates are used, who depends on them, and when they expire. Renewal is automated where stable, but exceptions are tracked where application behavior or platform constraints require manual control.
For identity-bearing material such as certificates, the key question is not who administers the PKI tool, but who is accountable when the certificate affects a production service. The better operating model is one where PKI sets the control framework and workload owners are responsible for timely adoption. That aligns with the broader NHI ownership model described in NHI Ownership and Accountability Guide and the lifecycle focus in Ultimate Guide to NHIs.
One practical test is whether the organisation can answer three questions quickly: which workload owns the certificate, which automation path renews it, and which team will notice first if renewal fails. If any of those answers are vague, governance is too centralised in policy and too weak in operations.
Risk and Threat Considerations
When certificate governance is owned only by a central team, the main risk is silent service failure. Expiry, broken automation, or an unexpected trust-chain change can take down a workload even when the PKI process itself is technically sound. The threat side is also real: poorly governed certificates and long-lived private keys create attractive abuse paths for impersonation and persistent access.
Failure mechanism: Renewal deadlines, key custody, and service dependencies become disconnected, so a valid policy exists but the live workload still fails or exposes trust material.
Impact: The result can be authentication outages, broken service-to-service trust, emergency manual changes, or credential abuse if a certificate or private key is exposed.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate lifecycle, renewal, and key handling map to authenticator management. |
| IA-9 — Service Identification and Authentication | Certificates often authenticate services and workloads rather than people. | |
| AC-6 — Least Privilege | Shared certificate governance needs bounded administrative access and delegated ownership. | |
| Recommendation — Manage certificate issuance, rotation, and retirement under IA-5. Use IA-9 to govern service certificate authentication and trust. Limit certificate administration and renewal rights to the minimum necessary roles. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Certificate governance defines who may issue, renew, and use trust material. |
| A.8.24 — Use of cryptography | Certificates are cryptographic trust objects whose lifecycle must be governed. | |
| Recommendation — Define and enforce certificate access and ownership rules in policy. Control certificate issuance, protection, and cryptographic lifecycle handling. | ||
Practitioner Guidance
What to prioritise: Assign one accountable owner per certificate-bearing service, even when PKI centrally manages issuance. Ownership should follow the workload that would fail if the certificate expired or changed, not the team that created the policy.
What to verify: Confirm that each renewal path is tested in the same environment where the certificate is used, including reverse proxies, service meshes, load balancers, and client trust stores. If renewal has only been validated in a lab, treat production impact as unproven.
Decision rule: If a certificate protects a shared platform or platform-managed service, PKI can own the standard and automation; if it protects a business service with service-specific dependencies, the workload owner must own execution and rollback readiness.
Practitioner takeaway: Central teams should govern the certificate system, but only workload owners can truly govern the service risk created when that certificate changes or expires.
Related resources from NHI Mgmt Group
- How should security teams use IAST and RASP in NHI governance?
- What should IAM teams learn from PKI and certificate governance?
- Who is accountable for PKI governance when certificate management is centralised across multiple teams?
- Who should own certificate and digital identity governance when PKI spans security, operations, and development teams?
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 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org