Engineering · Automotive Cybersecurity · India
Automotive Penetration Testing in India
ECU and vehicle penetration testing for Indian OEMs and Tier-1 suppliers: ECUs, telematics, EV and two-wheeler platforms attacked on the bench in Bengaluru or at your own facility, then written up as the verification evidence ARAI, iCAT and your global OEM customers expect — mapped to AIS 189, UNECE R155 Annex 5 and ISO/SAE 21434 in one report.
Reviewed by Shreyansh, Founder & CTO, Agnile Technologies •
What is automotive penetration testing in India?
Automotive penetration testing in India is authorised, hands-on security testing of a vehicle’s ECUs, in-vehicle networks, telematics, EV battery and charging interfaces and backend, to prove which attacks actually work. Agnile Technologies runs it from its Bengaluru lab or on-site at OEM and Tier-1 benches, and writes the findings as verification evidence for AIS 189 assessment at ARAI or iCAT and for the UNECE R155 and ISO/SAE 21434 evidence global OEMs require from Indian suppliers.
Context
Why Indian Programmes Are Testing Now
Three pressures arrive at the same time for an Indian OEM or Tier-1, and each ends in the same question from an assessor: show us the testing.
Domestic approval under AIS 189
India’s automotive cybersecurity standard is built deliberately on the UNECE R155 pattern: an organisational Cybersecurity Management System, a threat and risk assessment per vehicle type, and verification that the mitigations hold. The test agency reviewing the submission wants evidence that the measures were attacked and survived, not a statement that they were designed. AIS 190, the companion standard, governs software updates, so update-path security is tested under it.
Status (reviewed 14 October 2026): applicability and enforcement dates for AIS 189 and AIS 190 are set by MoRTH notification and were still evolving at the time of review. Our AIS 189 and AIS 190 guide tracks the current position, scope and the two-wheeler question.
The export cascade from global OEMs
UNECE R155 has applied to every new car, van, truck and bus registered in the EU since 7 July 2024, and it regulates the OEM — who cannot pass an assessment without supplier-side evidence. Indian Tier-1s and captive engineering centres inherit penetration-testing obligations through the Cybersecurity Interface Agreement, whether or not the component ever sees an Indian road. A report written only for a domestic reviewer fails that second audience; ours is written for both.
EV, connected and two-wheeler growth
Battery management systems, on-board chargers, charging communication, AIS 140 tracking devices and app-connected two-wheeler clusters have put a remote attack surface on vehicle classes that never had one. With the EU applying R155 to L-category vehicles from December 2027, two-wheeler exporters are scoping their first assessments on the same timeline as their next platform.
Scope
ECU, Telematics and EV Security Testing Scope in India
The full method — reconnaissance, hardware and protocol analysis, exploitation, reporting — is on our automotive penetration testing services page, as are the three levels we test at — component, ECU and vehicle. These are the targets where Indian programmes carry the most risk today.
ECU penetration testing — gateways and domain controllers
Debug ports, firmware extraction, UDS seed-key handling, CAN and Automotive Ethernet injection, and Secure Boot — scoped from the AIS 189 risk assessment or your OEM’s threat list, so the evidence lands against the attack paths the reviewer will ask about.
Telematics control units and AIS 140 devices
Cellular, GNSS and backend interfaces on telematics units and on the vehicle tracking devices mandated for commercial and public-transport fleets. We test provisioning, the session to the backend, firmware update paths and the trust relationship back into the vehicle network — the path by which one device flaw becomes a fleet-wide one.
EV battery management and charging interfaces
Battery management system diagnostics and calibration access, on-board charger control, ISO 15118 and CCS2 charging communication on the vehicle side, and OCPP on the charger side. Findings here carry thermal and electrical safety consequence and are rated for it, not filed as data-loss issues.
Two-wheeler clusters, digital keys and theft scenarios
BLE pairing and app-based keys, keyless and relay attacks on premium two-wheelers, cluster firmware and update paths. These platforms were designed for cost and speed; we test them against the theft scenarios Indian fleets already see and the threat model their export markets will apply.
Infotainment, companion apps and backend
Android-based infotainment heads, their USB, Bluetooth and Wi-Fi surfaces and the bridge to the vehicle network; the companion mobile app; and the cloud API behind it — the usual route from a consumer-grade component to a vehicle-grade consequence.
Process
How an Automotive Penetration Test Runs — Five Steps
The same five-step procedure runs on every engagement, wherever the bench is. It follows ISO/SAE 21434 verification and validation (Clauses 10 and 11) and produces the testing evidence UNECE R155 paragraph 7.3.6 and AIS 189 expect. Durations are typical for a single-ECU, grey-box scope; vehicle-level scopes extend step 3. Regional logistics — shipping, on-site work, contracting — are in the practicalities table below.
Scoping and NDA Week 1
Targets, interfaces and the assessment milestone the evidence is for. Access model agreed — black-, grey- or white-box. Mutual NDA on your template or ours.
Rules of engagement, TARA alignment and bench access Weeks 1–2
Signed authorisation and rules of engagement from the system owner. Review of your TARA extract or threat list so testing targets the attack paths that carry risk. Hardware to the lab, or the team on your bench.
Test execution Weeks 2–7 for one ECU
Hardware interfaces and firmware, UDS and DoIP diagnostics, in-vehicle networks, Secure Boot and Secure Onboard Communication, wireless and backend — with protocol fuzzing instrumented on the bench. Critical findings escalated as they are confirmed.
Report and findings walkthrough Week after execution
Every finding with reproducible steps, evidence, severity, attack-feasibility input per ISO/SAE 21434 Clause 15 and remediation guidance, mapped to the applicable threat catalogue — UNECE R155 Annex 5 or AIS 189 — and to ISO/SAE 21434 Clauses 10 and 11. Walked through live with your engineers.
Retest and closure evidence 1–2 weeks after your fixes
Re-execution against remediated firmware, a retest report and closure evidence filed in the structure your Cybersecurity Case already uses.
Checklist
What to Have Ready Before Scoping
None of these block the first call, but having them shortens the gap between scoping and the first finding.
- Sample units — ideally two, one with debug unlocked
- Firmware builds under test, plus the flashing procedure
- Interface list: DBC, ARXML or an equivalent signal and diagnostics description
- TARA extract for the item, or the OEM's threat list if you are a supplier
- Bench harness, power supply and any gateway or peer ECUs needed to bring the unit up
- Schematics and design documents for grey- or white-box scope
- Your assessment date — ARAI, iCAT or OEM audit — so the retest lands before it
Two regimes
AIS 189 vs UNECE R155 — What Changes for the Evidence
Most Indian programmes answer to both. The assessor and the legal basis differ; the engineering evidence does not have to.
| Aspect | AIS 189 (India) | UNECE R155 (EU and other contracting parties) |
|---|---|---|
| Who assesses | CMVR test agencies — notably ARAI (Pune) and iCAT (Manesar) | Approval authorities such as KBA or RDW, via designated technical services such as TÜV SÜD or UTAC |
| Legal basis | AIS 189 / AIS 190 under the Central Motor Vehicles Rules, by MoRTH notification | UN Regulation 155 under the 1958 Agreement; mandatory in the EU through Regulation (EU) 2019/2144 |
| Threat catalogue | Aligned to UNECE R155 Annex 5 by design | Annex 5 — 69 threat and vulnerability examples the risk assessment must consider |
| Mutual recognition | None — India is not a 1958 Agreement party | Recognised across contracting parties; India approvals do not transfer |
| What reuses | The engineering evidence: TARA, verification and penetration-test reports, Cybersecurity Case | The same evidence, if written to ISO/SAE 21434 structure — which is how we write it |
Primary sources: Regulation (EU) 2019/2144 (makes R155 mandatory in the EU) and Delegated Regulation (EU) 2025/1455 (L-category extension). For AIS 189 status, see the AIS 189 compliance page.
Practicalities
Engagement Practicalities in India
The questions procurement and programme managers ask before the scoping call, answered up front.
| Where testing happens | Agnile lab in Bengaluru, or on-site at your bench — Pune and Chakan, Chennai, Hyderabad, Bengaluru, Manesar and the NCR, Hosur, Sanand |
|---|---|
| Hardware logistics | Domestic shipping only; no export-control filings or customs holds on prototypes |
| Contracting | Agnile Technologies Private Limited — Indian entity, INR contracts, GST invoicing; mutual NDA before scoping |
| Working hours | IST, on your programme's schedule; findings walkthroughs with your engineers live |
| Approach | Grey-box by default; black-box or white-box by scope |
| Typical duration | 4–10 weeks per ECU or telematics unit; 12+ weeks vehicle-level |
| Cost drivers | Targets and interfaces, box colour, sample units available, on-site days, retest rounds — fixed price after scoping |
| Data handling | Firmware, schematics and findings handled under Agnile's ISO/IEC 27001:2022 information-security system |
| Deliverables | Findings report, AIS 189 / R155 Annex 5 mapping, attack-feasibility input for the TARA, retest report and closure evidence, executive summary |
Engagement models — component assessment, programme retainer, pre-assessment validation — are described on the services page. Serving European OEMs from India? See automotive penetration testing in Germany and Europe.
Why Agnile
An Indian Team That Builds the Stacks It Attacks
- Headquartered in Bengaluru. Indian contract, Indian time zone, hardware that never leaves the country — and a team that already works inside Indian OEM and Tier-1 programmes.
- Engineering depth, not a checklist. The same engineers write Secure Boot chains, integrate Hardware Security Modules and ship AUTOSAR security stacks, so the test starts from how the stack was actually built.
- One report, two audiences. Findings are mapped once to AIS 189, UNECE R155 Annex 5 and ISO/SAE 21434, so the same artefact set serves the domestic test agency and the global OEM customer's Interface Agreement.
- Certified operations. Agnile is ISO 9001:2015 and ISO/IEC 27001:2022 certified; your firmware and findings are handled under an audited information-security system.
Penetration testing sits inside our wider automotive cybersecurity practice. Programmes that need the surrounding process — TARA, CSMS evidence, Interface Agreements — pair it with ISO/SAE 21434 consulting or run the analysis in the KAVACH workspace.
FAQ
Automotive Penetration Testing in India — Questions
Explore next
Plan the test around your programme
The service overview and methodology, the compliance hubs the evidence maps to, and the India-specific regulatory guide.
Penetration Testing
Scope Your Penetration Test in India
A short scoping call from Bengaluru: bring your target ECU, your bench location and your ARAI, iCAT or OEM assessment date. We respond to qualified enquiries within one business day.