Mapping business requirements to authorization policy for utilities

It’s a few minutes before 9am, and Zoe is waiting for her morning cuppa at a local café. One soy milk matcha latte for Zoe!” yells the barista. Zoe, a cybersecurity control operator, grabs her drink and hurries across the road into a multi-storey office, she walks into a massive room where screens reach three floors high. These belong to the SCADA systems of EGL utility company, where every action is controlled and monitored, and authorization acts as the lifeline keeping the systems operating smoothly.

About six months ago, the Sydney-based electricity and gas utility company EGL Ltd (a fictitious organization) was deciding how to modernize its authorization capabilities. The company evaluated two approaches: adopting the Cerbos authorization platform, or continuing to manage authorization internally using a roles-based access matrix spread across databases and embedded application rules.

In this article, we compare what life looks like from day two in production under each approach, contrasting the experience of running authorization on Cerbos versus maintaining a role-based authorization model at enterprise scale.

While deploying an authorization system is no small feat, keeping it running smoothly is a whole other ball game. Especially when it comes to the day-to-day challenges of maintaining and updating it at a utility company.

If you’re a Head of Cybersecurity or responsible for the IAM (Identity and Access Management) function, you know this feeling. Did you make the right decision between building an authorization system in-house versus adopting a dedicated platform? Has your chosen approach delivered what you expected, or does reality fall short? Does it free up your time, or does it end up consuming more of it?

To showcase the differences between a traditional RBAC model and a policy-based approach using Cerbos, we’ll examine a set of recurring operational and governance scenarios commonly seen in utility companies. Each scenario is reviewed under both approaches to highlight the impact on delivery effort and risk.

EGL intends to perform:

1. Making a change to an authorization policy for gas flow sensor access.
2. Deploying the updated authorization policy into production.
3. Onboarding a new application into EGL's authorization framework.
4. Providing authorization logs to an external auditor for ISO27001 compliance certification.
5. Onboarding a third-party vendor.

 

Challenges

The authorization landscape of the utility industry presents itself with challenges that are unique to the way it operates:

1. Complex access requirements Utility companies often have a mix of user populations that access their systems, consisting of internal employees, short-term contractors, third-party vendors, and external auditors. Each of them who may have access to similar systems and resources, but may vary by the location, duration of access, time of access, read or write access, and other fine-grained permissions.

2. Operational complexity SCADA and other OT (operational technology) often have different authorization mechanisms compared to IT (information technology) systems. Maintaining consistent access policies across them is sometimes tricky.

3. Dynamic pressures shaping authorization Unlike many other industries, utility companies face constant cost pressures on electricity and gas rates due to factors such as:

• Government policies and regulatory changes
• Grid demands, including fluctuations in consumption or incoming power from renewable sources like solar
• Inflation and economic pressures
• Other operational factors

Each of these can directly affect authorization requirements. If policies rely solely on RBAC (role-based access control), these changing conditions may lead to frequent updates and administrative overhead. In contrast, ABAC (attribute-based access control) allows policies to adapt dynamically to contextual factors, reducing the need for constant manual adjustments.

4. Unauthorized access Operational Technology (OT), which serves as essential infrastructure for utility industries, must be protected against unauthorized access, equipment tampering, and compliance violations. Each and every equipment plays a critical role in ensuring the system operates efficiently and delivers accurate results. A compromised gas flow sensor, a tampered circuit breaker, a switchgear, or a non-compliant billing system can have serious consequences for operations. Utilities often operate on thin profit margins, so even a brief disruption can significantly impact business.

 

A quick refresher on authorization policies

Before we take a look at EGL managing the authorization platform, let's do a quick refresher on an authorization policy. The building blocks of the policy are:

• Principal
• Action
• Resource

Principals are the actors performing the action, such as an Operational Engineer. Actions are the acts performed by the principals, such as read, write, and update. A resource is the entity on which the action is being performed like a gas flow sensor, SCADA system, customer data, and so on.

Popular ways of implementing authorization include:

• RBAC: Role-based access control, where access to resources, such as read, write, or update are granted via roles. This requires pre-defined user-to-role mapping and role to resource mapping.
• ABAC: Attribute-based access control relies on attributes of resources or principals to grant access.
• PBAC: Policy-based access control, an extension of ABAC, is the process of centralizing the definition of access control.

