They miss dormant access, active abuse and stale entitlements that still look valid on paper. Permission-only programmes can certify accounts without knowing whether the access is being used, making reviews slow, noisy and weak at reducing risk. Usage data is what converts identity governance from an inventory exercise into a control function.
Why permission inventories fail without usage visibility
Permission-only identity programmes answer a narrow question, “what could this account do?” rather than the more important control question, “what is it actually doing?” That gap hides dormant access, stale entitlements and active misuse because a valid grant can still sit unused for months or be exercised only in a narrow window. When teams cannot compare entitlement to behaviour, recertification becomes paperwork instead of risk reduction.
This is why usage data changes the operating model. It lets identity teams separate permissions that are merely assigned from permissions that are genuinely exercised, so review decisions can be based on evidence instead of account lists alone. Identity Security Programme Guide is useful here because it frames identity as an operating model, not just a directory exercise.
Usage also exposes when a policy is technically correct but operationally ineffective. An entitlement may be approved, yet never used by its owner, used far less than expected, or used by a different workflow entirely. That is the point where identity governance stops being a static inventory and starts becoming a control loop that can explain why access exists and whether it still needs to.
What breaks in reviews, recertification and access cleanup
When programmes rely only on permissions, reviewers are forced to certify accounts without context. They see a role, group or entitlement, but not whether it has been used recently, whether it maps to real work, or whether the access path is functionally dead. The result is noisy reviews, longer approval cycles and a tendency to rubber-stamp risk because there is no behavioural signal to challenge the list.
Usage data makes cleanup decisions materially better. If an entitlement has not been exercised in a long time, it becomes a candidate for investigation, right-sizing or removal, while frequently used access may need tighter controls rather than simple retention. The NHI Lifecycle Management Guide is relevant because lifecycle thinking depends on visibility into provisioning, rotation, offboarding and inactive access, not just the original grant.
This is also where access governance quality becomes visible. Permission-only programmes often miss orphaned access, shared access and entitlements that survived role changes long after the business need disappeared. A usage-led view gives reviewers a practical way to ask whether an entitlement is still part of an active workflow, or whether it is simply lingering because nobody can prove it matters.
Why actual usage is the control signal, not just an extra report
Usage data is not a cosmetic enhancement, it is the evidence that turns identity governance into a control function. It helps distinguish dormant access from essential but low-frequency access, and it helps detect active abuse that still looks legitimate on paper. That distinction matters because the absence of usage can be as informative as repeated use, especially when the entitlement was granted for a one-time task or a temporary exception.
For broader context, the same pattern appears in overprivilege, stale accounts and hidden blast radius. Top 10 NHI Issues highlights how visibility gaps, ownership gaps and excessive permissions combine into governance failure when teams manage grants but never validate actual use. That principle applies beyond non-human identities: unused access is still risk, even if no one is presently exercising it.
The practical test is simple: if a permission cannot be tied to observed business use, a team should treat it as unproven rather than justified. That does not mean every rarely used entitlement should be removed automatically, but it does mean it should be challenged, explained or time-bounded instead of being carried forward indefinitely.
Risk and Threat Considerations
Permission-only programmes create blind spots that attackers and insiders can exploit. Dormant entitlements are attractive because they often evade casual review, yet they can still provide a valid path into sensitive systems if the account is compromised or the access is repurposed. Weak reviews also allow stale access to accumulate, which increases the chance that a forgotten privilege becomes the easiest privilege to abuse.
Failure mechanism: The control fails when certification checks whether an entitlement exists, but not whether it is used, needed or consistent with the account’s current role. That lets inactive access remain approved and makes abuse harder to distinguish from legitimate behaviour.
Impact: Teams miss excessive access, delayed revocation and suspicious use patterns, so real exposure stays open even while governance reports look healthy. The result is higher residual risk, weaker audit confidence and a larger attack surface for account takeover or insider misuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Usage evidence is needed to review and analyze whether granted access is actually exercised. |
| AC-2 — Account Management | The question concerns stale access, certification and cleanup of accounts and entitlements. | |
| AC-6 — Least Privilege | Permission-only programmes miss excessive access unless usage is checked against actual need. | |
| Recommendation — Use AU-6 to review access activity and flag entitlements that are granted but never used. Use AC-2 to validate account necessity and remove inactive or unjustified access. Use AC-6 to right-size access based on observed use and current job need. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity programmes that track permissions need account lifecycle and usage checks to curb stale access. |
| CIS-6 — Access Control Management | Usage-based control is required to avoid certifying access that remains unused and risky. | |
| Recommendation — Use CIS-5 to inventory, review and remove inactive or unnecessary access. Use CIS-6 to enforce access reviews that consider entitlement use, not just assignment. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be reviewed and adjusted using evidence of continued need and use. |
| A.5.16 — Identity management | The subject is about governing identities through their active access behavior and lifecycle. | |
| A.8.15 — Logging | Usage visibility depends on logs that show whether granted access is actually exercised. | |
| Recommendation — Review and revoke access rights that are no longer justified by actual use. Maintain identity records that reflect current use and remove stale entitlements promptly. Collect logs that prove access use and support entitlement review decisions. | ||
Practitioner Guidance
What to prioritise: Start by comparing entitlement lists with actual activity, then rank access by last-used date, frequency and sensitivity of the resource reached. This quickly separates harmless dormant access from permissions that deserve immediate review.
What to verify: Before trusting a certification outcome, confirm whether the entitlement has been exercised by the intended owner, whether any exceptions exist, and whether the usage pattern still matches the job function. If you cannot answer those questions, the review is incomplete.
Common mistake: Treating “approved” as the same as “needed” is the usual failure mode. A clean permission inventory can still hide stale entitlements, so evidence of use should influence both removal decisions and escalation for higher-risk access.
Practitioner takeaway: A permission list tells you who could act, but usage tells you what still deserves to exist, and that is the difference between an administrative inventory and a control that actually reduces risk.