Medical Device Cybersecurity: Architecture, Best Practices & Protocols

Medical device cybersecurity protects medical equipment, software, connected systems, and patient data from unauthorized access or disruption. It applies to connected patient monitors, infusion pumps, imaging systems, diagnostic equipment, wearable devices, and software that qualifies as a medical device. The work goes beyond installing security software. Manufacturers need secure product designs and update processes, while healthcare providers must control network access, monitor devices, and plan for downtime. 

This guide explains medical device cybersecurity architecture, communication protocols, practical security controls, testing methods, and regulatory requirements across the device lifecycle.

What is Medical Device CyberSecurity?

Medical device cybersecurity is a process that secures medical devices, or their hardware, software, firmware, communications and network infrastructure, against cyber attacks that could impact the safety, security, or operation of the device.

Even if a medical device performs its intended clinical function properly, it can have security vulnerabilities. For instance, a pump might have an exposed service, an outdated software element or an insecure remote maintenance interface. Those weaknesses may pose risks which are not apparent during routine clinical use.

There are several related medical device cybersecurity domains:

• Security of devices: Security of firmware, operating systems, applications, hardware interfaces and internal components.
• Network security: Regulating the ability of the device to connect to hospital networks, external systems, and cloud-based services.
• Application and data security: Ensuring that medical data, device settings and application functions are not accessible to unauthorized parties.
• Product security: Integrating security into the product development, testing, release, servicing and vulnerability management lifecycle.
• Operational security: Assistance to healthcare organizations in the setting up and configuration, monitoring, maintenance, and secure operation of devices.

The goal is to lower cybersecurity risks, while keeping clinical function and access to care intact. Security measures should not only take into consideration the usage of the device, but also its users and the consequences of its absence.

In the guidance on cybersecurity in medical devices published in February 2026, the US Food and Drug Administration (FDA) considers these issues. The guidance addresses design that is relevant to security, labelling, quality management, and information for premarket submissions.

Which Medical Devices Need Cybersecurity Protection?

There are a number of medical technologies that have cybersecurity implications. The appropriate controls are based on the connectivity, software, use of the application, its architecture and the potential impact of compromise.

This list is not a statement that every product has the same regulatory classification or obligations. Manufacturers must assess the specific product and the rules that apply to it.

Connected medical apps can pose cybersecurity risks, requiring assessments of the device, local interfaces, configurations, and connected systems.

What Are the Most Common Medical Device Cybersecurity Risks?

Medical device vulnerabilities can arise either during product development, through third-party software, from insecure configurations, or from changes in the environment in which the device is used.

1.Outdated software and firmware

Devices can operate with known vulnerabilities in their operating systems, libraries, firmware or applications. Without a manufacturer's support, it may be difficult or impossible to get a security fix.

Manufacturers need to be up to date with software versions and support timelines. Healthcare organizations should be aware of the devices that known vulnerabilities impact, and coordinate with the manufacturer to identify safe mitigations.

2.Weak authentication and excessive privileges

Uncontrolled service accounts, unnecessary administrator privileges, default passwords, and shared accounts may lead to unauthorized access by other users to the device or its management functions.

No more access than is necessary for the role of each user and system. Where possible, service credentials should be unique, protected, rotated as necessary, and eliminated when no longer needed.

3.Insecure communication protocols

A protocol might not be robust enough on its own to provide adequate protection in a given device. An unencrypted or improperly authenticated communication can allow for the exposure of information or for unauthorized changes.

Don't assume that a protocol is secure just because it is widely used. They must confirm the particular implementation, backed security features, configuration and network controls.

4.Vulnerable remote access and service interfaces

While exposed remote access services provide more points of entry, remote maintenance can also be used to troubleshoot and update devices.

Only authorised personnel should have remote connections, they should only be established for the required systems, they should be logged and they should be disabled if not required. Access should be temporary and have a clear approval process and a time limit.

5.Third-party software and supply-chain vulnerabilities

Medical devices often employ operating system software, libraries, commercial software and open-source software developed by other entities.

A new vulnerability that is discovered in one of these dependencies may impact several products. Manufacturers benefit from having an accurate software bill of materials (SBOM), supplier communication and a documented vulnerability assessment process to help identify impacted versions, and plan remediation.

6.Insecure cloud services and APIs

The connected devices can rely on cloud storage, application programming interfaces (APIs), device-management services or remote monitoring platforms.

