When a Software Flaw Becomes a Clinical Event: One NHS Cyber Comment, Read Closely

A wireless weakness in a Medtronic MiniMed insulin pump was logged in 2019 as CVE-2019-10964 and scored 8.8 on the ten-point Common Vulnerability Scoring System — high severity. On a server, a figure like that books an out-of-hours patch. On a pump worn against the skin, the same number describes a path to over- or under-delivering insulin. The unit of harm has changed, even though the score has not. That gap is what a recent npj Digital Medicine piece sets out to close.

Before the argument, the genre. This is a Comment in npj Digital Medicine — indexed by PubMed as a Letter — addressed to Britain's Medicines and Healthcare products Regulatory Agency (MHRA). It runs no experiment, presents no new data, and tests no hypothesis. It reasons from public incidents and existing standards toward a policy ask. Judged as what it is, an opinion argued from the record, it is a clean and useful one; judged as evidence, it proves nothing, and the authors do not pretend otherwise.

Risk that moves in two directions

The organising claim is that a connected medical device occupies three layers at once: a physical layer (the pump, the pacemaker, the glucose sensor on the body), a network layer (Bluetooth, Wi-Fi, cellular), and a cloud layer (the manufacturer's servers and interfaces). Most security assessment looks at one layer at a time. Faults do not. A weakness can travel from cloud down to device, from device up to cloud, or both — so a problem rated as contained on one layer surfaces as a safety problem on another.

Three incidents carry the point, and read in sequence the direction of travel is the lesson. In 2017, WannaCry entered NHS systems from the network and cloud and spread downward, by the authors' count cancelling more than 13,500 outpatient appointments and forcing hospitals to divert emergencies. The same year, the MedJack campaign ran the other way — starting at physical devices such as radiology workstations and infusion pumps and climbing into the wider infrastructure. In 2024, a faulty CrowdStrike update fell from the cloud once more, freezing imaging, records and monitoring across hundreds of hospitals at once. Three events, three vectors, one shared assumption — that each layer can be secured on its own — that did not hold.

Read it with the disclosure in view

One declaration belongs in the body, not a footnote: the first author is a co-director and majority shareholder, holding 75 percent or more of the shares and voting rights, of CYBNODE Ltd, a UK cybersecurity firm. A call for stricter cybersecurity regulation from someone who owns a cybersecurity company can be entirely correct — and is still the kind of argument a careful reader weighs with the interest in plain sight. The authors state it openly, which is the right thing to do, and which is also why a reader should keep it open.

It matters here because the case rests on selection rather than measurement. The three incidents are real, but choosing three vivid ones makes an argument; it does not estimate an effect. There is no figure for how often cross-layer propagation actually occurs, no comparison of regimes that did and did not require the controls proposed, no cost or harm model. The implied claim that those controls would have prevented these specific events is plausible and unproven. The right way to take the framing — risk travels between layers, and single-layer assessment misses it — is as a well-argued lens, not as an effect size.

Three asks of the regulator

From the framing follow three recommendations. Assess cross-layer risk at approval: require a manufacturer to show explicitly how a vulnerability could cascade across physical, network and cloud rather than certifying each in isolation. Build security in across the lifecycle rather than bolting it on, evidenced by a Software Bill of Materials (SBOM) — the dependency list that lets a hospital know what is actually inside a device when the next flaw is disclosed. And set a clear line of accountability — who patches, who controls access, who monitors — across the handover between manufacturer and operator, where responsibility today is blurred.

Why it travels beyond Britain

The structural gap described for the NHS is not a British peculiarity. In the European Union, the Medical Device Regulation (MDR) sets cybersecurity expectations and the NIS2 directive raises obligations for essential services, yet a single mandatory cross-layer assessment that ties device, network and cloud together at approval — backed by a routine SBOM, as the US Food and Drug Administration now expects — is not consistently in place. The value of this Comment is not that it settles the question. It is that it states the question European regulators and hospital boards have to answer for themselves: when a fault can move up and down the stack, who is accountable for the whole stack, and how would anyone know what is inside a device before the next disclosure arrives.

Source: Toparti O, Rajput K, Darzi A, Ghafur S. Cybersecurity in connected medical devices: a policy agenda for the NHS. npj Digital Medicine 2026;9:204. This is a Comment — an opinion piece with no primary data — and the first author discloses majority ownership of a cybersecurity company, both of which a reader should keep in view.