How Trusted Applications and TEE Ensure Rollback Protection in Automotive ECUs

Not all cybersecurity attacks inject new code. Some just bring back the old.

In modern vehicles, outdated software can be just as dangerous as malware, posing a direct threat to vehicle security.  Rollback protection prevents attackers from reinstalling older versions of ECU firmware that may still carry valid signatures but contain known vulnerabilities.

It’s simple. If the system doesn’t check the version, it accepts the firmware as authentic. The result? Security patches are undone. Vulnerabilities are reopened. Attackers regain access to things that were supposed to be fixed.

As vehicles evolve into software-defined platforms, the problem gets worse. ECUs are updated more often. OTA update pipelines grow more complex. And attackers have more chances to exploit outdated firmware.

To ensure firmware rollback protection, you need security that is embedded beyond the reach of the attacker. Robust ECU update security therefore starts with blocking any attempt to load obsolete code. That’s the role of Trusted Execution Environment (TEE) and Trusted Applications (TA).

A TEE is a secure zone in the processor, isolated from the main OS. Inside it, a TA can verify firmware versions, track updates, and reject anything that tries to go backwards.

In this article, we’ll explore where current defences fall short and how TEE-based rollback protection can close the gap.

Limitations of Traditional Anti- Rollback Protection Methods

Despite the growing importance of firmware rollback protection, many ECUs still rely on fragile defences – Version checks in the bootloader, metadata stored in external flash, counters that can be tampered with. These methods were never designed for the complexity of software-defined vehicles.

And they are no match for real-world attackers.

Let’s take a closer look at why today’s rollback protection mechanisms often fail and what makes them so easy to bypass.

Common Weaknesses in Current ECU Rollback Protections

1. Version Checks in Application or Bootloader
   • Logic resides in the same domain as firmware.
   • Attackers can bypass checks by patching memory or boot logic.
   • On various ECUs, simple integer values are stored in flash and can be overwritten.
2. Version Counters in External Memory
   • External EEPROM or flash is physically accessible.
   • Attackers can downgrade both firmware and counters together.
   • No protection against tampering during the update process.
3. Lack of Hardware-Rooted Trust
   • No use of secure OTP, eFuse, or TEE-protected counters.
   • Version info stored in mutable memory or exposed via diagnostics.
   • Secure boot verifies signatures but does not verify whether firmware is latest.
4. Version Info Not Signed with Firmware
   • Metadata like version number is stored separately.
   • Attackers can mix a valid firmware signature with an outdated image.
   • Signature checks pass even when firmware is obsolete.
5. Erasable Update History
   • Update flags are stored in flash/EEPROM without protection.
   • These records can be deleted or spoofed, triggering a fake update.

Key Takeaway

Most rollback protection measures exist within the same attack surface as the software they’re protecting. Without hardware-backed isolation or tamper-proof enforcement, these solutions are inadequate for modern connected vehicles.

How TEE and Trusted Applications Enhance Firmware Security

On paper, firmware rollback protection seems straightforward. Just reject older firmware versions. But in practice, it is one of the trickiest security challenges in an automotive ECU.

Why? Because the system often has no tamper-proof way of knowing which version is “current.”

Many ECUs today still store version numbers in flash or external EEPROM. These are memory regions that were never designed with security in mind.

Let’s now understand how TEE and TAs are able to handle these newer cybersecurity issues.

1. The Core Elements of a Rollback Protection Update Flow

The idea behind preventing rollback attacks using a Trusted Execution Environment and a trusted application in automotive cybersecurity is simple.

TEE moves the rollback enforcement to a part which is isolated from the system. TA takes on the responsibility of tracking firmware versions and making the decision whether the new firmware is acceptable.

It does not rely on external memory, it cannot be overwritten by normal software, and it does not take instructions from untrusted components.

In a nutshell, TEE provides isolation. TA defines the rules. Together, they create an enforcement layer.

Now that the role of TEE and TA is clear, let’s build on this and understand the process of firmware rollback prevention in detail.

2. TEE and TA based Rollback Prevention in Modern Automotive SoCs

Modern automotive SOCs are already implementing TEE and TAs as part of their core automotive cybersecurity architecture. The much-needed isolation of enforcement logic from the rest of the system, provided by the TEE, forms the basis for a trusted update mechanism.

