Accountability typically sits with the identity, application, and business owners who approve, retain, or fail to revoke access. Governance frameworks also expect security teams to provide visibility and evidence, but ownership cannot be delegated away. If no one can explain why access still exists, the control model has already failed.
Why This Matters for Security Teams
Excessive access is not just an entitlement hygiene issue. It is a governance failure that leaves no clear owner for risk, remediation, or audit evidence. When access remains in place after the business need has changed, security teams are usually asked to prove why it was never removed, while application and identity owners argue the approval was inherited. The control problem is larger for non-human identities, where Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, widening blast radius and complicating accountability.
The practical issue is that access reviews often document who signed off at one point in time, but not who owns the decision to keep access alive today. That gap matters because retention of access is an operational choice, not a static fact. OWASP’s OWASP Non-Human Identity Top 10 treats overprivilege and lifecycle failures as recurring identity risks, not one-time admin mistakes. In practice, many security teams encounter accountability only after a privilege review, incident, or audit finding forces someone to explain why access still exists.
How It Works in Practice
Accountability should follow the control that allowed access to persist. In a mature model, the business owner explains the need, the application owner validates technical necessity, the identity owner maintains the entitlement path, and the security team verifies evidence. Current guidance suggests that ownership should be explicit at each stage of the lifecycle: request, approval, provisioning, review, renewal, and revocation. That is the only way to avoid a shared-responsibility gap where everyone sees the risk but nobody is accountable for removal.
For human access, this often means tying entitlements to a named role owner and requiring recertification when the role changes. For machine access, the same logic applies, but the lifecycle must be tighter. NHI governance expects secrets, service accounts, API keys, and certificates to have an owner, a purpose, and an expiry path. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how long-lived credentials and excessive privileges compound exposure when revocation is delayed.
- Assign one accountable owner for each entitlement, not a committee with no decision authority.
- Record the business justification and the technical dependency that keep access active.
- Set review dates and revocation triggers at provisioning time, not after drift appears.
- Require evidence of continued need before renewal, especially for privileged and non-human access.
- Escalate unresolved access to the application or service owner, because retention without ownership is a policy failure.
This is consistent with NIST’s Zero Trust Architecture principles, where access decisions must remain continuously justifiable rather than assumed valid forever. These controls tend to break down in legacy applications with no clean ownership model because revocation depends on tribal knowledge instead of enforceable workflow.
Common Variations and Edge Cases
Tighter access ownership often increases administrative overhead, requiring organisations to balance faster delivery against stronger accountability. That tradeoff becomes especially visible when teams inherit old service accounts, contractor access, or application-managed credentials that no one wants to claim. Best practice is evolving, but there is no universal standard for how far shared ownership can extend before accountability becomes too diluted to be useful.
One common edge case is outsourced or platform-managed access. A vendor may administer the system, but the enterprise still owns the risk of excessive access inside its environment. Another is emergency or break-glass access, where temporary overprivilege is acceptable only if the approval, time limit, and post-use review are enforced. The same is true for automated workflows that need persistent access to run, but should still be bounded by purpose and expiry. Where organisations fail is not usually in granting access, but in letting exceptions become permanent without a named approver.
For that reason, security teams should treat “who is accountable?” as a lifecycle question, not an incident question. If an entitlement cannot be tied to a current owner, a current justification, and a current revocation path, the organisation has already lost control of it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Excessive NHI access is a core overprivilege and lifecycle risk. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be reviewed and adjusted to current need. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous justification for every access decision. |
Keep entitlements under periodic review and revoke access when business justification no longer exists.
