Quick answer: A modern vehicle is not a single computer but a network of dozens of electronic control units (ECUs) talking to each other over the CAN data bus. The CAN bus itself has no authentication or encryption; any device that can reach this bus can read every message from brakes to engine control, replay it and forge it. The OBD II port is the official gateway that gives outside access to this bus, and the UDS (ISO 14229) protocol running over it can reset ECUs, write their memory and even reflash their firmware. Automotive cybersecurity testing measures how exposed this bus is and whether UDS services are protected by any form of authentication, by listening to real traffic and sending controlled messages.

Inside a vehicle, dozens of separate computers, from the instrument cluster to the brake system, from climate control to engine management, constantly talk to each other. The shared language of this conversation is the CAN (Controller Area Network) data bus, largely unchanged for almost thirty years. Automotive cybersecurity is the field that studies how accessible this internal network is from the outside and what becomes possible once it is reached.

Why the CAN bus is this open

When the CAN protocol was designed in the 1980s, the goal was reliability, not security; the idea was that the vehicle should keep running even if a sensor failed. Because of this the protocol has no authentication, encryption or message signing. Any device with physical access to the bus can passively listen to all traffic, replay a message it has seen before, and inject a completely forged message. The vehicle itself cannot tell whether a message came from a real ECU or from an attacker.

The OBD II port and the UDS protocol

The OBD II port found under the dashboard of every vehicle legally provides outside access to the CAN bus for service and diagnostics. This port speaks the UDS (Unified Diagnostic Services, ISO 14229) protocol. Alongside harmless services that let a technician read an ECU's memory, UDS also defines much more powerful services.

UDS service What it does Why it is critical
ECUReset (0x11) Restarts the ECU Unwanted restart while driving
SecurityAccess (0x27) Unlocks protected functions Can be bypassed with a weak seed key
WriteDataByIdentifier (0x2E) Writes to ECU memory Calibration and setting manipulation
RequestDownload / TransferData (0x34 / 0x36) Loads new firmware Malicious firmware flashing surface
CommunicationControl (0x28) Silences ECU communication Disabling specific modules

Some of these services are genuinely needed by a real service technician. The question is whether these services are equally open to anyone who plugs in an OBD II dongle.

How an assessment is done

An automotive cybersecurity assessment usually starts with passive listening; while the vehicle runs, bus traffic is recorded and which arbitration IDs talk, how often and with what content is extracted. UDS traffic is then parsed and it is determined which services are used in diagnostic sessions (functional 0x7DF, physical 0x7E0 to 0x7E7, responses 0x7E8 to 0x7EF). If SecurityAccess, ECUReset or flash services are reachable without authentication, this is reported as an ECU takeover or malicious reflash surface. In the active testing stage, controlled messages are sent to confirm whether these services actually work and whether any authentication layer exists, the same way every finding in a penetration test needs to be backed by proof.

Not just CAN

Modern vehicles use LIN (simple sensor and actuator lines) and FlexRay (high speed real time systems) alongside CAN, and increasingly Automotive Ethernet (DoIP, SOME/IP). Connected vehicles add a telematics unit reaching a cellular network, and keyless entry systems add a short range radio attack surface. This expanding surface turns automotive cybersecurity into a problem similar to classic SCADA and industrial control systems security: an old protocol never designed with security in mind is being opened up through new connection points.

The KAOS and DSET approach

DSET assesses the CAN bus and UDS diagnostic surface for automotive manufacturers and suppliers. Our local AI engine KAOS passively listens to a CAN interface to characterize traffic, automatically classifies UDS services, and reports with proof whether critical services such as SecurityAccess or flash are left unprotected. The assessment proceeds from passive listening first, then to controlled and reversible active tests, in a way that never risks the vehicle's real driving safety.

Frequently asked questions

Does listening to the CAN bus damage the vehicle? No. Passive listening only reads traffic without sending any message to the bus and does not affect the vehicle's operation in any way. The risky part is sending real messages during active testing, and this step must always be controlled, reversible and done with prior authorization.

Does every vehicle have a UDS vulnerability? No. Some manufacturers implement strong seed key algorithms and rate limiting for SecurityAccess, while others use weak or old algorithms. The level of protection varies greatly by make, model and model year, which is why assessment must be done separately for each vehicle.

Is plugging in an OBD II dongle dangerous on its own? Plugging your own dongle into your own vehicle generally carries no risk. The real risk is a third party gaining physical access to a vehicle and connecting a malicious device, or a wireless OBD II dongle itself carrying a vulnerability.

Sources

To assess your vehicle's or fleet's CAN bus and UDS diagnostic surface, contact DSET. We provide automotive cybersecurity consulting from our Ankara Hacettepe Teknokent laboratory.