Implantable Device Cybersecurity: Risks, Controls, Evidence

Part of our Bluetooth Low Energy security series for medical devices. For the full overview, start with BLE Security in Medical Devices: What to Get Right.

Reviewed September 17, 2026

An implanted pacemaker cannot be rebooted at a convenient hour. That single fact drives most of what separates implantable security from everything else in medical device cybersecurity. Every control you might rely on later, from key rotation to firmware updates, has to survive a device that is powered by a battery meant to last a decade and is physically inaccessible for its entire service life.

Manufacturers of pacemakers, defibrillators, neurostimulators, insulin pumps, and cochlear implants face a design problem in which security, battery life, and clinical availability all pull against each other. Getting the tradeoffs right on paper, and documenting why they are acceptable, is what a submission has to demonstrate.

Why the Stakes Are Different Here

The FDA has treated implantable security as a distinct problem for years, and the record explains why. In 2017, Abbott recalled roughly 465,000 implantable pacemakers for a firmware update addressing cybersecurity vulnerabilities, with the update applied during a patient visit rather than remotely. In 2019 the FDA issued a safety communication about the Medtronic Conexus telemetry protocol, which lacked encryption and authentication, affecting implantable cardiac devices and their home monitors. In both cases the vulnerability reached patients because it was baked into deployed hardware.

That is the lesson the February 3, 2026 premarket cybersecurity guidance reflects when it asks manufacturers to document the ability to deploy updates and patches. For an implantable, that documentation cannot be a generic statement about over-the-air updates. It has to explain what is updatable, what is not, how an update reaches the device, and what happens if the update fails partway through in a patient who depends on the device for cardiac output.

Section 524B applies here in full. An implantable with wireless telemetry and software is a cyber device, and the statutory requirements for a vulnerability management plan, timely updates, and an SBOM do not bend because the hardware is difficult to reach.

The Constraints That Shape Every Control

Three constraints dominate, and they interact.

Power is the constraint people underestimate. An authenticated session that seems trivially cheap on a benchtop can become significant when it runs on every telemetry interaction across ten years. This is why cryptographic decisions belong in the silicon selection conversation. Once the chip is chosen, your options narrow to what it can do efficiently, and a firmware change cannot add a hardware accelerator that is not there.

[KEY REQUIREMENT] Document the security decisions you made at chip selection and why, including what you could not afford to do. A reviewer is more persuaded by a justified constraint than by a claim of complete protection.

The Attack Surface Is Bigger Than the Implant

The implanted device is rarely the easiest target. The ecosystem around it usually is.

The Conexus case is the clearest example of why this matters: the exposure lived in the telemetry protocol shared between the implant and its monitor, not in a mistake unique to the implanted hardware. When you build your threat model, the boundary should enclose the full therapy chain, and each link should state what it authenticates and what it trusts.

How Harm Modeling Changes for Implantables

Under ISO 14971, severity is rated by the harm that reaches the patient. For most connected devices, the worst realistic outcome of a compromise is a data breach, a denial of service, or an incorrect reading. For an implantable, the plausible outcomes include inappropriate therapy delivery, therapy inhibition, and premature battery depletion, each of which is a direct physiological event.

This changes the calculus twice. First, it raises severity ratings, which means controls that would look disproportionate elsewhere are justified here. Second, it means the cybersecurity threat model and the safety risk file cannot be separate documents that never reference each other. A reviewer expects to trace a telemetry threat through to the hazardous situation it creates and the harm it can cause, and to see the same control appear in both places.

Battery depletion deserves special mention because it is easy to miss. An attacker who cannot alter therapy may still be able to force repeated wake-ups or authentication attempts, converting a communications flaw into an early explant surgery. Rate limiting is a patient safety control in this context, not a nuisance protection.

Emergency Access Without a Backdoor

See also: Differences in the IoT and the IoMT, The Dangers of Pacemaker Hacks, and Interconnected Medical Device Cybersecurity: Network Risks.

Every implantable design eventually confronts the same question: how does a clinician who has never seen this patient before interact with the device during an emergency? The historical answer, an unauthenticated magnet-activated or proximity-based mode, is precisely the design that security research has targeted.

