A secure OTA update workflow under UN R156

What a secure OTA workflow has to guarantee

A secure OTA update workflow is the end-to-end path a software package travels from the build server to a running vehicle, together with the controls that keep it trustworthy at every step. UN R156 does not prescribe a specific architecture, but it does set the properties the workflow must have: the software identity must stay traceable through RxSWIN, the update's integrity must be protected, installation must happen under safe conditions, and there must be records that prove all of it. Get those properties right and the mechanism can be built many ways; miss one and no amount of engineering elsewhere recovers it.

It helps to read the workflow as a chain of custody. The package is only ever as trustworthy as the weakest link between where it was built and where it runs.

The stages, and the control at each

Stage	What happens	Control that makes it safe
Build	The update is compiled from a known, version-controlled source	Reproducible build; software configuration recorded against RxSWIN
Assess	The update is evaluated for effect on regulated functions	SUMS decision on approval extension and RxSWIN change
Sign	The package is cryptographically signed	Signing keys held in an HSM; key access controlled and logged
Distribute	The package is placed on the update backend	Authenticated, integrity-protected channel to the vehicle
Pre-check	The vehicle confirms it can safely install	Battery/state, correct target ECU, compatible version
Verify	The vehicle checks the package before install	Signature and integrity verified on-device before anything is written
Install	The update is applied	Safe-state; power and communication protected during flash
Confirm	The result is captured	Success/failure recorded; rollback or recovery on failure
Record	Evidence is retained	Per-vehicle log of what, when and outcome, tied to RxSWIN

The order matters. Verification happens on the vehicle, immediately before installation — not only at the backend — because the threat model includes tampering in transit and at rest on the device. A package that was signed correctly but altered afterwards must be rejected by the vehicle itself.

Integrity and authenticity rest on PKI

Every "signed" and "verified" box above depends on a working public-key infrastructure. The manufacturer signs update packages with a private key held securely; the vehicle carries the corresponding trust anchor and verifies the signature before it installs anything. If that key is exposed, an attacker can sign malicious updates that the fleet will accept as genuine, which is why key generation, storage in an HSM, rotation and revocation are treated as first-order concerns rather than an implementation detail. We cover this lifecycle in automotive PKI and key management; for an OTA workflow it is the foundation, not an add-on.

Pre-conditions and the safe state

An update must not install just because it arrived. R156 expects installation to occur under conditions that keep the vehicle and its user safe. In practice the vehicle checks a set of pre-conditions — sufficient power, the correct target ECU present, a compatible current version, the vehicle in a state where installation will not interrupt a safety function — and defers or refuses if they are not met. During installation the relevant systems are held in a defined safe state so that a mid-flash interruption does not leave a control unit in an undefined condition.

Failure is part of the design

Updates fail: power drops, connectivity is lost, a package is corrupted. A secure workflow treats failure as an expected branch, not an exception. The vehicle must be able to return to a known-good state — either by rolling back to the previous image or by recovering to a safe operating condition — and the outcome must be recorded. This is where R156 and ISO 24089 meet the ground, and we treat it in full in rollback, recovery and integrity. The short version: an update that cannot fail safely is not fit to release.

Records are the deliverable

The part teams underweight is record-keeping. For each campaign the SUMS must be able to show what was delivered, which vehicles received it, when, and whether it succeeded — all tied back to the software identity via RxSWIN. These records are not bureaucracy; they are the evidence the assessor opens, and they are what lets you answer a regulator or a field-safety question months later. An OTA workflow that installs cleanly but keeps no defensible record will still stall at assessment. This is the same evidence discipline that a broader SUMS documentation set has to satisfy.

Where R155 meets R156 in the same channel

The OTA channel is one surface viewed through two regulations. Under R156 it is a software-update path that must preserve integrity and configuration. Under R155 it is an attack surface — a way in that Annex 5 explicitly contemplates — and so it must also be monitored and defended after approval. Designing the signing, delivery and verification once, to satisfy both, is far cheaper than retrofitting one onto the other.

The AutoSifu view

We build OTA workflows as compliance and engineering together: the R156 and AIS-190 mapping, the signing, delivery and RxSWIN solutioning that makes the workflow real, and the CoC and VTA evidence that gets it assessed. With CIRT working alongside us, the approval body sees the update architecture while it is still being shaped, so the record set the assessor eventually opens is the one that was designed in from the start.