ECU (Electronic Control Unit)
An ECU is an embedded computer that controls one function of a vehicle. What sits inside, which interfaces it exposes and why every ECU is a security test object.
Updated This page as Markdown
In short
An ECU (electronic control unit) is an embedded computer in a vehicle that reads sensors, runs control software and drives actuators for one or more functions: engine, brakes, charging, lighting, infotainment. A modern vehicle has dozens to over a hundred of them, connected over CAN, CAN FD, LIN, FlexRay and Ethernet. Each ECU exposes diagnostics, usually UDS, and often debug interfaces, which makes it a test object in its own right under ISO/SAE 21434.
What is an ECU?
An ECU, electronic control unit, is an embedded computer that controls a function of the vehicle. It has a microcontroller or system on chip, memory for code and calibration data, transceivers for the vehicle buses and the drivers for its sensors and actuators. Power-electronics ECUs such as a DC/DC converter or on-board charger often run on automotive microcontrollers like Infineon AURIX (TriCore); infotainment and ADAS controllers run Linux, Android or a hypervisor on larger SoCs.
In diagnostic terms, the ECU is the server: it answers the requests of a diagnostic client (the tester). That is the view ISO 14229-1 takes.
Where is it defined?
There is no single legal definition of “ECU”. ISO/SAE 21434 does not use the word as a defined term; it works with items (functions at vehicle level) and components (parts of an item, such as an ECU with its software). ISO 14229-1 treats the ECU as the diagnostic server. The bus interfaces are defined in their own standards, for example ISO 11898-1 for CAN and ISO 13400-2 for diagnostics over IP.
What it means in practice
For security testing, an ECU is the unit you put on the bench. It has a power supply, one or more bus connections and sometimes a debug header. Its attack surface is everything that accepts input: the UDS stack with its sessions and services, the ISO-TP layer, the application that processes CAN signals, the bootloader in programming session, network services on Ethernet ECUs and any debug port left open.
What we regularly see on ECU benches: services reachable in default session that should need extended session, writable identification DIDs without SecurityAccess, seed/key schemes with constant seeds or no attempt counter, and ECUs that reset on malformed ISO-TP frames. On power-electronics ECUs the firmware often holds the seed/key algorithm in plain view once it is extracted.
How AutoST tests it
AutoST tests one ECU at a time on the bench. The test agent connects over CAN, CAN FD or Ethernet, enumerates sessions, services and DIDs, checks SecurityAccess, scans routines from the ODX or CDD file and fuzzes UDS and CAN. Findings are scored per ECU and land in a report and a Fix Plan. Licensing is per tested component.
Common misunderstandings
An ECU is not secure because it sits behind a gateway. Gateways get misconfigured, diagnostic routing gets opened for workshops, and in a pentest the attacker usually starts directly on the ECU bus anyway.
FAQ
Frequently asked questions
How many ECUs does a vehicle have?
It depends on the architecture. Classic distributed architectures have dozens of ECUs, premium vehicles more than a hundred. Zonal architectures consolidate functions into fewer, more powerful controllers, but each of them carries more functions and more attack surface.
Is an ECU the same as a component in ISO/SAE 21434?
Often, but not always. ISO/SAE 21434 speaks of items and components. An ECU with its software is a typical component; an item is a function at vehicle level, which can span several ECUs.
What does an attacker usually target on an ECU?
First the diagnostic interface (UDS over CAN or DoIP), then debug ports such as JTAG or UART, then the firmware itself. The diagnostic interface is attractive because it is reachable from the bus without opening the housing.
Sources
- ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering (item, component, clause 3 terms and definitions)
- ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer
- ISO 11898-1:2015 Road vehicles, Controller area network (CAN), Part 1: Data link layer and physical signalling
Related pages
- GlossaryUDS (Unified Diagnostic Services)UDS (ISO 14229) is the diagnostic protocol of most automotive ECUs: sessions, services, DIDs and SecurityAccess. What it defines and why it is the first attack surface.
- GlossaryGateway ECU (Central Gateway)The gateway ECU connects the vehicle networks and decides which messages cross between them. Why it is the key security boundary and how its diagnostic routing fails.
- ComparisonsAutomated ECU Security Testing vs Manual Penetration TestAutomated ECU testing catches repeatable weaknesses on every build; a manual pentest finds logic flaws and chained attacks. What each finds, costs and when to use which.
- GlossaryCAN Bus (Controller Area Network)CAN (ISO 11898) is the broadcast bus most ECUs share: identifiers, arbitration, error handling. Why any node can send any frame and what that means for security testing.
- PlatformA dashboard in the browser, an agent on the bench.AutoST has three parts: a web dashboard, a backend that orchestrates and stores, and the Carbyne agent on your bench. See the scan flow from wiring an ECU to the fix.
- For your teamAutoST for Tier-1 Suppliers: Test Your ECU Before the OEM DoesHow Tier-1 suppliers use AutoST to test their own ECUs against the OEM cybersecurity requirements before each sample phase, and hand over evidence that holds in an audit.
