Root of Trust in the software-defined vehicle

What state of the art looks like in vehicle cybersecurity

The automotive industry has learned, at series-production scale and under binding regulation, how to anchor trust in hardware and keep it intact for a vehicle’s whole service life.

Since UN R155 and R156 became mandatory for all new vehicles in the EU in July 2024, manufacturers must show that software is authentic, that only authorised parties can change it, and that this stays true for the vehicle’s life. The answer is a hardware Root of Trust extended through a verified chain: secure boot, signed software, secure OTA, authenticated access and managed keys.

What Diadrom brings. We have built these mechanisms, not just studied them. Our bootloader and security stack run secure boot, signed download and authenticated access in ECUs on public roads today, including Volvo Cars programmes. This paper sets out what is settled, what it costs, and what is still open.

Every connected ECU is part of the attack surface

The software-defined vehicle has more code, more connectivity and more parties touching its software than ever. Each of them is a way in.

Entry point	Examples	State-of-the-art control
Wireless and remote	Cellular and OTA, Wi-Fi, Bluetooth, NFC	Signed and encrypted update packages, authenticated backend, gateway firewalling
Physical ports	OBD-II, USB, charging port, harness connectors	Certificate-based diagnostic authentication, rate limiting, locked debug
In-vehicle networks	CAN, CAN FD, LIN, FlexRay, Ethernet	SecOC message authentication, domain segmentation, intrusion detection
Software supply chain	Tier 1 and Tier 2 code, open source, tools	OEM trust centre signing, SBOM per release, requirement-traced tests
Production and aftermarket	End-of-line key programming, workshops, third-party repair	Key injection in secured environments, role-based tool credentials
Backend and data flows	OEM backend, vehicle SOC, apps and smart devices	CSMS monitoring and incident response under UN R155

Software now defines the vehicle

Hardware and software lifecycles are being decoupled, so vehicles gain functions long after delivery. That only works if every update arrives authentic and every ECU can prove what it runs.

Security is here to stay, at a cost

Cybersecurity adds bill-of-material cost, engineering effort and latency. The question is no longer whether to pay it, but how to pay it once and reuse it across programmes.

Where to start. The update path. It is the one interface that touches every ECU, every supplier and every vehicle long after delivery.

Regulation made security non-negotiable

Vehicle cybersecurity became mandatory when it became a condition for type approval. Standards now define what good looks like.

Instrument	What it requires	What it means for suppliers
UN R155 (CSMS)	Certified CSMS across the vehicle lifecycle. New types from July 2022, all new vehicles from July 2024 (EU).	The OEM audit flows down: TARA input, vulnerability handling and evidence per ECU.
UN R156 (SUMS)	SUMS: version identification (RXSWIN), integrity, authenticity, compatibility. A failed OTA update ends in the previous version or a safe state.	The ECU must verify packages, report its version and recover from an interrupted update.
ISO/SAE 21434:2021	Cybersecurity engineering, including Threat Analysis and Risk Assessment (TARA). A revision is under way.	A cybersecurity interface agreement and work products for each delivery.
ISO 24089:2023	Software update engineering at organisation, project, package and campaign level.	Update packages with the metadata a campaign needs: targets, dependencies, compatibility.
ISO 14229-1 (UDS)	Authenticated diagnostic access via service 0x29, introduced in the 2020 edition. Current edition: 2026.	Certificate handling in the ECU and in every tester.
Uptane (IEEE-ISTO 6100)	Voluntary framework for compromise-resilient OTA, first standard released 2019.	Split signing roles, so compromising one repository is not enough to push arbitrary software.

Observation 1 · Regulation flows down to suppliers. The OEM holds the approval; suppliers produce most of the evidence: traced tests, TARA outputs, signed releases, SBOMs.

Observation 2 · Proving it is the hard part. The mechanisms are well understood. What separates programmes is traceability: which software, signed by whom, runs in which vehicle.

A hardware anchor, extended into a chain of trust

State of the art in automotive is a security anchor inside the microcontroller, extended step by step to cover boot, update, access and communication.

