Utilities should prioritise policy-based authorization when the same resource must be governed differently for operators, contractors, auditors, and third parties. If access decisions keep changing with business context, policy-based control is usually the better choice because it centralizes the decision logic instead of multiplying roles across applications and databases.
Why policy-based authorization fits better as access needs change
Role expansion works best when access is stable and the same job function can safely share a common entitlement set. Once utilities need different access outcomes for operators, contractors, auditors, vendors, and temporary responders, role count starts to grow faster than the business logic. Policy-based authorization keeps the decision rules in one place and lets the same resource be governed differently without cloning roles for every exception.
That matters most where access depends on context, not just employment status. Time of day, asset criticality, geographic location, maintenance window, segregation of duties, and emergency mode can all change the right decision. A policy layer can evaluate those conditions directly, while role expansion usually pushes teams to create narrower and narrower roles that become difficult to understand, review, and retire.
What breaks when you keep adding roles instead of rules
Role expansion creates a maintenance problem as well as an authorization problem. Each new role can overlap with others, inherit too much access, or survive long after the business case has changed. In utilities, that can produce privilege creep, inconsistent approvals across systems, and a growing gap between what the role name suggests and what the account can actually do. The result is often more manual exceptions, not less friction.
Policy-based authorization is usually the better control when the same resource must be governed differently across plants, regions, or operational states. It reduces the pressure to encode exceptions into application-specific roles and helps preserve least privilege when access decisions are conditional. For a deeper comparison of role, attribute, relationship, and policy approaches, see the Authorisation Models Guide.
How to decide which model is the better fit
Use role expansion when access is mostly static, easy to describe, and tied to a small number of repeatable job functions. Use policy-based authorization when decision logic changes often, when multiple audiences need different treatment for the same system, or when access must reflect operational context at the time of request. The key question is whether you need more categories of people or more precise decision logic.
Utilities should also look at where the decision will be enforced. If every application reimplements the same exceptions, role growth becomes brittle very quickly. If a shared policy engine can centralize those decisions, teams can keep roles coarse for administration while making the actual allow or deny decision much more precise. That is especially useful for third parties and auditors, where access should be narrow, time-bound, and easy to revoke. The broader identity and governance baseline is covered well in IAM and IGA Basics.
Risk and Threat Considerations
Role proliferation can hide excessive access because each role looks reasonable in isolation, even when the combined effect is too broad. In utility environments, that creates exposure around operational technology, maintenance tooling, reporting systems, and third-party support paths, especially when roles are copied across sites and never fully reviewed. Policy-based authorization reduces that drift by evaluating the actual request context rather than trusting a long-lived role label.
Failure mechanism: Teams keep adding roles to satisfy edge cases, which fragments governance, increases review effort, and makes it harder to prove who should have access to what under changing conditions.
Impact: The organisation ends up with broader effective access, more exception handling, weaker segregation of duties, and a higher chance that an inappropriate account can reach a sensitive control or data path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Policy-based decisions help limit access to only what each utility context needs. |
| AC-3 — Access Enforcement | The topic is about where access decisions are enforced, centrally or in roles. | |
| AC-2 — Account Management | Utilities must manage changing access for operators, contractors, auditors, and third parties. | |
| Recommendation — Apply AC-6 to keep access narrowly bounded and avoid role-driven excess privilege. Use AC-3 to enforce allow and deny decisions consistently at the resource or policy layer. Use AC-2 to keep account entitlements aligned to current business need and revoke stale access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is fundamentally about choosing a stronger access control model for changing conditions. |
| A.5.18 — Access rights | Role expansion versus policy logic determines how access rights are granted and maintained. | |
| Recommendation — Define access control rules that adapt to business context instead of multiplying static roles. Review and adjust access rights so exceptions are controlled without creating role sprawl. | ||
Practitioner Guidance
What to prioritise: Prioritise policy-based authorization for resources that are shared across functions, exposed to third parties, or governed by different operating contexts. Keep roles for coarse job separation, then use policy to decide whether the request is allowed in the moment.
What to verify: Verify that the policy inputs are reliable enough to drive the decision, such as operator status, asset class, location, maintenance state, and exception approval. If those signals are inconsistent, policy logic will only move the ambiguity from roles into the policy layer.
Common mistake: Treating role expansion as the simpler option because it is faster to implement. That usually delays complexity, then reintroduces it as role sprawl, brittle reviews, and harder deprovisioning.
Practitioner takeaway: If the access decision depends on context, not just job title, keep the role model small and let policy carry the variability.
Related resources from NHI Mgmt Group
- When should organisations prioritise policy-based access control over ad hoc role assignments in finance systems?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between policy-based access control and role-based access control for enterprise authorization?
- What do security teams get wrong about role-based logic in policy-based authorization?