A curated list of applications or services users can request through an internal portal. It reduces friction, but it also defines a policy boundary because only approved items should be available. If the catalogue grows without review, it can hide access risk.
Expanded Definition
A self-service catalogue is the controlled menu of applications, data services, automation jobs, and access bundles that users can request through an internal portal. In NHI and IAM programs, it is more than a convenience layer because it expresses policy in operational form: if an item appears in the catalogue, it is implicitly considered pre-approved, supportable, and governable.
Definitions vary across vendors on how much automation belongs in the catalogue. Some treat it as a simple request front end, while others include policy checks, approvals, entitlement templates, and workflow orchestration. In NHI security, the important distinction is that the catalogue should only expose items whose identities, secrets, permissions, and expiry rules are already understood. That makes it closely related to the NIST Cybersecurity Framework 2.0 principle of controlled access and governance. The catalogue should also reflect lifecycle controls described in Ultimate Guide to NHIs, especially where service accounts, API keys, and automation access are provisioned.
The most common misapplication is treating the catalogue as an inventory of everything technically requestable, which occurs when approvals are added after items have already been made visible to users.
Examples and Use Cases
Implementing a self-service catalogue rigorously often introduces governance overhead, requiring organisations to balance faster fulfillment against tighter review of what is exposed for request.
- A developer requests a pre-approved CI/CD service account bundle that includes scoped access, a named owner, and a defined rotation schedule.
- An engineering team requests a new API key for an internal integration, but the catalogue only offers a time-bound template rather than free-form secret creation.
- A platform team publishes a standardized application access package after verifying entitlement mappings, logging, and offboarding steps.
- An organisation removes a legacy queue-processing role from the catalogue after discovering it granted broad standing privileges to multiple automations.
- A self-service portal routes each request through policy checks so that the item cannot be issued unless the approver, owner, and expiry are already defined.
In practice, catalogue design often mirrors the maturity gaps documented in Ultimate Guide to NHIs, where weak visibility into service accounts and inconsistent secret handling create hidden risk. The request experience can be streamlined, but only if the requestable items are bounded by identity governance rather than convenience alone.
Why It Matters in NHI Security
A self-service catalogue is a policy enforcement surface, not just a usability feature. If the catalogue includes overly broad bundles, stale automations, or request paths that bypass ownership validation, it can become a fast lane for privilege accumulation. That matters because NHI risk often scales silently: NHIs outnumber human identities by 25x to 50x in modern enterprises, and 97% carry excessive privileges, according to NHI Mgmt Group. When a catalogue is not curated, those issues are amplified by repeatable self-service issuance.
For governance teams, the catalogue should be reviewed as part of identity hygiene, access recertification, and secret lifecycle control. That includes verifying which requests create long-lived credentials, which ones require ownership attestations, and which ones should be removed entirely. The catalogue should also align with the access governance expectations in NIST Cybersecurity Framework 2.0 and the lifecycle practices described in Ultimate Guide to NHIs. Organisations typically encounter the true impact of a weak self-service catalogue only after a review, incident, or audit exposes that users could request privileged access that was never meant to be broadly available.
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 | Catalogue scope affects which NHIs and secrets can be requested or exposed. |
| NIST CSF 2.0 | PR.AC-4 | Self-service catalogues implement access restriction and governance for requested entitlements. |
| NIST Zero Trust (SP 800-207) | Catalogue requests should fit Zero Trust by verifying context before access is issued. |
Bind requestable items to least-privilege approval, logging, and periodic entitlement review.
Related resources from NHI Mgmt Group
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
