Mapping business requirements to authorization policy for automotive

A board member at a major car company picks up the morning news to find that a faulty firmware update at his company was pushed to 50,000 vehicles overnight. Customer phones are ringing, regulators are asking questions, dealer service desks are overwhelmed, and no one can immediately answer who authorized the push.

This is no longer a hypothetical scenario.

In November 2023, a “fat-finger” incident by a Rivian engineer inadvertently pushed the wrong firmware build, which included incorrect security certificates and code, to a number of R1T and R1S vehicles across the fleet. A month later, Tesla's December 2023 Over-The-Air (OTA) software update was pushed to over 2 million vehicles, disabling their safety-critical driving systems entirely. And earlier that same year, a Chevy Colorado OTA update left owners with drained vehicle batteries.

Three incidents, three different manufacturers, all having one common thread: software reaching vehicles without adequate control over who could push it, to which vehicles, and under what conditions.

The connected car is more than just a vehicle to travel, it is effectively a data platform on four wheels. So when your enterprise endpoints are zooming through on public roads, traditional authorization is not enough. In this blog, we are driving into the modern automotive data stack to see where standard access control breaks down and how a policy-as-code approach provides the security required for the open road.

Authorization Landscape

Safeguarding computer system resources has traditionally meant using RBAC (Role-Based Access Control). The idea is pretty straightforward, transform your organisation's access patterns into roles such as vehicle engineer, production manager and cybersecurity analyst, and assign users to those roles, thus letting the role determine what they can do.

It works objectively until it doesn't. Over time, more projects spin up based on needs, and more bespoke roles get created to meet a deadline, and hardly anyone cleans them up. Then with every passing day, you accumulate hundreds of roles that partially overlap, contradict each other, or grant access nobody can justify anymore. This is called role explosion, and it's an endemic problem in large enterprises including automotive.

ABAC (Attribute-Based Access Control) emerged to address what RBAC can't: context. So, rather than asking "what role does this user have?", ABAC asks "who is this user, what are they trying to do, to what resource, under what conditions?" A Vehicle Engineer might be allowed to push firmware to a test fleet but not a production fleet. A Cybersecurity Analyst might be allowed to read Electronic Control Unit (ECU) diagnostics during an active incident, but not otherwise. ABAC makes those distinctions expressible. CARIAD, Volkswagen Group's software entity, adopted the ABAC model explicitly across its connected vehicle platform, precisely because vehicle data access can't be reduced to a fixed set of roles.

The next problem was consistency. As organisations scaled, authorization logic ended up scattered across services, written in different languages by different teams, drifting out of sync. The same rule would be implemented differently in three places, and nobody noticed the discrepancy. Policy-as-code treats authorization rules the way engineering teams treat application code, which is by performing version control, reviewing it, testing, and finally deploying it. Cerbos is built around this model, where policies are written in YAML, live in a Git repository alongside your other infrastructure, and are auditable in the same way your codebase is. When a rule changes, it changes in one place and when something goes wrong, you have an audit trail.

Architecturally, Cerbos runs as a sidecar or standalone service, a PDP (Policy Decision Point) that your applications call at the moment of an access request. The application (the PEP or Policy Enforcement Point) asks: "Can this principal perform this action on this resource?" Cerbos evaluates the policy and returns a decision. The logic never resides in the application code. In cases where it is not practical for automotive apps to consistently reach out to the central PDP, Cerbos supports the use of ePDP (Embedded Policy Decision Point), that executes authorization logic locally using WebAssembly, without requiring network calls.

The building blocks of a Cerbos policy are:

Principals — the entities requesting access. In an automotive context: a Vehicle Engineer, Cybersecurity Analyst, Production Manager, or Executive. Resources — the assets being protected. Here: a Vehicle ECU configuration, a Customer Vehicle record, or a Supply Chain System. Actions — what the principal wants to do: read, write, delete, approve, execute.

Policies are then written and maintained in cloud-native Cerbos Hub or self-managed git repositories.

Enterprise Automotive Platform landscape

The enterprise automotive platform is not a one-size-fits-all; it reflects how each OEM structures its supplier relationships throughout the supply chain and even beyond into the car owner’s usage lifecycle.

At one end of the spectrum, the OEM owns the entire connectivity stack and a single platform governs everyone, the workforce, and supplier partners. For example, BMW's Cloud Data Hub on AWS, processing 10TB of vehicle data daily while BMW retains full control of everything in it.

At the other end, OEMs and suppliers maintain their own platforms and exchange data under contract. Catena-X has modernised this significantly, a federated ecosystem where each participant runs their own EDC (Eclipse Dataspace Connector), negotiating data sharing peer-to-peer while retaining full sovereignty over their data. A real-world example is Ford joining the Catena-X ecosystem in 2022, aimed at improving sustainability in the automotive supply chain.

