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

At a glance

What this is: This is an analysis of why connected vehicle authorization needs policy-as-code, with the key finding that RBAC alone cannot govern OTA updates, supplier access, owner permissions, and non-human identities at scale.

Why it matters: It matters to IAM practitioners because the same control patterns that fail in automotive often fail in any programme where human, partner, and non-human access converge on the same resources.

👉 Read Cerbos's analysis of connected vehicle authorization and policy-as-code

Context

Connected vehicle authorization fails when access rules are hardcoded into applications and cannot keep up with changing personas, vehicle state, and supplier relationships. In this article, the primary identity problem is not authentication but governance over who can approve, deploy, or read data across the automotive lifecycle.

That makes the topic relevant to workforce IAM, partner access, customer access, and non-human identity governance at the same time. The article argues that policy-as-code is needed because authorization decisions in software-defined vehicles must be auditable, versioned, and enforced consistently across cloud and embedded environments.

Key questions

Q: How should security teams govern OTA update approvals in connected vehicle environments?

A: Security teams should require OTA approvals to depend on fleet state, update status, and role context rather than a broad engineer or manager role. The policy should separate approval, deployment, and rollback, so no single identity can move an update through the entire chain without conditions being satisfied at each step.

Q: Why do connected vehicles create problems for traditional IAM models?

A: Connected vehicles create problems because the same resource may be touched by engineers, suppliers, owners, guests, and machine identities over different lifecycle stages. Traditional IAM models assume more stable access patterns than vehicles actually have, so they struggle to express temporary, conditional, and ownership-based access cleanly.

Q: How do organisations know if their automotive authorization model is working?

A: A working model produces consistent decisions across services, clear audit trails for who approved each action, and permissions that change automatically when fleet status or ownership changes. If the same access question gets different answers in different systems, the governance model is already failing.

Q: Who should be able to manage vehicle access when ownership or service status changes?

A: That depends on the policy, but the critical requirement is that access changes must be driven by the new ownership or service context rather than manual cleanup. The governance process should remove stale access automatically so the previous state does not keep authorizing the vehicle after the relationship has changed.

Technical breakdown

Why RBAC breaks in software-defined vehicles

Role-based access control works when access needs are stable, but connected vehicles create a fluid environment where permissions change by fleet, service state, contract status, and use case. The problem is role explosion: as teams add special cases to move fast, roles multiply and overlap until no one can explain why a permission exists. In an automotive stack, that becomes dangerous because one mis-scoped role can affect firmware deployment, diagnostics, or owner data across thousands of vehicles. ABAC becomes relevant because it evaluates attributes such as vehicle group, supplier ownership, and update status at decision time rather than relying on broad job titles.

Practical implication: replace role-only entitlement models with attribute-based rules for fleet state, ownership, and contract context.

Policy-as-code and policy decision points in automotive

Policy-as-code moves authorization out of application logic and into version-controlled policy definitions that can be reviewed, tested, and audited like software. In the architecture described here, the application acts as the enforcement point and asks a policy decision point whether a principal can take an action on a resource. That separation matters in distributed automotive systems because the same rule often needs to apply across web services, internal tools, and embedded workflows. When the policy lives centrally, security teams can prove who was allowed to approve, deploy, or rollback an OTA update at a given time. Embedded decision points extend the model to places where network latency or connectivity make remote calls impractical.

Practical implication: centralise authorization policy outside business logic and keep every decision auditable in version control.

Non-human identities in OTA and telemetry workflows

The article treats telematics units, OTA agents, and service mesh identities as non-human identities that must be governed differently from workforce, partner, and customer access. These identities do not behave like people, but they still act on vehicle data and system functions under machine conditions. That means a telematics agent may need to read and write telemetry, while an engineer may also be allowed to initiate diagnostics. The key design issue is not whether the actor is human, but whether the policy can distinguish machine-mediated actions from operator actions at the point of decision. In automotive environments, that distinction becomes essential when identical APIs are exposed to multiple principal types.