Device data and management capabilities can be at risk due to poor authorization checks, exposed credentials, too many API permissions, and incorrect cloud configurations.

These supporting services should be considered for the security assessment if they are a part of the device system or are part of its intended operating environment.

7.Wireless communication weaknesses

Wireless connectivity interfaces such as Wi-Fi and Bluetooth can make devices vulnerable to unauthorized pairing or insecure configuration or to attacks on the wireless connection.

Manufacturers should provide appropriate authentication and encryption, restrict pairing and access to approved systems and keep a record of the security configuration supported. Wireless controls should be tested with the actual implementation of the device.

8.Legacy medical devices

Medical devices with older operating systems or software-dependent components may continue to be clinically useful even if those operating systems or software components are past their end of support date.

They may not be immediately replaceable due to cost, clinical validation, compatibility, procurement or operational reasons. Healthcare organisations should document risks and apply controls such as network isolation, restricted access, enhanced monitoring, and controlled maintenance until remediation or replacement.

These controls may be effective at minimizing exposure, but do not provide complete protection from vulnerability.

What Does Medical Device Cybersecurity Architecture Look Like?

Medical device cybersecurity architecture is the design of the device and how it relates to the environment around it. It defines the components to be protected, the systems they interact with, the trusted and untrusted boundary, and the controls used to protect it.

Architecture that is useful should be representative of the product and the product's use environment. It should provide a description of the device, external interfaces, management systems, network connections, cloud dependency and update mechanism (if applicable).

Key layers of a medical device cybersecurity architecture

The controls should be selected according to the product's risks and intended use. A particular mechanism, such as hardware-backed key storage or mutual TLS, may be appropriate for one design but unavailable or unsuitable for another.

1.Define the device's trust boundaries

Components use a trust boundary to partition those that have different trust assumptions. For instance, a patient monitor can be linked to a hospital network, a central monitoring server and a remote service platform. Every connection is a possible boundary and needs to be understood and protected.

The architecture should indicate who starts communication, what information is shared, what services are exposed, and what an attacker could do in case of a compromise of one of these.

2.Separate device functions and management access

The access paths to clinical functions are not necessarily the same as the access paths to administrative functions. Provide and manage communication between devices and remote service without relying on the management interface.

Access to the administration should only be given to those that are authorized. Remote support should never be a "backdoor" from an external network to a clinical area.

3.Protect the device's software and firmware

The device should have controls on it to prevent unauthorized software and firmware changes. This may involve secure boot, code signing, integrity checks, limited debug access, and tamper-resistant storage of cryptographic keys, among other other features depending on the design.

Update mechanisms need to check the authenticity and integrity of the update package. In addition manufacturers must consider the update process itself – interrupted installation, failure recovery, rollback behaviour, and potential impact of update on clinical functionality.

4.Design for monitoring and recovery

Architecture should account for what happens when the device or its connected systems are under attack or become unavailable.

Manufacturers decide which security events can be recorded, how logs can be accessed for investigation, and what happens if the network, cloud service, or authentication service is unavailable.

The recovery procedure must ensure patient safety. While automatic blocking of a connection or deactivation of a device might alleviate one security concern, it might create another clinical concern—responses need to be tailored to the device and its intended setting.

5.Document external interfaces and dependencies

Security architecture should enable communication with external programmers, mobile applications, cloud services, clinical systems, and supplier-managed platforms (if applicable).

Document each interface’s function, data flow, authentication, supported protocols, network access, and security controls to give engineering, security, regulatory, and clinical teams a shared system overview.

What Medical Device Cybersecurity Protocols exist?

There are several different communication protocols used in medical devices, depending on their clinical applications, connectivity, and environment. Some protocols involve trading clinical data, others enable wireless communication, while others help to secure data transmission or verify users and applications.

One major difference is that a communication protocol does not necessarily imply security in a medical device. Security relies on the implementation and configuration of the protocol, as well as on whom they are authenticated, what access they will have and how keys and credentials will be managed.

Important medical device communication and security protocols

These protocols are not equally relevant to every medical device. The manufacturer's interface documentation and the healthcare organization's network design should establish which ones apply.

A.TLS and HTTPS: Protecting Data in Transit

When properly configured, Transport Layer Security (TLS) secures network communications from eavesdropping and tampering. For securing web traffic and API requests, HTTPS is using TLS. Manufacturers should ensure applications have appropriate authentication and authorization requirements enforced and maintain certificates/cryptographic keys and use supported secure configurations. Encrypting does not stop unauthorized use. 

