AIS-189 and AIS-190 in India: CSMS, SUMS and Homologation Readiness Guide

Introduction

Modern vehicles rely on electronic control units (ECUs), connected services, vehicle networks and software-driven functions. These technologies improve safety and functionality but also create cybersecurity risks and challenges when software is updated.

In India, AIS-189 addresses vehicle cybersecurity and the Cyber Security Management System (CSMS), while AIS-190 addresses software updates and the Software Update Management System (SUMS). Both are important for automotive manufacturers preparing for cybersecurity governance, software-update controls and homologation requirements.

This guide explains their purpose, vehicle applicability, compliance processes, and what OEMs and Tier-1 suppliers should prepare.

1. What are AIS-189 and AIS-190?

AIS-189: Cybersecurity and CSMS

AIS-189 establishes a risk-based approach to identifying, assessing and managing cybersecurity threats affecting vehicles and their electronic systems. It aligns with the principles of UN Regulation No. 155 (UN R155).

A CSMS is not simply a cybersecurity test or a security product. It is an organisational framework covering responsibilities, processes, risk management, development, production, monitoring and post-production activities.

Key activities include:

• Defining the vehicle’s electronic architecture and external interfaces.

• Conducting Threat Analysis and Risk Assessment (TARA).

• Identifying threats, vulnerabilities and attack paths.

• Implementing and validating cybersecurity mitigations.

• Managing supplier risks and cybersecurity-related changes.

• Monitoring vehicles for emerging threats after production.
  

AIS-190: Software Updates and SUMS

AIS-190 focuses on how vehicle software updates are developed, authorised, validated, delivered and recorded. It is informed by UN Regulation No. 156 (UN R156).

A SUMS ensures that software updates are controlled and traceable, whether updates are delivered over the air (OTA) or through a workshop or service process.

Core activities include software-version identification, update compatibility checks, secure delivery, validation, update records, failure handling and protection against unauthorised changes.

The difference: AIS-189 manages cybersecurity risks across the vehicle lifecycle; AIS-190 manages the integrity, traceability and controlled execution of software updates. The two processes must work together.

2. Which vehicle categories may require AIS-189 and AIS-190 in India?

The scope of a standard and the dates on which its requirements become mandatory under Indian vehicle regulations are separate questions.

MoRTH’s draft notification G.S.R. 503(E), dated 17 June 2026, proposed introducing Rules 125-T and 125-U into the Central Motor Vehicles Rules, 1989.

Standard	Categories identified in the draft
AIS-189 / CSMS	M, N, T when fitted with at least one ECU, and L7 vehicles with Level 3 or higher automated-driving functionality
AIS-190 / SUMS	M, N, T, A and C

Vehicle-category definitions and the final applicable scope must be checked against the relevant standards and final notifications. In particular, manufacturers should verify how the applicable category and vehicle configuration are defined rather than relying on informal descriptions.

What about two-wheelers and three-wheelers? 

The AIS-189 scope reviewed identifies M, N, T and specified L7 vehicles; it does not establish a blanket AIS-189 requirement for every L-category vehicle. The draft’s proposed AIS-190 category list is different. Do not assume all two-wheelers, e-rickshaws or three-wheelers are automatically included or permanently exempt confirm the current official requirements for the specific vehicle.

Proposed implementation timeline

The June 2026 draft proposed a phased approach, including:

• 1 October 2026: New models with Level 3 and above automation.

• 1 April 2027: Existing models with Level 3 and above automation.

• 1 April 2028: New models with OTA-capable ECUs, excluding infotainment systems and tracking devices.

• 1 October 2028: Existing models in the corresponding OTA-enabled phase.

• 1 October 2029: Further software-update and OTA categories, as set out in the draft table.
  

3. How does AIS-189 CSMS compliance work?

OEMs should treat CSMS as a lifecycle process rather than a one-time approval activity.

Step 1 — Define the vehicle scope: Document the vehicle type, ECU architecture, communication interfaces, connected services, backend systems and external dependencies.

Step 2 — Conduct TARA: Identify assets, potential threat scenarios, vulnerabilities, attack paths and associated risks. Assess the risks and document the treatment decisions.

Step 3 — Implement mitigations: Depending on the risk, controls may include secure boot, access control, secure diagnostics, cryptographic protection, network segmentation, authenticated communication and secure key management.

Step 4 — Verify and validate: Perform relevant cybersecurity testing, vulnerability assessment, penetration testing and validation of the implemented controls. Retain evidence linking risks to mitigations and test results.

Step 5 — Manage suppliers: Obtain relevant cybersecurity requirements, architecture information, risk assessments, component evidence, vulnerability-handling processes and change notifications from Tier-1 and other suppliers.

