Rust in the Vehicle Why the Language Issue Has Become A Regulatory Issue

The choice of programming language for vehicle control units was long considered to be purely a question of development. Since a UN regulation has become mandatory for all newly registered vehicles in the EU and European manufacturers are delivering the first Rust-based ECU software in series vehicles, this has become a decision that affects architecture, approval and purchasing.

As a co-founder of a company that develops and delivers software for vehicle control units, I am observing a shift that is now also affecting product liability and strategy. The question of which programming language is used to write vehicle software is leaving the development offices and moving into areas where decisions are made about architecture, risk and approval. In 2026, European manufacturers will deliver Rust-based software in production vehicles for the first time. This is not an experiment, but a reaction to requirements that have been in force since mid-2024.

What the UN Regulation Has Triggered

UNECE R155 is the UN regulation on vehicle cyber safety. It has been mandatory for all new vehicles registered in the EU since July 2024. Since then, manufacturers and suppliers have had to prove that their vehicle software can be monitored for cyberattacks, evaluated and updated if necessary. The focus is on cryptographic functions, update mechanisms for wireless software updates and all components that process external data. This is precisely where the most dangerous software errors are located.

What is changing as a result of the regulation is not so much a new feature, but the obligation to provide evidence. Anyone who wants to register a new vehicle today must demonstrate how the software is monitored and safeguarded over the entire life cycle. This changes the evaluation of programming languages. What was purely a development decision yesterday is now part of a dossier that has to stand up to the authorities and certification bodies.

Why Memory Errors Are Becoming A Key Issue

A study by the Microsoft Security Response Center and the Google Chrome Security Program shows that 60 to 70 percent of security vulnerabilities in embedded systems can be traced back to memory problems. This refers to errors in which software accesses memory that it should not access or memory that has already been released. The problem with this error class is that it is often not visible in the vehicle.

On a desktop operating system, a protection mechanism usually intercepts a memory corruption and generates a visible crash. On a microcontroller in a vehicle, this protection is missing in many cases. A corrupted state can go unnoticed and lead to unreliable sensor data or malfunctions in safety-critical systems. In production, this is the class of error that is the most difficult to reproduce and the most expensive to rectify.

Rust addresses this problem at language level. The ownership model, the language's core mechanism for memory management, determines at the time of compilation which program parts may access which memory area and when. Illegal accesses are not intercepted at runtime, but rejected by the compiler. Code that cannot be built cannot cause any damage in the field.

What European Manufacturers Deliver Today

Anyone who has so far rejected Rust in the automotive sector with the argument that it lacks series references will have fewer arguments in 2026. Every Volvo EX90 and Polestar 3 that rolls off the production line today has a low-power control unit whose firmware is written entirely in Rust. Ampere, the electric mobility brand of the Renault Group, has trained over 200 developers in Rust and uses the language specifically in safety-relevant components. This includes cryptographic operations and the processes for firmware updates. Ampere is planning to use Rust at ASIL B level for the next generation of driver assistance systems. In order to be able to use Rust at level B in series production today, qualified compilers and certified parts of the standard library are required. This infrastructure has visibly grown since Embedded World 2026.

Not A Language Debate, But An Architectural Issue

Rust does not replace C. Anyone who claims this does not know the reality of industrial embedded development with product life cycles of 15 years. The question that development management and purchasing must answer today is different. Where does the change reduce the overall risk, and where does it increase it?

AUTOSAR Classic is implemented in C and has been validated in the field for decades. Rewriting hardware-related drivers that have already been certified at the highest safety level under existing tool chains makes no economic sense. The C ecosystem for these layers is mature, audited and its error behavior is well understood. The pragmatic answer is provided by the AUTOSAR runtime environment, i.e. the interface between the application and basic software. A number of automotive software providers now enable Rust components on this layer. Existing C code and new Rust code coexist in the same ECU project. This is not a compromise, but an engineering reality.

Even within the Rust ecosystem, safety certification is not a binary switch. Ferrocene, the certified Rust tool chain for safety-critical applications, is qualified to ASIL D for the compiler and currently to ASIL B for parts of the core library. The ecosystem is continuously closing these gaps, but anyone working at the highest safety levels today must factor this into the architecture decision.

Where Rust Has the Greatest Leverage in the Vehicle Today

From the perspective of a company that develops and supplies Rust-based software for control units ranging from the Infineon Aurix TriCore to Linux-based high-performance systems, three fields of application have crystallized.

The software layer between hardware abstraction and the actual vehicle function is growing in complexity the most. Parallel processes, asynchronous communication between components and a state model that can be corrupted globally if the memory management is faulty. The mechanism that Rust uses to prevent parallel write accesses at compile time is the most direct way of dealing with this and eliminates an error class that is one of the most complex debugging cases in C code bases.

The second group comprises components with an attack surface. Cryptographic functions, update handlers and parsers for external messages are the places where memory errors do not lead to malfunctions, but to exploitable security vulnerabilities. Here, structural memory security is not a technical virtue, but a regulatory expectation. If you want to demonstrably fulfill UNECE R155, you will have to justify for these components why you are foregoing the security guarantees that Rust provides at language level.

The third group are new platforms without old stock. Anyone developing a new control unit from scratch today does not have any

There is no longer any objective reason to insist exclusively on C. In greenfield projects, migration costs are completely eliminated, the choice of tools is free, and the team can work with the language's security guarantees from the outset instead of having to create them later using external analysis tools.

The List of Excuses is Getting Shorter

For technical decision-makers, the more productive question is no longer "Rust or C?", but rather: Which components carry the least overall risk, technically, regulatory and economically, with which language? This is an architectural decision, not a language debate.

What has changed in 2026 is concrete. Vehicle manufacturers deliver series vehicles with Rust components. Regulatory requirements are becoming more concrete. Certification infrastructure is growing. Anyone setting up a new ECU platform today will have to justify why they are not using Rust, and no longer the other way around.

So the question is no longer whether Rust belongs in the vehicle. Rather, which components should be migrated first and with what technical and regulatory justification. (se)

Daniel Frassinelli is co-founder and CTO at Veecle GmbH.

The 3D Tech Auto Experts Can’t Afford to Ignore!

3D Digitilization in Automotive Sector