UDS (ISO 14229) security: the protocol that can reflash an ECU, and what guards it

UDS is ISO 14229, an application-layer protocol. ISO's own published abstract for the current withdrawn-but-authoritative 2020 edition (ISO 14229-1:2020, third edition, 466 pages, maintained by ISO/TC 22/SC 31) states it "specifies data link independent requirements of diagnostic services, which allow a diagnostic tester (client) to control diagnostic functions in an on-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle," and explicitly states it "does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units." UDS is data-link independent by design: the same application-layer service set can run over CAN (via ISO 15765-2, "Diagnostic communication over Controller Area Network"), over Ethernet (via DoIP, ISO 13400), over LIN or over FlexRay. ISO 15765-2's own published abstract confirms this layering directly: it "specifies a transport and network layer protocol with transport and network layer services tailored to meet the requirements of CAN-based vehicle network systems," and states that "the diagnostic communication over controller area network (DoCAN) protocol supports the standardized abstract service primitive interface as specified in ISO 14229-2 (UDS)." In practice, when someone says "UDS over CAN," they mean ISO 14229's services carried inside ISO 15765-2's transport framing — single-frame, first-frame, consecutive-frame and flow-control messages that let a diagnostic payload larger than one CAN frame (8 bytes on classic CAN) move as a reassembled sequence.

UDS is a direct descendant of an older protocol, ISO 14230 (KWP2000, Keyword Protocol 2000), and the two are sometimes confused in casual writing — a distinction this guide treats carefully below, because it matters for at least one widely cited piece of automotive security research.

AUTOSAR's Diagnostic Communication Manager (Dcm) specification — a freely published PDF describing the software module that implements UDS on most AUTOSAR-based production ECUs — documents these services at the level of exact requirements and negative-response codes (NRCs). The services that matter most for security are:

AUTOSAR's specification also documents the built-in anti-brute-force mechanics around SecurityAccess: a configurable attempt counter and delay timer, with specific negative response codes for each failure mode — NRC 0x24 (RequestSequenceError) if a key is sent without a prior valid seed request, NRC 0x35 (InvalidKey) for a wrong key, NRC 0x36 (ExceededNumberOfAttempts) once a configured attempt limit is reached, and NRC 0x37 (RequiredTimeDelayNotExpired) while a lockout delay is active. These mechanics are genuinely useful anti-brute-force controls — but they only help if the key-derivation algorithm behind them is also strong, which is where real-world weaknesses have repeatedly shown up.

ISO 14229 standardizes the mechanics of the seed-key exchange — the request format, the response format, the resulting security-level state machine — but it deliberately does not mandate a specific cryptographic algorithm for turning a seed into a key. That choice is left to each vehicle manufacturer and ECU supplier. In practice, that openness has produced a recurring pattern of weak, ad hoc implementations rather than a healthy variety of strong ones:

• Miller and Valasek's 2015 Jeep Cherokee research reverse engineered Fiat Chrysler's dealer-only wiTECH diagnostic software and, after de-obfuscating encrypted ".esu" unlock files, found the key-derivation logic "involve[d] some secrets and simple bitwise manipulations" — describing this pattern of lightweight, non-cryptographic schemes as "ubiquitous within the automotive industry."
• Koscher et al.'s 2010 "Experimental Security Analysis of a Modern Automobile" (cited directly in the 2024 Colorado State NDSS paper discussed below) found commonly used 8- or 16-bit seed-key pairs susceptible to brute-force.
• Maag, Reding and Howell's 2017 presentation on heavy-vehicle seed-key exchange found a linear mapping between seed and key in some medium/heavy-duty vehicle implementations, making 16-bit seed-key pairs predictable without needing the underlying secret.
• Sekar Kulandaivel's 2021 Carnegie Mellon PhD thesis, "Revisiting Remote Attack Kill-Chains on Modern In-Vehicle Networks," found that seeds used in some UDS challenge-response implementations were not fully random and could be influenced by ECU uptime — meaning an attacker could potentially predict a usable seed-key relationship without ever learning the manufacturer's algorithm.
• A 2026 Synack test, explicitly run "against a simulator, not a live vehicle," showed how trivial the weakest end of this spectrum can get: an AI testing agent determined a SecurityAccess key was simply the seed's bitwise complement (key = seed XOR 0xFF), letting it compute a valid key from any observed seed with a single operation.

None of these findings is a defect in ISO 14229's published text. They are the direct, repeated consequence of a standard that leaves algorithm strength entirely up to implementers — and of implementers, across multiple OEMs and vehicle classes over more than a decade, choosing weak ones.

Two pieces of research are worth separating carefully, because they're often conflated and they actually show different things.

