India Just Tightened Its EV Cybersecurity Rules. What Changes for BMS Makers?

A Battery Management System used to have one job: watch voltage, current, temperature and state of charge, and protect the battery from itself. Today it does far more than that. It talks to gateways, mobile apps, cloud platforms and OTA infrastructure over Bluetooth, BLE and other wireless interfaces, often as a matter of routine, sometimes as a competitive feature.

That shift is exactly what AIS-156’s cybersecurity requirements for EV Battery Management Systems are responding to. All India EV reached out to BMS manufacturers for their perspective on what this means in practice, not as a compliance headline, but as an engineering and industry question.

Three companies responded: Exicom, Maxwell Energy Systems and Electrifuel.

Read together, their answers sketch out where BMS cybersecurity in India actually stands, and how far it still has to go.

The Baseline: Some Manufacturers Got There Early

Not every company is starting from zero. Ashwin, Exicom, points out that his company treated this as a design principle well before it became a regulatory requirement:

Exicom being a pioneer in the design and manufacture of high quality Battery Systems and BMS and a responsible ecosystem enabler identified the need for implementing such a cybersecurity measure way back in 2019, and since then our industry acclaimed indigenous Lite and MEXX BMS platforms have already been compliant to such basic cybersecurity principles.

That is a useful data point for the industry. It suggests AIS-156 is, in part, formalising practices that some serious players had already adopted. Exicom’s current focus, according to Ashwin, has moved further upstream, working with global semiconductor partners to build multipoint hardware-based security into its newer BMS platforms, aiming to stay ahead of the legislation rather than simply comply with it, across both wired and wireless interfaces.

This matters because it separates two very different postures in the industry: companies retrofitting security to satisfy a new rule, and companies for whom the rule is catching up to what they were already doing.

The Architecture Argument: Security Cannot Be Bolted On

Kavita, Maxwell Energy Systems, makes the case that AIS-156 should be read as a floor, not a finish line, and that the real work happens far earlier than certification:

For BMS manufacturers, security must begin at the architecture stage, across hardware, firmware and communication interfaces, not as a compliance activity at the end.

Her breakdown of what that actually requires is worth sitting with:

• Hardware: security-capable controllers, protected key storage, and proper isolation between wireless interfaces and safety-critical functions
• Firmware: secure boot, device authentication, signed updates, and protection against command injection, spoofing and replay attacks
• Wireless access: built on least privilege, so a diagnostic or telemetry interface is never a backdoor to critical battery controls
• Legacy interfaces: CAN, UDS, bootloaders, flashing and debug ports need the same scrutiny as newer wireless channels
• Connected infrastructure: OTA and cloud connectivity require device identity, certificates, key management and verified software integrity as baseline requirements

Her framing of the attack surface is blunt: Bluetooth, CAN, UDS, diagnostic tools, mobile apps, cloud platforms and OTA infrastructure are not separate problems to patch individually. They are one security ecosystem, and the goal isn’t to restrict connectivity but to make sure connectivity never becomes uncontrolled access.

Where Safety and Security Converge

Both Maxwell and Electrifuel independently arrive at the same conclusion, and it is arguably the most important point to come out of all three responses: functional safety and cybersecurity are no longer separable problems in a connected BMS.

Kavita puts it this way:

Functional safety addresses unintended failures. Cybersecurity addresses deliberate compromise. In a BMS, the two can quickly converge. A manipulated protection parameter, unauthorised command or compromised communication path can turn a cyber incident into a safety event.

Sumesh Sheoran, Co-Founder, Electrifuel, reaches the same place from a different angle, describing the emerging discipline as cyber-physical safety:

Functional safety generally deals with what happens when something fails. Cybersecurity deals with what happens when someone intentionally tries to make the system behave incorrectly. The problem is that a cyberattack can potentially create a safety event… The underlying battery may be safe by design, but the system around it has created a new risk.

Sumesh is also explicit about where the line has to be drawn architecturally: a compromised Bluetooth connection should never be able to reach a battery’s fundamental protections.

If somebody compromises a Bluetooth connection, they should not suddenly have the ability to compromise the fundamental safety mechanisms of the battery. Over-temperature, over-current, over-voltage, short-circuit and other critical protections should continue to work independently.

That is a specific, testable engineering requirement, not a general statement of intent, and it is the kind of question AIS-156 audits should be asking directly.

The questions Electrifuel says every BMS engineering team should now be asking as a matter of routine:

• Who can connect?
• What can they see?
• What can they change?
• What commands can they execute?
• What happens if that connection is compromised?

The India-Specific Problem: Security at Every Price Point