Fixed function: SHE, Secure Hardware Extension

A HIS specification, widely used with AUTOSAR. A small module with AES-128, CMAC and protected key slots. Supports a hardware-triggered secure boot that compares a CMAC of the boot code with a stored reference.

Programmable: HSM, Hardware Security Module

Following the EVITA profiles. A security core with its own memory, true random number generator, AES, SHA-2 and asymmetric acceleration (ECC, on some parts RSA) and isolated key storage. Found across Infineon, NXP, Renesas and ST families.

The public key is the actual Root of Trust. Software authenticity is proven with asymmetric signatures, typically RSA-PSS with keys of at least 2048 bits, or ECDSA. For keys that must last beyond 2030, 3072-bit RSA is the safer choice. Good practice is to keep the verifying public key in immutable storage after end-of-line production, or to protect it with a hardware-enforced boot check, and to let no external interface overwrite it.

Security state is explicit and one-way. Every device carries a readable security state, development or production. The step to production is irreversible, every unit leaving the line is checked, and debug and non-specified services are permanently disabled.

Each stage checks the next before handing over control

On board, in each controller, from the anchor down. The off-board parts are shown where they connect.

On board · in each controller

1

Hardware Root of Trust. HSM or SHE: isolated keys and crypto engines. Root-of-trust public key in protected storage.

checks the next

2

Primary bootloader (PBL), verified by the Hardware Root of Trust at every start-up. Secure boot of the boot area. Starts only parts marked valid.

checks the next

3

Secondary bootloader (SBL), which the PBL loads into RAM to program. Writes to flash, then verifies before marking it valid.

Off board · supplies the signed part

OEM trust centre. Signs production releases and holds the private keys.

checks the next

4

Application software. Only parts marked valid can start. Authenticated diagnostics and SecOC on internal buses.

Off board · authenticates to it

Diagnostic tool or OTA backend. PKI certificate, role-based, revocable.

• The anchor is locked after end-of-line production.
• The trust centre stays with the OEM; suppliers sign with development keys.
• Every tool and backend is identified by a revocable certificate.

Three ways to update an ECU safely

OTA makes the update path the most exposed interface in the vehicle. How an ECU stores and activates new software decides what happens when an update fails.

A/B swap in four steps

1. Bank A: Active. Runs v1.4 while the vehicle is in use.
2. Bank B: Written in background. v1.5 downloaded, signature and version verified.
3. Switch: Atomic swap. B becomes the executable range at next start-up.
4. Rollback: A is kept. If v1.5 fails, the ECU starts from A again.

Strategy	How it works	Strengths	Costs
In-place update via bootloader	The ECU enters programming mode. The bootloader erases and rewrites flash; boot code stays in protected memory.	Minimal flash. Works on the smallest MCUs. Proven for decades.	ECU unavailable while programming. Recovery means downloading a valid version again.
A/B swap on a dual-bank MCU	The new image goes to the inactive bank while the vehicle runs. Hardware swaps banks at start-up.	Near-zero downtime, fast rollback while the old bank is intact, well suited to OTA. Supported in hardware on, for example, Infineon AURIX TC3xx and NXP S32K3.	Roughly twice the flash for the application. Keys, counters and configuration must stay consistent across both banks.
A/B partitions on high-performance computers	Linux or Android systems update an inactive partition and switch at reboot.	Mature tooling, large images, well suited to delta updates.	Large storage needs. Every partition and the whole boot chain must be verified.

Where Diadrom stands. Our deliveries so far use the in-place model with a fallback primary bootloader. A/B swap is gaining ground as OTA reaches more ECUs.

The OTA chain, from backend to ECU

A secure OTA update is only as strong as its weakest link. Each step verifies before it passes the package on.

Off board1

OEM backend. Builds, signs and plans the campaign.

In the vehicle

2

Gateway or TCU. Downloads over a secure channel, checks metadata and vehicle state.

3

Update orchestrator. Distributes to target ECUs, for example AUTOSAR V-UCM.

4

Target ECU. Installs, verifies signature and version, activates only if valid.

