Who should own certificate risk when outages affect multiple teams?

Why This Matters for Security Teams

Certificate ownership is not just a housekeeping issue. When an expiry takes down authentication, APIs, or service-to-service traffic, the outage becomes a coordination failure between the team that can act on the certificate and the team that depends on the service. NHI Management Group research shows that certificate expiry is the leading cause of outages for 45% of organisations, and clear ownership is one of the few controls that prevents repeat incidents. That is why certificate risk should be treated as operational risk, not a narrow infrastructure task, as reflected in the Critical Gaps in Machine Identity Management report and the NIST Cybersecurity Framework 2.0.

Security teams often get this wrong by assigning ownership only to the platform team or only to the service owner. In practice, neither side has complete context on its own: one side sees the renewal mechanism, the other sees business impact. The gap is visible in machine identity programs that lack accurate inventories and clear accountability, a pattern also highlighted in the Top 10 NHI Issues. In practice, many security teams encounter certificate failure only after a renewal deadline has already become a production incident.

How It Works in Practice

Effective certificate risk ownership is shared, but not ambiguous. The operational team owns the renewal path, deployment mechanics, and emergency rotation. The service owner owns the dependency map, business criticality, and the decision to accept risk if automation fails. That split matters because certificate management usually spans infrastructure, application code, load balancers, ingress gateways, identity providers, and external integrations.

A workable operating model usually includes the following:

• A named certificate owner for every service, environment, and external dependency.
• An inventory that ties each certificate to a service owner, renewal date, issuer, and fallback path.
• Alerting at multiple thresholds so expiry is visible before the final window.
• Documented renewal runbooks that define who can rotate, who approves downtime risk, and who validates success.
• Escalation paths that cross team boundaries, especially for shared platforms and third-party dependencies.

This is also where workload identity discipline helps. If systems rely on long-lived static certificates without lifecycle tracking, risk accumulates quickly. Current guidance suggests pairing certificate ownership with automated discovery and renewal controls, then mapping those controls into the broader machine identity program described in the Critical Gaps in Machine Identity Management report and the identity context covered in Ultimate Guide to NHIs — What are Non-Human Identities.

From a governance standpoint, NIST CSF 2.0 pushes organisations toward explicit accountability and repeatable recovery, which aligns well with certificate ownership models that combine operational execution with service accountability. These controls tend to break down in highly federated environments where application teams, platform teams, and external vendors all touch the same certificate lifecycle because no single group owns the full renewal chain.

Common Variations and Edge Cases

Tighter ownership models often increase coordination overhead, requiring organisations to balance resilience against the administrative cost of mapping every dependency. That tradeoff becomes most visible in platform shared-services, multi-cloud estates, and vendor-managed certificates, where the party that can renew a certificate is not always the party that feels the outage first.

Best practice is evolving for these cases. Some organisations assign primary ownership to the service owner and delegated execution to the platform or SRE team. Others require joint ownership with a single incident commander during renewal windows. There is no universal standard for this yet, but the principle is consistent: the entity that can act and the entity that is accountable for the service outcome must both be named.

The edge cases that cause the most trouble are certificates embedded in legacy appliances, certificates issued by external partners, and certificates hidden inside automation pipelines. These situations often fail because expiry tracking is not integrated into the service catalog, so the outage lands before the right team even knows which certificate is at risk. That is why the operational answer should always be paired with inventory, escalation, and renewal evidence, not just a ticket assignment.

For broader context on why these ownership gaps matter, see the Ultimate Guide to NHIs — Why NHI Security Matters Now and the 2024 ESG Report: Managing Non-Human Identities.

Related resources from NHI Mgmt Group

• How should teams reduce the risk from overprivileged NHIs?
• How can teams reduce the risk of SAML certificate rotation outages?
• Why do DNS retirements create governance risk for IAM and platform teams?
• How should security teams govern DNS when it supports authentication and certificate services?