“If someone can take the wheel without the rider’s consent, who really owns the journey?” That question, once rhetorical, has a new urgency after researchers demonstrated they could remotely control a motorized wheelchair over Bluetooth — and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued an advisory about the risk.
The advisory describes a simple but stark failure: certain WHILL model wheelchairs did not require authentication for Bluetooth pairings, allowing any attacker within radio range to pair with a device, issue movement commands, change speed limits, and modify configuration profiles — all without credentials or user interaction, according to CISA. In short: a nearby attacker could commandeer a mobility device and dictate where it goes and how fast it travels.
To understand why this matters, consider two realities. First, many connected devices were designed when cost and convenience dominated engineering tradeoffs; security was an afterthought. Research into radio and embedded systems has repeatedly shown how unencrypted or unauthenticated links create trivial avenues for exploitation, especially now that inexpensive hardware and open-source tools lower the technical barrier to entry for attackers. That broader pattern — the insecurity of legacy radio and embedded systems — has been documented in other domains and underscores why a Bluetooth pairing without authentication is a grave omission for a safety-critical device .
Second, wheelchairs are not phones or watches: they are mobility aids carrying people whose safety depends on predictable, reliable control. A remote actor who can override speed restrictions or steer a chair could cause collisions, falls, or force a user into unsafe locations. Beyond immediate physical harm, such access also threatens privacy and autonomy: changing configuration profiles or collecting telemetry could expose sensitive personal data or allow persistent surveillance.
What happened — briefly
- Researchers demonstrated remote control of WHILL wheelchairs via Bluetooth by pairing without authentication.
- CISA’s advisory notes the lack of enforced Bluetooth authentication and warns that attackers in Bluetooth range could pair and control affected units.
- The attacker capabilities described include movement control, override of speed limits, and manipulation of configuration profiles, all without user interaction or credentials.
Why the technical failure is so consequential
Bluetooth, when implemented correctly, can be secured with authentication, encryption, and pairing controls that limit which devices may connect. When manufacturers omit or misconfigure those protections — for reasons of convenience, legacy design, or cost — they create an attack surface that is trivial for motivated adversaries to exploit. For devices used by vulnerable populations, this is not merely a privacy bug but a safety hazard.
From a security practitioner’s perspective, three design failures stand out: absence of mutual authentication (so the device accepts any pairing request), lack of encryption or weak cryptography for command channels, and insufficient fail-safe behaviors (the device continues executing external commands rather than refusing or switching to a safe, limited mode). Those are basic defensive controls; failing to include them in a device that moves people compounds risk.
Who is affected
- Users and caregivers: immediate physical safety risks and loss of trust in assistive technology.
- Manufacturers and vendors: product liability, recall pressure, and reputational harm.
- Clinicians and institutions: potential exposure to liability if devices in care settings are compromised.
- Policymakers and regulators: a prompt to reassess minimum security standards for medical and mobility devices.
Multiple perspectives on the crisis
Technologists argue for technical fixes that are well understood: require mutual authentication for Bluetooth connections, use authenticated and encrypted channels for command-and-control traffic, enforce least-privilege configuration profiles, implement signed firmware updates, and design fail-safe states that default to safe behavior when anomalies are detected. They also urge coordinated vulnerability disclosure and rapid patching mechanisms so affected devices can be updated in the field.
Manufacturers will point to complex supply chains, the lifecycle of deployed hardware, and user convenience. Retrofitting security into devices already in widespread use can be costly and technically challenging — particularly when units lack over-the-air update capabilities or when users cannot easily bring a device into service centers. Still, when safety is at stake, these tradeoffs are increasingly hard to justify.
Policymakers face a balancing act. Regulation that demands baseline cybersecurity for medical and mobility devices can raise costs and slow innovation, but the alternative is a market where safety-critical products ship with predictable vulnerabilities. Several policymakers and standards bodies have already signaled they will tighten requirements for connected medical devices; this incident adds urgency to those efforts.
Users and advocates rightly demand simple protections: clear disclosure about a device’s connectivity and security posture, accessible instructions for securing devices, timely notifications about vulnerabilities, and free or low-cost fixes when problems are found. In the absence of those, users are left exposed.
Adversaries range from opportunistic local actors to organized criminals or state-level actors. The former might exploit a vulnerability for harassment or theft; the latter could use a fleet of compromised mobility devices for coercion, disruption, or surveillance. The cost and ease of exploitation determine who is most likely to attack — and the CISA advisory suggests this vulnerability did not require exceptional resources to exploit.
Practical steps for mitigation (short- and long-term)
- For users and caregivers: follow vendor guidance, install patches promptly, and, when possible, disable Bluetooth or keep devices in paired-only mode when not actively managed.
- For providers and facilities: inventory connected devices, apply mitigations at scale, segregate device networks, and deploy procedural safeguards (e.g., supervising devices in high-risk environments).
- For manufacturers: issue clear advisories, provide authenticated firmware updates, retrofit security where feasible, and commit to secure-by-design practices for future models.
- For regulators and purchasers: require baseline cybersecurity for mobility and medical devices, mandate coordinated disclosure, and tie procurement to security maturity.
Broader lessons
This episode is another warning that connectivity without security is not progress; it is exposure. Devices that interact with the physical world — especially those intended to assist people with disabilities — must be engineered to resist remote tampering, and the industry and regulators must treat cybersecurity as integral to safety. As prior research into other radio-based systems has shown, inexpensive tools and public documentation make many such attacks feasible unless designers build robust defenses from the start .
CISA’s advisory is a blunt instrument: it alerts users, vendors, and policymakers to immediate danger and compels action. What remains less settled is responsibility and pace of change. Will manufacturers move quickly to patch and redesign? Will purchasers demand secure products? Will regulators set enforceable standards before more incidents occur?
Modern mobility depends on trust — trust that a device will respond to its user, not to a stranger’s command. As we wire more of everyday life to wireless networks, that trust is earned through deliberate design, vigilant maintenance, and clear accountability. If those pieces are missing, the machines meant to restore freedom can become vectors of coercion.
How many more reminders will it take before security becomes a basic feature of every device that carries a person?
Source: https://www.schneier.com/blog/archives/2026/01/hacking-wheelchairs-over-bluetooth.html
