Topic starter
10/06/2026 11:25 pm
TL;DR: Utility operators dealing with SCADA, contractors, auditors, and third-party vendors face growing friction when authorization is spread across roles, embedded app rules, and databases, according to Cerbos. The core issue is that static RBAC makes policy updates, onboarding, audit evidence, and contextual access harder to manage at enterprise scale.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Mapping business requirements to authorization policy for utilities”.
Key questions
Q: Why does static RBAC become hard to manage in utility environments?
A: Static RBAC struggles when access depends on changing operational conditions such as location, time, approvals, or incident state.
Q: When should utilities prioritise policy-based authorization over role expansion?
A: Utilities should prioritise policy-based authorization when the same resource must be governed differently for operators, contractors, auditors, and third parties.
Q: What breaks when authorization rules stay embedded in code?
A: Governance breaks first, because access logic becomes scattered across services and harder to review consistently.
Practitioner guidance
- Define contextual access conditions Specify which access decisions depend on time, location, approval state, or resource attributes, then express those conditions in policy rather than in application code.
- Separate policy changes from application releases Keep authorization logic versioned and testable outside the consuming application so access updates do not require code changes across every service.
- Model contractor and auditor access as temporary Avoid permanent role expansion for external users by using narrow policy conditions that expire with the work, review, or audit task.
Bottom line: Static RBAC becomes brittle when utility access needs to reflect changing operational conditions rather than fixed job titles.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 5:22 am
Static role expansion is a governance debt pattern, not just a design choice. Once utility access is expressed as more and more roles, every exception has to be encoded as another role or another application rule. That creates a growing mismatch between real operating conditions and the access model. The practitioner consequence is that authorization governance becomes harder to certify, harder to change, and easier to misapply across SCADA and enterprise estates.
A question worth separating out:
Q: How should teams govern temporary access for auditors and vendors?
A: Teams should govern temporary access with conditions that reflect the work being done, not with permanent role growth. That means tying access to approval, duration, site, or task context, and then removing the assumption that external users need standing access. The goal is narrower access with clearer evidence, not more roles.
👉 Read our full editorial: Policy-based authorization for utilities: RBAC tradeoffs at scale
This post was modified 5 days ago by NHI Mgmt Group