Who is accountable when regulated access stays open too long?

Accountability should sit with the control owner for the application and the identity governance function that defines the review and removal process. If access remains open beyond its purpose, the failure is usually shared between business ownership, IAM operations and the control framework that failed to force closure.

Why This Matters for Security Teams

When regulated access stays open too long, the issue is rarely just a missed checkbox. It usually means the control owner, the business approver and the IAM or identity governance function were not aligned on when access should end, who must confirm that end, and what evidence proves removal. That becomes a governance failure, not a simple workflow delay. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both reinforce that access must be bounded, reviewable and revocable.

For NHIs, the accountability question matters even more because service accounts, API keys and tokens can remain active long after the intended business purpose ends. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys in the Ultimate Guide to NHIs, which helps explain why stale access persists in production. In practice, many security teams discover open access only after a review, audit finding or incident response event has already exposed the gap.

How It Works in Practice

Accountability should be assigned at three layers. First, the application or business control owner owns the need for access and must confirm when the purpose is complete. Second, the identity governance function defines the review cadence, approval path and removal workflow. Third, IAM operations enforces the technical closure, including deprovisioning, token revocation, key rotation and evidence capture. If any one of those layers is vague, regulated access tends to linger.

For human access, the operational model is usually periodic access recertification. For NHIs, best practice is evolving toward shorter-lived credentials and more explicit lifecycle events. The Lifecycle Processes for Managing NHIs guidance is especially useful here because it frames access as something that should be created, used, reviewed and retired, not merely approved once. That aligns with broader zero trust thinking in NIST CSF 2.0, where least privilege and ongoing oversight are core expectations.

• Define a named control owner who is accountable for business need and access expiry.
• Set review intervals based on sensitivity, not convenience.
• Require evidence of removal, not just approval of continued access.
• Automate revocation for tokens, keys and service accounts where possible.
• Escalate missed reviews to the risk or control owner, not only to IAM operations.

NHI Mgmt Group’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which means stale access is often paired with overbroad permissions. These controls tend to break down when ownership is split across teams that each assume another team is responsible for closure.

Common Variations and Edge Cases

Tighter recertification often increases operational overhead, so organisations must balance compliance assurance against review fatigue and automation quality. That tradeoff is especially visible in shared service accounts, inherited entitlements and third-party integrations, where a simple “remove it” instruction can disrupt production if ownership and dependency mapping are weak.

There is no universal standard for every environment yet, but current guidance suggests more aggressive expiry for privileged NHIs and exception handling for long-lived integrations. In highly regulated environments, the accountable party may need to be documented in the control itself, not inferred from team structure. The Regulatory and Audit Perspectives section is useful for translating that requirement into audit evidence, while the Top 10 NHI Issues page highlights how weak lifecycle ownership becomes a recurring failure mode.

The hardest edge case is when access technically remains open but is no longer used. That still counts as unresolved exposure because a dormant credential can become the easiest path for misuse, lateral movement or audit failure if it is not explicitly retired.

Related resources from NHI Mgmt Group

• Who is accountable when third-party access stays active too long?
• Who is accountable when a third-party open banking integration misuses access?
• Who is accountable when privileged access is granted too broadly to partners or contractors?
• Who is accountable when third-party access to personal data persists too long?