Four design decisions every OTA programme faces

Compression. Cuts transfer time and cost. Sign the unprocessed data so the signature survives a change of method; the decompressor then sees unauthenticated data and must be hardened.

Delta updates. Send only what changed. Saves time and bandwidth, but delta encoding is complex and pays off mainly on high-performance ECUs.

Encryption. Signing proves origin; encryption protects the software in transit. End to end, from backend to an ECU whose HSM holds the key.

Key management. Key files unlocked locally on engineering PCs are still common. State of the art moves to HSM-backed key vaults and server-side signing.

Compromise resilience with Uptane. Uptane splits trust between an image repository (which software exists) and a director (what this vehicle should install), each with its own keys. Primary ECUs cross-check both in full verification; secondaries should too where their hardware allows. With full verification, compromising one repository is not enough to install arbitrary software.

Secure boot and update, in series production

Diadrom Autotech Bootloader and Diadrom Encrypt implement this chain of trust in ECUs on public roads today.

• Primary bootloader. Runs secure boot and checks every part is valid, complete and compatible. No write access to flash. Treated as part of the hardware.
• Secondary bootloader. Loaded into RAM to program. Writes new software to flash, verifies it there, and marks it valid only if the check passes.
• Fallback concept. Proposed by Diadrom, approved by the OEM. Makes the primary bootloader updatable; an interrupted update never leaves the unit unreachable.

Security function	How it works in our deliveries
Secure boot	SHA-256 hash over a secure memory area, verified by the SHE or HSM at every start-up. Status logged and readable over diagnostics.
Software authentication	Each software part carries a table of per-block hashes. A root hash, signed by the OEM trust centre, is verified before activation.
Development and production signatures	Suppliers sign with a development key; the OEM re-signs for production. One binary moves from rig to vehicle without a rebuild.
Anti-rollback	Signed version information and release-order comparison block unauthorised downgrades to vulnerable versions.
Secure storage	Trust store integrity verified by MAC before every access. Device-unique symmetric keys where possible.
Authenticated access	Challenge-response access under UDS 0x27: AES-CMAC and AES-CTR over random challenges, with request rate limiting, false-attempt counters and delay timers.
Key management	Initial keys at the supplier, production keys programmed at the OEM, key status readable, keys protected end to end.
Evidence	Unit, system and stress tests traced to every requirement. MISRA C:2012 analysis. SBOM in CycloneDX format with every delivery.

Hardened by series production

• 250,000+ series-production vehicles run Diadrom software
• 0 units bricked by Diadrom software since 2016
• ~550 test cases across about 30 releases
• 10,000+ development hours in the bootloader

Selected programmes

• 2020 to 2025 · Head-up display for Volvo Cars and Polestar (SPA2), with Nippon Seiki. Pilot project for modern cybersecurity under UN R155: secure boot, secure software download, secure memory area, SHE integration and key management.
• 2021 onwards · European Tier 1 supplier. HSM-based cryptography, LIN and CAN FD. Two production variants in series vehicles.
• SPA3 · Updated for Volvo Cars’ latest platform. HSM integration, updatable primary bootloader, security logging and SBOM for every deliverable.
• Today · Volvo Cars secure update delivery. Bootloader, Encrypt and diagnostic stack shipped together. Diadrom software is in series production in the Volvo EX90.

Silicon already supported

Infineon AURIX TC3xx, NXP S32K, NXP MWCT2xxxS, Renesas RH850, Renesas RL78, STMicroelectronics STM32 and Microchip PIC32CZ CA.

The maintenance channel is the attack path

The diagnostic interface can flash firmware, unlock routines and read sensitive data: a remote code execution path with a connector on the end. With OTA, the same privileges reach the vehicle over the air.

Three generations of access control

