Introduction 

AIS 189 Compliance Is Coming. Your Automotive Software Team Has 18 Months to Build a System That Doesn’t Exist Yet.

India’s Automotive Industry Standards Committee published AIS 189 and AIS 190, the country’s cybersecurity and software update management standards for road vehicles, and by 2026-2027 they enter vehicle type approval scope. For a Tier-2 electronics supplier building telematics units, infotainment controllers, or ADAS ECUs, this is not a distant regulatory event. It is an engineering constraint already affecting procurement decisions from OEM partners who are themselves under compliance pressure. As of April 2026, no L-category two-wheeler in India meets the AIS 189 scope. Four-wheelers are not far ahead. The window to build a compliant Cybersecurity Management System is narrow, and it is closing.

What AIS 189 Actually Requires (and What Most Teams Think It Requires)

AIS 189 maps to UNECE R155 and ISO/SAE 21434. AIS 190 maps to UNECE R156 for software update management systems. Both are drafted by ARAI under the Ministry of Road Transport and Highways.

Most engineering teams read these standards and arrive at the same conclusion: they need better penetration testing. This is the wrong conclusion. The standards require a Cybersecurity Management System (CSMS), a documented, auditable process that covers:

Risk assessment across the full vehicle lifecycle, not just at design time

Supplier cybersecurity controls and their documentation

Incident monitoring and response procedures

Processes for issuing, verifying, and rolling back OTA updates securely

A penetration test produces a list of vulnerabilities. A CSMS produces evidence that your organization has a repeatable process for finding and managing vulnerabilities before, during, and after production. These are not the same deliverable.

AIS 189 is not a certification you acquire. It is an engineering process you must operate continuously.

The gap most suppliers have is not in their firmware. It is in their process documentation and their supplier chain controls.

The OTA Security Problem Is Harder Than the Update Problem

AIS 190 specifically governs Software Update Management Systems (SUMS). The engineering challenge here is distinct from the CSMS work under AIS 189.

A secure OTA update system for connected vehicles requires the following:

Code signing infrastructure: Every firmware package must be signed by the developer and verified by the receiving ECU before installation. This requires a Hardware Security Module (HSM) in both the signing pipeline and the vehicle endpoint.

Rollback protection: An ECU that accepted a compromised update and rolled back to a previous version is still a security incident. The SUMS must log the rollback and trigger an investigation workflow.

Campaign management with integrity checks: The update delivery pipeline must verify package integrity at every step, from the update server to the CDN to the vehicle’s telematics unit.

Multi-domain coordination: Modern vehicles carry 80 to 150 ECUs across multiple domains, sometimes from different Tier-1 suppliers. An OTA update to one domain can create compatibility issues in another if the SUMS does not manage dependencies explicitly.

Qualcomm and Google expanded their Android OTA partnership in January 2026 specifically to address multi-domain software complexity in production vehicles. The problem they are solving is the same one Indian suppliers are facing: OTA update systems designed for one ECU at a time cannot handle the software-defined vehicle architecture.

The global automotive OTA compliance market sits at USD 5.41 billion in 2026. By 2036, that number is projected at USD 18 billion. The compliance investment is not discretionary for OEMs selling into markets where type approval depends on it.

Where Indian Suppliers Are Getting Stuck

We worked with a Tier-2 automotive electronics supplier in Pune that produces telematics control units for three Indian OEMs. They had strong engineering on the firmware side, a mature CI/CD pipeline, and a reasonably secure TLS implementation on their update channel.

Their gap was not in the code. It was in the process.

They had no documented Threat Analysis and Risk Assessment (TARA) for their product portfolio. They had no supplier questionnaire for the component vendors who provided modules to them. They had no incident response playbook for a compromised update campaign. Their CSMS existed in the heads of three engineers who had each worked on ISO 21434 projects at previous employers.

When their OEM partner’s audit team asked for compliance documentation, there was nothing to hand over. The OEM did not cancel the relationship, but they required the supplier to produce a compliant CSMS within six months or face de-listing from their preferred supplier list.

Six months is not enough time to build a CSMS from scratch. It is barely enough time to document one.

The Vehicle Cybersecurity Compliance Ladder (VCCL)

Based on our work with automotive electronics teams, we use a five-rung model to assess readiness and sequence remediation:

Rung 1: Asset Inventory and TARA

List every software component, interface, and communication channel in your product portfolio. Complete a Threat Analysis and Risk Assessment per ISO/SAE 21434 Section 15. Output is a TARA document per product line, reviewed and signed off by engineering leadership.

Rung 2: CSMS Process Documentation

Document your cybersecurity policies, roles, incident response procedures, and supplier assessment process. This is the organizational layer that auditors look for first. Without it, Rungs 3 through 5 have no formal context.

Rung 3: Secure Development Lifecycle Integration

Embed security requirements into design reviews, integrate SAST and DAST into your CI pipeline, and define acceptance criteria for security test reports before milestone gates. Security testing becomes a release gate, not an audit activity.

Rung 4: OTA Security Infrastructure

Stand up your HSM-backed code signing pipeline, define your SUMS architecture per AIS 190, and build campaign management with rollback protection and integrity verification at every delivery stage.

Rung 5: Continuous Monitoring and Incident Management

Establish vulnerability monitoring for your product families, build the incident response runbook, and define your PSIRT (Product Security Incident Response Team) process. Post-production monitoring is a permanent CSMS obligation, not a project phase.

Most suppliers we assess are between Rung 1 and Rung 2. Rung 5 is required for full AIS 189 compliance. The gap is structural, not technical.

What Zero Trust Actually Means for OTA

Zero trust in an OTA context is often misunderstood as “always verify the update server.” That is table stakes. The zero trust model for OTA means the vehicle ECU does not implicitly trust any update, regardless of where it originates, unless it can independently verify the cryptographic signature against a root of trust stored in hardware.

This has three specific engineering implications:

The root of trust is in silicon. An HSM or Trusted Execution Environment (TEE) in the ECU holds the public key used to verify signatures. This key cannot be extracted or overwritten by software. The verification chain is end-to-end. Signature verification happens at the ECU, not at the gateway or the telematics unit. An intermediary device cannot re-sign on behalf of the ECU. Failed verifications trigger defined behavior. A rejected update does not leave the ECU in an undefined state. Your SUMS must specify the fallback behavior, and it must be tested against adversarial scenarios, not just network failure scenarios.

> Zero trust for OTA does not mean you distrust your update server. It means your vehicle ECU cannot trust it either.

The SAE technical paper 2026-26-0621, published in Q1 2026, provides implementation guidance for this architecture in multi-domain vehicle environments. It is worth reviewing before your next hardware design review, particularly the sections on ECU-level verification in Automotive Software Stores.

What this means for Automotive and Ride-Hailing Mobility leaders

If you are a CTO or VP Engineering at an Indian OEM or Tier-1/2 supplier, AIS 189 compliance is now a procurement filter, not a future concern. Your OEM partners are themselves under compliance pressure and will pass it down the supply chain through supplier audits and preferred supplier list criteria.

The concrete steps you can take this week: pull your current product list and identify which ones have a TARA document. For those that do not, assign an owner and a four-week timeline to produce one. Separately, identify who in your organization owns incident response for a potential OTA security event. If the answer is no one specifically, that is the highest-priority gap in your CSMS.

You do not need to complete the VCCL in six months. You need to be able to demonstrate to an auditor that you are actively climbing it, with evidence at each rung.

More Blog: Your Shopify Store Cannot Serve an ONDC Buyer App. Here Is What Can.