Why Was BAT-BMS Banned?

Pankaj Kumar · 09 Jul, 2026

Share

In late June and early July, videos started circulating on Instagram of people walking up to moving e-rickshaws, tapping a phone, and watching the vehicle lose power mid-ride. 

It spread as a prank trend before anyone fully understood the mechanism. Drivers in Patna (India) reported it first, assuming mechanical failure, until investigators traced it to something else entirely: a mobile app called BAT-BMS.

The Indian government has since ordered BAT-BMS, along with two similar apps, Epoch Li-ion and Lossigy, removed from the Google Play Store and Apple App Store. 

Delhi’s Transport Department and police have opened an investigation. It’s being covered as an Indian cybersecurity story. It shouldn’t be. This is a global failure pattern that happens to have surfaced in Delhi this time.

The Ministry of Electronics and Information Technology (MeitY) confirmed the action directly. Speaking at a CII cybersecurity summit on July 3, IT Secretary S. Krishnan said two of the flagged apps had already been pulled after coming to the ministry’s attention the previous day, and that the government would press app stores to review similar tools more carefully before publishing them, as MediaNama reported. 

This piece covers what BAT-BMS was, why it’s a global problem and not just an Indian one, our take on why it keeps happening, and where the same gap shows up in enterprise platforms. 

What BAT-BMS Actually Was?

BAT-BMS wasn’t built as a hacking tool. It’s a companion app made by Shenzhen Grenergy Technology for Battery Management Systems, the electronics inside lithium-ion battery packs that monitor charge, health, and performance. 

Manufacturers, dealers, and service technicians use apps like it every day to diagnose batteries without opening the pack. It connects over Bluetooth, typically within a range of 10 to 15 meters, the same way a fitness tracker talks to your phone.

The problem wasn’t the app’s purpose. 

It was what the battery hardware allowed the app to do once connected. Many low-cost e-rickshaw battery packs broadcast their Bluetooth signal with little or no authentication, no password, no verified pairing, and nothing confirming the connecting device belonged to the vehicle’s owner or technician. 

Once connected, the administrative controls exposed by the BMS included the ability to disable the battery’s power output. Anyone within range could find an unsecured battery and use those same controls a technician would use, with no permission required.

Not every e-rickshaw was affected, and passenger EVs weren’t part of this at all. A demonstration at a Tata Motors showroom indicated that passenger electric cars run closed-loop, encrypted battery management systems, which made unauthorized Bluetooth access substantially harder, per the Sunday Guardian’s reporting. 

The vulnerability tracked specifically to cheaper, aftermarket battery packs common in budget e-rickshaws, not to electric vehicles broadly, and it tracked directly to which hardware vendor’s BMS was installed, and how seriously that vendor had treated authentication as a requirement rather than an afterthought.

The human cost was immediate and unglamorous. One Delhi driver told the Daily Pioneer that his e-rickshaw kept switching off mid-route; he initially spent money getting it inspected for a mechanical fault before learning an app was the cause. 

Passengers who don’t know what’s happening tend to just get out and hail another rickshaw, leaving the driver to absorb the lost fare, on top of the safety risk of losing power in moving traffic.

This Isn’t an India Story, or a China Story. It’s a Global One

Strip out the geography, and BAT-BMS stops looking like a local prank and starts looking like the latest chapter in a story cybersecurity researchers have been telling since 2016.

That was the year Mirai, malware built by three college-age hobbyists, scanned the internet for cameras, routers, and DVRs still running factory-default logins like admin/admin, and turned more than 600,000 of them into a botnet, according to Cloudflare’s retrospective analysis. 

When Mirai pointed that botnet at the DNS provider Dyn, it knocked GitHub, Twitter, Reddit, and Netflix offline for most of a day, not because anyone hacked those companies directly, but because hundreds of thousands of cheap, forgotten devices never had real authentication in the first place.

Nine years later, the pattern hasn’t gone away; it’s just changed protocols.

In 2022, researchers at NCC Group demonstrated a link-layer relay attack against Bluetooth Low Energy proximity authentication, the same “nearby device, trust it” logic BAT-BMS leaned on, and showed it could be used to unlock millions of cars, residential smart locks, and building access systems worldwide with cheap, off-the-shelf hardware. A car on one continent, opened by someone who was never anywhere near it.

