Join our Newsletter — 33% off our NHI Course

How do organisations decide which access controls should stay central and which should move to resource owners?

The dividing line is context. Central teams should own the policy framework, identity standards, and audit requirements. Resource owners should manage day to day approval logic for their own systems, including approvers, request duration, and event based revocation. This balance supports scalability without giving up governance.

Why This Matters for Security Teams

Access control ownership breaks down when every approval, review, and revocation request must pass through a central bottleneck. Security teams need consistency, auditability, and policy enforcement, but resource owners understand the business context of their systems, data sensitivity, and operational urgency. The practical question is not whether to decentralise, but which decisions can be safely delegated without weakening governance. Current guidance from OWASP Non-Human Identity Top 10 and Ultimate Guide to NHIs points to a shared model: central teams define the guardrails, while owners manage system-specific decisions inside them.

This matters because over-centralisation slows change, encourages exceptions, and pushes teams toward shadow access paths. Over-delegation does the opposite, creating inconsistent approval logic, weak revocation, and stale permissions that outlive the business need. NHI Mgmt Group research shows 97% of NHIs carry excessive privileges, which is a strong signal that access decisions often drift away from least privilege once ownership becomes unclear. In practice, many security teams discover that access control gaps were created by process design long before any technical compromise occurred.

How It Works in Practice

The cleanest split is between control plane and decision plane. Central security or IAM teams should own identity standards, policy templates, privileged access patterns, logging requirements, and review cadence. Resource owners should own the approval logic that depends on their application, such as who can approve access, how long access should last, and what event triggers revocation. That division aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls and CIS Controls v8, which both emphasise consistent control objectives with accountable implementation.

In mature programmes, central teams typically set:

  • Approved identity sources, naming standards, and lifecycle rules
  • Minimum evidence required for access approval and review
  • Baseline role definitions and separation-of-duties rules
  • Logging, retention, and audit reporting requirements

Resource owners then configure system-specific approval chains, JIT duration limits, and event-based revocation conditions. That is especially important for NHI workflows, where secrets and service accounts can be over-permissioned if approvals are treated like human access requests. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how quickly this becomes operational debt when ownership is fragmented. Central policy should be enforced through tooling, not handoffs, so resource owners cannot weaken the framework even when they own local decisions. These controls tend to break down in fast-moving engineering environments where application teams can bypass central workflows through direct grants, shared secrets, or ad hoc emergency access.

Common Variations and Edge Cases

Tighter central control often increases ticket volume and slows delivery, so organisations must balance governance against operational friction. The right split depends on the risk profile of the resource, and current guidance suggests that there is no universal standard for this yet. For highly regulated systems, central teams may retain approval authority for privileged or production access, while resource owners only recommend or attest. For lower-risk internal tools, owners can approve within centrally defined policy limits.

Edge cases usually appear where access is time-bound, machine-to-machine, or tied to an incident response window. In those scenarios, resource owners may need authority to grant short-lived access quickly, but only if the control is still bounded by central rules for TTL, logging, and revocation. That is why the most effective models use central guardrails plus local execution, rather than a binary central versus decentralised choice. The NHIMG research on Ultimate Guide to NHIs — Standards is useful here because it frames governance as a lifecycle issue, not just an approval problem. Organisations with legacy IAM, multiple cloud tenants, or unmanaged API keys often need a transitional model before they can move any authority safely to resource owners.

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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-01 Defines governance boundaries for non-human identities and access ownership.
NIST CSF 2.0 PR.AC-4 Covers access permissions management and least-privilege enforcement.
CSA MAESTRO GOV-02 Addresses governance operating model for agentic and autonomous access decisions.
NIST AI RMF GOVERN-1 Supports accountable governance structures for automated decision-making.
ISO/IEC 27001:2022 A.5.15 Requires access control rules and responsibilities to be defined and reviewed.

Set central NHI guardrails first, then delegate only bounded approval logic to system owners.