AIS 189 and AIS 190 Guide for Indian Automotive Cybersecurity and Software Updates.

India produced more than 28 million vehicles in FY 2024-25 — around 19 million two-wheelers, 4 million passenger vehicles, and just under a million commercial vehicles. It is the world's largest two-wheeler market and among the three largest vehicle markets globally by unit volume. Any regulatory gap in Indian automotive cybersecurity translates into a gap across tens of millions of newly-produced vehicles every year.

The architecture argument runs parallel. Indian-produced vehicles are increasingly software-defined. Passenger cars routinely include connected infotainment, OTA-capable clusters, and ADAS features that integrate multiple ECUs. Commercial vehicles include fleet telematics, AIS 140-mandated tracking, and increasingly electrified powertrains with battery management systems transmitting telemetry to cloud backends. Electric two-wheelers have complete connected-vehicle architectures — BMS telemetry, OTA firmware updates, mobile app integration, and in some cases remote diagnostics. The attack surface exists. The regulatory baseline did not.

The treaty argument is the third piece. India acceded to the 1998 UNECE Agreement, which allows contracting parties to develop their own technical regulations that align with UN Global Technical Regulations. India is not a party to the 1958 Agreement, under which UN Regulations (R155, R156, R157) carry automatic mutual recognition among member states. This meant India could not simply adopt R155 and R156 as effective domestic rules. A separate Indian instrument was required — hence AIS 189 and AIS 190.

MoRTH (Ministry of Road Transport and Highways) has been developing this framework through ARAI (Automotive Research Association of India) since the early 2020s. AIS 189 was drafted by ARAI's Automotive Industry Standards Committee and is dated April 2024 on the ARAI title page. AIS 190 followed shortly after. Enforcement notifications specify October 2027 for new vehicle type approvals, with full compliance for all vehicles projected by October 2028.

AIS 189 is the Indian equivalent of UN Regulation No. 155. Its title is Approval of Vehicles with Regards to Cyber Security and Cyber Security Management System. The document addresses two parallel obligations on vehicle manufacturers — approval of individual vehicle types for cybersecurity adequacy, and approval of the manufacturer's Cybersecurity Management System (CSMS) as the organisational mechanism that produces those cybersecure vehicles.

The AIS Standards Pathway

An AIS standard progresses through a defined path before it becomes enforceable:

1. Drafting by the Automotive Industry Standards Committee (AISC) under ARAI, with input from industry, testing agencies, and sometimes academic stakeholders
2. Approval by the Central Motor Vehicles Rules Technical Standing Committee (CMVR-TSC)
3. Gazette notification by MoRTH, which confers mandatory status
4. Implementation timeline specified in the notification, typically with a window for new type approvals followed by a broader window for all vehicles

AIS 189 has passed AISC drafting and is listed on ARAI's published AIS index. The MoRTH gazette notification confirms enforcement from October 2027 for new vehicle type approvals, with full compliance for all vehicles from October 2028.

Scope of AIS 189

AIS 189 applies to:

• Category M — passenger vehicles (M1 passenger cars, M2 and M3 buses), with at least one electronic control unit
• Category N — goods-carrying vehicles (N1 light commercial, N2 and N3 heavy commercial), with at least one electronic control unit
• Category T — agricultural tractors, with at least one electronic control unit
• Category L7 — heavy quadricycles, but only those with SAE Level-3-and-above automated driving functionality

Notably absent: general L-category coverage. Earlier drafts of AIS 189 included scope across the L-category two-wheeler and three-wheeler population. The final draft removed L1 through L5 and restricted L-category coverage to L7 with L3+ automation. This is a deliberate regulatory choice that we discuss in a dedicated section below.

Relationship to UNECE R155 and ISO/SAE 21434

AIS 189's CSMS architecture mirrors UNECE R155 closely. Both mandate:

• Cybersecurity governance at the organisational level
• Risk management (TARA) at the vehicle-type level
• Continuous monitoring of the vehicle population for cybersecurity threats
• Incident response with defined escalation paths
• A three-year CSMS certificate with annual surveillance
• Type-approval submission of cybersecurity evidence per vehicle type

The underlying TARA methodology expected in AIS 189 submissions is aligned with ISO/SAE 21434:2021. The threat baseline in AIS 189 Annex D parallels UNECE R155 Annex 5. In practical terms, an OEM operating a mature ISO/SAE 21434 CSMS can use the same evidence base to satisfy AIS 189 with modest adaptation. For the deeper ISO/SAE 21434 reference, see our ISO/SAE 21434 guide.

AIS 190 is the Indian equivalent of UN Regulation No. 156 and governs Software Update Management Systems (SUMS). Its scope applies to vehicle categories permitting software updates, including M, N, T, and the categories A (agricultural), C (construction), and equivalent vehicles where software updates affect type-approval-relevant behaviour.

