Who is accountable when a certificate is distrusted or revoked?

Why This Matters for Security Teams

Certificate distrust or revocation is not just a PKI event. It is an operational trust decision that can stop authentication, break service-to-service calls, and expose gaps in ownership. When a certificate anchors an automated workload, the blast radius often extends across application teams, identity operators, and platform teams at once. That is why accountability must be explicit before a trust-store change, not negotiated during an outage.

Machine identity failures are especially hard to contain because they sit in the gap between lifecycle management and production operations. NHIMG’s Critical Gaps in Machine Identity Management report found that only 38% of organisations have automated certificate lifecycle management in place, while certificate expiry is the leading cause of outages for 45% of organisations. In practice, many security teams encounter certificate distrust only after a service has already failed, rather than through intentional renewal, revocation, and fallback planning.

How It Works in Practice

Accountability should follow control over the certificate lifecycle, the trust store, and the workload that depends on the credential. The service owner usually owns business impact and application readiness. The identity or PKI team owns issuance policy, revocation decisions, and certificate hygiene. The platform operator owns distribution of trust anchors, deployment mechanics, and rollback paths. That division is consistent with the operational themes in the Ultimate Guide to NHIs and with the control expectations described in the OWASP Non-Human Identity Top 10.

In mature environments, the workflow is documented before the event:

• Define who can request revocation, who can approve it, and who can execute it.
• Map every certificate to a named service owner and a technical recovery contact.
• Maintain a tested fallback path, such as alternate trust anchors, staged rollout, or temporary pinning exceptions.
• Validate that monitoring detects both expiration risk and unexpected distrust changes.
• Record whether the certificate protects human access, service authentication, or an agentic workload, because the recovery pattern differs.

For automated systems, the key question is not only who approved revocation, but whether the workload can fail closed safely. Guidance from NHI lifecycle management also points to renewal authority and offboarding as distinct controls, because revocation without coordinated rollout can create a self-inflicted outage. Where possible, platform teams should align trust-store changes with policy-as-code and change windows, while PKI teams keep evidence of the decision path. These controls tend to break down when certificates are embedded in legacy appliances or hard-coded into CI/CD pipelines because the organisation cannot update trust quickly enough.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance fast trust response against service continuity. That tradeoff becomes sharper in environments with external partners, embedded devices, or long-lived workloads that cannot refresh trust automatically. Current guidance suggests documenting exception handling, but there is no universal standard for exactly how much grace period should be allowed after distrust.

Edge cases matter most when the certificate is used as a trust anchor rather than a simple transport layer credential. If the certificate supports mTLS for microservices, distrust can cascade across an entire service mesh. If it protects a third-party integration, accountability may include contract owners and vendor managers, not just internal teams. If it belongs to an autonomous agent or other NHI, the organisation should treat the certificate as a workload identity control and pair revocation with runtime validation and secret rotation. The NHI Lifecycle Management Guide and the Guide to the Secret Sprawl Challenge both reinforce the same point: unclear ownership is what turns a trust decision into a prolonged incident.

Related resources from NHI Mgmt Group

• Who should be accountable for registrar access, DNS changes, and certificate renewal?
• Who is accountable when temporary privilege is not revoked on time?
• Who should be accountable when certificate abuse leads to domain compromise?
• Who should be accountable when an agent makes a high-risk decision?