Who should own application access decisions when roles and permissions are managed in the identity layer?

Why Ownership Must Be Split Between the App and Identity Layers

When roles and permissions are managed in the identity layer, the ownership question is less about who clicks approve and more about who understands the control point. Application teams know which screens, APIs, and workflows need protection; identity teams know how roles, groups, and entitlement patterns are enforced at scale. That division matters because access failures often appear only after a role is reused too broadly or a permission map drifts out of sync with the application’s actual logic.

The risk is not theoretical. NHIMG research shows that 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, which is why role ownership cannot sit in one silo alone. The governance model should be anchored in the application boundary, while identity administration handles the reusable policy structure. This is also consistent with the Ultimate Guide to NHIs and the control themes in OWASP Non-Human Identity Top 10, both of which emphasise governance, visibility, and privilege minimisation. In practice, many access disputes are discovered only after a user leaves, a role changes, or an audit finds that nobody can explain why the permission existed in the first place.

How Application Teams and Identity Administrators Should Divide the Work

The cleanest operating model is to treat identity as the policy engine and the application as the policy consumer. Identity administrators own the role catalogue, naming standards, group membership logic, and lifecycle controls. Application teams own the resource map: which functions require access, where screen-level or API-level checks occur, and which business workflows need stronger controls than the default role can express.

In practice, that means access decisions should be made at design time together, then enforced at runtime through the identity layer. The app team should define:

• what actions require access approval or step-up controls,
• which screens, APIs, or data sets are sensitive enough to need finer-grained rules,
• what happens when a role is added, removed, or inherited through another group.

The identity team should define:

• the authoritative role model and permission taxonomy,
• joiner, mover, and leaver processes,
• periodic access review and exception handling,
• how access is revoked when a role becomes stale or overbroad.

This split works best when it is governed by documented policy and audit evidence, not informal agreement. NIST Cybersecurity Framework 2.0 supports this approach by tying access control to governance and risk management, while Lifecycle Processes for Managing NHIs reinforces the need to align identity ownership with offboarding, rotation, and review. These controls tend to break down when teams centralise roles in identity but leave the application free to interpret permissions differently across modules.

Where This Model Gets Messy in Real Environments

Tighter central control often increases coordination overhead, requiring organisations to balance consistency against the speed of application change. That tradeoff is real, especially in legacy systems, federated estates, or applications with deeply embedded screen-level logic.

There is no universal standard for this yet, but current guidance suggests the split should flex based on complexity. If an application has simple coarse-grained access, identity can own more of the enforcement logic. If the application has sensitive workflows, exception paths, or data-specific rules, the app team must retain clear ownership of the enforcement points even when the role model lives elsewhere.

Common edge cases include merged applications with different permission histories, acquired systems with inconsistent role names, and service accounts that bypass human review entirely. Those environments often need a cleanup phase before ownership can be clarified. The strongest practice is to document a single decision path for each entitlement: who defines it, who approves it, who enforces it, and who reviews it. That is also where audit teams look first, because ambiguous ownership usually leads to stale permissions, duplicate roles, and delayed revocation. In fact, NHIMG notes that 71% of NHIs are not rotated within recommended time frames, which is a reminder that unmanaged identity processes tend to decay fastest where accountability is weakest.

Related resources from NHI Mgmt Group

• Who should be accountable when access decisions in Django span both application code and an external policy layer?
• Why do employees who change roles create access risk if permissions are not updated quickly?
• Who should own access decisions when identity controls are spread across multiple platforms?
• Who should own governance when AI agents cross identity, access, and application teams?