B.HL7 FHIR, OAuth, and SMART on FHIR

FHIR is not a security protocol, but it facilitates exchange of Healthcare Data. Delegated authorization is supported by OAuth 2.0, user authentication by OpenID Connect and secure access to healthcare applications by profile definition (SMART on FHIR). Implementations should ensure that they use suitable authentication, limited API permissions, secure communications and auditing.

C.DICOM Security for Medical Imaging

Digital Imaging and Communications in Medicine (DICOM) allows imaging devices, workstations, and picture archiving and communication systems (PACS) to communicate with each other. Its security features are implementation and configuration dependent. Check the manufacturer's DICOM Conformance Statement and confirm security profiles, secure transport and audit controls. Communication with DICOM is not inherently encrypted. 

D.Bluetooth, Wi-Fi, and Connected Medical Devices

The connected medical devices communicate with the mobile app and clinical systems or with the cloud through Bluetooth, WiFi or cell networking. The security measures shall include an appropriate encryption, authenticated pairing, restricted access, protected keys, and secure configuration. Manufacturers need to test for connection handling and unauthorized access, and healthcare organizations must configure their wireless networks to suit their device needs.

E.Which is the most secure protocol for teams to use?

Select protocols depending on what data is being transmitted, the capabilities of the devices, the environment in which the devices are operating, and the risk of compromise. Implementing tests, not protocol specifications, to verify authentication, confidentiality, integrity, and access controls. If legacy devices do not have the newest security devices, consider compensating controls like network segmentation and access limitations, as well as documenting any remaining risks.

What Are the Best Practices for Medical Device Cybersecurity?

Medical device cybersecurity demands manufacturers to embed security into product design and continue to keep it secure following release. Healthcare organizations need to ensure the security of connected devices, control access and be ready for events that might impact patient care.

Best Practices for Medical Device Manufacturers

1. Security in Design: Identify the security needs up front, perform threat modelling, capture trust boundaries, and evaluate overall impact on patient safety and device effectiveness.
2. Apply risk-based controls: Rank vulnerabilities by exploitability, exposure of device architecture and potential clinical consequences. Minimize attack surface by turning off unneeded services, limiting interfaces, and use of insecure default configurations.
3. Safeguard identities and updates: Use proper authentication, least-privilege access, protect credentials, and secure software & firmware updates. Verify integrity, installation and recovery tests.
4. Maintain software inventories: Ensure software bill of materials (SBOM) is kept up to date, monitor third-party components and support lifecycle, and evaluate newly disclosed vulnerabilities for affected software.
5. Test and document security: Conduct and record static and dynamic analysis, vulnerability scanning, fuzz testing, software composition analysis and penetration testing. Keep architecture diagrams, risk assessments, test reports, remediation records and appropriate cybersecurity labeling.
6. Manage vulnerabilities after release: Set up coordinated disclosure practices, keep track of new vulnerabilities, evaluate disclosed vulnerabilities, release patches when required, and keep records of what has been remediated and when across the life cycle of the device.

Best Practices for Hospitals and Healthcare Organizations

1. Keeping a device inventory: Keep track of device locations, manufacturers, software versions, network connections, responsible teams and support status for vulnerability assessments and incident response.
2. Manage network access: Isolate medical device networks, limit unneeded connections, control administrative access, and ensure remote servicing is done via authorized, monitored connections.
3. Coordinate updates and monitoring: Work with manufacturers and clinical engineering teams to assess updates before deployment. Monitor available logs and network traffic for suspicious activity, and document compensating controls when immediate patching is not feasible.
4. Prepare for Incidents and Downtime: Develop incident response plans, escalation routes, safe clinical work arounds, device isolation decisions, recovery checks, and maintain patient care during incidents and downtime.
5. Integrate security into procurement: Assess security characteristics of devices, software support periods, update commitments, known vulnerabilities, SBOM availability (where relevant), remote access, and supplier responsibilities prior to device acquisition of connected medical technology.

These practices help manufacturers and healthcare organisations manage cybersecurity, protect patient data and device functionality, and reduce operational risks.

What are the Standards and Regulations that apply to Medical Device Cybersecurity?

There are a number of different aspects to this, and the requirements for medical devices depend on product, intended use and target market. Manufacturers need to differentiate between binding regulations and voluntary standards and regulatory guidance.

