TEE-based ECU security refers to the use of Trusted Execution Environment to safeguard critical operations within an automotive Electronic Control Unit (ECU).
A TEE creates a secure zone inside the processor, an area where trusted applications can run without interference from the rest of the system. It’s like giving the ECU a secure room to handle the most sensitive tasks: verifying software, storing cryptographic keys, managing secure updates, and more.
This method adds a much-needed layer of protection to systems that can’t afford to fail, whether it’s an infotainment system or the central gateway that enable connected systems.
Modern Vehicle Architectures and Emerging Cyber Threats
Vehicle Architecture is changing. Older cars had a simple layout: each function had its own ECU, mostly isolated from the others. But as the demand for features grew, that model became hard to scale.
To solve this, manufacturers are turning to domain and zonal architectures.
In a domain model, ECUs are grouped by type- body control module, powertrain, infotainment system.
In zonal setups, ECUs are organized by physical zones, like front-left or rear-right, and connected to a central compute unit.
This enables shared resource usage and reduces wiring, but it also changes how systems communicate and how attackers might navigate them. This shift has introduced new paths for cyberattack. An attacker has got the ability to compromise one system and pivot across others.
We are all aware of the Jeep Cherokee hack in 2015. Security researchers Charlie Miller and Chris Valasek exposed a vulnerability in the 2014 Jeep Cherokee’s infotainment system. The Uconnect head unit was accessible via cellular network and lacked proper input sanitization and isolation. Once connected, the researchers were able to remotely:
- Rewrite firmware
- Send CAN messages
- Control functions like steering, brakes, and transmission
At the time, this vehicle’s ECUs were connected on a single CAN bus communication channel. Also, the ECUs operated independently. So, if an attacker managed to send a spoofed message on the bus, each ECU would need to be targeted individually.
Now imagine this in a modern zonal architecture.
Modern vehicles use zonal ECUs connected by automotive Ethernet to a central computer. Each ECU controls multiple components in its area, like sensors, lights, and actuators. These are no longer tied to a single function. They serve multiple systems at once.
This design improves efficiency but expands the risk. A vulnerability in one ECU can affect others across the network.
Infotainment system technology is often the first target. IVI systems connect to the internet and run third-party apps. If compromised, attackers can access the internal vehicle network. From there, they may reach the zonal ECU and control other components nearby.
Because zones are connected, the attack can spread. Fake messages or commands can move from one ECU to another. This increases the chance of critical systems being affected.
Over-the-air updates add more risk. If the update process is not secure, an attacker can install older or modified software. This reintroduces known bugs or disables security features.
In this setup, a single weak point can compromise the entire system. The more connected the vehicle, the faster the damage can spread.
Recent reports underscore the growing cybersecurity concerns in the industry:​
- According to Upstream’s 2025 Global Automotive Cybersecurity Report, 95% of cyberattacks in 2024 were executed remotely, with 85% being long-range attacks, highlighting the increased risk posed by interconnected vehicle systems. ​
- The same report notes that the number of high and massive-scale incidents potentially impacting thousands to millions of mobility assets increased by 2.5 times compared to 2022, emphasizing the escalating scale of cyber threats in the automotive sector.
Firmware over-the-air updates are a crucial entry point for cyber risks. If the update mechanism lacks strong validation, attackers could inject modified firmware. A rollback attack, where older and less secure firmware is reinstalled, could expose known vulnerabilities across several ECUs.
In this architecture, a single point of failure can escalate quickly. One compromised ECU may open a path to central compute or multiple zones. Without strict isolation and hardware-backed access control, SDVs face system-wide exposure from localized attacks.
While such threat to secure automotive systems looms large, traditional security methods do not seem to be enough. Let’s understand why.
Why Software-Only Cybersecurity Measures Break Down in Zonal ECU Networks?
At first glance, a zonal ECU looks like a gateway. It routes signals, controls local components, and connects to a central computer. But internally, it’s more complex. It’s often built around a general-purpose processor or SoC running a full operating system. It manages real-time tasks, diagnostic services, communication handlers and more.
In many cases, these tasks share memory. They access common system calls and may even rely on shared device drivers. This is where vulnerabilities begin.
- Shared memory and privilege leakage
- Overwriting configuration for motor control logic
- Changing voltage thresholds for safety sensors
- Modifying message filters in the CAN or LIN interface
- Firmware update routines stored in unsecured flash regions
Inside the ECU, multiple services such as diagnostics, actuator control, and communication, run in user space or kernel space, often without strict separation. If one service is compromised (for example, the stack that parses incoming Ethernet packets), an attacker can use that to gain higher privileges and access memory regions allocated to other tasks.
This opens the door to reading or modifying sensitive runtime data. For example:
Since these are in-memory changes, they can happen silently, with no logs or alerts unless hardware security features are used to enforce memory protection boundaries.
Most ECUs allow firmware to be updated over-the-air or via diagnostics. In many implementations, the bootloader or update agent stores the new firmware in external flash. This flash is often not encrypted or authenticated. If an attacker gains access to the communication layer, they may be able to write directly to these memory regions.
They don’t need to exploit the bootloader itself, they just need to place the firmware in the right location with the right CRC. If the bootloader doesn’t perform cryptographic signature verification (or if it uses software-based checks that can be bypassed), it will execute the modified firmware at next boot.
Now, the attacker controls the ECU from power-on, including low-level peripherals, interrupt handlers, and safety loops.
How does TEE based Security for Automotive ECUs Work?
Code running inside the TEE is not accessible to anything running in the main operating system. Even if an attacker takes full control of the regular software stack, they still cannot access what’s inside the TEE.
But isolation is only the foundation. The real power of a TEE comes from how it allows you to separate roles and responsibilities inside the ECU. Sensitive functions are moved out of the shared system and placed into small, secure programs called Trusted Applications.
What Exactly Happens Inside the TEE?
- Execution Isolation
- Memory Protection
- Device Control
- Secure Boot Enforcement
- Tamper Resistant Storage
- Cryptographic Services
- Service Authentication
- Intrusion Detection and Monitoring
- Fallback and Recovery
All code running in the secure world is isolated from the normal world. Even if malware takes over the infotainment system or vehicle telematics system, it cannot touch what runs inside the TEE. This is enforced by processor-level control signals and memory partitioning.
The TEE has its own memory region. Normal world applications cannot read, write, or even detect this memory space. Sensitive data like private keys, authentication tokens, or diagnostic logs remain hidden from all other vehicle software.
The TEE can take exclusive ownership of specific peripherals or communication channels. For instance, a network interface or a CAN controller can be mapped only to the TEE, making it the only component that can process or forward specific packets. This allows it to implement a hardware-enforced firewall or apply filtering rules that cannot be bypassed.
The boot process begins with hardware checks. Once the bootloader is verified, control passes to the TEE, which extends the chain of trust. It verifies every other component including firmware, operating system, and application updates before they are allowed to run.
The TEE maintains a secure file system where cryptographic keys, configuration files, credentials, and logs are stored. These assets are protected not just by encryption, but also by access control enforced by the TEE. Even if an attacker gains root access in the normal world, this data remains protected.
The TEE can act as a virtual Hardware Security Module. Applications in the normal world can request signing, encryption, or verification, but they never get direct access to the cryptographic keys. The TEE receives the request, performs the operation, and returns the result while the keys never leave the secure world.
There are scenarios when two ECUs need to trust each other, for example, during a firmware update or V2X communication. The TEE can perform mutual authentication using stored credentials. This ensures that both ends of the communication are verified at a hardware-rooted level.
A TEE enhances system security by securely storing incident data and routing it through trusted channels, even if other parts of the system are compromised. This ensures that critical information reaches the security operations centre or triggers a fallback response without the risk of tampering. By providing a trusted layer for managing incident data, the TEE strengthens the overall defence system.
If the normal world crashes or behaves unexpectedly, the TEE can activate a lightweight recovery OS. This fallback system allows essential operations to continue, such as pushing diagnostics, accepting remote commands, or even rebooting the primary OS under controlled conditions.
Why This Matters for SDVs and Zonal ECUs
In SDVs, vehicle features are increasingly updated over the air. A TEE can help validate these updates before they are executed, ensuring that a corrupted update server does not compromise an entire zone. It is like an added layer of security to safeguard against ever-evolving threats.
In zonal architectures, a gateway ECU may control power steering, braking signals, and connectivity all at once. If one function is compromised, the attacker should not be able to pivot to the rest. TEE-based separation makes this possible – isolating not just functions, but the trust boundaries within a single device.
A TEE also enables selective security. For example, it helps manage access to critical One Time Programmable (OTP) memory bits on the SoC. These bits store important values like secure boot keys, anti-rollback counters, and Secure JTAG configurations. While the SoC enforces these features, a Trusted Application running in the TEE allows secure access for tasks like key provisioning and configuration without exposing them to the normal world.
Most importantly, TEE-based security is scalable. It can be deployed in a central gateway, an infotainment system, or a zone controller. It works across different processor architectures and can be customized to suit the needs of each ECU type.
