Cybersecurity for medical devices
Imaging systems, infusion pumps, monitors, implants with remote programming, and health software in hospital networks and clouds.
Patient safety now depends on cybersecurity.
Infusion pumps, imaging systems, monitors and implants are connected to hospital networks, apps and clouds. Health software runs in data centres and on phones. A vulnerability can affect diagnosis, therapy and patient data.
Regulators have responded. The EU MDR treats security as part of safety and performance, and the FDA expects a complete cybersecurity file before it clears a connected device. Manufacturers need evidence across the whole product life.
Who it is for
- Manufacturers of active medical devices and implants
- Makers of software as a medical device and health apps
- Suppliers of components and platforms for medical technology
- Hospitals and operators of medical device fleets
Where medical devices are exposed today
The attack paths we see most often in medical technology, from the implant to the hospital network.
Wireless
Wireless interfaces
Bluetooth, radio and Wi-Fi links to implants, pumps and wearables can accept unauthorised commands if they lack authentication.
Network
Hospital networks
Devices share networks with office IT. Ransomware that hits the hospital can reach imaging and monitoring systems.
Legacy
Outdated operating systems
Imaging and lab systems often run on operating systems that are no longer supported, because every change needs new evidence.
Cloud
Apps and cloud platforms
Remote monitoring and therapy apps move patient data, and sometimes settings, through cloud services.
Service
Remote service access
Manufacturers maintain installed devices remotely. Shared credentials and always-on connections are frequent weaknesses.
Updates
Software updates
Updates must be fast enough for security and controlled enough for safety. Unsigned updates are a direct risk.
Supply chain
Third-party components
Devices use operating systems and libraries from many suppliers. Without an SBOM, nobody knows where a new vulnerability applies.
Data
Patient data
Health data is valuable to criminals. Breaches lead to penalties, lawsuits and lost trust.
When it went wrong
Three documented cases from healthcare. They show how cyberattacks reach patients, from the hospital network to the implant.
May 2017, ransomware
WannaCry: England's health service loses its systems
The WannaCry ransomware spread worldwide on 12 May 2017 through a Windows vulnerability for which a patch was already available. In England, around a third of NHS hospital trusts were disrupted, and some had to divert ambulances.
Impact
Around 19,000 appointments and operations were cancelled. The Department of Health later estimated the cost at £92 million.
Sources: UK National Audit Office, October 2017; Department of Health and Social Care, 2018
August 2017, implant vulnerabilities
Abbott pacemakers: a firmware recall for 465,000 devices
Researchers showed that radio-connected pacemakers from St. Jude Medical, now Abbott, could be accessed without authorisation using commercially available equipment.
Impact
The FDA approved a firmware update as a recall for about 465,000 devices in the US, and patients had to visit their clinic to receive it. No patient harm was reported, but the case changed how regulators look at device security.
Sources: FDA safety communication, August 2017; Abbott; RAPS
February 2024, ransomware
Change Healthcare: claims processing stops across the US
Attackers used a stolen login without multi-factor authentication to enter the systems of Change Healthcare, a large processor of medical claims, and deployed ransomware on 21 February 2024.
Impact
Pharmacies and practices could not process claims for weeks. Data of about 190 million people was affected, a ransom of USD 22 million was paid, and the parent company projected costs of about USD 2.9 billion.
Sources: UnitedHealth Group; Fierce Healthcare; Healthcare Finance News
What a working medical device security approach looks like
Six building blocks that satisfy notified bodies and the FDA and keep devices secure after release.
1
Security risk management linked to ISO 14971
Security risks are assessed in their own process and linked to safety, so every threat is traced to its possible harm.
2
Secure development lifecycle
A process according to IEC 81001-5-1, integrated with software development to IEC 62304.
3
SBOM and component monitoring
A complete software bill of materials and continuous monitoring of every component in it.
4
Secure communication and updates
Authentication, encryption and signed updates for every interface of the device.
5
Coordinated vulnerability disclosure
A public channel for researchers and a process to assess, fix and communicate findings.
6
Documentation for approval
The cybersecurity file that notified bodies and the FDA expect, kept current after release.
How we help
From the first gap analysis to the cybersecurity file for your submission and the process after release.
Regulatory readiness
Clarity on the MDR, the FDA and further rules for your devices.
What we do
- Gap analysis against MDR Annex I and MDCG 2019-16
- Review against the FDA premarket cybersecurity guidance and section 524B
- Roadmap for your next submission
You receive
Gap list, submission roadmap
Product security engineering
Security built into your device and its ecosystem.
What we do
- Threat modelling for device, app and cloud
- Security requirements and architecture review
- Security risk assessment linked to ISO 14971
You receive
Threat model, requirements, risk file
Testing and vulnerability handling
Evidence that the controls work, before and after release.
What we do
- Penetration tests of devices, apps and interfaces
- SBOM creation and vulnerability monitoring
- Coordinated disclosure and postmarket process
You receive
Test report, SBOM, postmarket process
Security management and audits
An organisation that supports secure products.
What we do
- ISO 27001 gap analysis and implementation
- NIS2 measures for healthcare entities
- Audit preparation
You receive
ISMS documentation, audit plan
How we work
Step 1
Scope
We agree on the devices, markets and submissions in scope.
Step 2
Assess
Workshops and a review of your design and risk files show where you stand.
Step 3
Build
We create the work products with your engineers, or generate them with AITIGRITY.
Step 4
Prove
Tests, reviews and submission support close the gaps that matter.
Standards and regulations
EU MDR (EU) 2017/745 and IVDR (EU) 2017/746
Require protection against unauthorised access as part of safety and performance (Annex I). MDCG 2019-16 explains what notified bodies expect.
FDA section 524B
Since March 2023, submissions for cyber devices in the US must include a plan for postmarket vulnerabilities, an SBOM and evidence of secure design.
IEC 81001-5-1
The security lifecycle for health software and medical device software, complementing IEC 62304.
ISO 14971
Risk management for medical devices. Security risks with a possible safety impact are part of it.
Cyber Resilience Act and NIS2
Devices placed on the market under the MDR or IVDR are excluded from the CRA, but apps, accessories and software outside these rules can fall under it. NIS2 covers many healthcare providers and parts of the industry.
Related services and modules
The consulting services and AITIGRITY modules medical technology companies use most often.
Not sure where to start?
A short scoping call shows what your next submission needs and which steps come first.
Talk to an expertFrequently asked questions
Does the CRA apply to our medical devices?
Devices placed on the market under the MDR or IVDR are excluded from the CRA. Companion apps, accessories and non-medical software can fall under it. We check this per product.
What does the FDA expect for a connected device?
A plan for postmarket vulnerabilities, a software bill of materials, a threat model and evidence of security testing, as described in its premarket guidance and section 524B.
How do security and safety risk management fit together?
Security risks are assessed in their own process and linked to ISO 14971 wherever they can cause harm. AAMI TIR57 and IEC 81001-5-1 describe how.
Can you help with questions from our notified body or the FDA?
Yes. We prepare the cybersecurity parts of your technical documentation and help you answer reviewer questions.
Where does your product stand?
Tell us about your product and the rule you are facing. You talk to an engineer from the first call.
Cybersecurity consulting and the AITIGRITY platform for connected products and industrial systems.