Who should own certificate risk in DevOps and workload identity programmes?

Why This Matters for Security Teams

Certificate risk is not just a platform hygiene issue. It sits at the intersection of workload ownership, renewal automation, revocation, and access policy, which means gaps often appear when responsibility is split between DevOps, platform engineering, and security. Machine identities are not passive config artifacts; they authenticate, authorize, and can be abused for lateral movement when lifecycle controls fail.

NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, a signal that ownership gaps quickly become exposure gaps. The operational lesson is simple: if no team is accountable for issuance, renewal, and revocation, certificates drift into shared infrastructure debt. Current guidance also aligns with the NIST Cybersecurity Framework 2.0, which treats identity and access as governable risk, not just technical plumbing.

In practice, many security teams encounter certificate expiry, stale trust chains, and orphaned workloads only after an outage or incident has already exposed the ownership problem.

How It Works in Practice

Ownership should follow the workload lifecycle, with the product, platform, or service team accountable for keeping the certificate valid and the identity or security function accountable for the policy that governs how it is issued, scoped, and revoked. That split works because the workload team knows when a service changes, while the security team defines the guardrails for trust, rotation, and minimum privilege.

In mature programmes, certificate risk is tracked the same way other production risk is tracked: inventory, expiry, revocation, blast radius, and exception handling. The best practice is evolving toward workload identity rather than static certificate handling alone, because a cryptographic identity is more defensible when it is bound to the workload and evaluated in context. The SPIFFE workload identity specification is a useful reference point here, since it formalises identities for software workloads rather than treating certificates as standalone secrets.

• Assign a named service owner for each workload certificate and its renewal schedule.
• Define policy ownership in security or identity engineering for issuance rules, TTL, and revocation criteria.
• Automate discovery so expired or orphaned certificates are visible before they fail in production.
• Use short-lived credentials where possible, and tie revocation to deployment and decommission workflows.

NHIMG’s Critical Gaps in Machine Identity Management report shows that only 38% of organisations have automated certificate lifecycle management in place, which explains why ownership breakdowns often become manual-fire-drill problems. These controls tend to break down in highly dynamic Kubernetes and multi-cloud environments because workloads change faster than inventories, and manual handoffs cannot keep pace.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance faster delivery against stronger control over trust material. That tradeoff becomes visible in ephemeral environments, service meshes, and platform teams that provision thousands of workloads per day, where rigid approval chains can slow releases and encourage shadow processes.

There is no universal standard for who must own every certificate event, but current guidance suggests a practical split: workload teams own operational continuity, while identity or security owns policy, standards, and exception review. In regulated environments, that split usually needs explicit audit evidence, especially where certificates support customer-facing services or third-party integrations. The Ultimate Guide to NHIs is clear that weak offboarding, poor rotation, and limited visibility are recurring causes of exposure, and those problems worsen when ownership is implicit rather than documented.

Edge cases include shared platform certificates, legacy appliances, and externally managed services. In those cases, best practice is to name a control owner even if the technical owner is a vendor or central platform team. The right question is not who can touch the certificate, but who is accountable when it expires, leaks, or is no longer trusted.

Related resources from NHI Mgmt Group

• Who should own machine identity and cryptographic readiness programmes?
• Who is accountable for certificate and key lifecycle failures in modern identity programmes?
• When does secret exposure become a broader identity risk?
• Why do short certificate lifecycles create more outage risk for identity programmes?