FDA Cybersecurity Guidance and Section 524B

On February 3, 2026, the FDA released guidance on cybersecurity practices for secure device design, test, labeling, and premarket submission. Section 524B establishes cybersecurity requirements for qualifying devices, including SBOMs, vulnerability management, and security updates. Requirements apply to applicable: 510(k), PMA, De Novo, PDP, and HDE submissions.  FDA cybersecurity guidance and FAQs.

The FDA Quality Management System Regulation (QMSR)

Effective February 2, 2026, FDA’s QMSR incorporates ISO 13485:2016 into 21 CFR Part 820, requiring manufacturers to integrate cybersecurity risk management into design, testing, supplier management, and corrective actions. FDA QMSR.

IEC 81001-5-1 and ISO 14971

IEC 81001-5-1:2021 covers health software cybersecurity during the development, testing and maintenance phases throughout the life cycle of health software. The ISO 14971 standard outlines medical device risk management, and it also covers a risk evaluation process for safety concerns resulting from cybersecurity problems. They are not applicable for all devices, nor for all regulatory situations.

NIST Cybersecurity Resources

The NIST SP 800-213 series and NISTIR 8259 series are guidance for the security requirements of IoT devices and their manufacturer responsibilities, respectively. These resources may be used in product design and security planning, but are not a requirement for all medical devices.

European Union Regulations and Guidance

Medical devices sold in the EU must comply with the applicable MDR or IVDR requirements.The cybersecurity guidance from the European Commission (MDCG 2019-16 Rev.1) covers security throughout the lifecycle of a device. For hospitals and other healthcare providers looking at adopting connected technologies, there are further guidelines that can be found in ENISA's 2026 healthcare procurement guidelines.

HIPAA and Healthcare Cybersecurity

Under HIPAA's Security Rule, covered entities and business associates are required to implement reasonable security measures to protect ePHI. It is not a medical device cybersecurity certification that applies to all devices. Manufacturers and health care providers will have to review their respective responsibilities individually. HHS cybersecurity guidance.

Manufacturers need to check the latest regulations for each of their markets, separating those that are mandatory from those that are recommended.

What Documentation should Medical Device Manufacturers Keep?

Cybersecurity documentation helps manufacturers explain device design, assess risks, verify controls, and manage post-release vulnerabilities.

The content of the submission will vary based on the device, the risks, and regulatory requirements applicable to the device. The FDA doesn't specify 14 distinct files for each medical device. Here are some categories to help organize supporting evidence:

There is overlap in some of these categories. Cyber risk assessments can be included in risk reports, while penetration testing and retesting evidence can be documented in verification records.

The key is "traceability. A reviewer / internal security team should be able to trace an identified risk through the selected mitigation, supporting testing, final disposition and post market management plan.

For qualifying cyber devices, manufacturers should also ensure their submissions address the applicable statutory requirements under Section 524B.

How Should Medical Device Cybersecurity Testing Be Conducted?

Medical device cybersecurity testing verifies security controls and identifies exploitable vulnerabilities in real-world operating environments.

Testing should accurately reflect the architecture, interfaces, software dependence and potential patient safety implications of the device.

Vulnerability scanning and software analysis

The vulnerability scanning process is used to determine if known vulnerabilities exist in exposed services, operating systems, applications, and software components. Static analysis and dynamic analysis can be used to detect issues in software source code or running software.

Software Composition Analysis uncovers sensitive third-party components. These activities can give broad coverage, but they do not indicate whether a weakness is exploitable in a given device or whether multiple weaknesses can be linked.

Fuzz testing and Interface testing

Fuzz testing feeds badly formed, unexpected, or odd inputs at software interfaces to look for software errors and vulnerabilities in input handling.

Medical device interface testing covers communication services, APIs, file formats, device management, and connected clinical systems. It is important to test carefully, to avoid unacceptable clinical risks and damage to the equipment.

Penetration testing

The penetration test tries to determine if the tester can take advantage of vulnerabilities in the device or network. Assessment should employ a specific domain and process suitable to the architecture of the device and threat that was identified.

Reports should include the following: Testing environment, length of testing, testing techniques, test results, and the manufacturer's evaluation of un-solved or deferred problems. The test should also involve checking if the vulnerabilities can be combined to create a more severe attack chain.

The Medical Device Innovation Consortium (MDIC) released its resource on validating medical device cybersecurity through penetration testing in June of 2026 which offers additional guidance on scoping, supplier selection, execution, risk disposition and reporting.

