A background note can be accessed here: Lok Sabha Q&A: Government Flags Cybersecurity Risks in E-Rickshaw Battery Systems
The Government's response highlights that cybersecurity vulnerabilities in battery management systems (BMS) can create real-world safety risks, even where existing vehicle safety standards are met. How should India rethink product safety regulation as connected technologies become integral to mobility?
Automotive Industry Standard (AIS) 156 and AIS 038 Rev. 2 ask whether the battery burns. They do not ask who can send commands to it. A battery management system with unrestricted device pairing and blank credentials passes every physical test and still allows an unauthorised user to cut discharge while a vehicle is moving. Our certification framework measures the metal and ignores the code. Type Approval under Rule 126 must start asking different questions. Who can issue a command? How is that command authenticated? Is the firmware signed? Who patches it three years from now, and for how long?
The draft requirements built on AIS 189 and AIS 190 point in this direction, but a standard focused on vehicle categories, including L (two- and three-wheelers), M (passenger vehicles) and N (goods vehicles), that does not cover three-wheeler assemblers or imported components leaves the actual risk untouched. Certification is currently a one-time event. Software does not respect one-time events. Approval must carry continuing duties to monitor, disclose and remediate throughout the declared support period, which must be visible to the buyer. Otherwise, we are certifying a snapshot and calling it safety.
The immediate response has focused on removing vulnerable mobile applications and issuing advisories, while broader cybersecurity regulations for e-rickshaws are still evolving. To what extent should India's regulatory approach move beyond reactive interventions towards securing the entire connected mobility ecosystem?
Removing an application from an app store addresses only one layer of the risk. The firmware continues to be installed in new vehicles, the pairing is still open, the APK still circulates outside the store, and the next batch of vehicles carries the same defect. We treated a manufacturing failure as a content moderation problem.
This segment is assembled, not engineered. Small units buy cells, controllers and battery management systems from suppliers whose embedded code nobody in the chain has read. Ask any assembler for the source of the Bluetooth software in their battery management system and the lack of software traceability quickly becomes evident. Regulation aimed only at the finished vehicle will keep missing the component that failed.
What would actually move this? Cybersecurity type approval at the component level, a software bill of materials identifying embedded software components and filed at the time of certification, secure defaults made mandatory rather than optional, verified firmware provenance that establishes where the firmware originated, and testing agencies staffed to examine embedded systems instead of relying on supplier declarations. The regulatory chain also needs a clear allocation of responsibility across suppliers, assemblers and the entity placing the vehicle on the market. Ultimately, the entity placing the vehicle on the market must answer for it. A coordinated disclosure route through the Indian Computer Emergency Response Team (CERT-In), with fixed remediation and notification timelines, turns a one-time advisory into an institutional cybersecurity framework.
E-rickshaws are central to India's affordable urban mobility and clean transport transition. What lessons does this episode offer for scaling connected electric mobility without undermining public confidence?
Unique credentials, closed pairing, authenticated commands and signed updates cost almost nothing per unit. They are missing because no rule demanded them and no buyer knew to ask. We keep describing this as a cost constraint when it is a specification failure.
Remember what is at stake. An e-rickshaw is not a gadget. It is a household's monthly income, standing at a traffic signal with a passenger in the back. A remote shutdown is a lost day of earnings for a driver with no cushion and no helpdesk. Trust, once lost in this segment, will not be recovered through campaigns.
So set a floor. Establish minimum digital safety requirements that apply at every price point, with a workable transition window, reference designs and testing access for small manufacturers who cannot build security teams. The support commitment should also be visible. Print the software support period in the same way that we print the warranty period. Give the driver one number to call when the battery behaves strangely. Visible support commitments and accessible after-sales assistance reinforce confidence long after the vehicle leaves the showroom. Scale without trust is fragile. Build trust into the specification now, or spend the next decade defending the transition instead of leading it.