App inventories tell you where access exists, but entitlement reviews tell you whether the level of access is appropriate. A user with standard access and a user with admin rights may look identical in a coarse inventory, yet their governance and risk profiles are very different. Granularity is what makes certification decisions meaningful.
Why entitlement reviews answer a different question than inventories
An app inventory answers “where can access exist?” entitlement reviews answer “what exactly can each identity do there?” That distinction matters because governance decisions are made at the permission level, not the application name level. A system with 5,000 accounts can look tidy in inventory form and still contain excessive roles, dormant entitlements, or toxic combinations that only appear when you inspect the grants themselves.
Inventories are useful for coverage and discovery, but they are coarse by design. They tell you which applications, tenants, or systems are in scope, which is necessary for audit completeness, yet not sufficient for certification. Reviews become meaningful only when you can see the actual entitlements, group memberships, delegated rights, and privileged assignments attached to each account or role.
That is why access governance is built around certification, recertification, and removal of unnecessary access rather than around asset listing alone. The right unit of analysis is the entitlement set, because that is what changes the risk profile of the identity and determines whether the access is still justified.
What granularity changes in practice
Granularity turns a vague question into a defensible one. “Does this user need Salesforce?” is too broad to govern well if the real issue is whether the user has read-only access, export rights, approval authority, or admin capabilities. Entitlement reviews force that distinction, which is what makes reviewer judgment actionable instead of ceremonial.
This is also where identity governance becomes operational rather than theoretical. If a review only confirms that an account exists, it misses privilege creep, role drift, and permission accumulation over time. If it examines the specific entitlements, it can reveal when a user moved teams, a contractor kept legacy access, or a service account inherited permissions that were never revalidated after a change.
For teams trying to reduce access risk, the practical question is not whether the application is present in an inventory, but whether the attached permissions still match the current business need. Access Reviews and Certification Guide is useful because it frames the review around removal decisions, not just record-keeping.
Why inventory alone can hide the real risk
A coarse inventory tends to flatten distinct levels of authority into one line item. That can hide the difference between a low-risk standard account and a high-risk admin account, or between a harmless application login and a permission set that can modify records, approve payments, or export sensitive data. From a governance perspective, those are not equivalent exposures.
Inventory also struggles with indirect access. Many of the riskiest paths are inherited through groups, roles, templates, shared accounts, or delegated administration. If you only count applications, you will miss whether the entitlement model is well-structured or whether access has become oversized, duplicated, or difficult to explain.
That is why access review quality depends on knowing the entitlement model underneath the app list. IAM and IGA Basics is a good reference point for the distinction between provisioning, entitlements, and governance, while Authorisation Models Guide helps when the review needs to separate role-based access from attribute- or relationship-based access.
How stronger reviews improve decisions and remediation
Entitlement reviews create a decision trail: keep, reduce, or remove. That trail is only credible when the reviewer can see what the entitlement does and whether it matches the person’s current job, function, or delegated responsibility. A good review therefore supports both governance and cleanup, while a bad one merely re-stamps old access.
The best programs also treat inventory as an input, not the outcome. Inventory establishes scope, but entitlement review establishes appropriateness. When the two are combined, teams can prioritize high-risk access first, focus on privileged or sensitive entitlements, and spot systemic issues such as stale groups, excess rights, or recurring over-assignment patterns.
If your control objective is to reduce risk rather than to produce a completeness report, start with the entitlements that can do the most damage, not the applications that happen to host them. Privileged Access Management Guide is especially relevant where the review must distinguish ordinary access from privileged access, and Segregation of Duties (SoD) Guide becomes important when the entitlement combination itself creates conflict.
Risk and Threat Considerations
App inventories can give a false sense of control if they do not surface what an account is actually allowed to do. The risk is not merely incomplete visibility, but governance blind spots that let excessive privilege, dormant access, and conflicting duties persist long after the original justification has disappeared.
Failure mechanism: The inventory records presence, while the entitlement set carries authority. If reviewers never inspect the permission layer, inherited access, privileged roles, and hidden delegation paths remain unchecked and can be reused or abused.
Impact: Organisations may certify unsafe access, miss toxic combinations, and leave users or machines with more authority than their current job or function requires. That increases the blast radius of compromise and weakens audit defensibility.
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 | AC-2 — Account Management | Entitlement reviews govern who retains access and what rights remain assigned. |
| AC-6 — Least Privilege | The question is about judging whether access levels are appropriate, which is least-privilege control. | |
| AU-6 — Audit Review, Analysis, and Reporting | Certification decisions rely on evidence from reviewable access records and entitlement change history. | |
| Recommendation — Review account permissions regularly and remove unneeded access. Limit each identity to the minimum permissions required for its role. Use audit evidence to validate access decisions and spot privilege drift. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access governance requires controlled assignment and review of entitlements, not just asset listing. |
| A.5.18 — Access rights | The page focuses on reviewing whether access rights remain appropriate for each identity. | |
| Recommendation — Define and enforce access rules at the entitlement level. Periodically review, adjust, and revoke access rights that are no longer justified. | ||
| CIS Controls v8 | CIS-5 — Account Management | Entitlement reviews are a core account-management safeguard for detecting excess or stale access. |
| Recommendation — Maintain an accurate access review process and remove unnecessary accounts and privileges. | ||
Practitioner Guidance
What to prioritise: Review the entitlements that change consequence first, especially admin rights, data export rights, approval rights, and delegated management privileges. An inventory can tell you where to look, but it should not decide what gets approved.
What to verify: Confirm that reviewers see the actual permission detail, not just the application name or account status. If the review record cannot distinguish standard access from elevated access, it is too coarse to trust.
Practitioner takeaway: The value of entitlement review is precision, because governance only becomes real when the decision is tied to the exact authority granted, not to the fact that an application exists.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org