Self-Service Access Catalog

Expanded Definition

A self-service access catalog is more than a request form. In NHI security and IAM, it is a governed access layer that exposes approved entitlements, routes requests through policy, and creates an auditable path from demand to approval to provisioning. For service accounts, API keys, tokens, certificates, and other secrets, the catalog should express what access is allowed, who can approve it, how long it should last, and what evidence is recorded.

Definitions vary across vendors on whether the catalog is treated as part of identity governance, IT service management, or privileged access workflows, but the security requirement is consistent: access must be discoverable, constrained, and reviewable. That aligns with least privilege and control expectations in the OWASP Non-Human Identity Top 10 and the baseline control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls.

The most common misapplication is treating the catalog as a convenience portal only, which occurs when teams automate requests but skip policy scope, approval context, or expiry enforcement.

Examples and Use Cases

Implementing a self-service access catalog rigorously often introduces policy-design overhead, requiring organisations to balance user speed against tighter approval logic and shorter-lived access.

• A developer requests a temporary API key through the catalog, and the workflow issues it only after code-owner approval and a 24-hour expiry check.
• An incident responder requests elevated access to a production service account, and the catalog forces a time-bound grant with automatic revocation after the incident closes.
• A platform team publishes approved database roles in the catalog so application owners can request access without opening manual tickets, while all entitlements remain mapped to policy.
• A secrets-management team uses the catalog to separate standard access from break-glass access, making exceptional grants visible and reviewable.
• An organisation feeds the catalog with risk data from identity governance so requests for privileged access require stronger justification before provisioning.

These patterns are easier to govern when they are connected to the NHI lifecycle guidance in the Ultimate Guide to NHIs and to documented control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Why It Matters in NHI Security

Self-service access catalogs matter because NHIs scale much faster than human identities, and manual request handling cannot keep pace without introducing blind spots. NHI Mgmt Group research shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, while only 5.7% of organisations have full visibility into their service accounts. That makes a catalog a governance control, not just an efficiency feature.

When access is requested through a governed catalog, organisations can reduce secret sprawl, enforce expiry, and improve accountability for privileged grants. That is especially important given the risk profile described in the Ultimate Guide to NHIs — Key Challenges and Risks and the incident patterns reflected in 52 NHI Breaches Analysis.

Organisations typically encounter the consequences only after a service account is overprovisioned, a secret is exposed, or a recovery event demands proof of who approved access, at which point the self-service access catalog becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who should own access decisions in a self-service app catalog?
• How can organisations make self-service access management safer?
• How can security teams tell whether self-service access is working?
• Why do self-service portals create governance risk when access is involved?