IAM teams should check which applications are listed, who can approve them, and what entitlement bundle is granted behind each request. The catalogue should reflect current policy and role boundaries, because an outdated app store can quietly expose users to software that no longer fits business or security requirements.
Why This Matters for Security Teams
Self-service app stores can look like a convenience layer, but for IAM teams they are effectively a policy enforcement point. If the catalogue is stale, the approval path is weak, or the entitlement bundle is overbroad, users can self-select software and access that no longer matches role, risk, or data handling requirements. That creates hidden privilege creep, shadow access paths, and a gap between what policy says and what the store actually delivers. The NIST Cybersecurity Framework 2.0 treats governance and access control as operational disciplines, not one-time design decisions, which is exactly why catalogue hygiene matters. NHI Management Group research also shows how quickly access control assumptions break down when secrets and privileged paths are poorly managed, as seen in Azure Key Vault privilege escalation exposure. In practice, many security teams discover app-store sprawl only after an audit, incident, or exception review has already exposed the gap.
How It Works in Practice
IAM teams should treat the self-service app store as a controlled inventory, not a simple software menu. Each application entry needs an owner, a business justification, an approval route, and a defined entitlement bundle. The key question is whether the request path enforces current policy at the moment of request, rather than relying on a static catalogue that may have drifted from RBAC and data access rules. That means checking whether approval groups still match organisational authority, whether high-risk apps require step-up review, and whether the bundle behind the button includes only the minimum access needed.
Practitioners usually review four control points:
- Application listing accuracy: is the software still approved, supported, and scoped to the right business use?
- Approver legitimacy: can the named approver actually authorise the requested access today?
- Entitlement mapping: does the bundle align with least privilege and current role boundaries?
- Lifecycle control: are retired apps, orphaned bundles, and exceptions removed on a defined schedule?
This aligns with NIST Cybersecurity Framework 2.0 expectations for access governance, and it becomes even more important when the store is feeding downstream SaaS, cloud, or privileged workflows. The broader NHI context matters too: NHI Management Group data shows that 97% of organisations carry excessive privileges and only 20% have formal offboarding and revocation processes, which means catalogue mistakes can persist long after they should have been removed. The most mature programmes also cross-check app-store entries against secrets handling and service-account exposure, using guidance from The Ultimate Guide to Non-Human Identities. These controls tend to break down when app ownership is decentralised across multiple business units because no single team keeps the catalogue, approvers, and entitlement bundles in sync.
Common Variations and Edge Cases
Tighter catalogue control often increases approval overhead, so organisations have to balance user convenience against the risk of granting outdated access paths. That tradeoff becomes especially visible in large enterprises with federated IT, where local teams maintain their own approved apps and exception lists. Best practice is evolving, but current guidance suggests that high-risk categories should not be treated the same as low-risk productivity tools.
Watch for edge cases such as:
- Apps approved for one region but visible globally, which can create policy mismatches across jurisdictions.
- Bundles that include hidden entitlements, such as admin scopes or shared service access, that users do not realise they are receiving.
- Acquired companies where legacy app-store entries survive after identity consolidation and still grant access.
- Apps tied to external sharing or third-party workflows, where the store entry looks benign but the downstream access path is not.
Where there is no universal standard for this yet, teams should prioritise review cadence, ownership clarity, and entitlement transparency over perfect catalogue design. If the store also governs privileged or non-human access, use the broader NHI lens from NHI Management Group research to check for privilege creep and secrets exposure, because app-store hygiene and identity hygiene usually fail together rather than separately.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-03 | Checks whether app-store access matches current policy and approved roles. |
| OWASP Non-Human Identity Top 10 | NHI-01 | App stores can expose overprivileged non-human and delegated access paths. |
| NIST AI RMF | Governance is needed when self-service systems automate access decisions. |
Review catalogue entitlements against current policy and remove app entries that no longer fit approved access.
Related resources from NHI Mgmt Group
- What do security teams get wrong about self-service app requests?
- What should IAM and NHI teams check before relying on metadata-service credentials?
- Why do self-service app catalogues create governance risk if they are not tightly controlled?
- Why do self-service employee workflows create IAM risk if they are not governed?
