IAM or IGA teams should own the control design, but managers and application owners should validate whether the entitlement still matches business need. That shared model is what makes access certification useful, because governance only works when technical ownership and business accountability both exist.
Why This Matters for Security Teams
Role reviews and entitlement cleanup fail when ownership is treated as a paperwork exercise instead of an operational control. IAM or IGA teams can run the process, but they cannot reliably judge whether a permission still supports the business task. That validation belongs with managers and application owners, because they understand current duties, project changes, and when access has quietly outlived its purpose.
This is especially important in NHI-heavy environments, where entitlement sprawl creates hidden risk faster than manual reviews can catch it. NHI Management Group notes in the Ultimate Guide to NHIs that only 20% of organisations have formal offboarding and revocation processes for API keys, and 97% of NHIs carry excessive privileges. That combination makes “who owns the review” a governance question with direct security impact, not an administrative detail. The NIST Cybersecurity Framework 2.0 reinforces that access governance must be tied to accountable decision-making, not just ticket closure.
In practice, many security teams discover stale access only after an audit finding or incident exposes that nobody felt responsible for removing it.
How It Works in Practice
The cleanest operating model splits control design from business validation. IAM or IGA teams define review cadence, evidence standards, and escalation paths. They also maintain the mechanics: certification campaigns, exception handling, revocation workflows, and reporting. Managers and application owners then answer the question that tools cannot answer on their own: does this identity still need this entitlement for a current business purpose?
That shared model works best when ownership is explicit for both people and systems. For human access, line managers usually validate job fit, while application owners confirm whether a permission is still required in the application context. For NHIs, the equivalent owner is often the service owner, platform team, or product team responsible for the workload. The practical test is simple: the owner must be able to explain why the access exists, what would break if it were removed, and when it should be revoked.
- IAM or IGA team: define the review process and keep evidence consistent.
- Business manager: confirm whether the entitlement still matches the role or function.
- Application owner: verify the access is still required by the application or service.
- Security team: enforce escalation when certifiers miss deadlines or reject cleanup.
Current guidance suggests reviews should focus on active business need, not just role title, because job titles often lag behind real access usage. For NHIs, the process should also include secret location, rotation status, and whether the credential is tied to an owned workload. The Ultimate Guide to NHIs is clear that poor visibility and excessive privilege make cleanup harder once access has drifted. These controls tend to break down when application ownership is unclear across shared platforms, because nobody can confidently approve revocation.
Common Variations and Edge Cases
Tighter review ownership often increases operational overhead, requiring organisations to balance security precision against review fatigue and slow approvals. That tradeoff is real, especially in large enterprises where thousands of entitlements must be certified on a schedule.
There is no universal standard for this yet, but best practice is evolving toward risk-based ownership. High-risk entitlements, privileged roles, and production NHIs should receive stronger validation than low-risk, low-impact access. Some organisations use a tiered model where IAM runs the campaign, managers approve standard access, and application owners must sign off on privileged or sensitive entitlements. In mature environments, cleanup is tied to joiner-mover-leaver events so that reviews are not the only chance to remove access.
Edge cases usually appear where business ownership is distributed. Shared platforms, outsourced operations, and ephemeral engineering teams can make a single approver hard to identify. In those cases, policy should define a default owner of record and an escalation path when the true owner is unavailable. For NHI cleanup, this matters even more because service accounts and API keys may not have a direct human operator watching them every day. Without that clarity, access certification becomes a ritual instead of a control.
For a broader view of how ownership, lifecycle, and revocation fit together, NHI Management Group’s Ultimate Guide to NHIs is the most useful starting point alongside the NIST Cybersecurity Framework 2.0.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access is only valid when ownership and approval are clear. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege reviews depend on periodic entitlement cleanup. |
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI cleanup must include revocation of stale non-human credentials. |
Assign approvers for each entitlement and revoke access when business need is not revalidated.