This is where the responses diverge from a generic global cybersecurity conversation into a distinctly Indian one. India’s EV market spans two-wheelers, three-wheelers, commercial vehicles and passenger cars, each with wildly different compute, memory, power and cost budgets. Kavita frames this as Maxwell’s central engineering constraint:

A premium passenger vehicle and a high-volume two-wheeler have very different compute, memory, power and cost constraints. The answer is not the most complicated security architecture. It is the right level of protection for the right level of risk.

That is a meaningful caution for regulators and industry alike. A security standard that only works at premium price points will not secure the vehicles India is actually building in volume. The compliance bar has to be met, and it has to be met inside a two-wheeler’s cost structure, or the mandate risks becoming aspirational for most of the market it is meant to cover.

Beyond Vehicles: A Bigger Argument From Electrifuel

Sumesh makes the case that the conversation is being framed too narrowly if it stays confined to EVs at all. Lithium batteries with a BMS are going into telecom backup, banks, hospitals, data centres, government infrastructure and renewable-energy storage, not just vehicles.

From Kanyakumari to Kashmir, we are going to have millions of battery systems operating in different environments… If a vulnerability exists in one BMS, it may affect one product. But if the same vulnerability exists in a BMS platform that has been deployed across thousands or potentially millions of systems, the nature of the risk changes.

He goes further, connecting this to critical-infrastructure resilience rather than individual product safety:

Critical infrastructure increasingly depends on connected electrical systems… The concern isn’t necessarily that someone will ‘hack the battery.’ The bigger concern is scale and dependency.

This reframes AIS-156 compliance as something closer to supply-chain and national resilience policy than a vehicle-type-approval checkbox, a scale of thinking the standard’s current scope may not fully anticipate.

What Changes on the Development Floor

All three responses agree, implicitly or explicitly, that validation processes are about to get heavier. Sumesh lists out what BMS teams will now need to test for as a matter of course:

• Can an unauthorized device discover and connect to the BMS?
• Can sensitive information be read without authorisation?
• Can parameters be changed or commands replayed?
• Can firmware be replaced, and is the OTA mechanism actually secure?
• Does the battery remain safe if the communication layer itself is compromised or flooded?

This means threat modelling, penetration testing, firmware security testing and system-level validation will become much more common. It will add some cost and development time. But honestly, I think that is the right cost to pay. It is much cheaper to design security into a BMS than to discover a serious vulnerability after millions of devices are already deployed in the field.

Kavita’s version of the same point is that security validation now has to sit alongside, not after, functional, electrical, EMC and environmental testing, with the same rigour applied throughout.

Compliance Is Not the Finish Line

Perhaps the most useful shared message across all three responses is a warning against treating AIS-156 as a one-time hurdle. Kavita states it directly:

Compliance is the baseline, not the destination… The connected BMS is no longer just managing energy. It is managing a safety-critical digital system.

She also stresses that security has a lifecycle, not a launch date:

Vehicles remain on the road for years. Vulnerabilities emerge. Software changes. Diagnostic tools evolve. Security therefore has to continue across the lifecycle, from development and manufacturing through vehicle integration, service and OTA updates.

Sumesh’s closing framing puts the same idea in blunter terms:

If batteries are going to power everything, can we afford to have an insecure BMS sitting at the centre of them? I don’t think we can.

Where This Leaves the Industry

Three companies, three slightly different vantage points, one shared conclusion: AIS-156’s wireless cybersecurity requirements are less a new obligation than a formal recognition of what BMS engineering already needed to become.

• Exicom’s response shows that early movers built cybersecurity into their platforms years before regulation demanded it, and are now pushing toward hardware-based, multipoint security ahead of what the standard requires
• Maxwell’s response makes the case that security has to be architected in from day one, scaled to India’s cost realities, and treated as inseparable from functional safety
• Electrifuel’s response widens the frame furthest, arguing that BMS security is not just an EV compliance issue but a question of critical-infrastructure resilience at national scale

What none of the three respondents claim is that this problem is solved. AIS-156 sets the requirement, but the industry’s own responses make clear that the real work, secure architectures actually deployed at scale, penetration-tested wireless interfaces, and lifecycle-long vulnerability management, is only just getting started.

The question this leaves for regulators and OEMs alike: as India connects millions of batteries to the internet, at two-wheeler cost points and grid-storage scale alike, is a type-approval standard enough, or does BMS cybersecurity need to be treated as ongoing infrastructure policy rather than a one-time certification?

That is the conversation AIS-156 has opened. Whether it gets closed at the vehicle level, or expands into the broader energy-infrastructure question Electrifuel is raising, will shape how secure India’s connected battery ecosystem actually turns out to be.

Please follow and like us: