A self-service app store helps users request or discover software, while a governed entitlement catalog defines which access options are allowed, who can approve them, and what information is exposed during the request process. Without those rules, self-service becomes convenience without control.
What each model is trying to control
A self-service app store is primarily a discovery and request experience. A governed entitlement catalog is an access-governance experience, where the catalog is constrained by policy, approval logic, and the information exposed to the requester. The practical difference is that one optimises convenience first, while the other makes entitlement choice itself part of the control plane.
That distinction matters because the catalog is not just a prettier front end. It is where organisations decide whether users can see all possible options, only approved options, or only the options that fit their role, location, system, or risk tier. In other words, the governed catalog is where request convenience is intentionally bounded by access policy.
A useful way to think about this is that the app store answers, “What can I ask for?” while the governed catalog answers, “What may I ask for, under what conditions, and with what oversight?” When those questions are separated cleanly, teams can simplify requests without turning the request portal into an ungoverned entitlement marketplace.
Where governance changes the request experience
Governance changes more than approval routing. It can also control entitlement naming, eligibility, ownership metadata, separation of duties, and the fields shown during the request flow. That means the catalog can reduce ambiguity, prevent overbroad requests, and expose only the context a requester needs to make a valid choice.
In practice, that often means curating the request set rather than presenting every technically available access path. A governed catalog may hide internal implementation details, suppress duplicate or deprecated options, and group entitlements by business role or service function so the request matches the organisation’s access model instead of the directory structure.
The strongest implementations also make the approval path visible enough to be auditable without overwhelming the user. If a request needs manager, system owner, or risk-based approval, the user should understand that before submission. That reduces back-and-forth, but more importantly it prevents people from treating access request as a shopping cart with automatic fulfilment.
NHIMG’s IAM and IGA Basics is useful here because the app-store-versus-catalog distinction sits squarely in the gap between request UX and entitlement governance. For a deeper access-control lens, the Authorisation Models Guide shows why the visible options should reflect policy, not just inventory. The Access Reviews and Certification Guide adds the lifecycle follow-through, since a catalog is only trustworthy if its approved options stay aligned with actual access over time.
Why the difference matters for entitlement sprawl
Without governance, a self-service store can become a list of whatever integrations or tickets the platform happens to support. That creates entitlement sprawl, duplicate requests, and hidden privilege paths that are hard to review later. The risk is not just too many items, but too many inconsistent ways to obtain the same access.
A governed catalog reduces that sprawl by making the request surface smaller and more intentional. It helps enforce least privilege by limiting which access options are requestable, requiring context for higher-risk items, and steering users toward standard access patterns instead of ad hoc exceptions.
That is also why lifecycle control matters. If a catalog still exposes stale entitlements, orphaned roles, or old access paths, the “governed” label is cosmetic. Good governance requires that the catalog reflect current policy, current owners, and current approval rules, otherwise the request layer becomes a distribution channel for outdated access.
The Joiner-Mover-Leaver (JML) Guide is relevant because request catalogs and lifecycle processes need to stay aligned, especially when access must change as people change roles. The Role Mining and Role Design Guide is also directly useful, since a governed catalog works best when the requested options map to stable, reviewable roles rather than one-off access bundles. For organisations managing broad entitlement hygiene, the IGA Buyer’s Guide helps frame the catalog as part of a wider governance stack, not a standalone request portal.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Governed catalogs should constrain requestable access to least-privilege options. |
| AC-2 — Account Management | Catalog governance depends on controlled provisioning, approval, and entitlement lifecycle. | |
| AC-3 — Access Enforcement | The catalog's allowed options must reflect enforced policy, not just UI convenience. | |
| Recommendation — Limit catalog offerings to the minimum access needed for each role or use case. Tie requests to managed account and entitlement lifecycles with ownership and approval. Enforce policy so only approved access paths can be requested and granted. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Governed entitlement catalogs are an access-control implementation and governance point. |
| Recommendation — Define which access options are allowed and ensure the catalog reflects those rules. | ||
Practitioner Guidance
What to verify: Check whether the catalog enforces eligibility before approval, not just after submission. If users can browse and request everything the system can technically provision, you have a request store with workflow, not a governed catalog.
Decision rule: If the catalog exposes entitlement choices that a reviewer would later reject as out of policy, tighten the catalog itself. If the main issue is only request usability, improve search and grouping without widening what is requestable.
What good looks like: Requesters see a curated set of approved, current access options, along with the minimum context needed to choose correctly. Owners, approvers, and review evidence are attached to the entitlement record, so governance survives beyond the request form.
Practitioner takeaway: Treat the app store as a convenience layer and the governed catalog as an enforcement layer, because once request visibility exceeds policy visibility, the control problem has already shifted upstream.