Workable approaches share a pattern. Emergency access is constrained in what it can do, bounded in how long it lasts, requires close physical proximity, and leaves an audit record. It is not the same interface as full programming access and it does not grant the same capability. The important part for a submission is that this is a designed behavior with a documented rationale, not an unexamined legacy of the previous product generation.

What to Do About Devices Already Implanted

A submission for a new generation does not resolve the risk in the installed base, and the FDA's postmarket expectations do not stop at products still in production. The realistic options are narrow and should be evaluated honestly.

Firmware updates delivered during a clinic visit are the most common path, and they work when the update mechanism was designed with a verified, interruptible, fail-safe process. Where an update is not possible, the remaining options are compensating controls in the ecosystem, such as hardening or replacing the home monitor, restricting programmer distribution, and issuing clear clinical guidance. Where neither is possible, the honest answer is a documented residual risk with a monitoring plan, communicated through coordinated disclosure.

What does not work is treating the installed base as out of scope. The Abbott and Medtronic actions both show the regulatory path when a fielded implantable carries a vulnerability, and both required a plan that reached patients already carrying the device.

How Blue Goat Cyber Approaches This

We test implantable ecosystems as a chain rather than a single device: the telemetry protocol, the programmer, the home monitor, the app, and the cloud services behind them. Radio analysis, firmware and hardware interface review, and protocol testing produce findings that map to patient harm rather than to a generic severity score, which is what the risk file needs.

For manufacturers preparing a submission, our medical device penetration testing covers the wireless and hardware layers that a software-only assessment misses, and our threat modeling work ties each threat to the hazardous situation and harm it produces.

Frequently Asked Questions

Can implantable medical devices actually be hacked?

Documented vulnerabilities exist, and regulators have acted on them. The FDA issued a safety communication in 2019 regarding the Medtronic Conexus telemetry protocol, which lacked encryption and authentication, and Abbott conducted a firmware update in 2017 for implantable pacemakers to address cybersecurity vulnerabilities. Neither event involved reported patient harm, but both required clinical action, which is why regulators treat the risk as real rather than theoretical.

Why can't implantables just be patched over the air like phones?

Power, reliability, and safety. An interrupted update in a device a patient depends on for cardiac pacing is a safety event, so updates are typically applied under clinical supervision with the patient present and monitored. The update mechanism itself also consumes battery capacity, which is a finite resource tied to the device's service life and, ultimately, to when the patient needs another surgery.

Does encryption drain the battery significantly?

It depends entirely on whether the cryptography is accelerated in hardware. Operations performed in software on a low-power microcontroller cost far more energy than the same operations on a chip with a dedicated accelerator. This is why cryptographic capability is a silicon selection decision made early in development rather than a firmware feature added later.

How should emergency access be handled securely?

Through a designed emergency path with limited capability, enforced physical proximity, a bounded session duration, and an audit record, rather than an unauthenticated mode that grants full programming access. The submission should describe exactly what the emergency path permits and why that capability set is the minimum required for clinical care.

What does the FDA expect for implantables specifically?

The same premarket documentation required of any cyber device under the February 3, 2026 guidance, with particular attention to the update mechanism, the threat model's coverage of the full therapy chain, and the justification for controls given power and accessibility constraints. Reviewers also look for consistency between the cybersecurity documentation and the ISO 14971 risk file.

Are legacy implantables still a regulatory concern?

Yes. Postmarket obligations apply to devices in the field, and both the Abbott and Medtronic actions required plans that reached already-implanted patients. A vulnerability management plan that addresses only devices still in production will not satisfy a reviewer asking about your installed base.

Talk Through Your Implantable Threat Model

If your device is implanted, wireless, and expected to last a decade, the security decisions you make before the design freezes are the ones you will live with. We can review them with you while changes are still possible. Book a strategy session.

---

Blue Goat Cyber specializes in medical device cybersecurity, from threat modeling and penetration testing through premarket submission support. Our team works exclusively with device manufacturers preparing FDA submissions. Learn more about Christian Espinosa, our founder and CEO.