AIS 190's core obligations:

• Software Update Management System certification. The manufacturer must operate a certified SUMS — processes that ensure software updates do not introduce unsafe or insecure behaviour.
• Software identification numbering.Each software version installed on a type-approved vehicle must carry a unique identifier, equivalent in function to UNECE R156's RxSWIN. India has defined its own identifier scheme rather than using the UN notation.
• OTA infrastructure expectations. Updates must be delivered through cryptographically signed channels, with rollback capability, integrity verification at install time, and audit logs retained for a defined period.
• Impact assessment. Before any software update that affects type-approval-relevant behaviour is deployed, the manufacturer must assess whether the update changes the type approval and re-submit if required.

AIS 190 is expected to follow a similar implementation timeline, subject to final official notification and interpretation. The two standards carry independent MoRTH notifications.

For OEMs and Tier-1 suppliers operating programmes across both European and Indian type-approval markets, understanding the alignment and divergence matters. Most of the CSMS architecture transfers directly. A few areas do not.

The single most consequential divergence is institutional. Under UNECE R155, the technical service (the body that performs technical testing) is institutionally separate from the type-approval authority (the body that grants approval). In Germany, KBA grants approval while independent technical services perform testing. In France, UTAC plays a testing role; approval sits with the French authority. The separation provides structural independence.

In India, ARAI and iCAT perform both functions — technical testing and approval — depending on vehicle category. ARAI handles passenger vehicles in western India. iCAT handles northern India, including most two-wheeler and three-wheeler type approvals. Both bodies are institutionally integrated with the approval function. This is a legitimate regulatory choice under the 1998 Agreement framework but it does change the dynamics — manufacturers work with a single counterparty through the cybersecurity approval process, simplifying some interactions while concentrating regulatory power in fewer institutions.

The second consequential difference is mutual recognition. A UNECE R155 certificate issued by KBA is recognised as prima facie valid in any 1958 Agreement contracting party. An AIS 189 certificate issued by ARAI confers Indian type approval only. Indian OEMs or Tier-1s that export to UNECE markets must obtain both an AIS 189 certificate and a UNECE R155 certificate for the same vehicle or component. In practice, a well-designed CSMS can support both — the evidence is the same, only the submission package differs — but two separate approval cycles are required. For the R155-side deep-dive, see our ISO/SAE 21434 vs UNECE R155 comparison.

India is the world's largest two-wheeler market by unit volume. More than 19 million two-wheelers were produced in FY 2024-25. Many of them are now connected vehicles — telematics in premium motorcycles, full connected architectures in electric scooters, mobile app integration across the electric two-wheeler segment. The cybersecurity attack surface exists at scale.

Yet AIS 189's final draft removed general L-category coverage. The scope language restricts L-category coverage to L7 quadricycles with SAE Level-3-plus automated driving. As of April 2026, no L-category two-wheeler in India meets this scope.

Three reasons are commonly cited for the exclusion. First, the fragmentation of the L-category supply chain — AIS 189 compliance requires a full CSMS, which is structurally heavier than what smaller two-wheeler OEMs operate today. Second, the absence of a clear homologation pathway for cybersecurity in two-wheelers under the 1998 Agreement framework — UNECE R155 itself does not currently include mandatory L-category coverage, though proposals for L-category extension have been discussed at UNECE WP.29 for effective dates from around 2029. Third, the regulatory authority's pragmatic view that forcing CSMS compliance on every connected electric scooter manufacturer would delay electric two-wheeler adoption.

The practical implication for two-wheeler OEMs: no AIS 189 obligation today. But two-wheeler OEMs that export electric scooters or motorcycles to UNECE markets increasingly face indirect pressure from OEM customers and enterprise fleet buyers. Connected electric two-wheelers exported to European cities often include BMS telemetry and OTA capabilities that raise cybersecurity expectations regardless of regulatory status. Many Indian two-wheeler OEMs are therefore voluntarily aligning to ISO/SAE 21434 as a contractual matter, anticipating that regulatory alignment will follow.

The AIS 189 obligation cascade is simpler than UNECE R155's but still layered.

Vehicle Manufacturers (OEMs)

Indian OEMs producing M, N, T, or L7-L3+ vehicles for the domestic market must:

• Operate a certified CSMS and hold a valid AIS 189 CSMS certificate (three-year validity, annual surveillance)
• Submit cybersecurity evidence per vehicle type at type-approval time
• File annual monitoring reports on the vehicle population
• Maintain incident response capability with defined escalation paths
• Complete the SUMS certification under AIS 190 if the vehicle permits software updates