Each pattern carries a different access control challenge, but the question is the same across all four: who is authorised to act on data?

Cerbos addresses this through two complementary capabilities.

1. Logically, keeping Workforce authorization policies separate from suppliers and partners authorization policies by spinning up multiple tenants in 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. Read more on tenant policy segregation.

2. Suppliers and partners introduce a different access control problem. It's not just about what role someone holds, but also whose data they're touching. A Tier 1 supplier should be able to read their own component telemetry, but not another supplier's. A partner with read access to supply chain data shouldn't be able to see customer vehicle records. ABAC handles this by tagging resources with ownership attributes and evaluating them at decision time, rather than encoding every permutation into roles. In Cerbos, this is handled using resource policies by attaching a data_owner attribute to the resource and matching it against the principal's organisation at policy evaluation. The policy example below illustrates this.

# resource_policy.access.yaml
---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "supply_chain_system"
  rules:
    - actions: ["read"]
      effect: EFFECT_ALLOW
      roles: ["supplier", "partner"]
      condition:
        match:
          expr: request.resource.attr.data_owner == request.principal.attr.organisation

Persona: Who is holding the car keys ?

A software-defined vehicle (SDV), electric or otherwise, has the principal (user) problem: Who is holding the keys now?

A vehicle isn't a static asset; it’s a moving target of overlapping permissions. Over its lifecycle, dozens of distinct "principals" require access. If your authorization logic is hardcoded, every one of these transitions is a potential security incident waiting to happen. In Identity and Access Management (IAM), this is usually classified into separate domains:

• Workforce IAM, also referred to as B2E.
• Partner IAM, also referred to as B2B.
• Customer IAM (CIAM), also referred to as B2C.
• Non-Human Identity management (NHI) or autonomous driving system identities.

Each persona introduces specific authorization requirements.

1. Workforce

The Factory Engineer needs deep diagnostic "write" access, but only while the VIN (vehicle identification number) is on the production line. Once it passes the gate, that permission must be programmatically dead.

The Vehicle Engineer has the technical capability to push firmware, but should only be "authorized" to do so if a change request is approved and the target fleet is in a non-safety-critical state.

2. Partner

In the era of the "connected car" , you are inviting Tier 1 suppliers and service partners into your data environment.

Suppliers (for example, Bosch, Continental) should only see telemetry for the components they built. A powertrain supplier has no business seeing ADAS (Advanced Driver Assistance Systems) sensor data. Static roles can’t solve this; you need attribute-based policies that map component IDs to supplier IDs.

Dealer Technicians and Logistics Providers represent ephemeral (temporary) access. A technician’s right to "execute" a diagnostic sweep should begin with a service work order and expire the moment the car is marked "ready for pickup."

3. Customer

The most complex authorization challenge is the owner, guest, second-hand-buyer loop. The Owner is the "consent anchor." They manage profiles and accept OTA updates. The Guest or Valet is a "Driver" but not a "Manager." They need to drive the car but must be denied "read" access to the owner’s payment credentials or "execute" permissions for remote commands. Finally, the resale is the ultimate authorization test. When a vehicle changes hands, the previous owner’s access must be nuked, not through a manual dealer reset, but via an automated policy change that recognizes a new "Owner" attribute.

4. Non-Human

In this category, we are not just referring to autonomous driving systems with identities that are used for autonomous driving and parking in modern EVs like Tesla, but the full breadth of machine identities such as telematics units, OTA update agents, V2X endpoints, and service mesh identities operating without a human in the loop. Policies need to be in place to identify and if a human or a non-human identity is accessing the resource and apply different authorizations accordingly. For example, a vehicle engineer and a telematics agent (non-human) both may require access to the vehicle telemetry system. The engineer may need access to fault codes and initiate a diagnostic session, but the agent should not be able to initiate a diagnostic session; it can read and write to the telemetry. With the increasing adoption of AI agents, its not far fetched where AI agents would be increasingly deployed across multiple systems in the car for autonomous activity.

The same APIs and the same ECUs are hit by all these users. The difference isn't in the identity, it’s in the policy. A valet isn't a valet forever, and an engineer isn't an admin everywhere. When you hardcode these rules into your microservices, you create an inflexible system that can’t handle the fluid reality of the automotive lifecycle. This is where decoupling the policy from the code becomes a necessity.

Let’s look at some example policies defined in Cerbos that can help address this when multiple personas access the same resource. To be clear, we are referring to users accessing resources via OEM’s cloud APIs, where authorization systems such as Cerbos reside and can take action.

