Security Testing for Medical Devices
Medical device security carries stakes most products do not. A vulnerability in a connected infusion pump, pacemaker, or monitor is not just a data risk, it is a patient-safety risk. That changes how the testing is done, how findings are weighed, and what regulators expect. Here is what makes medical device security testing distinct, and how I approach it.
Safety Changes Everything
In most products the worst case of a security flaw is data loss or financial harm. In a medical device it can be physical harm to a patient: a delivered dose changed, a therapy disabled, a reading falsified. That elevates every security question, because the impact axis now includes injury, and a flaw that would be moderate elsewhere can be critical here.
This safety dimension is the lens for the whole assessment. The question is not only can an attacker compromise the device but can a compromise harm a patient, and the findings are ranked accordingly. A security tester working on medical devices has to think like a safety engineer too, because the two concerns are inseparable in this domain.
Testing Without Harming Patients
Medical device testing has a constraint software testing rarely faces: the device may be in clinical use or destined for it, so testing cannot endanger anyone. Assessments run on lab units, test benches, and simulators rather than on devices connected to patients, and destructive or disruptive tests are carefully isolated from anything clinical.
This shapes the logistics heavily. The tester needs representative units that are not in care, a controlled environment, and clear boundaries about what can be disrupted. The discipline mirrors the device’s own design philosophy, fail safe, do no harm, and a careless test that bricked a device meant for a patient would itself be a safety event, so the rules of engagement are stricter than usual.
The Regulatory Backdrop
Medical device security is increasingly mandated, not optional. Regulators such as the FDA expect cybersecurity to be addressed across the device lifecycle, with premarket submissions including threat models, security testing, and a plan for handling vulnerabilities after the device ships. Security has moved from a nice-to-have to a condition of market access.
This means testing serves two goals at once: finding real issues and producing the evidence regulators require. An assessment for a medical device is often structured to support a submission, with documentation of the threat model, the testing performed, and the findings and their resolution. Knowing the regulatory expectations shapes the deliverables as much as the testing itself.
Map the Full System
A connected medical device is rarely alone. It talks to a hospital network, a cloud backend, clinician apps, and sometimes other devices, and the assessment has to map all of it. The attack surface spans the device hardware and firmware, its wireless interfaces, and the ecosystem it connects to, each of which can affect patient care if compromised.
The mapping matters because attacks often arrive through the ecosystem rather than the device directly. A weakness in the hospital-facing API, or in the wireless link, can reach the device without physical access. Treating the device in isolation would miss the paths that a real attacker, who cannot get to the device but can reach the network, would actually use.
Examine the Therapy-Delivery Path
The highest-stakes part of a therapeutic device is the path that controls the therapy: the dose, the stimulation, the delivery. The assessment scrutinizes how that path is protected, whether commands affecting it are authenticated and validated, whether a compromise of the general firmware can reach it, and whether safety limits are enforced independently of the security-sensitive code.
A well-designed device isolates the therapy-critical function so that even a compromised communication stack cannot drive it outside safe bounds, often with independent hardware limits. Testing whether that isolation holds, whether an attacker who owns the network interface can influence the dose, is the most important thing the assessment does, because it is where security failure becomes patient harm.
Wireless and Telemetry
Many medical devices use wireless, Bluetooth, proprietary RF, or network links, for telemetry and control, and that radio is reachable without touching the device. The assessment tests the pairing, authentication, and encryption of these links, because an attacker in range who can inject commands or falsify telemetry can affect both care and the clinician’s decisions.
Falsified telemetry is a subtle but serious risk: a monitor that can be made to report normal vitals during a real emergency, or abnormal ones during calm, manipulates care through the data rather than the device. Testing the integrity and authenticity of the wireless channel, not just its confidentiality, is essential, because in medicine the trustworthiness of the reading is itself a safety property.
Firmware and Update Integrity
The device firmware gets the same scrutiny as any embedded target, extraction, analysis, key storage, and the update mechanism, but with the safety lens. An attacker who can push unsigned firmware to a therapeutic device can do anything the device can, which is why verified, signed, anti-rollback updates are not optional here.
The update path is also a safety mechanism, because it is how security fixes reach fielded devices, sometimes devices implanted in or attached to patients. The assessment checks that updates are both secure and deliverable, since a device that cannot be safely updated is one that cannot be fixed when a vulnerability is found, which regulators increasingly treat as a defect in itself.
Legacy and Long Lifecycles
Medical devices live for many years, often far longer than consumer electronics, and the fleet includes old devices running old software that cannot easily be replaced. The assessment has to account for this reality: a vulnerability may affect devices that will remain in service for a decade and cannot all be updated promptly.
This long tail shapes both findings and recommendations. Mitigations that do not depend on updating every device, network segmentation, monitoring, compensating controls, matter more here than in a product with a short refresh cycle. The testing considers not just the current device but the installed base, because patient safety depends on the devices already in care, not only the next model.
Coordinated Disclosure and Postmarket
Regulators now expect a plan for what happens after a vulnerability is found in a fielded device: a coordinated disclosure process, a way to assess and communicate risk, and a path to remediate. The assessment often evaluates this readiness, because finding issues is only useful if the manufacturer can responsibly handle the ones that emerge later.
A mature manufacturer treats security as a lifecycle commitment: monitoring for new vulnerabilities, maintaining the ability to update fielded devices, and engaging with researchers and regulators when issues arise. Testing that posture, alongside the technical assessment, reflects that medical device security is not a one-time gate but an ongoing obligation tied to patient safety.
A Concrete Testing Example
To make the approach concrete, consider a connected infusion pump on a lab bench. The assessment maps its interfaces, the hospital network link, a maintenance USB port, a wireless telemetry radio, and tests each against the safety question: can this path change the dose or hide a problem. The network link gets probed for the command path; the radio for injection and spoofing.
# enumerate the device's network services on a lab unit (never a clinical one)
nmap -sS -sV -p- 10.50.0.25443/tcp open https (device web UI) 8080/tcp open http (maintenance API, no auth observed) 9100/tcp open proprietary (infusion control channel?)
An unauthenticated maintenance API and a proprietary control channel are exactly the surfaces that demand the safety lens: the next question is whether either can influence the dose, and that is tested on the bench unit with extreme care, never on anything connected to a patient.
Defense in Depth for Patient Safety
Because the consequence of failure is harm, medical device defense leans hard on layering and on isolating the therapy from the attackable surface. The communication stack, the radios, and the app are treated as compromiseable, and the dose-delivery function is walled off behind independent safety limits that hold even if everything else is owned by an attacker.
This architecture is what lets a device be both connected and safe. The assessment specifically tests whether that isolation holds, whether an attacker who fully compromises the network interface can still not drive the therapy outside safe bounds, because that boundary is where security failure either does or does not become patient harm. Confirming it is the most consequential result the test produces.
Where This Fits
Security testing for connected medical devices, with the patient-safety lens and the regulatory evidence regulators expect, is specialized product security assessment work. If you are building a connected medical device and need it assessed against both attackers and regulators, that is the kind of work we do at Berkner Tech.