UN R156 for non-OTA vehicles: what still applies

The misreading that costs programmes

The most expensive assumption a team can make about UN R156 is that it only applies if the vehicle updates itself over the air. It does not. R156 requires a Software Update Management System whenever a vehicle type can be updated at all — and almost every modern vehicle can, at minimum, be reflashed at a dealer or workshop through a diagnostic tool. OTA is a delivery mechanism. The SUMS obligation attaches to the fact that software can change after type approval, not to how that change is delivered.

A manufacturer that reasons "we do not do OTA, so R156 does not touch us" and then ships vehicles whose ECUs are updated in service has misjudged its scope. The part of R156 that always applies is the part about keeping software identity traceable and update integrity protected, and that is precisely the part such a manufacturer has skipped.

What is the same, regardless of channel

It is worth being precise about what carries over and what changes. The core obligations are channel-independent. Only the delivery mechanism and its specific controls differ.

Obligation	OTA vehicle	Non-OTA (workshop) vehicle
SUMS required	Yes	Yes
RxSWIN management	Yes	Yes
Integrity of the update	Yes	Yes
Records of updates	Yes	Yes
Type-approval extension on regulated change	Yes	Yes
Delivery channel	Wireless backend to vehicle	Diagnostic tool at workshop
Channel-specific controls	Authenticated OTA channel, on-vehicle pre-checks	Controlled tool access, authorised technician

Read down the left column: the substance of R156 — the SUMS, RxSWIN, integrity, records, approval-extension logic — is identical. The channel row is the only place the two genuinely diverge. This is why a non-OTA programme cannot treat R156 as optional; it inherits almost all of the obligation.

RxSWIN does not depend on OTA

The point that most surprises non-OTA teams is that RxSWIN applies in full. The RxSWIN identifies the regulation-relevant software of a type and must change when that software changes. A workshop reflash that alters a regulated function is, from the regulation's point of view, exactly the same event as an over-the-air update that does the same thing: the RxSWIN changes, the change is assessed for its effect on type-approval-relevant functions, and a type-approval extension may be required before the update is rolled out to vehicles in service. The delivery being manual does not exempt it. We cover the mechanics in generating and managing RxSWIN for R156; the discipline is identical whether the update travels over the air or down a diagnostic cable.

Integrity in a workshop context

Integrity is often where non-OTA teams assume they are safe — the technician is trusted, the tool is trusted, so what is there to protect? Quite a lot. The update package still has to be authentic and unaltered from what was built and signed, because the workshop tool and its supply chain are themselves an attack surface. A compromised diagnostic tool, an altered package on a technician's laptop, or an unauthorised image loaded through legitimate access all defeat the assumption of a trusted channel. The integrity controls — signed packages, verification before installation — apply for the same reason they apply to OTA: the endpoint cannot assume the path was clean.

Records still have to exist

R156's record-keeping obligation is entirely channel-independent. For a non-OTA vehicle the SUMS must still be able to show what was updated, on which vehicle, when, and with what outcome. In practice this is sometimes harder for workshop updates than for OTA, because the events happen across a dealer network rather than through a single backend, and the records have to be collected back to the manufacturer. A programme that reflashes ECUs at dealers but cannot reconstruct which vehicles received which software has a records gap that will surface at assessment. The full set is covered in SUMS documentation.

India: the same logic under AIS-190

For Indian OEMs the picture is identical under AIS-190, India's SUMS standard, which is aligned to R156 and centres the same SUMS and RxSWIN mechanics. A non-OTA vehicle sold in India is no more exempt from AIS-190 than it is from R156. The enforcement dates for AIS-189 and AIS-190 in India are proposed in MoRTH draft G.S.R. 503(E) (phased from October 2026) but not yet finalised, so the prudent position is to build the capability rather than wait on the final date — and that capability is the same for non-OTA as for OTA programmes. We compare the two regimes in AIS-190 vs UN R156.

There is also a planning advantage in treating a non-OTA programme as fully in scope from the start. A manufacturer that builds the SUMS, RxSWIN discipline and integrity controls for its workshop-update process is most of the way to supporting over-the-air updates should it add them later, because the substance of the obligation is already met and only the delivery channel and its controls remain to be built. The reverse — assuming exemption, then discovering the obligation at assessment or when OTA is added — forces the same work under time pressure and with a certificate waiting behind it. Building for the full obligation early is the cheaper path even for a manufacturer with no immediate plans to go over the air.

The AutoSifu view

Non-OTA programmes are where we most often find scope drawn too narrowly, and it is a costly place to be wrong. We map the full R156 and AIS-190 obligation for workshop-updatable vehicles, build the SUMS, RxSWIN and integrity controls that a manual channel still needs, and prepare the CoC and VTA evidence on one route. With CIRT in the room, the approval body confirms the scope early, so a non-OTA manufacturer is not surprised at assessment by an obligation it assumed did not apply.