Who should be accountable for revoked or expired keys in PKI programmes?

Why This Matters for Security Teams

Revoked or expired keys are not just housekeeping issues. They are trust decisions with direct security impact, especially when keys support service-to-service authentication, signing, automation, or privileged workflows. If ownership is vague, the organisation can end up with credentials that technically should not work but are still accepted by dependent systems, backup processes, or cached trust stores. That creates a control gap between policy and enforcement.

Accountability matters because PKI is a lifecycle discipline, not a one-time issuance event. The team that approves, tracks, renews, revokes, and proves removal is the team that can actually prevent trust from lingering. This aligns with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects organisations to assign responsibility, manage system components, and maintain auditability. The risk becomes sharper in environments where keys are embedded in CI/CD, containers, hardware modules, or Non-Human Identity estates, because revocation can be administratively complete while operationally incomplete.

In practice, many security teams discover expired or revoked key exposure only after a dependency failure, a certificate incident, or an audit finding, rather than through intentional lifecycle monitoring.

How It Works in Practice

Effective accountability starts with a named key owner and a named operational custodian. The owner is responsible for business need, approval, and retirement timing. The custodian, often a platform, identity, or PKI operations team, is responsible for executing renewal, rotation, revocation, and evidence capture. Security governance then verifies that the control exists and works. This split is useful because storage alone does not equal control, and control alone does not equal accountability.

For high-value environments, the key lifecycle should be documented across issuance, distribution, use, expiry, revocation, and destruction. Each stage needs a system of record, a review cadence, and an exception path. Where keys support automated workloads, NHI governance becomes important because the same lifecycle rules that apply to human credentials also apply to service identities, workload certificates, and signing keys. The OWASP Non-Human Identity Top 10 is useful here because it highlights the operational risks that emerge when machine identities are not governed with the same discipline as human access.

Practically, teams should implement:

• Clear RACI assignment for issuance, renewal, revocation, and emergency withdrawal.
• Automated expiry alerts and revocation workflows tied to ticketing or orchestration.
• Periodic reconciliation between active trust stores and the authoritative PKI inventory.
• Audit evidence showing when a key was revoked, where trust was removed, and who approved it.
• Escalation rules for stale certificates, orphaned keys, and failed renewal attempts.

Current guidance suggests that accountability should be traceable across both the policy owner and the operator, because either role alone is insufficient when certificates are replicated across clouds, pipelines, or embedded device fleets. These controls tend to break down when keys are distributed into unmanaged endpoints, offline appliances, or third-party environments because removal cannot be verified centrally.

Common Variations and Edge Cases

Tighter pki governance often increases operational overhead, requiring organisations to balance rapid automation against proof that trust was actually removed. That tradeoff is most visible in high-availability services, where aggressive revocation can interrupt dependent systems if inventories, caches, or clients are not refreshed in time.

There is no universal standard for every exception scenario, but best practice is evolving toward explicit exception handling for break-glass keys, long-lived device certificates, and cross-organisational trust chains. In those cases, the accountable team should still own the expiry decision, even if a separate infrastructure team executes the technical removal. The key point is that accountability must remain with the party that can answer: why did this key exist, when should it have been removed, and what evidence proves removal?

Where PKI is tied to agentic automation or workload identity, the accountability model should extend beyond certificate storage to the business service that depends on the key. That is the only practical way to avoid orphaned trust in ephemeral environments, especially when keys are issued at scale and consumed by tools that no human checks daily.

Operationally, the model becomes weakest when ownership is split across multiple vendors, internal teams, and shadow renewal processes, because no single party can reliably confirm that revoked or expired keys are no longer trusted.

Related resources from NHI Mgmt Group

• Which teams are accountable for S/MIME governance when certificates span HR, PKI, and domain ownership?
• Why do healthcare DX programmes need both PKI and IAM governance?
• How should security teams govern API keys used for generative AI access?
• What problem does ownership attribution solve for service accounts and API keys?