Self-Service App Store

Expanded Definition

A self-service app store is a governed catalog that lets end users or teams request approved software without opening a manual ticket queue. In NHI and IAM contexts, the important distinction is that the store is not just a shopping interface. It is a policy enforcement layer where approval logic, device posture, entitlement scope, and identity proofing are embedded into the catalog itself.

Definitions vary across vendors, but the security model is consistent: the store should expose only pre-approved options, route high-risk requests through stronger review, and produce an audit trail for each installation or grant. That makes it closely related to NIST Cybersecurity Framework 2.0 and its emphasis on governed access and asset management. In practice, a self-service app store can apply to endpoint software, internal tools, AI agents, or developer utilities, provided the request path is bounded by policy and visibility.

The most common misapplication is treating the store as a convenience portal while bypassing approval criteria for privileged software or credentials, which occurs when catalog owners prioritise speed over access control design.

Examples and Use Cases

Implementing a self-service app store rigorously often introduces catalog governance overhead, requiring organisations to weigh faster delivery against the cost of maintaining approval rules, ownership records, and exception handling.

• A finance team requests a spreadsheet add-in through the store, but the catalog only exposes a version that has passed security review and license validation.
• A developer installs an internal CLI tool from the store, while the request automatically checks device compliance and records the approval path.
• An AI team adds an approved agent integration, but only after the store verifies which APIs, secrets, and scopes the tool will access.
• An organisation centralises software requests so that new applications can be tracked against inventory, reducing shadow IT and unsupported installs.
• When a high-risk utility is requested, the store routes it to a manager or security approver rather than granting immediate access.

For NHI-heavy environments, this matters when a catalog item indirectly introduces a new service account, API key, or integration secret. The Ultimate Guide to NHIs is useful here because it shows how hidden identities often emerge from routine access workflows, not just from explicit infrastructure projects. A well-designed store should therefore document whether an app creates a non-human identity and what controls govern its lifecycle.

Why It Matters in NHI Security

Self-service app stores become security-critical because they concentrate decision-making about software, access, and identity creation into one workflow. If catalog design is weak, teams can approve tools that introduce excessive permissions, unmanaged secrets, or third-party exposure before anyone notices. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which means a store can easily become the front door for new NHIs that are never properly tracked.

This is why app-store governance maps naturally to the visibility and least-privilege themes in NIST Cybersecurity Framework 2.0. When approvals are embedded in the catalog, security teams can enforce risk classification, ownership, and review thresholds before software reaches production endpoints or operational users. That reduces shadow IT, but only if the catalog is continuously reconciled with actual installations and identity grants.

Organisations typically encounter the real risk only after an unauthorised app, agent, or privileged integration is discovered during incident response, at which point the self-service app store becomes operationally unavoidable to examine.

Related resources from NHI Mgmt Group

• What do security teams get wrong about self-service app requests?
• Why do self-service app catalogues create governance risk if they are not tightly controlled?
• When does self-service app access create more risk than it reduces?
• Service Account Governance