The RBAC way of applying access control relies on traditional, well defined roles that account for all responsibilities of users. This often falls short of any contextual parameters that are accounted for in ABAC. For example, ABAC can account for access based on location or time to allow for access. Please refer to this article for more on the RBAC vs ABAC discussion.

 

Living with the authorization platform

Zoe has assumed operational responsibility for the authorization platform as part of her broader remit overseeing cybersecurity across EGL’s control centre.

Scenario 1: Updating the gas flow sensor access policy

In the SCADA control room, Zoe is viewing the section where the NSW (New South Wales) regional gas distribution network is monitored. A slew of warning notifications pop up in the dashboard where live telemetry from gas flow sensors are present. While the situation does not yet require an emergency shutdown, it does need further investigation. Under normal circumstances, regional operations engineers can view and adjust setpoints for these assets. However, as the anomaly presents itself, additional temporary access is needed for senior pipeline engineers to access affected zones and adjust sensor readings.

Managing access with roles database & embedded app rules

If this were managed using RBAC and access was needed quickly, the organization might rely on a purely RBAC-based approach, with authorization enforced through application logic and role assignments. In that case, access to the gas flow sensors would be controlled solely through role changes, and the required update would look like this:

From

// Access to only regional operational engineers
if (role === "regional_operations_engineer" &&
    resource === "nsw_regional_gas_flow_sensor") {
  access = "ALLOW";
}

To

// Access to regional operational engineers and pipeline engineers
if (
  (role === "regional_operations_engineer" ||
   role === "senior_pipeline_engineer") &&
  resource === "nsw_regional_gas_flow_sensor"
) {
  access = "ALLOW";
}

The challenge with this approach is that RBAC policies are inherently static. As a result, senior pipeline engineers may retain access to gas flow sensors even after the warning condition has been resolved. Cleaning this up requires additional RBAC and application-level updates, which in practice are often delayed or overlooked.

Managing access with Cerbos

While Cerbos supports RBAC policies, ABAC policies in Cerbos are where it shines when contextual information can be leveraged in access decision.

The current RBAC policy in Cerbos would be defined, always giving access to regional operations engineers at all times, as follows:

---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  resource: "nsw_regional_gas_flow_sensor"
  version: "default"
  rules:
    - actions: ["view", "update"]
      effect: EFFECT_ALLOW
      roles:
        - regional_operations_engineer

Senior pipeline engineers should only receive temporary access with authorization from Zoe. Under this policy, the senior pipeline engineers can access only when all the following conditions are met:

• Zoe’s authorization is present
• The user’s title includes “Senior Pipeline Engineer” or higher
• The access occurs during business hours
• The user is physically at a regulator station where the sensor is located

# Derived Role
---
apiVersion: api.cerbos.dev/v1
derivedRoles:
  name: pipeline_access
  definitions:
    - name: temporary_authorized_senior_engineer
      parentRoles: ["pipeline_engineer"]
      condition:
        match:
          all:
            of:
              - expr: request.principal.attr.zoe_authorization == true
              - expr: request.principal.attr.title.matches("Senior Pipeline Engineer|Principal Pipeline Engineer|Lead Pipeline Engineer")
              - expr: now().getHours("Australia/Sydney") >= 9
              - expr: now().getHours("Australia/Sydney") < 17
              - expr: request.principal.attr.location == "regulator_station_nsw"

# Resource Policy Updated
---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "nsw_regional_gas_flow_sensor"
  importDerivedRoles:
    - pipeline_access
  rules:
    - actions: ["view", "update"]
      effect: EFFECT_ALLOW
      roles:
        - regional_operations_engineer
    - actions: ["view", "update"]
      effect: EFFECT_ALLOW
      derivedRoles:
        - temporary_authorized_senior_engineer

Derived role documentation

As you can see, the policy is more contextually aware, and senior engineers can access the gas flow sensors under certain conditions. While the existing RBAC access for regional operations engineers is retained. This approach is far more flexible and adaptive. And the pipeline engineers no longer have access once the authorization expires and/or other parameters are not met, keeping the intended use of the policy.

Scenario 2: Authorization policy rollout