Practical implication: model vehicle service accounts and agents as first-class identities with separate action rules from human users.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Policy drift is the hidden failure mode in connected vehicle authorization. The article shows how hardcoded rules and scattered authorization logic create inconsistent outcomes across services, fleets, and supplier environments. That is not just a software hygiene problem, it is a governance failure because the same access question is answered differently depending on where the check runs. The practitioner lesson is that auditability and consistency are the real control objectives.

ABAC is the right lens when vehicle access depends on context, not job titles. Vehicle state, update status, component ownership, and contract conditions determine whether access should exist at all. RBAC cannot express those conditions cleanly without growing into a brittle exception stack, which is why the article’s examples move toward attribute-based decisioning. The field should treat context-aware authorization as a core control requirement for connected assets, not an advanced option.

Non-human vehicle identities should be governed as separate principals, not as edge cases. Telematics agents, OTA update agents, and service mesh identities act on the same systems as people, but their permissions and trust boundaries are different. The article’s most important contribution is showing that machine identities in automotive are not side infrastructure, they are operational actors with distinct authorization needs. Practitioners should design governance around actor type first, then map actions and conditions.

Access to moving assets forces lifecycle governance into the authorization layer. A vehicle changes state, ownership, and service context over time, so permissioning cannot be static or purely role-driven. That means joiner-mover-leaver logic, offboarding, and temporary access expiry are part of authorization design rather than separate hygiene tasks. The implication is that connected vehicle programmes need governance models that understand lifecycle transitions as decision inputs.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how weak machine identity oversight still is in practice.
• For lifecycle governance and revocation patterns, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Connected vehicle programmes should expect authorization to become a cross-domain identity problem rather than a narrow application control issue. When workforce, partner, customer, and non-human access all converge on the same assets, the programme needs a policy layer that can explain decisions across cloud services, OEM systems, and device-bound workflows.

Identity blast radius: the real risk is not only who can access a vehicle system, but how far a single over-permissioned principal can move across fleets, suppliers, and lifecycle states. The practical response is to design around state change, not just role assignment, and to make every access rule auditable before deployment.

For practitioners

• Map every vehicle-facing principal type Inventory workforce, partner, customer, and non-human identities separately, then document which actions each one may take against OTA updates, telemetry, diagnostics, and vehicle records.
• Move authorization rules out of application code Store policy in version control, review it like code, and require every access decision to be explainable from a central policy record rather than hidden in multiple microservices.
• Use attributes for fleet state and ownership context Base access on resource attributes such as vehicle group, component ownership, update status, and service contract state so that permissions change when the business condition changes.
• Treat telematics and OTA agents as governed identities Assign machine identities their own policies for read, write, approve, and execute actions, and do not let human role models implicitly determine machine behaviour.

Key takeaways

• Connected vehicle authorization fails when role-based access cannot express fleet state, ownership, and service context.
• Policy-as-code gives OEMs and suppliers a way to version, test, and audit access decisions instead of burying them inside application logic.
• Non-human identities in automotive should be treated as governed principals with separate rules, not as implementation details.

Key terms

• Policy-as-Code: Policy-as-code is the practice of writing authorization rules in version-controlled code or configuration rather than inside application logic. It lets teams review, test, audit, and deploy access policy with the same discipline used for software changes, which makes decisions more consistent and traceable.
• Attribute-Based Access Control: Attribute-based access control is an authorization model that decides access using attributes such as identity, resource state, location, contract status, or time. It is useful when roles are too blunt, because the decision can reflect the real conditions around a request instead of a fixed job title.
• Non-Human Identity: A non-human identity is any machine or workload identity that acts on systems without a person directly driving each action. In automotive environments, that can include OTA agents, telematics units, service mesh identities, and other automated principals that still need explicit governance, auditability, and scoped permissions.

Deepen your knowledge

Connected vehicle authorization, policy-as-code, and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme has similar lifecycle and access-control pressure, it is worth exploring.

This post draws on content published by Cerbos: connected vehicle authorization and policy-as-code in automotive. Read the original.