Threat Modeling an Implantable Device
An implantable medical device sits inside a person, runs for years on a tiny battery, and cannot be easily updated or recalled. Those constraints are brutal, and they change threat modeling profoundly. The usual assumptions, you can patch it, you can recall it, downtime is acceptable, all fail. Here is how threat modeling adapts to a device where the stakes are a human life and the margins are razor thin.
The Hardest Constraints in Embedded
Implantables combine nearly every difficult embedded constraint at once. The device is physically inaccessible without surgery. Its battery may need to last a decade, so every security operation costs precious energy. It cannot fail, because failure can be fatal. And it often cannot be updated in the field at all, or only with great care. Threat modeling has to respect all of these simultaneously.
These constraints invert some normal security advice. You cannot lean on regular patching, so the design has to be right at ship time and stay defensible for years. You cannot spend energy freely, so heavyweight cryptography has a real cost. And safety overrides everything, so a security measure that could ever endanger the patient is unacceptable. The threat model is built inside this box.
Safety Is the Top Asset
The asset analysis starts where it must: patient safety. The therapy the device delivers, a pacing pulse, a drug dose, a neurostimulation, must remain correct and available, and nothing an attacker does should be able to harm the patient. This asset outranks confidentiality and even device integrity, because the consequence of its loss is injury or death.
Framing safety as the primary asset shapes every later decision. A security control that improves confidentiality but introduces any chance of disrupting therapy is the wrong tradeoff. The model continually asks, for each threat and each mitigation, whether it could ever affect the patient, and that question has veto power over choices that would be reasonable in any other product.
Characterize Realistic Attackers
The attacker analysis has to be honest about who would attack an implant and how. The realistic threats are an attacker in wireless range manipulating the device or its telemetry, a thief or researcher with an explanted unit, and attacks on the ecosystem, the clinician programmer, the home monitor, the cloud. A targeted attack on a specific patient is rare but catastrophic, and a broad attack on a device class is the larger systemic risk.
Distinguishing these matters because they call for different defenses. Proximity-based wireless attacks drive the design of the radio’s authentication and range. Ecosystem attacks drive how the programmer and monitor authenticate to the implant. Being specific about the attackers keeps the model from either ignoring real threats or burning the device’s scarce resources defending against implausible ones.
The Wireless Lifeline and Its Risk
An implant’s wireless interface is both essential and dangerous. It is how clinicians adjust therapy and how the device reports data, so it cannot simply be locked down, yet it is the main remote attack surface. The model has to find a design that authenticates legitimate access while denying an attacker in range, under tight energy and emergency-access constraints.
The emergency-access problem is uniquely hard: a clinician in an emergency, perhaps not the patient’s usual one, may need to reach the device immediately, which argues against strong authentication that could lock them out. Resolving the tension between locking out attackers and never locking out emergency care is one of the central design problems the threat model has to grapple with, and there is no easy answer.
Energy as a Security Constraint
On an implant, security costs battery, and battery costs surgery to replace. Strong cryptography, frequent authentication, and active monitoring all draw energy that shortens device life. The threat model has to weigh each security operation against its energy cost, choosing protections that fit the power budget without leaving the device exposed.
This forces efficiency rather than abundance. The model favors security that is cheap per operation, hardware crypto over software, infrequent but strong authentication over constant checks, and asks hard questions about anything energy-hungry. A control that would be obvious on a mains-powered device may be unaffordable here, and the model has to find protection that the battery can sustain for the device’s whole life.
Limited Updatability
Many implants cannot be updated in the field, or can only with risk, which removes the safety net most products rely on. The threat model must assume the device ships in close to its final state, so the security has to be right at design time and remain adequate for the device’s entire lifespan, which may be a decade or more.
Where field updates are possible, they are themselves a high-stakes operation: an update that bricks an implant is a surgical emergency. So the update path, if it exists, gets extraordinary scrutiny in the model, and where it does not, the design must be conservative and durable, choosing well-established cryptography with margin to remain strong for years, because there is no second chance to fix a weak choice.
Defense Without Disruption
Normal security responses, lock out, reset, shut down, are often unacceptable on an implant because they could interrupt therapy. The model has to design defenses that protect the device without ever risking the patient, which usually means failing toward continued safe therapy rather than toward a secure-but-disabled state.
This is the opposite of the fail-closed instinct that serves most security design. An implant frequently must fail open with respect to therapy, continue delivering safe care, even while resisting a security attack, and find ways to contain the attack that do not touch the life-sustaining function. Designing protection that never endangers the patient is the distinctive challenge, and it shapes every mitigation in the model.
Isolate the Life-Critical Function
A recurring answer in the model is isolation: separate the life-critical therapy function from the communication and security-sensitive code, with independent safety limits enforced in hardware. Even if an attacker compromises the wireless stack, they cannot drive the therapy outside safe bounds, because a separate, simple, verified mechanism enforces those bounds.
This separation is what lets the device be both connected and safe. The connected, updatable, attackable part is walled off from the part that keeps the patient alive, and the latter is kept as simple and as verifiable as possible. The threat model drives toward this architecture because it is the most reliable way to ensure that a security failure, however it happens, cannot become a safety failure.
Modeling the Whole Ecosystem
The implant does not exist alone; it pairs with a clinician programmer, a home monitoring unit, and usually a cloud backend, and attacks frequently target these rather than the implant directly. The threat model extends to the whole ecosystem, because a compromised programmer or a spoofed monitor can reach the implant through channels it trusts.
Modeling the ecosystem also surfaces the trust relationships that need hardening: how the programmer proves it is legitimate to the implant, how the monitor’s data is authenticated, how the cloud authorizes commands. The implant’s own defenses depend on these external components behaving, so the model has to assess them as part of the system, not as someone else’s problem.
Designing for a Decade
The throughline is durability under constraint. The threat model for an implant produces a design that is secure at ship, stays secure for years without easy patching, protects the patient under every failure mode, and fits a tiny energy budget. It is threat modeling with most of the usual escape hatches removed, which is exactly why it has to be done carefully and early.
Get it right and the device protects the patient against attackers for its whole life inside the body. Get it wrong and the cost is measured in surgeries or in harm, with no quick patch to fall back on. That is why implantable threat modeling is among the most demanding work in embedded security, and why it belongs at the very start of the design, when the constraints can still shape the architecture.
Where This Fits
Threat modeling devices under extreme constraints, implantables, life-critical systems, long-lived hardware, is specialized work I do at the design phase where it matters most. If you are designing an implantable or other life-critical device and need a threat model built around its real constraints, that is the kind of work we do at Berkner Tech.