Example 1: Which users can authorize OTA updates and when.

Resource	Action	Vehicle Engineer (Workforce)	Production Manager (Workforce)	Owner (Customer)	Guest (Customer)	OEM Partner (Partner)
OTA Updates	approve	✔️ if update is in "staged" status	✔️	❌	❌	✔️ if partner agreement status is "active"
OTA Updates	deploy	✔️ if vehicle is in "test fleet" group	✔️ if update has been approved	✔️ if vehicle is within active service contract	❌	✔️ if partner agreement status is "active"
OTA Updates	rollback	✔️	✔️	✔️ if vehicle is within active service contract	❌	✔️ if partner agreement status is "active"

In this scenario, we have "OTA Updates" as a resource and highlight which principals can perform what action against this resource. The action approve defines if the update can be sent to the fleet of vehicles, deploy defines if the OTA update can be deployed to the vehicle, and rollback is to undo the updates. The following is an example of a Cerbos-style YAML policy defined for the deploy action.

# resource_policy.ota_updates.yaml
---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  resource: ota_update
  version: "default"
  rules:
    - actions: ["deploy"]
      effect: EFFECT_ALLOW
      roles: ["vehicle_engineer"]
      condition:
        match:
          all:
            of:
              - expr: P.attr.principal_type == "workforce"
              - expr: R.attr.vehicle_group == "test_fleet"

    - actions: ["deploy"]
      effect: EFFECT_ALLOW
      roles: ["production_manager"]
      condition:
        match:
          all:
            of:
              - expr: P.attr.principal_type == "workforce"
              - expr: R.attr.update_status == "approved"

    - actions: ["deploy"]
      effect: EFFECT_ALLOW
      roles: ["owner"]
      condition:
        match:
          all:
            of:
              - expr: P.attr.principal_type == "customer"
              - expr: P.attr.service_contract_status == "active"

    - actions: ["deploy"]
      effect: EFFECT_ALLOW
      roles: ["oem_partner"]
      condition:
        match:
          all:
            of:
              - expr: P.attr.principal_type == "partner"
              - expr: P.attr.partner_agreement_status == "active"

Example 2: Who can run diagnostics on Vehicle ECU and under what conditions

Resource	Action	Vehicle Engineer (Workforce)	Production Manager (Workforce)	Owner (Customer)	Guest (Customer)	OEM Partner (Partner)	Telematics Agent (Non-Human)
Vehicle ECU	read_dtc	✔️	✔️	✔️ if vehicle is within active service contract	✔️ if guest session is authorized by owner	✔️ if partner agreement status is "active"	✔️ if agent is bound to the vehicle's VIN and operating within a valid telemetry session
Vehicle ECU	run_diagnostic	✔️	✔️ if diagnostic session is approved by vehicle engineer	❌	❌	✔️ if partner agreement status is "active"	❌
Vehicle ECU	clear_dtc	✔️ if fault code is not safety-critical	❌	❌	❌	✔️ if partner agreement status is "active" and fault code is not safety-critical	❌

Here, the read_dtc action is about reading diagnostic trouble codes, run_diagnostic action is self-explanatory, and clear_dtc action is about clearing the non-critical codes. Let's look at how Cerbos-style policy would be defined for the action run_diagnostic

# resource_policy.vehicle_ecu.yaml
---
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  resource: vehicle_ecu
  version: "default"
  rules:
    - actions: ["run_diagnostic"]
      effect: EFFECT_ALLOW
      roles: ["vehicle_engineer"]
      condition:
        match:
          expr: P.attr.principal_type == "workforce"

    - actions: ["run_diagnostic"]
      effect: EFFECT_ALLOW
      roles: ["production_manager"]
      condition:
        match:
          all:
            of:
              - expr: P.attr.principal_type == "workforce"
              - expr: R.attr.diagnostic_session_approved_by == "vehicle_engineer"

    - actions: ["run_diagnostic"]
      effect: EFFECT_ALLOW
      roles: ["oem_partner"]
      condition:
        match:
          all:
            of:
              - expr: P.attr.principal_type == "partner"
              - expr: P.attr.partner_agreement_status == "active"

    - actions: ["run_diagnostic"]
      effect: EFFECT_DENY
      roles: ["telemetry_agent"]
      condition:
        match:
          expr: P.attr.principal_type == "non_human"

Modern enterprise platforms seldom run a single identity provider (IDP) on the IAM platform. For example, workforce identities may live in Entra ID, customer authentication may happen through Auth0 or Cognito, and B2B partners may have their own directory. By the time an authorization request reaches Cerbos, it may carry nothing more than just a user ID or a token claim, not the full attribute context the policy actually needs. This is where Cerbos Synapse earns its place: it a Cerbos module that sits between your systems and the policy engine, pulling identity, resource, and relationship data together before every authorization decision. So the principal_type and conditions your resource policies depend on are resolved at decision time, not hardcoded somewhere upstream.