Miller and Valasek, 2015 Jeep Cherokee ("Remote Exploitation of an Unaltered Passenger Vehicle"). Reading the paper directly shows a more specific picture than the popular summary of "hackers reflash a Jeep's ECU remotely." The researchers achieved remote code execution on the Uconnect head unit's OMAP chip, then needed to pivot to the vehicle's CAN bus through a separate microcontroller, the Renesas V850. To do that, they reverse engineered the proprietary SPI protocol the head unit uses to push firmware to the V850 — a protocol the paper describes as looking "like ISO 14230 commands" (ISO 14230 is KWP2000, UDS's predecessor, not ISO 14229 itself), observing byte sequences matching startDiagnosticSession (10 85), requestDownload (34 ...) and requestTransferExit (37). Critically, the paper states plainly: "we see that the IOC can be re-flashed with firmware and that no cryptographic signatures are used to verify the firmware is legitimate" — the reflash path they actually exploited had no integrity check at all, UDS-style SecurityAccess or otherwise. Separately, for the live physical-control attacks on steering and braking, the researchers sent genuine diagnostic session-control messages on the car's real CAN bus (for example, "EID: 18DAA0F1 ... Data: 02 10 02 ..." to start a diagnostic session with the power-steering ECU) — but they explicitly reverse engineered Chrysler's ISO 14229 SecurityAccess seed-key algorithm from the wiTECH tool as a separate side investigation, and the paper states: "it should be noted that, unlike our previous research on the Ford and Toyota, we never really needed the security access keys to perform our attacks. The only thing the SecurityAccess algorithms were used for was re-flashing ECUs, which we didn't explore." In short: the Jeep paper is genuine, foundational, independently verifiable automotive security research, and it does document a weak real-world SecurityAccess implementation and an unsigned firmware reflash path — but its headline attack did not depend on defeating UDS SecurityAccess, and the reflash mechanism it actually used is described as ISO-14230-like, not confirmed as ISO 14229/UDS proper.

Chatterjee, Green and Daily, 2024, NDSS VehicleSec Workshop ("Exploiting Diagnostic Protocol Vulnerabilities on Embedded Networks in Commercial Vehicles"). This is a more directly on-point, independently verifiable ISO 14229 case. The Colorado State University researchers demonstrated three distinct vulnerabilities on both bench-level ECU testbeds and a real, fully equipped 2018 Freightliner Cascadia truck cab: a Read Data by ID Overload attack, flooding an ECU with ReadDataByIdentifier (0x22) requests to crowd out its periodic message transmission; a Session Denial attack, where an attacker establishes a diagnostic session with a spoofed source address and keeps it alive with Tester Present messages, exploiting the ISO 14229-1 requirement that "there shall always be exactly one diagnostic session active in an ECU" to lock out legitimate tools; and a Diagnostics Jam, which abuses ISO 15765-2's flow-control framing by alternating "Wait" and "Clear to Send" frames to stall an ECU's ability to process further diagnostic requests. The paper's gateway-ECU finding is the most operationally relevant one for a fleet operator: testing the Freightliner's gateway, the researchers found it "consistently permitted almost every diagnostic message, including those related to 'Read Data by ID', 'Diagnostic Session Control', and 'ISO-TP'" while blocking unrelated J1939 attack traffic — meaning a gateway explicitly designed to segregate diagnostics from the rest of the vehicle network let every one of these UDS-shaped attacks straight through, because diagnostic traffic is exactly what it's supposed to allow.

Whether SecurityAccess is strong, whether a firmware reflash path checks a signature, and whether hard-coded keys or a predictable seed-key algorithm sit inside an ECU's binary are all questions that get answered by examining the firmware itself, not by reading a protocol specification in isolation. SoftWSP's device & firmware security service scans a binary firmware image — including without source code — builds a software bill of materials, checks for hard-coded passwords and embedded keys, and flags update mechanisms that are not signed, with an engineer reviewing every AI-assisted finding before it reaches a report; see device & firmware security services for what a scan and, where source code is available, remediation actually covers.

This guide draws on ISO's own catalogue/abstract pages for ISO 14229-1 (2013 and 2020 editions) and ISO 15765-2:2016, fetched directly; AUTOSAR's publicly downloadable Diagnostic Communication Manager specification (R24-11), fetched and read directly for its SecurityAccess, DiagnosticSessionControl, RequestDownload/TransferData/RequestTransferExit and ReadDataByIdentifier/WriteDataByIdentifier requirements; Miller and Valasek's full "Remote Exploitation of an Unaltered Passenger Vehicle" paper, fetched and read directly in full; the 2024 Chatterjee/Green/Daily NDSS VehicleSec paper, fetched and read directly in full; CISA's ICSA-16-341-01 Tesla advisory, fetched directly; and search-surfaced quotations (not a direct full-document fetch, since the live PDF returned an access-denied response during this research) from NHTSA's September 2022 Cybersecurity Best Practices for the Safety of Modern Vehicles, which should be independently confirmed against the primary PDF before being relied on verbatim. Secondary findings attributed to Koscher et al. (2010), Maag/Reding/Howell (2017) and Kulandaivel (2021) are cited here as described in the NDSS paper's related-work section and were not independently re-fetched from their original publications for this guide. The full text of ISO 14229-1, ISO 14229-2 and ISO 15765-2 beyond their public scope/abstract pages is paywalled and was not purchased or independently reviewed for this guide; treat granular protocol-field claims as general description, to be confirmed against the primary ISO standard text and a specific ECU's actual implementation. This guide is general information, not a substitute for the purchased ISO standard texts, a vendor's product-specific diagnostic documentation, or a current CISA/NHTSA advisory search for your exact vehicle platform and ECU supplier.