IT should own the policy, guardrails, and exception handling, while engineering teams use self service to request the access or environments they need within those controls. That division lets IT enforce standards without becoming the bottleneck for every request. It also creates a practical balance between governance and productivity, which is the main reason self service scales well.
Where the ownership boundary belongs
The cleanest split is between control and consumption. IT defines the policy, approval criteria, guardrails, and exception path, while engineering uses self service to obtain approved access, environments, or secrets without waiting on manual ticket handling. That keeps the authority to grant access with the team responsible for governance, while pushing routine requests into a faster operational path.
Self service works only when the request is constrained by pre-approved templates, scoped permissions, and clear ownership for the underlying system. If engineering can bypass those controls, the model stops being self service and becomes unmanaged delegation.
This is the same operating model that makes lifecycle discipline possible in broader identity programs, especially where access, rotation, and offboarding must be controlled centrally even if the request path is automated. NHI Lifecycle Management Guide is a useful reference for that governance pattern, and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs explains why provisioning and revocation must stay policy-led rather than ad hoc.
What each team should actually own
IT should own the control plane: policy definition, entitlement boundaries, approval rules, logging requirements, periodic review, and escalation for anything outside the standard path. Engineering should own the operational request and use phase: specifying what they need, selecting from approved options, and validating that the provisioned access matches the intended use case.
That division prevents two common failures. First, it prevents IT from becoming a manual fulfillment queue for every routine environment or access request. Second, it prevents engineering from becoming the de facto policy engine through convenience, which usually leads to inconsistent access patterns and weak oversight.
The risk is easier to see when access objects are overprivileged or poorly retired. NHIMG’s Top 10 NHI Issues highlights the recurring failure modes around ownership, visibility, rotation, and excessive privilege, and the Ultimate Guide to NHIs, Standards shows how teams can anchor that ownership in established controls rather than informal practice.
Making self service safe at scale
Self service scales when the default path is narrow and predictable. The strongest model is: approved request types, pre-set access tiers, explicit expiration where possible, and a visible exception route for anything that falls outside the standard controls. The more variation you allow in the self service path, the less governance value you retain.
Teams should also distinguish between routine access and high-impact access. Routine access can be automated aggressively if it is bounded and logged. Elevated access, cross-environment access, and anything that can expose production systems or sensitive secrets should remain under tighter policy review, even if the request itself is submitted through self service.
The 2025 State of NHIs and Secrets in Cybersecurity is a useful companion when you are deciding how much trust to place in automated access paths, and the fact that 97% of NHIs carry excessive privileges is a reminder that the real control problem is not request speed, it is privilege scope.
Risk and Threat Considerations
Self service reduces bottlenecks, but it also concentrates risk if the guardrails are weak. The main failure mode is not the portal itself, it is uncontrolled entitlement sprawl, stale access, and poorly governed exceptions that outlive the original need.
Failure mechanism: A requester receives access through a standard workflow that is too broad, too long-lived, or insufficiently reviewed, then uses that access outside the intended scope or after the need has ended.
Impact: Over time, the organisation accumulates unnecessary access paths, larger blast radius, and weaker accountability, which increases the chance of misuse, accidental exposure, and difficult-to-revoke privilege.
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 CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Self service provisioning depends on controlled access grants and revocation. |
| 5 — Account Management | Ownership boundaries hinge on provisioning, review, and removal of access over time. | |
| Recommendation — Define approval paths, least-privilege entitlements, and revocation checks for self service access. Assign clear account owners and automate review and removal of stale access. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The question is about dividing access authority and enforcing guardrails around provisioning. |
| GV.RM — Risk Management Strategy | Self service needs governance decisions about exceptions, scope, and acceptable automation risk. | |
| Recommendation — Separate policy enforcement from request fulfillment and limit access to approved scopes. Set risk thresholds that determine when self service can proceed and when exceptions need review. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Provisioning workflows should match the assurance needed for the requested access. |
| AAL — Authenticator Assurance Level | Self service access depends on how strongly users are authenticated before entitlements are granted. | |
| Recommendation — Require stronger proofing and verification for higher-impact access requests. Use stronger authentication before granting access to sensitive environments or secrets. | ||
| NIST Zero Trust (SP 800-207) | 4 — Policy Engine and Policy Administrator | Self service should be governed by centralized policy with automated enforcement. |
| Recommendation — Centralise access policy decisions and let the request path execute only approved outcomes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets Management | Automated provisioning often includes secrets, tokens, or credentials that must stay governed. |
| NHI-03 — Least Privilege and Permissions | The core question is how to let teams self serve without granting excess access. | |
| Recommendation — Store and issue secrets through controlled mechanisms rather than manual distribution. Grant only the minimum permissions needed for the requested task or environment. | ||
Practitioner Guidance
What to prioritise: Put the policy boundary in writing before expanding self service. The most important decision is which requests can be fulfilled automatically and which must always route to exception handling or higher review.
What to verify: Make sure every self service path has an owner, a defined approval rule, logging, and a revocation expectation. If a request cannot be traced back to a business purpose and an accountable owner, it is not ready for automation.
Practitioner takeaway: The goal is not to remove human judgement from access decisions, it is to reserve human judgement for the cases that actually need it while making the standard path fast, bounded, and auditable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