Generation	Mechanism	Weakness or benefit
Legacy SecurityAccess (UDS 0x27)	Seed and key with a secret algorithm, often shared across an ECU family	Reverse-engineering one unit can compromise the whole range. Authenticates an unlock, not a session.
Cryptographic challenge	AES-CMAC over random challenges, keys per level, rate limiting and lockout	Strong and lightweight, but relies on symmetric keys that must be protected and distributed.
Authentication (UDS 0x29)	PKI certificates (e.g. X.509), signed challenge-response, roles bound to the certificate	Supports mutual authentication. A compromised tool can be shut out by revoking or expiring its certificate, without re-keying the fleet.

Rule of thumb. Every tool, workshop and backend is identified by a revocable credential with a defined role, never by knowledge of a fleet-wide key.

Secure on-board communication

AUTOSAR SecOC adds a truncated MAC and a freshness value, usually a counter, to critical messages between ECUs. It protects integrity and prevents replay on buses such as CAN that have no native security. On CAN FD and Ethernet the bandwidth cost is lower, so longer MACs become practical.

Uniform testing across suppliers

When many suppliers implement the same security concept, differing interpretations become a vulnerability in themselves. Diadrom uses shared automated test suites (Diadrom Dolphin) to verify every implementation against the same expected behaviour. Every OEM integrating many suppliers faces the same problem.

Trust lives in the lifecycle

A Root of Trust is only as strong as the processes around it. Most of the effort, and most of the failures, sit outside the silicon.

Key lifecycle

Every key has a cryptoperiod. Expired pairs are revoked, private keys deleted. Production keys live only in hardened servers run by a small, trained group.

Trust centre and signing

Production signatures come from the integrator’s trust centre, never the supplier. Suppliers test freely with development keys. Suppliers never hold production signing keys.

Configuration is the security record

You cannot prove the integrity of what you cannot enumerate: part, version, signature, serial number. Diadrom’s DiagStudio keeps this record and links it to PKI, PLM and update systems.

Fail-safe by design

Under UN R156 a failed OTA update must end in the previous version or a safe state. A two-level bootloader keeps the ECU reachable after an interrupted update. With OTA, where no technician is present, this is essential.

A new addition to the hardware abstraction layer

From our engineering notes · Jonas Hellberg, CTO

Verifying a software update takes time, and on a single-core MCU it blocks everything else. So the work moves into an HSM, whose interface differs by vendor and sits under NDA. We put a hardware abstraction layer in between.

• Portability. Switching semiconductor vendor no longer means rewriting the security code.
• Testability. The logic is unit tested against one generic interface.
• No vendor quirks. Polled jobs or interrupts, results come back the same way.

/* Encrypt data with AES-CTR */
bool dcs_cs_hal_aes_ctr_encrypt(
  uint8_t  *plain_data,
  uint32_t  plain_data_len,
  uint8_t  *iv,
  uint8_t  *encrypted_data);

The same layer covers SHE, HSM and HSE, so the security case moves with the platform from one programme to the next.

What works well, and what it costs

An honest view of today’s automotive practice, for anyone deciding what to adopt and what to watch.

Area	What works well	Limitations and cost
Hardware Root of Trust	Isolated keys and fast crypto, standard in current automotive MCUs.	Interfaces differ by vendor and sit under NDA. Older and low-cost MCUs lack an HSM. Side-channel protection varies.
Secure boot	Stops tampered code at every start-up.	Adds boot time. Each OEM must decide whether a failed check blocks start-up or is logged and reported, trading security against availability.
Signed software and anti-rollback	Proven at scale; one trust centre controls what reaches production.	Running the PKI and trust centre is a large, permanent effort. RSA signatures are large for small ECUs.
OTA with A/B swap	Near-zero downtime and fast rollback.	Roughly double flash. State must stay consistent across banks. Not available on every MCU.
Diagnostic access	Certificate-based 0x29 is strong, can be mutual, and limits the damage from one compromised tool.	Shared-secret 0x27 schemes are still common in the fleet. PKI in workshops is complex.
On-board communication	SecOC gives integrity and replay protection on CAN.	Truncated MACs trade security for bandwidth. Keys and freshness must be kept in sync across ECUs.
Supplier flow-down	Common standards make evidence comparable.	Suppliers interpret the same concept differently. Verification effort is heavy.
Cost	Reusable once built: the same stack serves many programmes.	Higher bill of materials, engineering effort and latency.

