They treat department membership as a sufficient proxy for need. In reality, people in the same business unit can require very different application access and privilege levels. When provisioning ignores role and task context, it creates excess access that expands lateral movement risk and makes least privilege impossible to enforce cleanly.
Why This Matters for Security Teams
Department-based provisioning feels efficient because it maps cleanly to org charts, but org charts are not access models. The mistake is assuming that finance, engineering, or marketing membership says enough about what a person needs to do safely. It does not. Access should follow task, system, and privilege context, or the organisation ends up granting broad access that is never fully challenged.
This is especially dangerous when the same department includes people with very different duties, contractors, and temporary project staff. The result is persistent overprovisioning, weaker auditability, and a larger blast radius when credentials are misused. NHIMG research shows that 97% of NHIs carry excessive privileges, which is a useful warning sign for human access design as well: privilege creep is rarely obvious at issuance, but it becomes highly visible during an incident. The Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 both reinforce the same operational lesson: identity context matters more than organisational label.
In practice, many security teams encounter privilege sprawl only after a user already has access to systems they should never have reached.
How It Works in Practice
The better model is to provision access from job function, application need, and current task context, then verify that access continuously. Department membership can still be a coarse input, but it should not be the deciding factor. A payroll analyst and a payroll auditor may sit in the same business unit and still need very different permissions. Current guidance suggests using role-based controls only as a starting point, then tightening them with approval workflows, entitlements review, and time-bound access.
For mature environments, that usually means combining RBAC with finer-grained policy rules and just-in-time elevation. Access is granted only when there is a specific request, a valid business reason, and an appropriate expiry. This is the same basic principle behind stronger NHI lifecycle controls in the NHI Lifecycle Management Guide. It also aligns with least-privilege guidance in the OWASP Non-Human Identity Top 10, which treats overprivilege as a recurring control failure rather than a one-time provisioning issue.
- Map access to application, data class, and task, not just department.
- Use approval paths that require system owner review for sensitive entitlements.
- Set expiry dates for elevated or exceptional access.
- Review entitlements after transfers, promotions, and project changes.
- Remove access automatically when the task or assignment ends.
Where organisations have strong identity governance, they also compare actual usage to assigned privileges and retire permissions that are never exercised. That matters because department-based models tend to persist access long after the reason for it has disappeared. These controls tend to break down in large hybrid enterprises because entitlement catalogs are incomplete and application owners cannot reliably explain what each permission does.
Common Variations and Edge Cases
Tighter provisioning often increases operational overhead, requiring organisations to balance speed against control. That tradeoff is real, especially in shared service teams, matrix organisations, and merger integrations where job titles and reporting lines do not cleanly map to access needs.
One common edge case is temporary access for cross-functional work. A developer helping with incident response may need short-lived access to security tooling, but department-based rules will either deny the request or leave the access in place too long. Another is third-party or contractor access, where department labels are meaningless and task scope should drive every entitlement. Best practice is evolving here, but the direction is clear: access reviews should ask whether a person still needs the privilege, not whether they still belong to the same team.
For broader identity governance context, the Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks show the same pattern in machine access: static labels do not describe real usage. The human analogue is no different. Department-based provisioning can support initial routing, but it should never be treated as proof of need.
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-01 | Overprovisioning and weak entitlement scoping mirror this access-pattern failure. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management directly addresses department-based overgranting. |
| NIST AI RMF | Risk governance applies when access decisions are based on weak organisational proxies. |
Replace department-only access with task-based entitlement review and periodic least-privilege recertification.
Related resources from NHI Mgmt Group
- What do security teams get wrong about role-based access control in provisioning workflows?
- What do security teams get wrong about trust in zero-trust access models?
- What do teams get wrong about least privilege in privileged access programmes?
- What do security teams get wrong about zero trust in agentic access environments?
