AIS-190 explained: India's software update standard

What AIS-190 is

AIS-190 is India's software update standard for road vehicles. It defines the requirements for a Software Update Management System (SUMS) and is aligned to UN Regulation No. 156 (Software Update). Like its cybersecurity counterpart, it was published by ARAI for the Automotive Industry Standards Committee under the CMVR Technical Standing Committee.

A vehicle is now a computer that ships and then keeps changing. Once software can be updated after the vehicle leaves the plant, a new question opens: how do you know the software running in a given vehicle is the software that was approved, and that every update since was legitimate, intact and recorded? AIS-190 exists to answer that question with a managed process rather than trust.

The SUMS: a process, not a portal

It is easy to read "software update management system" as the OTA platform. It is not. The SUMS is the organisational and technical process that surrounds every update, of which an OTA delivery system is only one part. AIS-190 expects an OEM to govern:

• What is being changed — the configuration of software on each vehicle type, and which of it is relevant to type approval.
• Whether the change is safe to apply — pre-conditions, dependencies between components, and the vehicle state required before an update proceeds.
• Integrity and authenticity — that the update package is the one the OEM built and has not been tampered with in transit.
• What happens on failure — a defined safe state and recovery path if an update does not complete.
• Records — evidence that each update was prepared, authorised, delivered and completed as intended.

The engineering beneath this is described in ISO 24089:2023, Road vehicles — Software update engineering, which stands to AIS-190 much as ISO/SAE 21434 stands to the CSMS standards.

RxSWIN: the thread that ties software to the approval

The concept that makes the whole regime work is RxSWIN — the Regulation X Software Identification Number. It identifies the regulation-relevant software of a vehicle type, is declared in the type approval, and must change when that software changes. RxSWIN is what lets an authority ask, years after launch, "is this vehicle running an approved configuration?" and get a defensible answer.

For AIS-190 this means an OEM needs the configuration-management discipline to know exactly which software is regulation-relevant, to version it, and to update the RxSWIN — and the approval — when it moves. Get RxSWIN wrong and the update record no longer maps to the approval.

OTA and non-OTA: the same obligation, a different channel

A common misreading is that AIS-190 is an OTA regulation. It is not. The SUMS applies regardless of how the update reaches the vehicle.

Aspect	OTA update	Workshop (non-OTA) update
SUMS required	Yes	Yes
RxSWIN maintained	Yes	Yes
Integrity of package	Yes	Yes
Update records	Yes	Yes
Additional focus	Authenticated delivery, safe-state over the air, rollback	Technician tooling, controlled flashing, station security

Whether a fix is pushed to a million vehicles overnight or applied one car at a time at a service centre, the process has to be managed, the RxSWIN kept correct, and the outcome recorded. We unpack the workshop-only case further in UN R156 explained, and the India-versus-UNECE detail in AIS-190 vs UN R156.

Where AIS-190 meets AIS-189

Software updates are how a CSMS closes the loop. Post-production monitoring under a CSMS finds a vulnerability; the SUMS is the mechanism that ships the fix and proves it landed. That is why AIS-190 and AIS-189 are best treated as one programme with two certificates, not two projects. The monitoring, vulnerability management and update pipeline share the same records and the same owners.

On enforcement dates

As with the cybersecurity standard, AIS-190's enforcement now sits in a draft rather than a final notification. MoRTH draft G.S.R. 503(E) (17 June 2026) carries AIS-190 through Rule 125-U, applying to vehicle categories M, N, T, A and C, with a phased timeline that reaches OTA-capable vehicles across 2028 and all other software-update-capable vehicles by 1 October 2029. Because it is open for public comment and not yet finalised in the gazette, treat those dates as the planning baseline, not a fixed deadline. The practical consequence is unchanged: a working SUMS — configuration management, RxSWIN discipline, integrity controls, records — takes real time to stand up, so the readiness work is worth starting independently of the exact calendar. The full schedule is in India's automotive cybersecurity timeline.

What good looks like at assessment

An assessor for AIS-190 will want to see the SUMS operating, not merely documented. In practice that means:

• A configuration baseline per vehicle type, with regulation-relevant software identified and tied to an RxSWIN.
• A documented update-preparation and authorisation process, with roles.
• Integrity controls — signing and verification — that can be demonstrated end to end.
• A defined failure/rollback behaviour and evidence it has been tested.
• Records of real updates that show the process was followed.

The recurring failure is the same one that catches CSMS assessments: the process is written but not evidenced. A dry-run before the assessment is the cheapest insurance against it.

The AutoSifu view

AutoSifu delivers AIS-190 as part of one route — compliance, secure solutioning, and CoC/VTA support — rather than handing an OEM a SUMS template and leaving. With CIRT as a strategic partner, and having co-built India's first SUMS workshop at CIRT Pune, we help teams take a software-update process from concept to an assessable state with the approval body in the room. The goal is a SUMS that would satisfy an assessor whenever the notification arrives.