Retesting and risk-based remediation

After remediation, retesting should determine the effectiveness of remediation. The manufacturer should also evaluate if the change will create other security, safety or intended functionality concerns.

Not all findings are created equal and all remediation actions are not. Decisions should be based on the evidence that is available and the risks involved with leaving the vulnerability in place and implementing the proposed fix.

The resulting answer should be written down for security, quality, engineering and regulatory teams to understand the decision and why.

How Is Medical Device Cybersecurity Managed After Release?

Cybersecurity tasks don't cease once the device is on the market. New vulnerabilities can occur in software dependencies, new attack paths can be found by the attackers, and components or software products may have to be changed by the manufacturers.

FDA's Postmarket Management of Cybersecurity in Medical Devices guidance offers recommendations for postmarket management of cybersecurity vulnerabilities in marketed and distributed devices.

The following are some activities that should be part of a practical postmarket process.

• Vulnerability monitoring: Keep an eye on the databases, security advisories, supplier notices, researcher and customer reports of vulnerabilities.
• Impact assessment: If software or devices are affected, determine if the vulnerable component exists, consider the degree of exposure and determine the impact on the safety and effectiveness of the device.
• Risk-based prioritization: Take into account exploitability, exploitation seen in the wild, mitigations available, functionality of device, clinical impact, and time required to implement a safe repair.
• Remediation and verification: Develop patches, updates, or other mitigations as appropriate. Verify the change and evaluate its impact before release.
• Customer communications: Inform impacted users on products affected, risks identified, interim actions and how remediation will be rolled out.
• Continuous improvement: Analyse the incidents, the test results and the vulnerability trends to enhance the security of the product and future development.

Manufacturers of qualifying cyber devices must meet Section 524B requirements for vulnerability monitoring, cybersecurity maintenance, and software updates.

What Are the Important Medical Device Cybersecurity Developments in 2026?

Several developments published in 2026 are relevant to medical device manufacturers, healthcare security teams, and organisations procuring connected medical technology.

• February 3, 2026: FDA updated its premarket cybersecurity guidance

This final guidance replaces the one issued in June 2025, entitled Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. New submissions from manufacturers should be based on the latest document and not on older checklists.

• February 2, 2026: QMSR took effect

The FDA's Quality Management System Regulation entered into effect and adopted and referenced ISO 13485:2016. Any activities that are cyber related should be coordinated with relevant quality management activities, such as risk assessment, design and development, changes, verification, corrective action, etc.

• April 2026: NIST updated its IoT manufacturer guidance

NIST published NISTIR 8259 Rev. 1 on April 9, 2026. It outlines IoT manufacturers’ responsibilities for developing and managing connected products throughout their lifecycle.

• April 22, 2026: MITRE published new risk and SBOM resources

MITRE published two relevant resources: Cybersecurity Risk Analysis for Medical Devices in the Era of Evolving Technologies and Considerations for Managing Challenges in Software Bill of Materials (SBOM) Data Normalization.

The first one focuses on security aspects of Cloud Computing, AI/ML, and Post Quantum Cryptography. The second explores the issues with conflating SBOM data and consistent component identification. They both help to reinforce the importance of evaluating the risks of new technologies and having usable data on inventory of software. They're technical resources and not new regulations.

• June 29, 2026: MDIC published penetration-testing guidance

The Medical Device Innovation Consortium released guidance on how to validate medical device cybersecurity using penetration testing. It covers scoping, assessment implementation, supplier choice, findings, and reporting. It can be utilized by the manufacturers to enhance the structure and utility of penetration testing, together with relevant FDA cybersecurity.

• July 22, 2026: ENISA published healthcare procurement guidelines

A set of procurement guidelines for hospitals and healthcare providers were issued by the European Union Agency for Cybersecurity. The recommendations focus on enabling organisations to integrate cybersecurity into their procurement processes and supply chain requirements. This is especially true when hospitals require better information regarding device support, maintenance, software requirements and vulnerability management.

• October 2026: Healthcare incident preparedness remains important

On October 9, 2026, HHS ASPR TRACIE updated their topic collection on cyber security. The focus is on incident response, patient care continuity and downtime planning.

The device operator's takeaway is to get ready for a device or connected system getting unavailable. Incident procedures should clarify who determines when to isolate, how to keep patients safe while being cared for and how to ensure devices are safe for use.

