Securing the diagnostic channel: ISO 21434, UN R155 and UDS 0x29

Two UNECE regulations now sit behind every new vehicle type approval in the EU and the wider UNECE market. UN R155 requires a certified Cyber Security Management System (CSMS) covering the whole vehicle lifecycle; UN R156 requires a Software Update Management System (SUMS) governing how software reaches a vehicle, whether over the air or through a workshop tool. R155 has applied to new vehicle types since July 2022 and, since July 2024, to all new vehicles produced for those markets. A vehicle cannot be registered without it.

Underneath the regulation sits the engineering standard, ISO/SAE 21434:2021, which specifies cyber-security engineering across the full lifecycle of electrical and electronic systems, from concept and development through production, operation, maintenance and decommissioning. It introduces Threat Analysis and Risk Assessment (TARA) as the structured method for identifying attack paths and justifying the controls that answer them. The diagnostic interface is precisely the kind of asset a TARA is built to scrutinise.

Diagnostics is not a read-only window. Through the off-board interface a tester can flash firmware, run a bootloader, unlock restricted routines, change configuration and read out sensitive data. That is exactly the privilege set an attacker wants. A diagnostic session that can reprogram an ECU is, in security terms, a remote code execution path with a connector on the end of it.

Because the same off-board protocol stack is used legitimately by every workshop and OEM tool, the bar for protecting it is high: the channel has to be open enough for authorised diagnostics everywhere, yet closed to anyone who simply plugs in. A 21434 risk assessment that takes flashing and unlock services seriously will almost always flag the access-control mechanism on the diagnostic channel as a top-rated item.

For decades, that access control has been UDS service 0x27, SecurityAccess (defined in ISO 14229-1). The tester requests a seed, applies a secret algorithm and returns a key; if the key matches, the ECU unlocks. The weaknesses are well documented. The seed-key relationship is often a fixed algorithm with shared secret constants reused across an entire ECU family, so reverse-engineering one unit can compromise the whole range. Implementations frequently leak through static seeds or easily invertible functions.

More fundamentally, 0x27 authenticates a one-off unlock, not a session, and it is unidirectional: the ECU never verifies the tester's identity, and the tester never verifies the ECU. Once unlocked, the channel offers no continuous proof of who is talking. That is a poor fit for a 21434 world in which provenance and integrity must be demonstrable, not assumed.

ISO 14229-1:2020 introduced service 0x29, Authentication, as the modern answer. Instead of a shared secret, it uses asymmetric cryptography. In its certificate-exchange mode (Authentication with PKI Certificate Exchange), the tester presents an X.509 certificate that the ECU validates against a trusted certificate authority, with a signed challenge-response proving possession of the private key. A challenge-response mode using pre-installed keys is also available where full PKI is impractical.

The improvements map directly onto what the regulations want. Authentication can be bidirectional, so tester and ECU mutually verify identity, defeating a class of man-in-the-middle attacks that 0x27 could not address. Roles and rights can be bound to the certificate, and revocation removes a compromised tool without re-keying every ECU in the field. The result is a diagnostic channel whose access decisions are based on verifiable identity rather than a secret that, once leaked, unlocks everything.

Authentication controls who may talk; UN R156 and 21434 also demand control over what gets installed. Secure software update means firmware images are cryptographically signed and verified before they are accepted, with version identification (RxSWIN) so type-approval-relevant software can be tracked, and rollback protection so an attacker cannot force a downgrade to a vulnerable older build. Secure boot then extends that chain of trust to start-up, refusing to run code that fails verification.

These guarantees rest on keys, and keys must be protected. A Hardware Security Module gives the ECU a tamper-resistant home for private keys and a place to perform signature checks and certificate validation in isolation from application code. The practical engineering challenge is that HSM hardware varies widely between silicon vendors. Abstracting the cryptographic and key-storage layer behind a stable interface, as Diadrom does with Encrypt and the Autotech Bootloader against the AUTOSAR Crypto Service Manager API, lets the same secure-boot and secure-download logic move across platforms without re-validating the security argument each time.