BAT-BMS didn’t invent a new failure. It’s the same failure, in a battery pack instead of a router or a car door: a device that trusts proximity, or trusts nothing at all, standing in for real authentication. 

The apps involved are being reported as Chinese in origin, and that detail is accurate as far as the coverage goes, but nationality was never the mechanism. 

Mirai’s worst-affected devices were made by manufacturers all over the world. NCC Group’s relay attack worked against Bluetooth hardware from many countries. What’s consistent across all three incidents isn’t where the device was made. It’s that authentication was treated as optional.

Our Take: Why This Keeps Happening

Here’s where we’ll be direct instead of neutral. This keeps happening for a boring reason.

Real authentication costs money and time that a lot of hardware and software vendors don’t want to spend, especially at the low-cost end of any market. 

Unique credentials per device mean either a provisioning step at the factory or a forced setup flow in the app, both of which add friction and cost to a product running on razor-thin margins. So vendors skip it, quietly bet that nobody’s really looking, and ship anyway.

That bet works right up until it doesn’t. It didn’t work for the manufacturers behind Mirai’s most-abused devices. It didn’t work for the BLE lock vendors after NCC Group’s research went public. 

It isn’t working right now for whichever battery pack suppliers sit behind BAT-BMS. And two structural problems always show up alongside the technical one: regulation reacts to headlines instead of preventing them, MeitY moved fast once this went viral, not before it did, and enforcement lags the announcement, as we noted above, the apps were still downloadable days after the takedown order.

Our opinion is simple if you’re building or buying anything with a control interface, physical or digital, the fix isn’t more security theater. It’s refusing to treat authentication as optional, deferred, or unnecessary just because an interface feels obscure or low-stakes. 

That exact assumption is what fails, every time, once enough people go looking. We’d rather say that directly than dress it up as a neutral incident report, because it isn’t one. It’s a pattern, and patterns are predictable if you’re willing to name them.

Where the Same Pattern Shows Up in Enterprise Platforms

Nobody reading this runs e-rickshaws. But the underlying failure, an administrative or control-plane action that executes without verifying who’s asking, shows up constantly in the platforms we audit, just with less dramatic consequences than a rickshaw stopping in traffic.

It looks like an internal API added during a rushed integration, reachable because it sits behind the corporate VPN and “nobody outside would ever hit it directly.” 

It looks like staging credentials that made their way into a production config and were never rotated. It looks like a third-party vendor integration granted broad account access two years ago, for a project that ended eighteen months ago, that nobody remembered to revoke. 

It looks like an admin panel with a predictable URL and no role-based permission check, because the team that built it assumed only internal staff would ever know it existed.

None of these requires a sophisticated attacker. They require someone who happens to be looking, the same way a bored teenager with a Bluetooth scanner happens to be looking.

What We’d Tell Any CTO Reading This

Do not add more security theater. A short, practical standard we’d hold any control-plane interface to, ours included:

Our standard for any control-plane interface

• Every administrative action gets authenticated, regardless of whether the channel feels “internal” or obscure.
• No default credentials, ever, not even temporarily, not even in staging.
• Every third-party integration’s access gets reviewed on a schedule, not left to run indefinitely after the project that created it ends.
• Administrative actions get logged and alerted on, so unusual access is visible before it becomes a pattern.
• “Nobody would think to look here” is never treated as a security control.

Most platforms don’t fail this standard everywhere. They fail it in one or two places nobody’s looked at recently, usually somewhere that grew fast, changed owners, or got integrated under deadline pressure. 

The risk rarely announces itself. It sits quietly until someone finds it, the same way it sat quietly in a battery pack until a teenager with a Bluetooth scanner did. 

That’s exactly the kind of gap a Platform Architecture Audit is built to surface: where governance, identity, and permissions haven’t kept pace with how the system actually grew, before it becomes a headline instead of a fix.

BAT-BMS wasn’t a hacking story. It was a story about a control interface that never asked who was asking, and got away with it until enough people found out. Every platform has at least one interface like that somewhere. The only real question is whether you find it before someone else does.

Let’s talk about your platform.

Author

Pankaj Kumar

Co-Founder & Managing Director