Who is accountable when a user retains unauthorized access after a certification cycle?

Why This Matters for Security Teams

Unauthorized access that survives a certification cycle is not a paperwork issue, it is an access governance failure with real operational blast radius. A reviewer may mark access as acceptable, but if removal, downgrades, or compensating controls are not executed, the organisation still carries excess privilege. That gap is especially dangerous for non-human identities and service accounts, where hidden access can persist far longer than a human reviewer expects. The OWASP Non-Human Identity Top 10 frames this as a lifecycle and governance problem, not just a review problem.

NHIMG’s Ultimate Guide to NHIs and NHI Lifecycle Management Guide both stress that access decisions only matter if they are enforced through revocation, rotation, and evidence-backed follow through. For certification cycles, the accountable party is usually the control owner or application governance owner, because they own the process that should detect, approve, and remediate excess access. In practice, many security teams discover this only after an audit exception, a toxic entitlement review, or an incident exposes that “approved” access was never actually removed.

How It Works in Practice

Accountability should be traced through the full access review workflow: who defined the entitlement, who certified it, who executed the change, and who verified completion. A sound process separates recommendation from enforcement. The reviewer can attest to business need, but the certification owner, application owner, or IAM operations function must ensure the removal ticket closes, the system state changes, and the evidence is retained. This is where control mapping matters under NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement and auditability.

Operationally, mature programs build a closed loop:

• assign a named owner for each application, role, and entitlement set;
• require explicit remediation tasks for revoked or reduced access;
• verify completion against source systems, not just the certification record;
• escalate overdue removals to governance or risk owners;
• retain evidence that access was changed, not merely approved.

This is particularly important where secrets, API keys, and machine accounts are involved. NHIMG’s Guide to the Secret Sprawl Challenge shows how fragmented ownership makes stale access hard to find and even harder to remove. If the environment includes automated workloads, then the review process must also account for dynamic credentials and downstream trust relationships, because revoking one entitlement may leave related tokens or inherited access intact. These controls tend to break down when ownership is split across HR, IAM, app teams, and vendors because no single party is accountable for verifying the final state.

Common Variations and Edge Cases

Tighter access certification often increases coordination overhead, requiring organisations to balance audit confidence against operational speed. The answer also changes when the “user” is not a person but a service account, integration account, or AI-driven workload. In those cases, the certifier may not be the best remediation owner, because the technical change usually sits with platform or application operations. Current guidance suggests that accountability should follow control ownership, not just review participation, but there is no universal standard for this yet.

Two common edge cases create confusion. First, when the reviewer correctly identifies excess access but the application cannot immediately enforce removal, the governance owner still remains accountable for escalation and risk acceptance. Second, when access is inherited through groups or nested roles, the direct reviewer may not see the actual entitlement path, so ownership must include whoever can trace and modify the underlying assignment logic. NHIMG’s Top 10 NHI Issues is useful here because it highlights how lifecycle gaps and role ambiguity turn routine reviews into recurring exceptions. The practical rule is simple: if access survives the cycle, accountability sits with the process owner until the system state is corrected and verified.

Related resources from NHI Mgmt Group

• Who is accountable when API-driven access changes affect contracts, licences, or user permissions?
• Who is accountable when a compromised integration changes repository settings or adds unauthorized access?
• Who is accountable when unauthorized users gain access to sensitive data through weak authorization controls?
• Who is accountable when high-risk access is approved after a weak identity check?