The enforcement sequence: from October 2027, new vehicle types submitted for approval must include AIS 189 evidence. From October 2028, all in-production vehicle types must have obtained AIS 189 approval or face renewal denial.

Tier-1 Suppliers

AIS 189 does not directly regulate Tier-1 suppliers. The cascade happens through Cybersecurity Interface Agreements. Indian Tier-1s supplying components to OEMs subject to AIS 189 will increasingly receive CIA obligations from their OEM customers — TARA responsibilities, vulnerability response SLAs, monitoring data sharing, audit rights.

Indian Tier-1s supplying European OEMs are already in this situation under UNECE R155 cascades. The AIS 189 effect extends the cascade to domestic OEMs.

Tier-2 Suppliers and Below

The cascade continues. Tier-2 suppliers of safety-relevant ECUs, gateways, telematics units, HSMs, and connectivity modules will see contractual cybersecurity obligations flow down from Tier-1 customers.

Importers and Accredited Representatives

Importers of vehicles into India must demonstrate cybersecurity compliance of the imported vehicle type per AIS 189 from October 2027. Accredited representatives (for foreign manufacturers without an Indian entity) carry this obligation.

Cloud, Backend, and Telecom Providers

AIS 189 interpretation material explicitly recognises that modern vehicle cybersecurity depends on backend cloud infrastructure, mobility service backends, and telecom channels. These parties may not be regulated directly by AIS 189 but are expected to be covered through CIA-style agreements with the OEM.

Recall and Defect Linkage

CMVR Rule 127C recognises cybersecurity defects as recall triggers. An AIS 189-approved vehicle with a discovered cybersecurity vulnerability that could endanger users or the vehicle population may be subject to recall under Rule 127C. This links the cybersecurity regime to India's existing recall framework, which has been in active use for mechanical and software defects since 2019.

Indian OEMs and Tier-1 suppliers with October 2027 as the enforcement target have a defined window. The following sequence prioritises the deliverables that defend the CSMS certificate audit and the first vehicle-type submission.

Phase 1 — Gap assessment against ISO/SAE 21434 (Months 1–2)

Because AIS 189's CSMS architecture mirrors ISO/SAE 21434, a gap assessment against ISO/SAE 21434 is the fastest path to AIS 189 readiness. Focus on Clause 5 (organisational CSMS), Clause 6 (project management), Clause 7 (distributed activities — CIAs), and Clause 15 (TARA methodology).

Output: gap-closure plan, role assignments, training needs, tooling decisions.

Phase 2 — TARA capability build-out (Months 2–4)

Establish the TARA methodology that will be applied across all in-scope vehicle types. Decide on the attack feasibility rating model (expertise-opportunity-tools or CVSS-adapted), the risk matrix, and the risk treatment framework. Execute TARA on one representative vehicle type to validate the methodology before scaling.

Output: TARA method documentation, one vehicle-type TARA package covering all eight Clause 15 work products.

Phase 3 — PSIRT and monitoring workflow (Months 4–6)

Stand up the continual cybersecurity activities pipeline per ISO/SAE 21434 Clause 8 — information source feeds, trigger rules, event handling, vulnerability analysis, and managed vulnerability evidence. Exercise the pipeline with real CVEs.

Output: functional PSIRT, documented workflow, first quarterly cybersecurity report template.

Phase 4 — Supply-chain Cybersecurity Interface Agreements (Months 4–8, parallel)

Draft CIA templates covering TARA responsibilities, vulnerability handling, incident response SLAs, monitoring data sharing, and audit rights. Negotiate and execute with the top three to five Tier-1 suppliers for each vehicle programme. Cascade to Tier-2 where applicable.

Output: executed CIAs with major suppliers, Tier-2 cascade plan.

Phase 5 — ARAI engagement and submission formats (Months 6–12)

Engage with ARAI or iCAT (as applicable) on submission format expectations. AIS 189 submissions require evidence packages in specific structures — the exact formats are refined through direct engagement with the approval authority. Pilot a submission for one vehicle type.

Output: ARAI-compatible submission package for first vehicle type.

Phase 6 — AIS 190 SUMS readiness (Months 8–15)

For vehicles permitting software updates, stand up the SUMS. Requirements include software bill of materials generation, update signing infrastructure, rollback capability, identifier scheme registration, and audit log retention.

Output: SUMS certification package, first OTA-capable type approved under combined AIS 189 + AIS 190.

Phase 7 — Internal audit and external CSMS certification (Months 12–18)

Conduct internal audit against AIS 189 requirements, close findings, then proceed to CSMS certification with ARAI. First vehicle type submissions follow certification.

Output: three-year AIS 189 CSMS certificate, first type-approved vehicle under AIS 189.

