An app catalogue is a governed inventory of software that users can request or be assigned through policy. For identity teams, its value depends on whether it reflects current ownership, risk status, and approved access paths, rather than acting as a static list of tools.
Expanded Definition
An app catalogue is more than a directory of software. In identity and access management, it is a governed control surface that determines which applications are approved, who may request them, what access path is allowed, and what policy conditions must be met before assignment.
Used properly, the catalogue links service ownership, risk classification, and entitlement rules to a repeatable approval workflow. That makes it different from a static software inventory, which may list tools without reflecting whether they are still sanctioned, whether the owner is accountable, or whether access should be self-service, manager-approved, or blocked entirely. This matters for NHI and agentic AI governance because many applications are now accessed by service accounts, workload identities, and AI agents rather than only human users.
Definitions vary across vendors when catalogues also include provisioning automation, software distribution, or SaaS discovery. In the NHI context, the useful definition is narrower: the catalogue should express policy, not just presence. For identity governance, NIST Cybersecurity Framework 2.0 reinforces the need to identify assets, manage access, and control authorised use across the environment. The most common misapplication is treating the app catalogue as a one-time onboarding register, which occurs when ownership and approval logic are not updated after application changes, mergers, or decommissioning.
Examples and Use Cases
Implementing an app catalogue rigorously often introduces governance overhead, requiring organisations to weigh faster self-service access against the cost of ongoing ownership, risk, and entitlement maintenance.
- A finance application appears in the catalogue with an assigned owner, a business justification, and a restricted approval path, so only approved teams can request access.
- A legacy internal tool is marked deprecated and hidden from new requests, while existing assignments are reviewed for migration or removal. Guidance on lifecycle visibility in the Ultimate Guide to NHIs supports this kind of governance discipline.
- A SaaS integration used by an AI agent is catalogued with a defined service account, risk rating, and rotation requirement so access does not depend on ad hoc provisioning.
- A developer portal exposes only approved internal APIs, with the catalogue linking each API-backed app to its control owner and request policy.
- A shadow IT application is discovered through access logs and added to the catalogue only after security review, not merely because employees are already using it.
In practice, catalogue quality is strongest when paired with discovery and entitlement review. Identity teams often compare catalogue records against actual usage, which helps surface drift between what is approved and what is still being consumed by humans, service accounts, or agents.
Why It Matters in NHI Security
An app catalogue becomes a security control when it helps answer a hard question: which applications are still safe to expose to non-human identities, and which ones should no longer be granted by default? That answer matters because NHI risk often concentrates in forgotten apps, stale entitlements, and unclear ownership. NHIMG research shows that 97% of NHIs carry excessive privileges, and that risk is amplified when catalogues do not reflect current access paths or decommissioning status. The same research also notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes catalogue accuracy part of breach prevention rather than administrative hygiene.
When an application is not accurately catalogued, governance breaks down in three ways: users request the wrong tool, security teams lose visibility into who owns the app, and automation continues to provision access after the business has moved on. A well-maintained catalogue supports least privilege, reduces accidental exposure, and gives reviewers a place to anchor access decisions. It also helps connect inventory to policy, which is essential when applications are consumed by NHIs that do not follow human joiner-mover-leaver patterns. Organisational failure usually becomes visible only after a dormant integration is abused or an audit exposes unowned access, at which point the app catalogue becomes operationally unavoidable to repair.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | App catalogues expose which non-human access paths are approved and owned. |
| NIST CSF 2.0 | ID.AM-1 | Asset inventories and governance depend on accurate software identification and ownership. |
| NIST Zero Trust (SP 800-207) | Zero Trust relies on explicit policy decisions for every application access request. |
Keep catalogue ownership, approval rules, and access paths current so NHI access is governed, not ad hoc.
Related resources from NHI Mgmt Group
- Why can a single SaaS app create such a large blast radius?
- What is the difference between a service account and an OAuth-connected app?
- What is the difference between a disabled app and a deleted app in Microsoft 365?
- What is the difference between app visibility and identity visibility in SaaS security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