It ensures that even if the bootloader, OS, or diagnostic interface is compromised, the version policy cannot be bypassed.

In this setup, the Trusted Application becomes the only gatekeeper that decides whether a firmware update can proceed. It performs version validation, manages secure counters, and updates them only when a new version is safely installed. These decisions are backed by cryptographic services and secure storage APIs offered by the TEE.

Let us explore how this is taking shape on real platforms.

Real-World Implementations on OP-TEE and Kinibi

• OP-TEE and Automotive SoC Security

In platforms running OP-TEE, the TA uses the TEE’s internal secure storage to maintain a version counter. This counter is encrypted and tied to the device’s unique key. It cannot be viewed or modified by any application code, bootloader logic, or external update tool.

During an update, the main firmware calls into the TA, passing the new version. The TA checks whether it is newer than the stored value. If not, the update is rejected silently. If it is valid, the TA waits until the update is complete before updating the stored version number. This protects against interrupted updates or reboots during installation.

This model is already being used in safety-critical ECUs including battery management system and motor control system where secure firmware updates for ECUs are critical to avoid security breaches.

• Kinibi on Commercial Automotive SoCs

Kinibi, a production-grade TEE from Trustonic, is widely used in infotainment SoCs, central gateways, and telematics control units. It supports both hardware-backed counters and software-maintained version tracking within the TEE.

Trusted Applications in Kinibi interact with the secure file system and access monotonic counter services to enforce rollback protection policies. These TAs are tightly integrated with the OEM’s OTA and diagnostic stack and can also be configured to enforce multi-module consistency. For example, a central TA can prevent activation of zonal ECUs if they are found running outdated firmware.

• TrustZone-Based Platforms with Split Responsibility

In some SoCs, rollback protection is distributed between the secure bootloader and the Trusted Application. The secure bootloader validates the firmware signature and initializes the TEE early in the boot process. From there, the TA steps in to check the version integrity before the new firmware is activated.

This dual-layer enforcement is being adopted in connected infotainment platforms and zonal gateways, where different teams may update software at different times, but rollback protection policies must be enforced system-wide.

Regardless of the platform, the core idea remains the same. The Trusted Execution Environment protects the decision-making process. The Trusted Application defines and enforces the version policy.

Use Case: OTA Firmware Validation in Central Gateway ECUs

It’s time to catch TEE and TAs in action!

Firmware over-the-air (FOTA), as we are all aware, is emerging as the preferred method of software update for automotive ECUs.

FOTA update is executed through a central controller or a gateway. This gateway becomes the single-entry point for software updates across the vehicle’s electronic architecture.

Now imagine this gateway receives a firmware package intended for one of the zonal ECUs say, the body control module. The firmware is signed. It appears valid. But it is an older version, possibly pulled from a previous update cycle.

This is where firmware rollback becomes a real threat.

If the system only verifies the signature and not the version, the outdated image is accepted. The zonal ECU downgrades, bringing back software that may contain known bugs or security gaps.

To counter such threats, TEE and TA combination is the ideal solution.

In this setup, the central gateway hosts a Trusted Application inside the Trusted Execution Environment. The TA keeps secure, isolated records of firmware versions.

When a firmware update is delivered to the gateway, this is what happens:

1. The TA receives the version information
   This includes details for its own update as well as metadata for each target ECU.
2. The TA compares incoming versions with stored records
   If the new version for any ECU is older than what was last accepted, the update is denied.
3. The decision cannot be overridden
   Even if the firmware is signed and authentic, it will not be installed unless it passes the version policy.
4. Once validated and installed, the TA updates its internal version tracker
   This tracker is protected by the TEE and cannot be altered from outside.

This approach allows rollback protection to extend beyond a single ECU. Even if a zonal ECU lacks TEE support of its own, the central controller can enforce version policies on its behalf. This is especially valuable in systems where zonal ECUs are built with lightweight controllers and limited security capabilities.

Conclusion

Trusted Execution Environments and Trusted Applications do more than support secure updates. They move rollback protection into a part of the system that cannot be bypassed.

This approach is already being used in platforms where safety, reliability, and long-term software integrity matter.

By enforcing version control from within a secure boundary, ECUs gain one clear advantage that they cannot be downgraded without permission.

In vehicles that are always connected and constantly updated, that kind of control is a gamechanger.