By keeping the "who can do what" to a dedicated policy layer, you keep your core vehicle services lightweight and focused on performance. In the following diagram, you can see how this centralized approach allows the same resource API to provide tailored functionality to every user in the ecosystem, from the factory floor to the driver’s seat.

Compliance

The automotive OEMs are becoming more and more conscious about compliance because adhering to international norms not only becomes their responsibility but also a competitive advantage. From the perspective of authorizations, policy-as-code is best suited to solve the security problems highlighted by the reports of Kaspersky Cybersecurity Report, Upstream Security Report, and UNECE R155/R156 guidelines.

1. Separation of Duties in Software Update Management (SUMS) The UNECE R156 rule stipulates that OEMs should provide for governed SUMS for all newly manufactured cars. It demands well thought out authorization policies to regulate actions such as triggering, approving, staging and pushing firmware updates. With the help of policy-as-code provided by Cerbos, separation of duties is achieved since the same user cannot possess permission to execute several distinct actions in the update.

2. Optimization of TARA and Audit Ready ISO/SAE 21434 mandates Threat Analysis & Risk Assessment (TARA), which is basically mapping out all the access routes to possible attack surfaces. The use of software such as Cerbos would be helpful here since in Cerbos, the policies are defined through version-controlled YAML files which clearly define what resources can be accessed by whom; thus making it easy to conduct an audit on this, as part of Cybersecurity Management System (CSMS) audit, prior to the launch of the car, which is a requirement under UNECE R155.

3. Resource Scoping of Supplier Data Based on OEM Requirements As per R155, vehicle manufacturers (OEM) have to make sure that the scope of Tier-1 and Tier-2 suppliers is restricted only to those components that they are responsible for. For example, a supplier dealing with diagnostic activities for braking ECU cannot possibly have any access to infotainment telemetry data. This requirement has been highlighted and discussed in previous posts and can be achieved using Cerbos' YAML-based policy-as-code approach.

4. Adopting Zero-Trust in SDVs In adopting Software-Defined Vehicles, the attack surface has greatly increased due to cloud services, OTA technologies, mobile applications programming interfaces, V2X communication, and third-party libraries (source). Under such circumstances, the only way to ensure security is by adopting a Zero-Trust framework. By using Cerbos' policy-as-code implementation, the organization can ensure that least privileges access is always maintained. All access will be strictly enforced according to the latest security policy.

5. Addressing Regulatory Fragmentation Around the World The automotive industry regulatory framework is extremely fragmented. Although there is an international standard for cybersecurity management in the automotive industry (ISO/SAE 21434), some jurisdictions have added additional requirements. For instance, China has GB 44495/44496, while India has its own AIS 189/190. Each jurisdiction will require unique access controls to be enforced within the system. Policy-as-code helps automotive OEMs enforce their policies for individual markets without incorporating jurisdiction-specific logic into the software source code.

Conclusion

Throughout this post, we have examined how connected cars or Software Defined Vehicles (SDVs) are not just consumer products; they are enterprise endpoints. Like any endpoint, they carry an attack surface that extends well beyond the vehicle itself, spanning the supply chain that builds them, the cloud infrastructure that serves them, and the full lifecycle over which they operate.

We explored what makes the enterprise automotive platform structurally distinct: the tight, contractual relationships between OEMs and their Tier-1 and Tier-2 suppliers, and why data scoping at the policy layer, rather than at the application layer, is the only approach that scales.

We illustrated the revolving door of principals that access a vehicle over its lifetime: workforce engineers, fleet partners, vehicle owners, guests, and non-human agents. Each converges on the same resources with different trust levels, different attribute shapes, and different conditions governing access.

We examined how regulatory obligations from UNECE R155 and ISO/SAE 21434 at the global level, to China's GB 44495 and India's AIS 189 at the regional level, demand auditable, versioned access control evidence that policy files in a centralized authorization system naturally provide.

The case for policy-as-code in automotive is stronger than ever. In an industry where a misconfigured access rule can ground a vehicle model across an entire market, that distinction is not a technical preference. It forms a business requirement. Give Cerbos a try and see if it can match your requirements.

---

Authorization in automotive is rarely a clean greenfield problem. If you're working through SDV access control, OTA update governance, or supplier data scoping against UNECE R155/R156 - try out Cerbos for free, or book a call with a Cerbos engineer to see how our solution can help streamline access control in your organization.

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, utilities, and MedTech.