How Implanted Medical Devices Talk to the Outside World, and What Happens When the Link Fails
October 8, 2026 — by v0id_walker — filed under The Wired World
A modern implant is rarely a sealed object. A pacemaker reports its battery status and heart-rhythm events to a bedside monitor, which forwards them to a clinic. A cochlear implant receives both its power and its sound through the skin from a processor worn behind the ear. An implanted brain-computer interface sends a stream of neural data to a computer that turns it into cursor movements or text. Each depends on a communication link: through the body, then often across the air, a phone network and the internet.
That link is easy to overlook, because it works quietly most of the time. But it determines much of what an implant can do, how its data is handled, how it can be updated, how it can be attacked, and what happens to the person who depends on it when something in the chain breaks. This article follows that chain outward from the body. It covers the main ways implants communicate, the hard limits on how much data they can send, and the documented security problems. It ends with the failure that gets the least attention, the end of support.

Getting a signal through the skin
There are four broad ways to move information between an implant and the outside world. They differ in bandwidth, range, power and risk, and most real devices combine more than one.
html
<table>
<thead>
<tr>
<th>Link type</th>
<th>How it works</th>
<th>Typical range</th>
<th>Strengths</th>
<th>Limitations</th>
<th>Examples</th>
</tr>
</thead>
<tbody>
<tr>
<td>Wired (percutaneous connector)</td>
<td>A connector fixed to the skull or skin passes signals through a direct cable</td>
<td>Physical cable only</td>
<td>Highest bandwidth and simplest electronics; no implanted battery needed</td>
<td>Permanent opening through the skin carries infection risk; user is tethered to equipment</td>
<td>Research BCIs using the Utah array pedestal</td>
</tr>
<tr>
<td>Inductive near-field coupling</td>
<td>Coils on either side of the skin transfer power and data magnetically</td>
<td>Millimetres to a few centimetres</td>
<td>Can power the implant, removing the need for an internal battery; very short range limits interception</td>
<td>External coil must sit close to the implant; stops working if removed or misaligned</td>
<td>Cochlear implants; China's NEO epidural BCI</td>
</tr>
<tr>
<td>Dedicated medical radio (MedRadio)</td>
<td>Low-power radio in protected bands around 401–406 MHz</td>
<td>Typically a few metres</td>
<td>Allows communication without close contact; spectrum reserved for medical use</td>
<td>Low data rates; power limits; older protocols lacked authentication and encryption</td>
<td>Pacemakers and implantable defibrillators communicating with programmers and home monitors</td>
</tr>
<tr>
<td>Bluetooth Low Energy</td>
<td>Standard consumer radio protocol at 2.4 GHz</td>
<td>Several metres in practice, reduced by body tissue</td>
<td>Talks directly to phones and tablets; widely supported; built-in security options</td>
<td>Depends on consumer operating systems and apps; shared, crowded spectrum</td>
<td>Some newer cardiac devices; fully implanted BCIs such as Neuralink's N1, according to the company</td>
</tr>
</tbody>
</table>The choice of link shapes everything else. A cochlear implant has no internal battery. It works only while the external processor's coil is held over it by a magnet, and stops when the processor is removed. That sounds like a limitation, and in one sense it is, but it also means the implant itself has very little that can fail or drain. China's NEO brain-computer interface, which received market approval from the National Medical Products Administration in March 2026, uses the same principle. Its implants have no internal battery and are powered through an external magnetic coil.
Cardiac devices made the opposite choice. A pacemaker must keep working continuously for years, so it carries its own battery and uses radio only intermittently: to report data, receive new settings or send alerts. In the US, these devices communicate in the Medical Device Radiocommunications Service, known as MedRadio, which occupies frequencies between 401 and 406 MHz. Within its core band, 402 to 405 MHz, Federal Communications Commission rules limit transmissions to 25 microwatts of effective radiated power per 300 kHz channel. That is a tiny fraction of the power of a mobile phone, enough to reach a programmer or a bedside monitor a few metres away and no further. The limit protects other users of the spectrum and the implant's battery, and it also constrains how much data can be sent.
Newer devices increasingly use Bluetooth Low Energy instead, because it lets an implant talk directly to a phone. That removes the need for a dedicated bedside monitor, but it ties the implant's usefulness to the behaviour of consumer operating systems, app stores and phone manufacturers, none of which are designed around medical devices.
The bandwidth problem inside brain implants
For a pacemaker, the amount of data is modest: a few rhythm records, battery measurements, alert flags. A brain-computer interface is different. It is trying to report the activity of many neurons in real time.
The scale of the mismatch is clear from figures Neuralink published in 2024, when it invited outside researchers to propose better compression methods. The company said its N1 implant generates about 200 megabits per second of electrode data, from 1,024 electrodes sampled 20,000 times a second at 10-bit resolution. The wireless link can transmit about 1 megabit per second. The raw data would have to be compressed more than 200-fold to fit through the link.
In practice, implants do not try to send everything. They process signals on board and transmit only what the decoder needs. That is usually detected spikes, or summary features such as how many times the voltage on each electrode crossed a threshold in each short time window. This is a reasonable engineering choice, since decoders often work well on those features. But it has consequences. Information discarded inside the body can never be recovered later. Algorithms on the implant are constrained by its power budget and heat limits, because tissue around an implant can only tolerate a small rise in temperature. Any change to what the implant computes requires a firmware update.
Other systems divide the work differently. Synchron's Stentrode carries electrodes in a blood vessel near the motor cortex and runs a lead to a processing unit implanted in the chest, which transmits wirelessly to an external receiver. Paradromics' Connexus system also uses a chest-implanted transceiver that sends data through the skin to an external receiver. Placing the electronics in the chest gives more room for batteries and processing, away from the brain, but adds a lead under the skin.
The general point is that every wireless implant is a negotiation between what the biology produces, what the link can carry and what the battery can power. Claims about channel counts mean little without knowing how much of that information actually leaves the body.
Beyond the body: phone, monitor and cloud
Once data leaves the implant, it usually goes further. A home monitor or a phone app collects it and forwards it over the internet to a manufacturer's servers. Clinicians view it through a web portal. For cardiac devices this is now routine. Remote monitoring lets clinics detect problems such as rhythm disturbances or failing leads between appointments, without the patient travelling to the clinic.
Each step adds capability and adds a dependency. What crosses each step also differs, and it is worth being precise about it.
Raw sensor data is what the electrodes measure: voltages over time. For brain implants, raw data rarely leaves the body in full, for the bandwidth reasons above.
Processed data consists of features derived on the device or nearby. Examples are spike counts, rhythm classifications or battery measurements.
Inferred information is what software concludes from processed data. A cardiac device might infer that an arrhythmia has occurred. A BCI decoder might infer that the user intended to select a particular letter.
Metadata describes the communication itself, such as when the device connected, from where and how often. It can be revealing even when the content is protected. For example, it can show when a person is at home or how frequently they use a device.
This distinction matters for privacy discussions about neural data. Current implanted BCIs decode specific, trained intentions such as attempted movements, attempted speech or cursor control, in people who are actively trying to use them. They do not read arbitrary thoughts. The privacy concern is real but more specific. Records of what a person typed through a speech or text BCI are as sensitive as any private communication. Long-term neural and usage records could in principle reveal health information, such as changes linked to disease progression. Both deserve the strongest protections, without exaggerating what the technology can extract.
What the documented security problems actually looked like
Concern about hacking implants is often expressed in dramatic terms. The documented cases are more instructive than the hypotheticals, because they show how real vulnerabilities arose and how they were handled.
In August 2017, the FDA announced that about 465,000 pacemakers made by Abbott, which had acquired St. Jude Medical, needed a firmware update. The update addressed vulnerabilities in their radio-frequency communication that could, in principle, let someone nearby with the right equipment change settings or drain the battery. The fix was applied in person at a clinic and took about three minutes. Patients and doctors were told there was a very small risk of the update itself malfunctioning, so each case had to weigh the update's benefits against that risk. No real-world exploitation was confirmed in the reporting at the time.
In 2019, the US Cybersecurity and Infrastructure Security Agency (CISA) published an advisory on Medtronic's Conexus telemetry protocol. The protocol was used by a wide range of implantable cardioverter-defibrillators and related devices, home monitors and clinic programmers. The advisory found that the protocol had no authentication or authorisation and did not encrypt its transmissions. Someone with suitable radio equipment could in principle intercept data or alter device settings. The advisory also set out the limits. An attacker would need to be physically close to the device, the implant's radio was active only briefly outside clinic sessions, and the vulnerabilities could not be exploited remotely. Medtronic released patches for many models, installed during routine clinic visits, and added monitoring for misuse of the protocol.
Three lessons from these cases recur across medical-device security.

