Accountability should sit with the system or application owner first, then with the identity governance process that allowed the gap to persist. If the account is unowned, the organisation has an offboarding or provisioning problem as well as a review problem. The review should trigger remediation, not just a sign-off, because no one can responsibly certify unknown ownership.
Why This Matters for Security Teams
When a user access review finds unowned or excessive access, the issue is not just a review failure. It is evidence that identity governance, application ownership, and lifecycle controls are misaligned. For non-human identities, that gap is especially dangerous because service accounts, API keys, and tokens often outlive the people who created them. NHI Management Group notes that only 20% of organisations have formal offboarding and key revocation processes, and 97% of NHIs carry excessive privileges, which means unresolved access is usually systemic, not isolated.
Accountability matters because access review are meant to confirm business ownership and validate necessity, not merely collect approvals. If no owner can explain why access exists, the organisation cannot prove least privilege or timely revocation. This is exactly the kind of failure model highlighted in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10, both of which treat ownership and lifecycle control as foundational to governance.
In practice, many security teams discover the real problem only after an audit, incident, or application retirement has already exposed that nobody can vouch for the access in question.
How It Works in Practice
The first accountable party should be the system or application owner, because that role should answer whether the access is still required, who depends on it, and what business function it supports. If the account is unowned, the review should escalate immediately to the identity governance process and to the service owner registry or CMDB equivalent. The review outcome should trigger a remediation workflow, not a passive certification record.
For human accounts, that means checking manager assignment, role necessity, and employment status. For NHI access, the same logic is not enough. Identity teams need ownership metadata, purpose tags, expiration dates, and a revocation path tied to NHI Lifecycle Management Guide practices. The workflow should ask:
- Who requested the access originally?
- Who currently owns the application or service?
- Is the privilege still required for production function?
- Can the account be reduced, time-bound, or revoked now?
This is where ownership discipline and inventory discipline converge. If the organisation cannot identify the owner, it should treat the access as a control gap, not as an acceptable exception. The same pattern is visible in the 52 NHI Breaches Analysis, where untracked identities and stale privileges repeatedly show up as root causes of larger incidents.
Operationally, the best practice is to route unresolved access to a remediation queue with a time limit, required approver, and evidence of either business justification or removal. These controls tend to break down in legacy environments where application ownership is undocumented and shared accounts are embedded in scripts, CI/CD jobs, or infrastructure-as-code pipelines.
Common Variations and Edge Cases
Tighter review controls often increase operational overhead, requiring organisations to balance faster sign-off cycles against stronger evidence and escalation. That tradeoff becomes sharper when access is inherited, shared across teams, or tied to an outsourced service.
Current guidance suggests three common exceptions deserve special handling. First, shared admin or break-glass access should never be approved through the same path as routine access, because the approval logic is different. Second, contractor and vendor access needs a named business sponsor, since “temporary” access often becomes persistent. Third, orphaned NHIs created by automation or application teams should be treated as lifecycle failures, not as ownership ambiguities.
There is no universal standard for this yet, but mature programs separate attestation from remediation. A reviewer can confirm that access is visible; only the owner can confirm that access is justified. If neither party can do that, the correct action is removal or containment. That principle aligns with the governance emphasis in the Ultimate Guide to NHIs — Key Challenges and Risks and the identity lifecycle discipline implied by OWASP.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unowned access is an ownership and lifecycle failure for NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Excessive access indicates weak access authorization and review controls. |
| NIST AI RMF | Accountability and governance are core to managing identity risk outcomes. |
Tie access approvals to least privilege and force remediation for unjustified entitlements.
