Decision RecordActivePublished without chair review
CRT-2026-003505 Jul 2026MORNING EDITIONDaily Roundtable
Bluetooth e-rickshaw BMS cyber-physical safety controls
Treat the issue as a real local cyber-physical safety warning: inventory Bluetooth-exposed BMS units, change or disable default credentials, require authenticated pairing, remove or block unauthorized BMS apps from fleet/driver phones, and test firmware or Bluetooth changes on a small set before fleet rollout.
Current public guidance · the full record
What to do now
Under reviewAt a glanceFor fleets operating Bluetooth-enabled e-rickshaw battery-management systems, treat nearby Bluetooth access as a safety issue now.
Inventory every e-rickshaw with a Bluetooth-exposed BMS. Change or disable no-password and factory-default BMS credentials. Require authenticated pairing before any phone can manage the BMS.
Remove or block unauthorized BAT-BMS, Lossigy, Epoch-i-ion, or other BMS-control apps from fleet-managed and driver phones.
Before a fleet-wide firmware, app, or Bluetooth setting change, test it on a small set of vehicles and confirm that the vehicle does not unexpectedly lose battery power during normal use.
Why now
Under reviewThe bounded packet from 2026-07-05 contains a cyberbrief handoff describing a Bluetooth e-rickshaw app flaw that lets nearby users remotely disable vehicles and a same-day Sara Kovacs analysis describing reported Bluetooth-enabled e-rickshaw BMS access within roughly 10–15 metres.
Because the reported outcome is battery power cut-off rather than only app data exposure, fleet operators should act before waiting for a full official model list: inventory exposure, remove default access paths, control pairing, and stage changes safely.
The reason to avoid stronger public claims now is also immediate: the packet lacks the underlying authoritative source confirming official action and exact affected scope.
Who is affected
Under reviewE-rickshaw fleet operators with Bluetooth-enabled battery-management systems are affected because nearby phones may be able to reach the BMS and cut battery power if credentials are absent or factory-default.
Drivers of those e-rickshaws are affected because vehicle immobilization can occur during operation and create a local safety hazard. Fleet or driver phones with BAT-BMS, Lossigy, Epoch-i-ion, or other BMS-control apps are affected because those apps may provide a path to interact with the BMS.
Maintenance teams are affected because credential changes, pairing controls, unauthorized-app removal, and staged firmware or Bluetooth testing fall within their operating duties. The packet does not confirm affected manufacturers, BMS model numbers, firmware versions, app versions, or fleet counts.
What supports this
Under reviewSara Kovacs's analysis supports treating the issue as a local cyber-physical safety warning: it says reports describe Bluetooth-enabled e-rickshaw battery-management systems reachable by nearby phones, often with no password or factory-default credentials, allowing users within roughly 10–15 metres to cut battery power.
The cyberbrief handoff supports the same topic at a summary level: it describes a Bluetooth e-rickshaw app flaw that lets nearby users remotely disable vehicles.
The evidence review supports the operational controls because the packet lists the same remediation actions: inventory exposed BMS units, change or disable default credentials, require authenticated pairing, block unauthorized apps, and stage firmware or Bluetooth changes.
A second evidence review flags an evidence gap: the packet supports the posture but lacks an underlying authoritative public source confirming exact app removals and affected scope.
How the Roundtable reached this
Under reviewSara Kovacs framed the Bluetooth-enabled e-rickshaw battery-management-system reports as a real local cyber-physical safety warning, not a nation-scale OT intrusion claim.
The scout converted that into an operational action: inventory Bluetooth-exposed BMS units, change or disable default credentials, require authenticated pairing, block unauthorized BMS apps on fleet or driver phones, and test firmware or Bluetooth changes on a small set before fleet rollout.
The linker found no existing bounded decision record to route this to.
The evidence review supported the operational posture but separated it from stronger claims because the packet contains summarized reported facts rather than an underlying MeitY order, vendor advisory, formal technical report, or affected-model documentation.
The boundary review kept the conclusion local and reported because official scope, severity, and affected models are not confirmed in the packet.
What is uncertain
MissingThe reported facts support action for nearby Bluetooth access to e-rickshaw battery-management systems, but they do not confirm the full affected scope.
The packet does not confirm which BMS hardware models, firmware versions, e-rickshaw manufacturers, cities, fleets, or app versions are affected. It does not show remote internet-wide fleet control, steering or braking compromise, battery thermal runaway, or a formal CVE or advisory.
The reported 10–15 metre access range and vehicle immobilization scenario should be handled as the working local-risk model until stronger technical or official evidence narrows or expands it.
What evidence is missing
MissingThe packet does not include the underlying public report, MeitY order, vendor advisory, formal technical report, or affected-model documentation confirming the reported BAT-BMS, Lossigy, and Epoch-i-ion removals or the exact Bluetooth-enabled e-rickshaw BMS exposure details.
It also does not provide confirmed affected BMS model names, firmware versions, app versions, fleet counts, exploit code, test logs, or incident records showing how often nearby users actually immobilized vehicles.
Until those items are available, treat the issue as a reported local Bluetooth cyber-physical safety risk rather than a confirmed nationwide compromise or confirmed steering, braking, or thermal-runaway scenario.
What would change this
Under reviewAn authoritative technical or official source confirming exact affected BMS models, firmware versions, app versions, and exploit conditions would narrow the action from broad fleet inventory to targeted remediation.
Evidence of remote internet-scale control, steering or braking impact, battery thermal runaway, or coordinated exploitation would raise the severity beyond the current local Bluetooth immobilization model.
Evidence that the reported apps or BMS configurations are not used in a fleet would lower that fleet's exposure, but only after inventory confirms no Bluetooth-exposed BMS units, no default credentials, and no unauthorized BMS-control apps on fleet or driver phones.
What to watch next
Under reviewWatch for an underlying MeitY order, vendor advisory, formal technical report, affected-model list, or app-store action confirming BAT-BMS, Lossigy, and Epoch-i-ion removal and the exact Bluetooth-enabled e-rickshaw BMS exposure.
If confirmed affected models or firmware versions are published, map them to the fleet inventory and prioritize those vehicles for credential, pairing, and firmware controls.
Track whether staged tests show unexpected battery cut-off after Bluetooth or firmware changes; if they do, pause fleet rollout and isolate the affected configuration.
For new procurement, require unique per-device credentials, encrypted BLE sessions, audit logs, and safe-fail behavior before accepting new BMS units.
Evidence basis
Public value history
- 05 Jul 2026Initial public guidanceCurrent guidance
Created the first public value version for this Decision Record.
Source RoundtableMorning roundtableConvened 05 Jul 2026Methodology
How the panel reaches a Public Decision Record.