Cybersecurity and connectivity in device documentation
A medical device that talks to a network raises documentation questions that a self-contained one does not. They come from two directions: what has to be said about protecting the device and its data, and what an assessor will ask about how the device connects to everything around it.
What cybersecurity covers
The information-security standard 27100 defines cybersecurity as the safeguarding of people, society, organisations and nations from cyber risks. In general it is the set of tools, habits, systems and decisions used to keep digital space safe, and everyday instances are the PIN that protects a phone and two-factor authentication on an email account.
Cybersecurity practices are crucial for individuals and organisations, from the bottom up, and cybersecurity is essential wherever technology exists, meaning any active device with any means of connection. The Stuxnet virus was introduced by human error rather than over a network: a USB stick was left at a McDonald's, and an employee of an Iranian company took it to see what it held.
Which devices and data are exposed
Knowing what assets are held and who is on the other side puts a defender in a good position against any threat.
Medical devices used to be isolated: a patient had an electrocardiogram taken, received a paper trace and carried it to the doctor. Now almost all medical devices are connected to some network, and a hospital resembles a smart home. Because of these connections, healthcare has become a prime target for cyberattacks. Over 700 incidents affecting patient safety and data integrity were reported in 2024 alone, and 250 million people have been affected by some kind of security breach. Healthcare data breaches affecting 500 or more individuals numbered only 18 in 2009, when few devices were connected, and the numbers for 2023 and 2024 are higher.
Many modern devices are software-driven, so the devices, and the patients implanted with or wearing them, have become part of the internet of things and are therefore vulnerable to attack. Large devices are exposed in the same way: an electrocardiograph, a body scanner or a surgical robot is run by software and can be breached by an experienced attacker at a distance.
The exposure reaches well beyond clinical equipment. A two-year internal study by a Midwestern US health care network, reported in 2014 and covering about 100 hospitals, health clinics and pharmacies, identified a disturbing and extensive lack of security that could potentially leave nearly every aspect of the health care system open to hackers. Vulnerabilities were found in medical devices, namely drug pumps for insulin and for pain management, implantable cardioverter-defibrillators, CT scanners and robotic surgical systems; in hospital storage and climate control systems, including the refrigeration units that store blood and pharmaceuticals; and in medical record and image-archiving systems. The network published the findings because the problem is likely rampant throughout the nation and around the world.
What an attacker can do with a device or its data
Stolen medical records can be used to generate compliant fake identities. A recent listing offered medical records stolen from a supplier serving 30 clinics, and an AI-generated passport made from such data passed a know-your-customer check.
A review of medical device cybersecurity presented theoretical scenarios of murder committed remotely, by manipulating a pump to deliver the wrong insulin dose or by reprogramming a pacemaker to give incorrect pacing. In 2017 the US FDA issued a safety communication on the cyber vulnerabilities of a radio-frequency-enabled implantable cardioverter-defibrillator and its transmitter.
For a device the patient depends on, those scenarios had still not become recorded cases by 2025. There is no recorded case of a person harmed directly by a cyberattack, but an indirect death is known: a woman in Germany received help late because of a cyberattack and died. The hazard has nonetheless been demonstrated: students in the United States took full control of a pacemaker on a simulated patient, changed its rate and switched it off, and the simulated patient died.
What makes a device vulnerable
The FDA recalled an insulin pump as a preventive action rather than in response to a cybersecurity incident, because the device was old, had no cybersecurity measures and could not be updated, while it could still be targeted by criminals.
Three properties make devices vulnerable. The first is legacy systems and outdated software. A manufacturer places a minimum viable product on the market, and its vulnerabilities have to be patched as they are discovered. A vulnerability not yet patched is a zero-day vulnerability, and whether the legal manufacturer or an attacker finds it first decides the outcome, and a device running legacy systems and outdated software can easily be a target. The second is inadequate security protocols, with little encryption, partly because measures such as an authenticator app are a nuisance at login. The third is complex interoperability: devices have to work on the hospital's own networks, regulators are working towards systems that talk to one another, and where systems do not, security management becomes more complicated.
Inadequate protocols were found in 2014 as well: many of the systems examined in the US network's study lacked rigorous authentication protocols for granting access and reconfiguration, and many were connected to intranets or even to the internet, leaving them wide open to manipulation.
Standards and regulatory obligations
The regulatory landscape is large, and most of it is based on risk. The first is the standard 14971; for software development there is 62304, and for software as a medical device 82304. Developers of systems that need cybersecurity are advised to add 81001-5-1, on security management in health software. Europe and the United States each have their own regulations and guidance documents, more or less at the same level.
Post-market surveillance and follow-up are important because that is where security flaws are discovered and patched, and manufacturers are expected to carry them out throughout the product's lifecycle. Technical documentation for CE marking of an active medical device or of medical device software now cannot be submitted unless the cybersecurity requirements are fulfilled. The industry has to adjust to new technical developments and keep up with new regulations, fulfilling them rather than avoiding them.
In January 2025 the European Union issued an action plan with measures on prevention, on detection, and on response and recovery, intended to help the healthcare sector and device manufacturers meet standards, protect their devices and stay a step ahead of cybercriminals. A public consultation on how to organise cybersecurity in the EU was open until 30 June 2025, after which the EU was to evaluate the responses and set a strategy.
The volume of requirements is large. The FDA has 21 guidances covering software, digital connectivity, cybersecurity and digital health, and 14 more covering specific device types. Together they yield more than 70 regulatory requirements, each with a package of information to be delivered. In the European Union, digital health alone has roughly 60 to 70 main regulatory deliverables.
How the regulatory framework developed
In June 2013 the US Food and Drug Administration issued an unusual safety communication aimed at medical device manufacturers and health care facilities. It was prompted by a growing concern that cyberattacks might be used to reconfigure or disable computer-controlled medical devices while patients were using them. It carried a summary of the problem, recommended actions for device manufacturers and for health care facilities' information-technology departments, and links to further reading.
By 2017 the regulatory answer was spread across several instruments. The US FDA had issued two industry guidances on device cybersecurity, on the content of premarket submissions in 2014 and on postmarket management in draft in 2016. The new MDR sets out to address cybersecurity in Section 17 of Annex I. Two further European instruments reach the same devices: the 2016 directive on the security of network and information systems, and the General Data Protection Regulation.
By 2020 the European Union had a guidance document of its own. Devices will always be subject to vulnerabilities that cannot be eliminated entirely, so manufacturers and developers must take a multi-tiered approach to minimise threats. The Medical Device Coordination Group's guidance MDCG 2019-16 sets out the steps developers must take to reduce the risk, and the International Medical Device Regulators Forum has a companion document that augments it. Both include strategies for pre-market development, including security requirements, risk management, cybersecurity management plans and labelling, and for the post-market side, including vulnerability remediation and incident response. Cybersecurity vulnerabilities can make devices and hospital networks inoperable, disrupting care across facilities, which may delay diagnosis or treatment in ways that may harm patients. The need for cybersecurity has grown with wireless, internet- and network-connected devices, portable media and the frequent electronic exchange of device-related health information, while attacks on the healthcare sector have become more frequent and more severe. Even a stand-alone device not connected to a network can be interfered with by unauthorised people.
Cybersecurity in the instructions for use
Manufacturers of active devices connected to a network have not been seen to mention any cybersecurity measure in their instructions for use. Nothing says what the user can do, and the user may be a healthcare professional at the hospital rather than the patient. First aid for an incident is not written in the instructions for use, users lack appropriate training, and they do not know what to do until a technician arrives and disconnects the device. The field is late in this, though some movement has begun.
Instructions for use should include cybersecurity measures, so that the final user knows how to protect against attack. A European agency publishes basic cyber-hygiene best practices, which are also useful for teaching others:
- Manage passwords and access.
- Be cautious with email and links, which have moved on from the advance-fee scam to AI and deepfake material that cannot be told apart from the real thing.
- Secure the wifi network. Avoid public networks, or use a VPN on one, so that nobody can read what is typed. A weak home network lets a criminal commit a crime through it that is then traced to that address.
- Educate yourself and others.
- Update software regularly.
- Back up important data at least once a month, since a backup can save data from a ransomware attack.
- Use antivirus and endpoint protection.
- Limit the personal information shared on social networks.
Device data in disclosed trial documents
An individual device records data specific to its wearer. Implantables range from stents to hip replacements to an artificial heart, and wearables, worn for diagnosis and therapy, from hearing aids to continuous glucose monitoring systems. Each unit is identified by a serial number and can provide metrics specific to its user. A pacemaker gave away its wearer in an arson case: at the time of the fire on his property the device recorded no cardiac activity indicative of the stress expected, which pointed to a deliberate setting of the fire by the wearer. In another case, a continuous glucose monitor's data revealed a deliberate insulin overdose delivered by the user.
That specificity also exposes the patient. Identifying an implanted or worn device from its model, manufacturer, bar code or serial number can de-anonymise an anonymised patient, and because the device is connected, an identified patient is open not only to an invasion of privacy but to an attack on the device, which endangers the patient's life.
So disclosure of device trial documents is a risk to patient privacy and also a major risk to patient safety, and in device work anonymisation protects lives as well as privacy. Many devices are nonetheless life-saving instruments that patients cannot do without, and their benefits far outweigh the risks. The writer's task is to reduce the risks to privacy and safety as far as possible while producing documents scientifically sound enough for regulators to assess the device's safety and performance.
The human as the weakest link
The weakest link in device cybersecurity is the human, so training and awareness of cyber threats matter for all employees, and for final users and patients too. For a patient who does not use a smartphone, a manual insulin pen may be a better choice than a smart insulin pump. Because of such a lack of technical knowledge a balance has to be found, and without continuous education and awareness little can be done for cybersecurity protection. New generations, born with smartphones, know technology well, while digital transformation is moving very fast.
What the medical writer contributes
A medical writer can contribute in four ways: promote awareness of the problem; act as a bridge between the technical and regulatory teams, since developers dislike paperwork and regulation and someone has to make that conversation happen; contribute to clear end-user communication, meaning the instructions for use and the technical documentation that shows the requirements are met; and collaborate with the cybersecurity and risk teams. Cybersecurity is not only about protecting data but about protecting lives.
Digital connectivity in diagnostic devices
Many products, not only combination products, now carry a digital connectivity component, so the writer has to communicate highly technical concepts to regulators and assessors and understand their clinical implications. The technology aims at the limits of traditional diagnostics: geographical barriers that keep rural populations from high-tech facilities, the monitoring burden of chronic disease such as diabetes, and workflow bottlenecks in hospital systems that earlier detection could relieve, since devices now reaching the market can identify cancer, liver disease and ocular disease years before symptoms. The answers are cloud-based integration and software as a medical device deployable anywhere, mobile connectivity carrying real-time data from wearables to be analysed and sometimes acted on, and AI-enabled diagnostics. Connectivity itself means integrating the diagnostic device with digital platforms over Bluetooth, wifi and cloud computing, across systems, communities and remote clinics.
The EU MedTech market is growing steadily, the digital health sector is expected to grow at 9.3% in the next few years, and the digital health market volume is above €50 billion. So the number of connected devices medical writers meet will keep rising. Examples include ambulatory blood-pressure devices for patients liable to a sudden spike or drop, glucose monitors reporting through a phone app or directly to the clinician, neuropathy treatment devices, a pathology device combining hardware and software to detect breast cancer in tissue samples, radiological devices detecting arterial calcification in images, a cloud platform detecting liver disease up to five years before symptoms, an ophthalmic device performing a refraction exam through a phone camera, and a device using a phone's accelerometer to detect heart disease years in advance.
These devices are complex and raise many connectivity questions that have to be answered. Besides the submission itself, they need educational materials, training guides and patient education content, and the writing has to address privacy regulations that are stricter in the European Union than in the United States.
Assessors' questions about connectivity
Safety and effectiveness remain the substance of regulatory evidence, but some connectivity questions bear on them: how the software architecture affects the communication protocols, and how those protocols may affect future deployments of the device. In one case a device's AI model had to be completely retrained because it was used in a different software and hardware combination, and a special 510(k) was needed. Regulators also ask about data security, about clinical evidence much as for any device, and about integration: interoperability, and how the device connects to hospital systems, to other devices and to the network.
This needs an evolving skillset. A medical writer may not be an IT or cybersecurity expert, but has to understand how AI models are trained, how they perform and how their performance is collected, some software development concepts, and how systems communicate with one another, well enough to answer a regulator. Regulatory expertise is needed for the submission, and user-centred communication for the cybersecurity and connectivity risks.
Questions received on three devices show how detailed these questions become. A pathology device, hardware and software that uses AI to digitise a slide of breast tissue and identify potentially cancerous cells, integrates with hospital systems through secure APIs, so that a specialist can read the slide remotely, even from another country. Because its model was self-adapting, a predetermined change control plan had to be submitted to justify the adaptations. The further questions were which communication standards were used, what safeguards existed if an image arrived in the wrong orientation, whether the AI ran on a local GPU or in the remote cloud, and, if that GPU was shared with other applications, how memory isolation was enforced.
A cloud-based digital in vitro diagnostic computes the risk of liver fibrosis from blood-based biomarkers through multivariable models. Its questions were how patient data traverses the public internet or leaves the hospital firewall, how often certificates are rotated and who manages the keys, what syntax and semantic validations are performed on each biomarker, and what stressor compatibility testing had been done across several laboratory information system vendors.
A wearable sensor placed within the cerebrospinal fluid both detects cerebrospinal pressure and drains fluid when the pressure is high, self-adapting under an AI algorithm. Its potential for harm to the patient pushed the questions into timing and tampering: the maximum allowable latency from a posture event to valve actuation, the worst-case timing if the algorithm failed to respond to a pressure spike, how the pressure transducer is calibrated, what alarms reach the hospital and how they are validated, how the system is secured, how it is made tamper-evident, and what logs would show that tampering had occurred.
The obstacle is understanding how these systems and their communication protocols work, and how the connection affects the patient. In the technical file or the clinical evaluation report, the writer has to represent not only the risks but also the mitigations implemented in the device. Innovation will keep increasing and the devices will keep getting more complex, so the writer has to keep adapting to their technological advances, and simplifying and communicating effectively to regulators will help submissions succeed.