Who should own access decisions in a self-service app catalog?

Why This Matters for Security Teams

Self-service app catalogs often create a false sense of simplicity: the request flow looks cleaner, but the real security question is who can approve access, on what basis, and with what auditability. If those decisions are vague, the catalog becomes a faster path to privilege creep, orphaned access, and inconsistent exceptions. This matters even more for NHIs and agentic workloads, where access can be chained across APIs, queues, and automation steps. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is why catalog governance cannot rely on convenience alone.

The right ownership model separates policy, risk acceptance, and the access decision itself. IT should define the guardrails, application owners should accept residual risk, and approvers should execute decisions within those guardrails. That model aligns with the broader guidance in the Ultimate Guide to NHIs and the control themes in the OWASP Non-Human Identity Top 10. In practice, many security teams encounter broken ownership only after exceptions have already been normalised into the catalog.

How It Works in Practice

A workable self-service model starts by treating policy as centrally defined and decisioning as bounded. IT or identity governance defines who may request what, which roles or app tiers are eligible, what evidence is required, and when step-up review is needed. Application owners do not approve everything by default; instead, they own the business risk of their applications and define approval boundaries for their domain. Approvers then make the actual access decision inside those predefined limits, with the system enforcing segregation of duties, ticket correlation, and time-bound entitlements.

This is where workflow design matters. A request in the catalog should capture the requester, target app, duration, justification, and any context needed for a real decision. For NHIs, the same logic should prefer workload identity, JIT provisioning, and short-lived secrets rather than standing access. NHI Mgmt Group’s 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Key Challenges and Risks both reinforce that visibility and overprivilege are recurring failure points.

• IT owns catalog policy, control requirements, and review cadence.
• Application owners own risk acceptance for their specific service or dataset.
• Approvers own the yes or no decision within preset thresholds.
• Automation should enforce expiry, revocation, and logging without manual follow-up.

Current guidance suggests pairing this model with least privilege, periodic attestation, and clean exception handling so the catalog does not become a permanent access store. These controls tend to break down when approval chains are nested across federated teams because accountability becomes ambiguous and revocation timing slips.

Common Variations and Edge Cases

Tighter approval boundaries often increase workflow overhead, requiring organisations to balance speed against control. That tradeoff is especially visible in high-volume app catalogs, emergency access, and cross-functional platforms where a single approver cannot reasonably understand every risk dimension. In those cases, best practice is evolving rather than settled: some organisations use tiered approvers, some delegate by app class, and some route only unusual requests to risk owners.

For NHIs, the edge cases are even sharper. A service account used by automation may need delegated approval, but that does not mean the account should receive long-lived standing privileges. The safer pattern is to keep policy central, issue credentials just in time, and expire access automatically when the task ends. That approach is consistent with the direction of travel in OWASP Non-Human Identity Top 10 and the governance emphasis in the Ultimate Guide to NHIs.

The main exception is regulated or safety-critical environments where approval must include additional evidence, such as data classification, change windows, or separation of duties checks. Even there, the principle holds: owners define the risk posture, but approvers own the discrete access decision. When catalogs blur those boundaries, access review quality usually degrades long before anyone notices a formal policy violation.

Related resources from NHI Mgmt Group

• Who should own access decisions when service management and IAM are connected?
• Who should own lifecycle decisions when access is delegated across IT, HR, and app owners?
• When does self-service app access create more risk than it reduces?
• Who should own access decisions when service desk tools are involved?