Accountability sits with the organisation that owns the identity governance programme, not with the fact that a system is old or hard to integrate. Auditors generally expect access reviews and revocation controls to cover critical systems, including on-prem and database-backed applications. If those controls are incomplete, governance and compliance owners must be able to explain the gap and remediate it.
Why This Matters for Security Teams
Incomplete access reviews and deprovisioning across hybrid systems create a governance gap, not a technical excuse. When service accounts, API keys, and database credentials remain active after ownership changes or role exits, accountability stays with the organisation that runs the identity governance programme. That expectation aligns with the OWASP Non-Human Identity Top 10 and with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, which both expect review and revocation to be operational, not aspirational.
NHI Management Group has found that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows why hybrid estates often drift out of compliance. The practical problem is that old platforms, database-backed applications, and on-prem integrations rarely fail loudly when governance breaks down. In practice, many security teams discover stale access only after an audit sample, an incident, or a privileged access review exposes gaps that should have been closed earlier.
How It Works in Practice
Accountability should be assigned to the identity governance, IAM, or compliance owner who controls the review process end to end, even when another team owns the legacy system. The control question is not whether a platform can automate perfectly, but whether the organisation can prove that access was reviewed, exceptions were approved, and deprovisioning was completed for in-scope identities. That is true for humans and for NHI assets such as service accounts, workload credentials, and API keys.
Hybrid environments usually need three layers of evidence:
- an authoritative inventory of identities and entitlements, including on-prem, cloud, and database accounts;
- documented review cadence with named reviewers and exception handling;
- revocation records showing what was removed, when, and by whom.
Where direct automation is not possible, the control should shift to compensating measures such as tighter approval workflows, sampled attestations, or connector-based exports from the legacy platform. The Ultimate Guide to NHIs notes that visibility and lifecycle management are inseparable, and the NHI Lifecycle Management Guide reinforces that offboarding must include credential revocation, not just account status changes. If reviewers sign off without verifying downstream access removal, the organisation has only completed paperwork, not deprovisioning. These controls tend to break down in heavily customised mainframe, database, and vendor-hosted legacy environments because entitlement data is fragmented and revocation often requires manual coordination.
Common Variations and Edge Cases
Tighter deprovisioning often increases operational overhead, requiring organisations to balance auditability against the friction of legacy integration. Best practice is evolving, but current guidance suggests the accountable owner does not change simply because a system is difficult to integrate or has no modern API. Instead, the organisation should document compensating controls, assign explicit exception owners, and track remediation dates so the gap cannot linger indefinitely.
Edge cases usually appear in three places: acquired businesses with separate IAM stacks, databases with shared technical accounts, and vendor-managed systems where the customer lacks direct revocation tooling. In those cases, accountability still remains internal, although execution may depend on another party. The reviewer must know whether access is truly removed, not merely disabled in one directory while remaining active in a local system. The risk is especially high when secret sprawl exists, because stale credentials can survive account removal.
The strongest programmes pair governance with lifecycle evidence and use a recurring challenge from incidents such as the 52 NHI Breaches Analysis to test whether reviews and revocation are actually working across the full hybrid estate. In practice, organisations usually learn this only after an audit exception or incident reveals that a “reviewed” account was still active somewhere else.
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, NIST SP 800-53 Rev 5 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 | Identity inventory and ownership are foundational when reviews miss hybrid accounts. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and reviewed across systems. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management covers provisioning, review, and deactivation obligations. |
| NIST AI RMF | Hybrid identity failures are a governance and accountability risk. |
Define accountable owners, escalation paths, and evidence requirements for identity governance gaps.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- When do NHI access reviews create more value than a one-time cleanup?
- How should security teams run SOX access reviews across multiple in-scope systems?
- Who is accountable for access reviews when users exist in multiple identity systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