Older protocols were designed for a different threat model. They assumed that only legitimate programmers in clinics would ever communicate with an implant. Authentication and encryption cost power and complexity, and were left out.
Physical proximity is a real protection, but not a complete one. Low-power medical radio and short-range inductive links make remote, large-scale attacks much harder. They do not prevent attacks by someone nearby with specialised equipment.
Fixing an implant is not like fixing a phone. A firmware update on a life-sustaining device carries its own risk. It often has to be done in person, and it cannot be rolled back easily if something goes wrong.
How regulation has changed
These incidents contributed to stronger rules. In the US, the Food and Drug Omnibus Reform Act, enacted on 29 December 2022, added a new section 524B to the Federal Food, Drug, and Cosmetic Act. It applies to "cyber devices", meaning devices that include software and can connect to the internet, and which could be vulnerable to cybersecurity threats. Manufacturers submitting new cyber devices must provide a plan to monitor and address vulnerabilities after the device reaches the market, including coordinated vulnerability disclosure. They must also describe processes for providing security updates and patches, and supply a software bill of materials, a list of the software components the device contains. The FDA began applying these requirements to submissions in 2023. It issued final guidance on premarket cybersecurity in September 2023 and an updated version in June 2025.
In the European Union, the Medical Device Regulation's general safety and performance requirements cover software and IT security, including protection against unauthorised access. EU guidance on cybersecurity for medical devices sets out how manufacturers should apply them.
These requirements address the security of the device and its software supply chain. They are less clear about a different kind of failure: what happens when the companies and services an implant depends on cease to exist.
The failure nobody designs for
The most instructive case in connected implants has nothing to do with hacking. Second Sight Medical Products made the Argus II, a retinal implant that gave some people with severe retinitis pigmentosa a limited form of artificial vision. The system used a camera mounted on glasses and an external video-processing unit, which sent signals wirelessly to the implant in the eye. More than 350 people worldwide received it.
Second Sight began phasing out the Argus II in 2019. In March 2020 it laid off most of its staff as it wound down operations, and it stopped providing upgrades and repairs. A 2022 investigation by IEEE Spectrum documented the consequences. Users learned of the decision second-hand. One user's video-processing unit broke in late 2020, and he had to find a refurbished replacement himself. People with the implant faced two options. They could keep a device that might stop working and could complicate future MRI scans, or undergo a difficult surgery to remove it. Second Sight later merged with another company that announced its focus would be on a different product line.
The implant itself did not fail. What failed was everything around it: the external hardware, the replacement parts, the software and the company. That is the characteristic risk of a connected implant. The part inside the body may last for decades, while the parts outside it run on commercial timelines measured in years.
html
<table>
<thead>
<tr>
<th>Failure point</th>
<th>What happens</th>
<th>Who is affected</th>
<th>Mitigation</th>
</tr>
</thead>
<tbody>
<tr>
<td>Short-range link interrupted</td>
<td>External coil removed or misaligned; radio out of range</td>
<td>Devices that depend on continuous external power or processing</td>
<td>Safe default behaviour inside the implant; rapid reconnection</td>
</tr>
<tr>
<td>External component lost or broken</td>
<td>Implant cannot be powered, programmed or used</td>
<td>Cochlear implants, BCIs, retinal implants</td>
<td>Spare parts, repair services and standard replacements</td>
</tr>
<tr>
<td>Phone operating system or app change</td>
<td>Companion app stops working or loses Bluetooth permissions</td>
<td>Devices that rely on consumer phones</td>
<td>Testing against operating system updates; fallback dedicated devices</td>
</tr>
<tr>
<td>Manufacturer server outage</td>
<td>Remote monitoring data delayed or unavailable</td>
<td>Cloud-connected cardiac and other monitored devices</td>
<td>Local storage on the device; therapy that does not depend on the cloud</td>
</tr>
<tr>
<td>Security vulnerability</td>
<td>Data exposure or unauthorised changes by someone nearby</td>
<td>Devices with legacy or unauthenticated protocols</td>
<td>Authentication, encryption, patches, vulnerability disclosure</td>
</tr>
<tr>
<td>Company withdrawal or end of support</td>
<td>No repairs, updates, parts or clinical support</td>
<td>Anyone with that implant</td>
<td>Long-term support commitments, open documentation, escrow of designs and software</td>
</tr>
</tbody>
</table>What good connected-implant design looks like
The evidence from these cases points to a set of principles. None is exotic, and each is easier to build in from the start than to add later.
Keep essential functions local. A pacemaker paces whether or not its home monitor is online. Therapy and safety functions should never depend on a network connection, a phone or a server. Cloud services should add monitoring and convenience, not hold up the core function.
Fail into a safe state. If a link drops, the implant should behave predictably and safely, whether that means stopping stimulation, holding its last safe setting or reverting to a basic mode. Users should know what that state is.
Treat proximity as part of the security design. Short-range links and limited radio duty cycles are genuine protections, provided they are paired with authentication and encryption rather than used as substitutes for them.
Plan for updates from the beginning. Devices will need security fixes over their lifetime. Update mechanisms must be secure, tested, and able to recover from a failed update, with clear guidance on when in-person updates are needed.
Plan for the end of the company, not just the end of the battery. Implants can outlive their manufacturers. Commitments to long-term parts and repair, documentation that would let others support a device, and arrangements to keep critical software available are as much a part of safety as electrical design.
None of these principles requires futuristic technology. They require treating the connection as part of the medical device rather than as an accessory to it. For people who depend on implants, the link and everything behind it are not a convenience. They are the device.