Ownership should sit with the team accountable for the service or domain, with identity, infrastructure, and security all sharing lifecycle controls. The key requirement is that every certificate has an owner, an expiry path, and a revocation process before service changes happen.
Who should own TLS certificates in an identity programme?
The practical answer is that certificate ownership belongs with the service or domain owner, because they are accountable for availability and change timing. Identity, infrastructure, and security should operate the controls around that owner, not replace them. A certificate without a named owner becomes a hidden dependency, which is how expiry, revocation, and rotation failures turn into outages.
What ownership needs to cover beyond “who requested the certificate”
Ownership is not the same as procurement or initial issuance. The owner must be able to answer three operational questions: where the certificate is used, when it must be renewed or replaced, and who can revoke it if the service changes or is compromised. That responsibility sits naturally with the team that runs the service, while platform teams provide standards, inventory, automation, and guardrails.
In an identity programme, this matters because TLS certificates are identity-bearing material. They often support machine-to-machine trust, API access, internal service authentication, and external customer-facing traffic, so the certificate lifecycle becomes part of the broader identity control plane. The owner therefore needs enough authority to act before a maintenance window closes or a service dependency changes.
For machine identity and certificate lifecycle context, see Machine Identity, PKI and Certificate Lifecycle Guide and the broader Ultimate Guide to NHIs — What are Non-Human Identities.
How ownership should be split across service, infrastructure, and security teams
The cleanest model is shared control with single accountability. The service owner owns business continuity and approves the certificate for the application or domain. Infrastructure or platform teams typically own the issuance tooling, certificate inventory, renewal automation, and deployment mechanics. Security sets policy for key protection, acceptable cryptography, revocation expectations, and exception handling.
This split avoids the common failure mode where a central team assumes it owns every certificate but has no visibility into service changes, or where a service team assumes a platform team will notice expiry in time. The certificate owner should be the person or team closest to the dependency, while the control owners keep the programme consistent across environments. That is why an identity programme should define RACI-style ownership for certificates, not just technical standards.
Teams building the operating model can use the Identity Security Programme Guide to structure accountability, and the NHI Lifecycle Management Guide to connect ownership to provisioning, rotation, and offboarding.
What good certificate ownership looks like in practice
Good ownership is visible, testable, and tied to change management. Every certificate should map to a named owner, a service record, an expiry date, a renewal path, and a revocation procedure. The owner should know whether the certificate is public, private, internal, or embedded in a device or workload, because those categories determine who can replace it and how quickly.
Good ownership also means the certificate is reviewed before service changes, not after them. If a system is being decomposed, migrated, or replatformed, certificate replacement should be part of the change plan. If ownership cannot be established, treat the certificate as an orphaned dependency and escalate until the business service owner is identified.
Teams that need a certificate-specific operating model can anchor it in Ultimate Guide to NHIs — Standards and Top 10 NHI Issues, both of which reinforce lifecycle and ownership discipline.
Risk and Threat Considerations
When TLS certificates lack clear ownership, expiry and revocation become operational blind spots. The immediate risk is service outage from an unrenewed certificate, but the deeper risk is that nobody can quickly assess exposure when a private key is replaced, a service is retired, or a certificate is suspected of misuse.
Failure mechanism: responsibility is split across teams without a single accountable owner, so renewal tasks slip, revocation requests stall, and certificate changes fail to keep pace with service changes or incident response.
Impact: attackers and accidental misconfiguration both benefit from the same weakness, because stale certificates, delayed rotation, and missing revocation create avoidable trust and availability exposure.
Certificate governance also has a real external baseline. Publicly trusted issuance and revocation expectations are shaped by CA/Browser Forum requirements, and key lifecycle decisions are covered by NIST SP 800-57 Key Management.
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-53 Rev 5, NIST SP 800-57 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | TLS certificates need lifecycle control, renewal, and revocation management. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Service and workload certificates authenticate non-human systems. | |
| AC-6 — Least Privilege | Certificate handling should be limited to the teams that truly need control. | |
| Recommendation — Control certificate lifecycle, rotation, and revocation under IA-5. Apply IA-9 to authenticated service identities using TLS certificates. Restrict certificate administration to the minimum required operators. | ||
| NIST SP 800-57 | Key Management Lifecycle | TLS certificates depend on key lifecycle, renewal, and revocation discipline. |
| Recommendation — Define cryptoperiods, renewal triggers, and revocation handling for certificate keys. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate ownership needs named accountability and lifecycle visibility. |
| Recommendation — Assign accountable owners and keep certificate records current. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Certificate ownership and revocation support controlled access to services. |
| Recommendation — Define access and ownership rules for certificate administration. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | TLS certificates can become long-lived identity material when lifecycle is unmanaged. |
| NHI-05 — Overprivileged NHI | Certificate owners should not have broader privilege than needed to manage them. | |
| Recommendation — Shorten certificate lifetimes and automate renewal before expiry. Limit certificate administration to the minimum necessary scope. | ||
Practitioner Guidance
What to prioritise: assign every certificate to the owner of the protected service or domain, then record the backup approver for renewal and revocation. If you cannot name the operational owner in one step, the certificate is already a governance problem.
What to verify: confirm that each certificate has a living inventory record, an expiry alert path, and a tested revocation process that still works during incident response and planned change. A control is weak if it exists only in documentation.
Common mistake: treating certificate management as a pure platform task. Platform teams should automate and standardise the lifecycle, but the service owner must remain accountable for whether the certificate still matches the system it protects.
Practitioner takeaway: ownership should follow operational accountability, because the team that can explain and change the service is usually the only team that can manage certificate lifecycle risk at the right speed.
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