Accountability stays with the organisation that defines the catalogue and approval policy, not with the user who clicks the request button. If the catalogue includes the wrong apps, if approvals are too loose, or if offboarding is not enforced, the governance failure sits with the access model.
Why This Matters for Security Teams
A self-service app store can look like a simple convenience layer, but it is really an access-control decision engine. When it grants the wrong access, the failure is usually not the click event itself. The real issue is that catalogue design, approval logic, entitlement mapping, and revocation rules were set up incorrectly. That is why accountability sits with the organisation that designed the control plane, not with the requester.
This is especially important for Non-Human Identity governance because the same pattern shows up in service accounts, API keys, and automated access paths. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer can rotate them consistently, which makes bad catalogue decisions persist long after approval. The broader risk profile is described in the Ultimate Guide to NHIs and the related Ultimate Guide to NHIs — Key Challenges and Risks. In practice, many security teams discover the access model was wrong only after a privileged request has already been approved and the downstream exposure has already occurred.
How It Works in Practice
Accountability follows control ownership. If a self-service catalogue exposes the wrong application, the wrong permission set, or the wrong approval path, the business owner of the catalogue and the identity governance team remain responsible for the outcome. The user merely triggered the workflow. Current guidance from the OWASP Non-Human Identity Top 10 reinforces that access sprawl, stale credentials, and excessive privileges are design problems, not requestor problems.
Operationally, the control model should separate request, approval, issuance, and revocation. That means:
- the catalogue only presents approved entitlements that match the actual role or workload need
- approvals are tied to policy, not informal manager trust
- just-in-time provisioning is used where possible instead of standing access
- offboarding and periodic access reviews are enforced automatically
- entitlements for NHIs are governed with the same discipline as human access, especially for tokens and API keys
This is where Zero Trust and NHI governance intersect. NHI Mgmt Group’s research shows that 97% of NHIs carry excessive privileges, which makes a weak catalogue dangerous even when the requester is legitimate. The practical takeaway is that a self-service store should be treated as a policy enforcement surface, not a convenience portal. Teams that want a governance baseline can use the NHI lifecycle and visibility guidance in the Ultimate Guide to NHIs alongside access governance patterns recommended by NIST and OWASP. These controls tend to break down when catalogues span multiple application owners because entitlement ownership becomes fragmented and no single team can enforce revocation consistently.
Common Variations and Edge Cases
Tighter catalogue governance often increases operational overhead, so organisations must balance speed against review depth. That tradeoff is real, especially in environments where access requests are frequent and application owners are distributed.
There is no universal standard for this yet, but current guidance suggests three common edge cases. First, if the catalogue is populated from upstream identity data that is already wrong, accountability remains with the team that failed to maintain the source of truth. Second, if an approver rubber-stamps requests without understanding the entitlement, the approval process is still defective, even if the user acted honestly. Third, if a self-service store is granting access to NHIs, the problem is usually worse because automated identities can chain privileges faster than humans can. That makes policy-as-code, short-lived credentials, and enforced revocation far more important than manual review alone.
For practitioners, the practical question is not who clicked request, but who owned the catalogue, the policy, and the revocation path. The strongest evidence of this pattern is in identity breach reporting, where compromised non-human identities are repeatedly tied to excess privilege and weak lifecycle controls. In environments with delegated admin models or third-party-owned applications, accountability may be shared contractually, but the enterprise still owns the governance outcome. In practice, many security teams encounter mis-granted access only after privilege has already been used, rather than through intentional catalogue testing.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Mis-granted access often stems from poor NHI credential lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Self-service access stores must enforce least privilege and controlled approvals. |
| NIST AI RMF | Accountability for automated access decisions fits AI governance and oversight. |
Review catalogue entitlements against NHI-03 and revoke excess access automatically on lifecycle change.