Step 6 — Monitor after production: Establish vulnerability intake, incident response, risk reassessment, mitigation planning and reporting processes for the operational fleet.

The manufacturer should also maintain the required organisational CSMS evidence and vehicle-type documentation. Organisational CSMS certification and vehicle type approval are distinct activities; one should not be represented as automatically replacing the other.

4. How does AIS-190 SUMS compliance work?

A controlled software-update process should cover the complete update lifecycle:

1. Identify: Record the software version, target ECU or vehicle, dependencies and intended update.

2. Authorise: Confirm the update’s origin, approval and compatibility with the vehicle configuration.

3. Protect: Apply appropriate security controls, such as code signing, authentication, encryption and secure access.

4. Validate: Test functionality, compatibility, safety implications and relevant cybersecurity risks before release.

5. Deploy: Deliver the update through the approved OTA or workshop process, with safeguards against interruption and unauthorised installation.

6. Verify and record: Confirm installation status, retain version and update records, and manage failures, recovery or rollback where supported and appropriate.
   

OEMs should maintain software identification, release approvals, validation evidence, update histories, supplier dependencies and procedures for unsuccessful updates.

This is a practical preparation workflow informed by SUMS principles. Confirm the exact obligations and evidence against the complete applicable AIS-190 text and current regulatory requirements.

5. What should OEMs prepare for homologation?

OEMs should establish a documented readiness programme before submitting a vehicle for approval.

• Regulatory scope: Confirm vehicle category, model status, applicable standard and current implementation requirements.

• Gap assessment: Compare existing engineering, cybersecurity and software-update processes with the applicable AIS requirements.

• Governance: Assign accountable owners across engineering, cybersecurity, software, quality, after-sales and supplier management.

• Technical evidence: Maintain architecture documents, TARA, risk treatment records, test reports, software inventories and update procedures as applicable.

• Supplier evidence: Collect component-level security information, vulnerability processes, interface details and change-management records.

• Lifecycle controls: Demonstrate processes for production, post-production monitoring, incident handling and software updates.

• Approval coordination: Engage the relevant Rule 126 testing agency and confirm its current documentation and testing expectations.
  

Keep evidence traceable from identified risks and requirements to implemented controls, validation results and approval documents.

6. What should Tier-1 suppliers do?

Tier-1 suppliers contribute directly to OEM readiness. They should:

• Map cybersecurity requirements to ECUs, software, interfaces and supplied components.

• Share relevant architecture, interface and component documentation under agreed confidentiality arrangements.

• Support TARA and provide risk assessments and mitigation evidence for supplied systems.

• Validate security controls and retain test results.

• Maintain vulnerability disclosure, incident response and patch-management processes.

• Control software versions, signed releases, dependencies and update-related changes.

• Notify OEMs of material vulnerabilities, product changes and security impacts through agreed processes.
  

OEMs remain responsible for demonstrating compliance for their vehicle type. Supplier evidence supports this process but does not automatically transfer the OEM’s regulatory responsibility.

7. How can automotive technology partners help?

Specialist automotive cybersecurity partners can support gap assessments, TARA, cybersecurity engineering, penetration testing, validation, supplier coordination and documentation readiness.

Ettiksoft Technologies’ relevant offerings include Cyphera for cybersecurity risk-analysis support, AutoPentrix for automotive penetration-testing capabilities, and E-SUMO for software-update management-related capabilities. The suitability of each solution depends on the vehicle architecture and project requirements; specific capabilities and compliance claims should be validated with the product team.

Tools can support the process, but they do not independently guarantee AIS compliance, CSMS certification or vehicle type approval.

8. Frequently asked questions

Is AIS-189 the same as UN R155? They are related in purpose and approach, but Indian compliance must be assessed against the applicable AIS and Indian regulations, not assumed from an international approval alone.

Is AIS-190 only for OTA updates? No. SUMS concerns-controlled software updates; the applicable standard and regulatory scope must be checked for the vehicle and update method.

Does passing a penetration test mean an OEM is AIS-189 compliant? No. Testing is only one part of a broader lifecycle CSMS and its supporting evidence.

Can a Tier-1 supplier obtain approval on behalf of an OEM?A supplier can provide essential technical evidence and support, but the OEM must meet its own applicable vehicle-level and organisational obligations.

Conclusion:

AIS-189 and AIS-190 readiness requires coordinated organisational processes, engineering controls, supplier collaboration, testing and lifecycle evidence. OEMs should begin by confirming their vehicle’s regulatory scope, assessing gaps, assigning responsibility and establishing traceable CSMS and SUMS processes.

Ettiksoft Technologies can discuss automotive cybersecurity engineering, risk assessment, validation and software-update management support relevant to your vehicle programme.