Skip to main content

Part of Guidance on protecting connected medical devices

Step 3. Apply mitigations to reduce the likelihood of compromise

Current Chapter

Current chapter – Step 3. Apply mitigations to reduce the likelihood of compromise


Exploits based on malicious data can only be successful if the data can reach a vulnerable device.  If untrusted data is prevented from reaching a system, then the possibility of malicious content reaching the vulnerable device is lowered, and so the risk from malicious content is reduced.

Routes by which malicious data could reach unpatched software include:

  • email
  • web browsing
  • file shares
  • network ports
  • installation of non-authorised software
  • removable media

We recommend that these routes be eliminated for all medical devices. Devices should not be used for end-user activities (such as email or web browsing), and data flows to medical servers should be carefully considered and constrained wherever possible.

Data and files sourced from the Internet should be treated as untrusted, even if originating from a known third party. Data retrieved from enterprise storage services should also be treated as untrusted if its source was originally external.


3.1 Prevent access to untrusted services

Implement technical controls to prevent access to external untrusted services from medical devices and associated workstations. This should include preventing access to external email and preventing the device from browsing the internet unless necessary and permitted by the device manufacturer. These controls will not be effective if they are not technically enforced.

By preventing access via email and the web browser to untrusted content and services, 2 of the most likely attack vectors for client systems are removed.


3.2 Prevent or reduce access to removable media

Access to removable media should be prevented as far as practicable, as it can be used to transport untrusted content. Access to removable media and any connected devices can be controlled through numerous mechanisms. However, as USB ports and CD drives may be part of normal or maintenance/service operations, they should never be altered without clear guidance and approval from the manufacturer of the specific medical device. 

It's also important to consider devices such as smartphones and tablets, which can  be used to transfer data, and, if compromised, can also launch attacks against devices they are connected to.

When considering mobile devices, it may be useful to see what the NCSC considered whilst choosing a product.


3.3 Constrain network access

When a medical device is connected to untrusted networks via its network interfaces, for example, to allow access by remote workers, it's directly exposed to external network-borne attacks. The only technical mitigation available would be to disable/remove all network access from the device, effectively making them stand-alone devices. This is clearly only possible if the applications on this device do not require access to network services.

Hence, the device could be connected to a physically or logically separate network which  only has similar medical applications and their required services on it, which has no direct external connectivity through which malware could get in.

In some cases it may be necessary for the medical device to connect directly to the internet, such as those that are used in patients homes. However, where this is the case, there must be sufficient security built into the connection, taking advantage of VPS/TLS technologies. 
Section 3.5 below details more about how to manage the need for remote access.


3.4 Remove unnecessary services

Non-medical devices should be checked to ensure that they only offer the services required. Those services which are not required to support the business function of the connected medical device should be removed or disabled permanently. 


3.5 Constrain remote access

To reduce the attack surface, medical devices should not be exposed to the wider network. Applying network segmentation techniques using intrusion prevention systems and application firewalls can be used to help defend against attacks and prevent lateral movement of an attack if your network is compromised. 

However, some medical devices will send diagnostic information back to the manufacturer to provide protective monitoring. The ports, protocols and application services needed to achieve this, and the actual data that is being gathered, needs to be fully understood and risk assessed and where necessary additional security controls applied. 

Many manufacturers will provide remote engineering and maintenance support which will require them to access the medical device directly via a VPN. Where this is in place, organisations need to ensure relevant controls and assurances are in place before such connections are established – such as MFA, time-bounded/scheduled sessions and set IPs.

Helpful advice and guidance on designing network architectures and managed privileged access can be found on the NCSC website:

Network architectures

Use privileged access management


3.6 User management

User accounts need to be managed appropriately. This means they need to be available for every user with a need to use the system they concern, and they need to allow the user to do their job. Past this, they need to restrict the user’s permissions so that they can’t do anything they shouldn’t. Shared accounts must not be used. 

Accounts need to be managed throughout their lifecycle too. For example, it’s important to delete them as staff leave the business or change jobs.


3.7. Medical device service contract

Medical devices that are covered by a service contract are more likely to be maintained with the latest updates than a device that is not tied to a specific support package.

As medical devices linked to a maintenance contract are more likely to receive patches following a vulnerability, consideration should be given to ensuring an appropriate service contract is put in place with the manufacturer or their agent during the procurement stage.  

Where this is not necessary or not possible, a suitable team within the organisation should be identified as able to undertake this responsibility – such as clinical engineering or scientific computing departments.


Last edited: 20 December 2022 4:38 pm