Following the policy updates to the gas flow sensor, Zoe would like to implement the access policy to the production systems. She needs the rollout to have minimal disruption to systems and provide access to the senior pipeline engineers at the regulator stations. The IT change management team has been engaged for the access policy change rollout.

Managing access with roles database & embedded app rules

The IT change management team submits the change details for Zoe’s approval. Zoe then logs into the change management system to review and authorize the request.

Change Number	CHG100095
Change Description	Update gas flow sensor access policy across managed systems
Submitted By	IT Change Management Team
Approval Required By	Zoe (Authorization Owner)
Scheduled Date and Time	10 March 2026 5:00pm AEST
Change duration	2 hours
Risk Level	🟡 Medium
Down Time Required	Yes

Impacted Systems

System ID	System Name	Change Description	Expected Impact
A01	App Roles Management SQL Database	Onboard new roles: Senior Pipeline Engineer, Principal Pipeline Engineer, Lead Pipeline Engineer. Upload user-to-role mappings.	No downtime; data upload occurs during maintenance window.
A02	Gas Flow Monitoring System (SCADA Dashboard)	Update access policy to enforce contextual access for senior pipeline engineers.	Application downtime of ~2 hours while policy update is applied and tested. Sensor data will be offline during this period; manual readings may be required for monitoring.

After reading the change details, although not surprising, Zoe hadn’t realized that the gas flow monitoring system would go offline for 2 hours and that she must coordinate with the team at the regulator station for manual readings to be reported during the change window. Nevertheless, she approves the change for deployment and proactively lets the management team know about the system downtime and that overrides need to be set up in the SCADA system to avoid false alarms.

Managing access with Cerbos

In contrast with the previous approach, in the world of Cerbos, the IT change management team prepares the change details in co-ordination with the analysts working on the change and submits it for Zoe's approval.

Change Number	CHG100095
Change Description	Update gas flow sensor access policy across managed systems
Submitted By	IT Change Management Team
Approval Required By	Zoe (Authorization Owner)
Scheduled Date and Time	10 March 2026 5:00pm AEST
Change duration	10 minutes
Risk Level	🟢 Low
Down Time Required	No

Impacted Systems

System ID	System Name	Change Description	Expected Impact
A03	Cerbos	Update the Cerbos policy Hub with version 2.0.1 of the policy set from the version controlled git repo, with addition of 1 resource policy	No downtime; Few seconds needed for policy synchronization from Cerbos Hub to the 3 associated PDPs (Policy decision point)

Zoe is pleasantly surprised at how quickly the access policy rolls out, and without any downtime. More importantly, none of the downstream systems receiving the updated policy are affected. The entire change window is over in minutes, short enough for her to step away for the next coffee break and return to business as usual.

Policy Updates: When a policy build is successful in Cerbos Hub, it distributes the pre-compiled policies to the relevant PDPs. The PDPs, which hold policies in memory for low-latency decisions, then hot-reload the latest version without any downtime.

Zoe schedules the policy update as planned, then quickly moves on to her primary utility responsibilities, assisting the pipeline engineers on-site to resolve the gas flow sensor issue.

The following architecture view shows how Cerbos Hub manages versioned policies, how updates flow through CI, and how each application, including SCADA, evaluates decisions locally through its PDP without interrupting operations.

Scenario 3: Onboarding a new application

At the end of an authorization deployment project and once it has gone live, we would like for the project parameters to stay intact. However, in reality, this is rarely the case; applications are constantly being onboarded into, and deprovisioned from, the EGL enterprise systems. Zoe has been tasked with overseeing the decommissioning of Vendor A’s Mobile Field App, used by field engineers to inspect assets, record readings, and manage maintenance tasks, while migrating operations to Vendor B’s solution. As part of the migration, the authorization policy logic must be rebuilt in Vendor B’s system, which is written in Rust and uses a different user and resource schema, replacing Vendor A’s .NET-based system. (Check Cerbos API documentation here)

Managing access with roles database & embedded app rules

A team of developers, business analysts, and a project manager is formed to run agile ceremonies to complete the migration of 200 authorization policies. Zoe has been informed that the policy migration would take an estimated duration of 12 sprints to perform build, test, and get it ready for production deployment.

Here are the sample sprint backlog tickets for the activities to be performed:

Epic	Story Points	Task Name	Sprint	Assigned To
Policy Migration	8	Analyze existing 200 authorization policies	1	Business Analyst
Policy Migration	13	Map policies to application roles and embedded rules	1-2	Developer
Policy Migration	21	Rewrite policies into application logic	2-4	Developer
Policy Migration	8	Unit testing of rewritten policies	3-5	Developer
Policy Migration	8	Integration testing with SCADA and field apps	4-6	Developer
Policy Migration	5	Document policy changes	5-6	Project Manager
Policy Migration	8	User acceptance testing and deployment	6-7	Business Analyst / Developer

As you can observe, this is a reasonably lengthy development effort that spans an entire quarter, approximately three months.

Managing access with Cerbos

In contrast, when using the Cerbos platform, a lean team of developers, business analysts, and a project manager is formed for the migration of 200 authorization policies. Zoe has been informed that it would take 2 sprints (approximately one month) to complete the migration.

Here are the sample sprint backlog tickets for the activities to be performed:

Epic	Story Points	Task Name	Sprint	Assigned To
Policy Migration	5	Analyze existing 200 authorization policies	1	Business Analyst
Policy Migration	8	Define policies in Cerbos (no rewriting needed)	1	Developer
Policy Migration	5	Update integration point from .NET SDK to Rust SDK	1	Developer
Policy Migration	5	Integration testing with SCADA and field apps	2	Developer
Policy Migration	3	UAT execution and production deployment	2	Business Analyst / Developer

With Cerbos, the migration is faster because there’s no need to rewrite the authorization policies within the application. Once the policies are defined in Cerbos, they remain unchanged and can be used by the new vendor system simply by updating the integration point. In this case, switching from the .NET SDK to the Rust SDK to call the PDP (Policy Decision Point), from the list of SDKs provided by Cerbos.

Scenario 4: ISO27001 compliance

EGL is seeking ISO27001 certification for its systems and is undergoing compliance activities to get certified. EGL’s management team has nominated Zoe to be the primary liaison from EGL to the external auditors overseeing the certification process. The auditors have requested samples of authorization logs from EGL’s systems, focusing on certain key periods such as incident windows and post-deployment of new applications.

Managing access with roles database & embedded app rules

Zoe calls for a technical meeting with all application system owners and gets them on board for the compliance project, which takes precedence over non-critical business activities. Each app owner needs to nominate a systems analyst from their team who can pull out the authorization decisions from different systems. Zoe then tracks progress and follows up multiple times until all policies and logs are collected and converted into a unified format. The process involves significant coordination and effort to compile the reports.

Managing access with Cerbos

With Cerbos managing authorization policies, the process is much simpler. Zoe logs onto the Cerbos Hub console, navigates to the audit section, and downloads the decision logs for the required time periods. She can then hand over the logs to the auditors, and the entire activity lasts for about a couple of minutes or about.

Scenario 5: Onboarding a third-party vendor

EGL’s management has decided to open up the business to allow bulk electricity and gas exports to third-party vendors, who can then resell these units to their own customers at market bulk rates. To support this initiative, the vendors need access to the Wholesale energy trading system at EGL, that track energy allocations, consumption data, and delivery schedules.

However, since they fall into a different user category than internal staff, their access must be strictly read-only. They can view the necessary information to operate effectively, but cannot modify any operational data or trigger system actions.

Zoe has been tasked with leading the authorization policy design for this initiative. She forms a team to define the strategy and assess access requirements, starting with the initial access matrix submitted for her review.

Resource	Action	Internal Staff: Market Analyst	Third-Party Vendor: Market Analyst (External)	Internal Staff: Trading Manager	Third-Party Vendor: Trading Manager (External)
Bulk Energy Allocation	View	✔	✔ Only between 8am-6pm and north-west Sydney region only	✔	✔ Must have completed the trading ethics course
Bulk Energy Allocation	Edit	✔	✖	✔	✖
Market Settlement Ledger	View	✔	✔ Cannot view solar feed-in settlements	✔	✔ Cannot view solar feed-in settlements
Market Settlement Ledger	Approve	✔	✖	✔	✖

From the above access matrix, you can observe that internal staff and vendors have different access. Internal staff have traditional access, such as view and edit to the resources, whereas the vendor staff has read-only access, and that too with additional contextual conditions.

