Security teams should base removals on observed activity, not entitlement lists alone. The practical sequence is to collect evidence of who used access, identify dormant permissions, and compare actual use against business need. That approach reduces noisy reviews, supports least privilege decisions, and gives auditors defensible proof when access is renewed or revoked.
Why proof of actual use matters before access removal
Entitlement reviews tell you what people or systems could use, but they do not prove what they actually used. For access removal, that distinction matters because dormant permissions can be overestimated, business-critical access can be overlooked, and revocation can create avoidable disruption if the entitlement was never exercised.
Proving actual use means collecting observed evidence from logs, access records, and administrative telemetry, then tying that use back to the business purpose of the permission. The stronger the evidence trail, the easier it is to justify revocation, renewal, or exception handling without relying on memory or broad role assumptions.
For teams operating across human and machine access, the same principle applies to service accounts, API keys, tokens, and other credentials: if you cannot show recent use, owner intent, and business need, the entitlement should be treated as a candidate for reduction rather than preserved by default. NHIMG’s Ultimate Guide to NHIs is a useful reference for the visibility and lifecycle side of that problem.
How to build defensible evidence of use
The most reliable sequence is to reconstruct usage from the systems that actually enforced or observed it, not from the access catalog alone. That usually means correlating authentication logs, application audit trails, privileged session records, cloud control plane events, and identity provider activity to determine whether the permission was exercised, by whom, from where, and for what system or workload.
A good proof set does three things. First, it shows recency, so you know whether the access is active or stale. Second, it shows scope, so you can tell whether the holder used only a narrow function or depended on broad standing rights. Third, it shows ownership and purpose, so the access can be matched to a real operational dependency instead of an inherited role assignment.
This is where access review programs often become noisy: teams confuse assignment with usage, or they accept a manager’s assertion that access is needed without validating that the permission still appears in logs. The practical fix is to combine usage evidence with business context, then narrow the entitlement to the smallest demonstrably used set before revocation.
When you have strong visibility gaps, the safest interpretation is conservative. If a permission cannot be observed in the relevant log sources, that does not prove it is unused, but it does mean the team lacks enough evidence to defend keeping it untouched. In that case, a temporary exception with tighter monitoring is usually better than permanent standing access with no proof trail.
Risk and Threat Considerations
Removing access without proving actual use can break workflows, but keeping access without proof creates a larger and more durable exposure. Unused or unobserved permissions are prime candidates for overprivilege, orphaned access, and credential abuse, especially when dormant accounts or keys remain valid long after their original purpose has ended.
Failure mechanism: Teams rely on entitlement lists or informal approval history instead of observed activity, so dormant permissions survive reviews while truly necessary access is either missed or removed without evidence. That weakens least-privilege enforcement and leaves a broad attack surface for misuse.
Impact: The result is twofold, unnecessary access persists for attackers or insiders to abuse, and legitimate operations can be disrupted when teams revoke rights they did not prove were unused. Over time, the organisation loses confidence in its access reviews because they are neither precise nor defensible.
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, CIS Controls v8, NIST SP 800-63 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-01 — Secrets and Credential Management | Actual-use proof depends on tracking and retiring standing credentials and keys. |
| NHI-03 — Visibility and Discovery | The question centers on proving where access is actually used before removal. | |
| NHI-05 — Least Privilege and Permission Review | The page answer is about reducing access to what is demonstrably needed. | |
| Recommendation — Correlate credential usage and rotate or revoke secrets that no longer show legitimate activity. Inventory access paths and log sources so removals are based on observed use, not assumptions. Re-certify access against observed business use and remove permissions that are not justified. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Access removal needs a defensible evidence basis aligned to governance decisions. |
| PR.AC-4 — Access Permissions and Authorizations | The subject is deciding which permissions are actually in use and still needed. | |
| Recommendation — Require evidence-based criteria for access retention and revocation decisions. Limit access to the minimum set supported by demonstrated operational need. | ||
| CIS Controls v8 | 5.2 — Establish and Maintain a Software Inventory | Usage proof depends on knowing which identities, applications, and services are in scope. |
| 6.3 — Periodic Access Review | The exact task is validating access before revocation during review cycles. | |
| 8.2 — Audit Log Management | Observed activity is the core evidence for proving actual access use. | |
| Recommendation — Maintain authoritative inventories so access reviews can map observed activity to specific assets. Use periodic reviews to compare granted access with recent observed use and business need. Collect and retain audit logs that can substantiate whether access was exercised. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Defensible access decisions require confidence in who the identity belongs to. |
| Recommendation — Verify identity evidence before trusting access records tied to a person or account. | ||
| NIST Zero Trust (SP 800-207) | 5.2 — Policy Engine and Enforcement | Access removal should be governed by policy based on current observed need. |
| Recommendation — Apply policy enforcement to narrow access as usage evidence changes. | ||
Practitioner Guidance
What to verify: Before removing access, verify that the relevant logs cover the full period you are judging, that the identity or credential is attributable to a known owner, and that the observed use matches the business function the access was meant to support. If any of those three are missing, treat the review as incomplete rather than forcing a yes-or-no decision.
Decision rule: If you can prove the access was not used during a representative period and no current business dependency exists, remove it. If you can prove it was used but only for a narrow purpose, reduce it to that purpose instead of preserving the original broad grant.
Practitioner takeaway: The best revocation decisions are evidence-led, not catalogue-led, and the evidence has to show both use and purpose if the result is going to stand up to auditors and operations alike.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