Bottom line. The mechanisms are mature and can be reused. The cost and the risk sit in the lifecycle around them: keys, PKI, evidence and updates.

Clear on mechanisms, still open on the lifecycle

Where automotive practice is settled, and where it is still moving.

Settled practice in automotive

• Hardware-anchored secure boot and signed software for every updatable ECU.
• A clear move from shared-secret unlocks towards certificate-based diagnostic authentication.
• Security requirements flowed down to every supplier, proven by traced test evidence.
• OTA with signed packages and safe rollback, increasingly with A/B swap.
• Security hardware behind an abstraction layer, so the security case survives a change of silicon.

Open challenges

1. Post-quantum migration. Systems designed today may still operate when quantum-capable attackers exist. Signatures must be replaceable in the field, with room for larger keys.
2. Crypto agility versus immutability. The Root of Trust must be immutable, yet keys and algorithms renewable. Updating the trust anchor itself, with no risk of an unrecoverable unit, is still hard.
3. Supply-chain assurance. Proving that each binary was built from the declared sources, by the declared supplier, remains hard. SBOMs are necessary but not sufficient.
4. Memory-safe implementation. Diadrom has evaluated a Rust bootloader for memory safety, performance and toolchain maturity on constrained hardware.
5. Controlled AI in operations. As AI enters fault analysis, its outputs must rest on authenticated, traceable data. Trust in the data path becomes part of the Root of Trust question.

Teams that start now can adopt the settled practice as it is, and design for the open questions instead of retrofitting them.

How we can help

Diadrom is a Gothenburg-based software company specialising in diagnostics, embedded software and lifecycle governance for mission-critical systems. Founded in 1999, ISO 9001 and ISO 14001 certified, listed on NGM Nordic SME (DIAH). Customers include Volvo Cars, Polestar, Lynk & Co, AB Volvo, Volvo Penta, Scania and Nippon Seiki, and in defence Saab, Thales and FMV.

• Security concept review. Practitioner review of your boot, update and access concept against current practice.
• Bootloader and HSM integration. Diadrom Autotech Bootloader and Encrypt, adapted to your MCU and OEM requirements.
• Test automation and evidence. Security tests traced to requirements with Diadrom Dolphin, ready for audit.
• Workshops. Sessions on OTA and cybersecurity, led by engineers who built these systems.

Key experts

• Jonas Hellberg, CTO. 12+ years and 25+ projects at Diadrom. Author of our secure bootloader requirement specification. Led bootloader and cybersecurity integrations for Nippon Seiki and other Tier 1 suppliers. Software download specialist on Volvo Cars SPA2; former diagnostic concept leader at CEVT.
• Dawid Ejdeholm Wirsén, Lead Embedded Software Developer. Leads development of the Diadrom Autotech Bootloader and Encrypt. HSM and HSE integrations, SecurityAccess and secure boot in two series-production variants. Led our Rust bootloader evaluation.
• Viktor Eliasson, CEO. Engagement lead. Speaker on automotive cybersecurity and the software-defined vehicle; leads Diadrom’s expansion into defence.

Contact. Viktor Eliasson, CEO · info@diadrom.se · +46 733 31 11 15

Sources

• Uptane Standard for Design and Implementation (IEEE-ISTO 6100; current version 2.1.0). uptane.org
• AUTOSAR Adaptive Platform: Vehicle Update and Configuration Management (R23-11). autosar.org
• AURIX TC39x product page: A/B swap OTA support, EVITA Full HSM. infineon.com
• S32K3 microcontrollers: A/B firmware swap, HSE secure boot. nxp.com
• Securing the diagnostic channel: ISO 21434, UN R155 and UDS 0x29.
• ISO 24089: software update engineering, explained.
• Abstracting the HSM: portable security for the bootloader. Jonas Hellberg.
• Software defines premium: The 7 Pillars. Diadrom white paper, 2025.
• Diadrom products: Bootloader, Encrypt, Diag Com Stack, DiagStudio, Dolphin.