Managing access with roles database & embedded app rules

Since the wholesale energy trading app is built on Python, the new authorization rules need to be developed and deployed in this coding language. Additionally, as a matter of policy, authorization policies for internal staff need to be kept separate from vendor authorization policies, and hence, a separate database table is instantiated. The brief high-level steps to achieve this would be:

1. Build authorization policies in python code in the app, deploy and test in non production environments.
2. Create and maintain a separate database table instance for storing vendor authorization policies.
3. Plan and schedule deployment for production for authorization policies, which may include downtime for the app.

A sample authorization policy written in Python

from datetime import datetime

def can_access_bulk_energy_allocation(user, action, context):
    """
    Simple policy evaluation for bulk_energy_allocation.
    """
    role = user.get("role")
    current_hour = datetime.now().hour
    region = user.get("region")
    completed_ethics = user.get("completed_trading_ethics", False)

    # Internal staff roles
    if role in ["market_analyst", "trading_manager"]:
        # Internal staff can view and edit
        return action in ["view", "edit"]

    # External Market Analyst
    if role == "external_market_analyst":
        if action == "view":
            return (8 <= current_hour <= 18) and (region == "north-west_sydney")
        return False

    # External Trading Manager
    if role == "external_trading_manager":
        if action == "view":
            return completed_ethics
        return False

    return False

Managing access with Cerbos

In this case, EGL is using the cloud-native Cerbos Hub, a PAP (Policy administration point), which provides the capability to spin up new tenants while maintaining the same platform to oversee policies across both. The brief high-level steps to achieve this would be:

1. Take a copy of the YAML-style authorization policies into the new tenant.
2. Edit the policies to retain only read-only access. Additionally, configure contextual conditions for the accesses.
3. Plan, test, and schedule deployment with no down time in production.

A sample authorization policy written in YAML on the Cerbos platform

# role_market_analyst.yaml
apiVersion: api.cerbos.dev/v1
rolePolicy:
  role: "market_analyst"
  rules:
    - resource: "bulk_energy_allocation"
      allowActions:
        - "view"
        - "edit"
---
# role_trading_manager.yaml
apiVersion: api.cerbos.dev/v1
rolePolicy:
  role: "trading_manager"
  rules:
    - resource: "bulk_energy_allocation"
      allowActions:
        - "view"
        - "edit"

Because Cerbos uses a YAML-based policy format, policies are quicker to define and easier to test than those implemented directly in application code. Cerbos Hub also supports policy testing with sample data, allowing teams to validate behaviour and build confidence before rolling changes into production. In addition, the ABAC approach makes it straightforward to apply contextual conditions directly in the policy, avoiding complex application logic and enabling business analysts, rather than developers, to maintain and evolve access rules.

 

Conclusion

Utility companies form the backbone of a country. They supply energy to public institutions, businesses, and households, keeping the economy moving. If you're part of the management team at a utility, your goal is steady, predictable operations - when issues arise, your focus should be on restoring service or improving infrastructure, not wrestling with internal authorization platforms.

As we've demonstrated, centralized PBAC with contextual conditions like geolocation, time, and authorization status lets you go from thousands of lines of authorization code spread across applications to a few hundred comprehensive YAML-style policies - git versioned and maintainable by business analysts. Policy updates roll out in seconds without downtime, compliance audit artefacts can be produced in minutes instead of days, and onboarding new applications or vendor tenants takes days rather than months.

This isn't just theoretical. Utility Warehouse, a FTSE 250 multiservice energy provider, replaced a cumbersome in-house authorization system spanning 4,500 services with Cerbos. The result: months of developer time reclaimed, a Zero Trust architecture with granular access control at every service hop, and full audit visibility for SOC and ISO compliance. Their Principal Engineer, Rob Crowe, summed it up: "Cerbos allows our team to focus on getting rid of technical debt and other business use cases instead of wondering how to write a policy evaluation language."

Give Cerbos a try and see the value for yourself.

---

If you’re interested in implementing externalized authorization - try out Cerbos Hub for free, or book a call with a Cerbos engineer to see how our solution can help streamline access control in your fintech applications.

To explore mapping business requirements to authorization policy for other domains - check out our foundational guide, or dive into these blogs specific to HR systems, insurance, aviation and MedTech.