Policy-as-code for connected vehicles: where RBAC breaks down

At a glance

What this is: This is a Cerbos analysis of why role-based access control breaks down in connected vehicles and why policy-as-code is needed for OTA, supplier, and identity-specific access decisions.

Why it matters: IAM teams, IGA leads, and security architects need to rethink how authorization works when vehicles, suppliers, owners, and machine identities all share the same operational stack.

Context

Connected vehicles turn authorization into a lifecycle problem, not a static permission problem. The same platform may need to decide differently for workforce engineers, suppliers, owners, guests, and non-human identities depending on vehicle state, contract status, and safety context.

RBAC struggles here because roles multiply faster than teams can govern them, while access conditions change with fleet stage, ownership transfer, and regulated OTA operations. The article argues that policy-as-code is a better fit because it makes those decisions versioned, auditable, and separable from application logic.

Key questions

Q: What breaks when RBAC is used for connected vehicle authorization?

A: RBAC breaks when access needs to depend on vehicle state, ownership, supplier boundaries, and safety context rather than a fixed job title. In connected vehicle platforms, the same role can be too broad for one action and too narrow for another, which creates role explosion, inconsistent exceptions, and unauditable edge cases.

Q: Why do connected vehicles require attribute-based authorization instead of simple roles?

A: Connected vehicles require attribute-based authorization because the right to act depends on who is requesting access, what vehicle or record is involved, and under what conditions the request occurs. That model is necessary when suppliers, owners, technicians, and machine identities all share the same platform but not the same authority.

Q: How do IAM teams know when policy-as-code is actually improving control?

A: Policy-as-code is working when the same authorization rule is enforced consistently across services, changes are versioned and reviewable, and access decisions can be traced to a clear policy record. In automotive environments, that also means updates, diagnostics, and supplier access all reflect the same governance logic.

Q: What should security teams do when vehicle access must span workforce, suppliers, customers, and machine identities?

A: They should define separate principal classes and tie each one to explicit conditions such as fleet stage, contract status, ownership, or work order state. That prevents a workforce permission from leaking into partner or non-human access and keeps lifecycle changes from becoming permanent access.

Technical breakdown

Why RBAC breaks down in connected vehicles

RBAC assigns permissions to roles, but connected vehicles need context that roles cannot hold cleanly. A vehicle engineer may be allowed to push firmware only to a test fleet, while a cybersecurity analyst may read ECU diagnostics only during an incident. Once the same platform must also handle suppliers, owners, guests, and telematics agents, role counts explode and overlap. The result is inconsistent authorization logic, especially when access must reflect vehicle state, contract status, or safety conditions.

Practical implication: model vehicle access around attributes and conditions, not around ever-growing role lists.

How policy-as-code changes authorization control

Policy-as-code separates authorization rules from application code and stores them as versioned policy files. In the model described here, applications ask a policy decision point at request time whether a principal can act on a resource, and the policy engine returns the decision. That architecture matters because it avoids duplicated rules across services and makes changes auditable. In automotive environments, this is especially useful when the same access rule must work across OTA updates, supplier data, and owner-facing workflows.

Practical implication: centralise authorization logic so access changes are reviewed, tested, and deployed like code.

Why vehicle identity and ownership make authorization harder

Connected vehicles are not just assets, they are shared systems with moving identity boundaries. Workforce users, suppliers, customers, and non-human identities all interact with the same data plane, but they do not share the same authority. A dealership technician’s access should expire with the service work order, and a previous owner’s access should end when the vehicle is resold. This is a classic governance problem because the authorization decision must change with lifecycle events, not with a one-time provisioning step.

Practical implication: tie access decisions to ownership, contract, and lifecycle attributes so permissions decay when the context changes.

Threat narrative

Attacker objective: The objective is to trigger unauthorized vehicle actions at scale, including firmware deployment, diagnostics, or data access, by exploiting weak authorization boundaries.

1. Entry occurs when a software update, diagnostic action, or supplier request is permitted without sufficient context around who can act, on which vehicles, and under what conditions.
2. Privilege escalation follows when broad or stale roles let a principal move from limited access to fleet-wide or safety-critical actions that were never meant to share the same authority boundary.
3. Impact occurs when the wrong firmware, telemetry access, or rollback action reaches production vehicles, creating operational disruption, safety risk, or regulatory exposure.

Breaches seen in the wild

• HPE Aruba Instant On hard-coded credentials: Hard-coded admin credentials in HPE Aruba Instant On access point firmware let anyone bypass login (CVE-2025-37103); no exploitation reported.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Connected vehicle authorization is a lifecycle governance problem, not a role-management problem. RBAC can express job titles, but it cannot reliably encode the state changes that govern vehicles across production, service, ownership transfer, and supplier access. The practical conclusion is that automotive programmes need authorization that follows lifecycle context, not organisational hierarchy.

Policy-as-code is the only scalable way to keep automotive authorization auditable. When access logic lives inside application code, teams duplicate rules across services and lose traceability when fleet conditions change. Versioned policies create a single place where approvals, reviews, and diffs can be examined, which is the minimum standard for an environment that can push code to thousands of vehicles at once.

Vehicle access is a multi-principal governance domain. Workforce users, suppliers, owners, guests, and non-human identities all touch the same resources, but each needs different constraints and expiry conditions. The implication is that automotive IAM must distinguish who is acting, whose data is involved, and whether the authority still exists after the business event that created it.

Policy drift becomes fleet risk when authorization is embedded in application logic. If the same rule is reimplemented in multiple services, small differences in vehicle-group checks, contract checks, or approval conditions can create inconsistent outcomes. That is not just a coding defect, it is a governance failure because the organisation can no longer prove that the same access rule was enforced everywhere it mattered.

What this signals

Policy lifecycle is the control boundary: In connected vehicle environments, the important question is not only who can access what, but whether the rule can be changed and evidenced when ownership, fleet state, or supplier relationships change. That pushes automotive IAM toward centrally governed policy updates rather than embedded service logic.

Vehicle programmes that still rely on broad roles should expect increasing exceptions as OTA, supplier, and customer workflows continue to multiply. The governance gap is no longer the absence of access control, it is the inability to express context fast enough to match the vehicle lifecycle.

For practitioners

• Map OTA approvals to vehicle state Separate approval, deploy, and rollback conditions by fleet stage, update status, and safety-critical context instead of using a single broad update role.
• Move access rules into versioned policy files Keep authorization logic outside application code so changes to supplier, owner, and workforce access can be reviewed and audited centrally.
• Tag resources with ownership and organisation attributes Use resource attributes such as supplier ID, component ownership, or customer tenancy to decide whether a principal can read or act on a record.
• Expire ephemeral access with the business event Tie technician, dealer, and partner permissions to work orders, contract status, or resale events so access ends when the operational condition ends.
• Separate human and non-human authorization paths Treat telematics agents, OTA agents, and workforce users as different principal types so diagnostic and execution permissions are not conflated.

Key takeaways

• Connected vehicle authorization fails when broad roles are asked to govern fleet state, ownership change, supplier boundaries, and machine identities at the same time.
• The article shows that policy-as-code is not just a software preference, it is a way to make authorization changes auditable and consistent across distributed vehicle systems.
• Automotive teams need access decisions that expire with the business event, otherwise a valid permission can outlive the condition that justified it.

Key terms

• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.
• Role Explosion: Role explosion happens when a shared authorization model accumulates too many narrowly tailored roles, often because every customer or team request becomes a permanent global role. The result is a harder-to-understand access catalogue, broader blast radius, and weaker governance over who can do what.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.