Who should be accountable for certificate trust decisions across identity programmes?

Accountability should sit with the teams that own the identity being protected, which may be IAM for people, NHI teams for workloads and services, or infrastructure teams for device trust. Security, platform, and identity functions should share policy oversight, but one team must own lifecycle decisions end to end.

Why This Matters for Security Teams

Certificate trust decisions are not just a technical approval step. They determine which identities, services, and devices are allowed to be trusted across the enterprise, which makes them a core governance issue rather than a narrow PKI task. When accountability is vague, organisations end up with inconsistent trust anchors, duplicated controls, and gaps between identity, infrastructure, and security operations. NHI Mgmt Group notes that 59% of companies report greater difficulty auditing machine identities because of lack of clear ownership and limited visibility in The Critical Gaps in Machine Identity Management report.

This matters because certificate trust failures can silently expand access, break service authentication, or allow an attacker to impersonate a trusted workload for far longer than a password-based issue would persist. The practical question is not whether trust should be shared, but who owns the lifecycle decision to issue, approve, rotate, revoke, and retire trust. NIST Cybersecurity Framework 2.0 reinforces that governance and accountability must be explicit, measurable, and owned. In practice, many security teams discover certificate trust drift only after an outage, revocation failure, or impersonation incident has already exposed the gap.

How It Works in Practice

The cleanest operating model is to assign accountability to the team that owns the identity domain being trusted. For people certificates, IAM should own the policy and lifecycle decision because the trust question is tied to human identity proofing and access governance. For workloads, services, and API-driven systems, NHI teams should own certificate trust because the certificate is part of the workload identity, not just the transport layer. For devices, infrastructure or endpoint trust teams should own the decision because certificate issuance and revocation must align with device posture and asset lifecycle.

Shared oversight still matters. Security should define minimum trust requirements, platform teams should operate the infrastructure, and identity teams should enforce standards. But one team must be accountable for the full lifecycle so there is no ambiguity during issuance, renewal, revocation, or incident response.

• Define the trust domain first: person, workload, or device.
• Assign one accountable owner for lifecycle decisions, not just certificate storage.
• Separate policy oversight from operational execution.
• Record who can approve exceptions, emergency revocations, and root or intermediate CA changes.
• Review trust anchors and certificate boundaries on a fixed cadence.

For workload environments, the most defensible pattern is to pair certificate trust with workload identity controls, such as short-lived credentials, cryptographic identity, and continuous verification. That aligns with the broader NHI guidance in the Ultimate Guide to NHIs and with the NHI failure patterns shown in Top 10 NHI Issues. Current guidance suggests that trust decisions should be tied to ownership of the identity lifecycle, not to whichever team happens to manage the certificate server. These controls tend to break down in federated environments where multiple platforms share the same CA but no single team owns revocation authority.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger trust controls against delivery speed and platform autonomy. That tradeoff becomes sharper in hybrid and multi-cloud environments, where certificates may be issued by central PKI, cloud-native services, or application teams with different renewal models. Best practice is evolving here, and there is no universal standard for exactly where all trust decisions must sit.

In regulated or high-assurance environments, central security may need veto power over trust policies, especially for root CA management, cross-domain trust, and exception approval. In agile product environments, delegated operational control may be necessary, but it should still operate under centrally defined policy and audit requirements. For service meshes, Kubernetes, and agentic workloads, the trust owner may also need to coordinate with platform engineering because certificate lifecycle and workload identity are tightly coupled.

The practical test is simple: if a team cannot revoke trust quickly and prove why a certificate was trusted in the first place, that team does not truly own the decision. The current challenge is not issuing certificates, but knowing who can stand down trust before a compromised identity is reused.

Related resources from NHI Mgmt Group

• Who should own compliance decisions across identity and certificate programmes?
• How should security teams govern AI transformation across identity and access programmes?
• Who is accountable when identity provider trust is mis-scoped across applications?
• Who should be accountable for AI access decisions in identity programmes?