Training and certification pathways along the way: India does not currently operate a dedicated AIS 189 practitioner certification scheme. The most common training paths used by Indian automotive cybersecurity teams are SGS and Bureau Veritas ISO/SAE 21434 practitioner certifications, plus vendor-specific courses from testing agencies. Our Agnile engineers hold relevant engineer certifications and train customer teams during engagements.

India's automotive ecosystem is geographically clustered, and AIS 189 will land unevenly across the clusters.

Bengaluruis India's automotive cybersecurity hub. The city hosts the largest R&D centres outside Germany for multiple global automotive companies, an active electric two-wheeler cluster, and a growing concentration of automotive software and cybersecurity startups. Bengaluru-based teams typically operate at the leading edge of CSMS maturity because many of them already serve European OEMs under UNECE R155 obligations. AIS 189 enforcement will catch these teams already prepared.

Pune is home to ARAI itself, along with major passenger vehicle and two-wheeler OEM headquarters. Pune is the centre of domestic type-approval engagement and will be the first-contact city for most AIS 189 certificate applications.

Chennai hosts large-scale passenger vehicle and commercial vehicle manufacturing operations, two-wheeler production, and a growing automotive software services sector. Chennai-based Tier-1 suppliers exporting to European and North American markets are in a similar posture to Bengaluru — UNECE R155 exposure creates AIS 189 readiness.

Delhi–Gurugram–Manesar–Bhiwadi(the NCR automotive belt) hosts the country's largest passenger vehicle manufacturer, major two-wheeler OEMs, and iCAT (which handles northern India type approvals including most two-wheeler and three-wheeler categories). This cluster will feel the two-wheeler question most acutely — electric two-wheeler OEMs in NCR watching the AIS 189 scope exclusion while still needing to satisfy European market obligations.

The clustering matters for implementation. A Bengaluru-based Tier-1 already running an ISO/SAE 21434 CSMS for European OEM customers can add AIS 189 readiness in one quarter. A regional two-wheeler OEM with no existing CSMS faces an 18-month build-out.

AIS 189 does not exist in isolation. Several other AIS standards and Indian regulations intersect with cybersecurity obligations.

AIS 140— vehicle location tracking and panic button requirements for commercial vehicles. Mandatory since 2018, this was India's first AIS with cybersecurity-adjacent obligations (tamper-resistant GPS modules, secure data transmission to backend servers). Existing AIS 140 compliance gives commercial vehicle OEMs a baseline that helps AIS 189 readiness.

AIS 156 and AIS 038 Rev 2 — battery safety standards for electric vehicles, including battery management system data logging. The BMS data captured under AIS 156 creates a cybersecurity-relevant data flow that must be covered in the AIS 189 TARA.

BNCAP (Bharat NCAP) and AIS 197— Bharat NCAP, India's crash-safety rating programme launched in 2023, currently evaluates crashworthiness, vulnerable road user protection, accident avoidance, safe driving assistance, and post-crash safety. Cybersecurity is not currently a BNCAP evaluation pillar. This is worth knowing because customer-facing cybersecurity ratings do not yet affect Indian vehicle purchasing decisions; all pressure comes from type-approval and export obligations.

AIS 184 through AIS 188 — ADAS-related standards notified under GSR 184(E) dated 20 March 2025. These cover lane departure warning, emergency braking, and related advanced driver assistance systems. ADAS systems increasingly rely on cybersecurity-sensitive data pipelines (cameras, radars, V2X), making the ADAS AIS standards and AIS 189 jointly relevant for modern passenger vehicle programmes.

Digital Personal Data Protection Act, 2023 — India's privacy law, operational in phased rollout through 2025 and 2026, affects connected-vehicle personal data handling. AIS 189 interpretation material explicitly references privacy obligations parallel to the DPDP Act, particularly for telematics data, location data, and in-vehicle biometric systems.

If you are an OEM or Tier-1 supplier planning for AIS 189 enforcement, the actions that matter most in the next 90 days:

1. Gap assessment against ISO/SAE 21434. If you do not have a current CSMS, start here. The closer your CSMS is to ISO/SAE 21434 maturity, the smaller the delta to AIS 189.
2. Draft the TARA methodology. Decide the attack feasibility model, the risk matrix, and the risk treatment framework. Do this before TARA is needed at scale.
3. Start the CIA cascade. Supplier cybersecurity interface agreements take months to negotiate. Start with your top three Tier-1 suppliers immediately.
4. Assign a project cybersecurity manager. Someone owns AIS 189 readiness in the organisation. Clause 5 of ISO/SAE 21434 and the equivalent in AIS 189 require this.
5. Engage ARAI or iCAT early. Submission format expectations are refined through direct engagement. The first OEMs to submit AIS 189 evidence will shape how ARAI reviews subsequent submissions.