These developments do not all carry the same regulatory weight. Manufacturers should distinguish binding legal requirements and applicable regulations from voluntary standards, technical research, and industry recommendations.

Medical Device Cybersecurity Checklist

Take this checklist to start a device security review, external device procurement or internal gap analysis. The depth and complexity of each activity should be based on the device risk and properties.

1.Architecture and design

• The team documents the device's components, interfaces, and communication paths. 
• The team identifies trust boundaries and external dependencies.
• The team models threats covering relevant attack paths and potential clinical consequences.
• The team assesses authentication, authorization, and communication protection.
• The team restricts unnecessary services, interfaces, and privileges.
• The team assesses software and firmware update mechanisms.

2.Protocols and network access

• We document supported protocols and their security configurations. 
• We define certificate and key management processes where applicable.
• We limit network access to necessary destinations, ports, and services.
• We restrict wireless pairing and access appropriately.
• We include external APIs and cloud services in the assessment.

3.Testing and documentation

• Cybersecurity risks have been assessed and linked to relevant controls.
• SBOM information is available where required or appropriate.
• Software support and end-of-support information have been assessed.
• Testing covers the device's relevant attack surface and security controls.
• Findings have documented remediation decisions and retesting results where applicable.
• User-facing security information and postmarket procedures are available.

4.Operations and postmarket security 

• The team maintains the device inventory and software information. 
• The team defines vulnerability monitoring and risk assessment responsibilities.
• The team documents patch approval, validation, and deployment procedures.
• The team controls and reviews remote support access.
• The team tests incident response and clinical downtime procedures.
• Manufacturers and healthcare organisations know their respective responsibilities.

This checklist does not establish regulatory compliance by itself. It should be used alongside applicable FDA requirements, market-specific regulations, recognised standards where relevant, and the manufacturer's documented risk management process.

Is Your Medical Device Secure?

Check your medical device security risks and find the right steps to protect patient data and meet cybersecurity requirements.

Speak with Our Experts →

Conclusion

Designers must incorporate cybersecurity into the architecture, communication interfaces, software dependencies, testing, and postmarket support of the medical device. Secure protocols, accurate SBOMs, and network isolation cannot replace proper authorization, vulnerability assessments, or support for outdated devices.

Manufacturers should make sure to set security requirements that are traceable and keep records of controls for the risks identified. Healthcare organisations must ensure accurate device inventories, limit unnecessary communication, communicate with clinical teams when they make changes, and be ready to handle medical device cybersecurity incidents that may impact care.

The first step is to have a clear overview of the device and all systems it relies on. From there the manufacturer and healthcare provider can determine which controls to implement and how well they are working in order to establish who will be responsible for maintaining security during the service life of the device.

FAQ

1.What is the main objective of medical device cybersecurity?

To minimize security risks that might affect the safety, effectiveness, availability, integrity, or confidentiality of medical devices. Security controls should facilitate the device's intended clinical use.

2.What is the difference between medical device security and hospital network security?

Medical device security targets the actual product, software and firmware, interfaces, credentials, update processes, and services. Hospital network security is about the environment in which devices are used, such as network segmentation, access controls, monitoring and incident response. These are both key to risk management in a connected healthcare landscape.

3.What do medical device cybersecurity professionals commonly use to secure devices?

Examples of such technologies are TLS, HTTPS for secure communication; HL7 v2, FHIR for healthcare data exchange; DICOM for medical imaging; Bluetooth or Wi-Fi for device connectivity. Some connected-device architectures may choose to use MQTT. Depending on the protocol implementation and security requirements of the device, the proper controls are applicable. 

4.Does the FDA require cybersecurity testing for medical devices?

Currently, FDA guidance states that cybersecurity testing and documenting is appropriate for devices with cybersecurity risks. Evidence is dependent on the device, risks identified and the applicable submission pathway. Penetration testing is not the sole method of the overall testing approach, but just one of the many important tests for security analysis and verification.

5.What are the best ways for healthcare organisations to deal with unsupported medical devices?

Organisations should assess affected devices, reduce risks, and plan for replacement, as compensating measures cannot eliminate vulnerabilities.

6.How often should medical devices undergo cybersecurity testing?

The best frequency of testing doesn't apply to all devices. Testing should align with the device’s lifecycle and risks, and be repeated after significant changes or newly identified vulnerabilities. Manufacturers need to record the basis for their testing plans.