CyberSecurity in Medical Devices

Cybersecurity in Medical Devices: Requirements, Risks & Best Practices

Connected medical devices bring clinical benefits and new security risks. This guide explains what the FDA expects manufacturers to do about cybersecurity and medical devices across the device lifecycle: how to build security into quality systems, design for it, be transparent about it, and document it in premarket submissions.

Cybersecurity in Medical Devices

As medical devices increasingly incorporate software, wireless connectivity, and integration with broader health IT systems, cybersecurity has become a critical part of device safety and effectiveness. This connectivity has created new attack surfaces, making devices more vulnerable to threats that can directly or indirectly affect patient care.

Cyber incidents such as ransomware attacks and the exploitation of software vulnerabilities have already disrupted hospital operations and compromised device functionality. In some cases they have delayed diagnosis or treatment and put patients at risk.

To manage these risks, the FDA expects manufacturers to consider cybersecurity throughout the Total Product Lifecycle (TPLC), from design and development through postmarket surveillance. The relationship between cybersecurity and medical devices is now treated as a core safety issue, not a side concern for IT teams.

The regulatory backdrop:

• Section 524B of the FD&C Act: Added by the Consolidated Appropriations Act, 2023, it took effect on March 29, 2023. It sets cybersecurity requirements for "cyber devices," which are devices that contain software, can connect to the internet, and have technological characteristics that could be vulnerable to cybersecurity threats. Manufacturers of cyber devices must provide a plan to monitor, identify, and address postmarket vulnerabilities, and processes that give reasonable assurance of cybersecurity. They must also provide a software bill of materials (SBOM).
• FDA premarket cybersecurity guidance: The FDA's guidance on cybersecurity in medical devices applies broadly to devices that have software, including devices that don't need a premarket submission, such as 510(k)-exempt devices. The FDA has revised the guidance several times, most recently in early 2026 to align it with the Quality Management System Regulation (QMSR). The revised version supersedes the June 2025 version, and its title now refers to "Quality Management System Considerations."

1. Cybersecurity - Integration with Quality System Regulation:

Cybersecurity is part of the quality system, not a separate IT activity. The link between cybersecurity and medical devices runs through design controls, risk management, and software validation, not through a bolt-on security review at the end. Since February 2, 2026, Part 820 has been the QMSR, which incorporates ISO 13485:2016 by reference. The FDA's updated guidance now points to ISO 13485:2016 subclauses instead of the old Part 820 sections. Software validation falls under subclause 7.3.7 and risk management under subclause 7.1, so software device manufacturers may need to establish cybersecurity risk management and validation processes.

To reduce vulnerabilities and support compliance, the FDA encourages using a Secure Product Development Framework (SPDF). An SPDF integrates security throughout the product lifecycle, from design through decommissioning. It helps minimize the likelihood and impact of cybersecurity risks, and it may prevent postmarket design changes when connectivity features are added or new vulnerabilities are discovered.

Medical Device Cybersecurity Strategies

An effective program combines nine connected strategies, covered in turn below. They span the lifecycle: threat modeling, risk assessment, interoperability, third-party software, the SBOM, unresolved anomalies, TPLC risk management, security controls, and testing.

a. Threat Modeling

Threat modeling is a proactive technique for identifying and mitigating cybersecurity threats during design. It lets developers visualize potential attack vectors, assess system-level vulnerabilities, and define countermeasures. Common approaches include data flow diagrams, STRIDE, and attack trees. Treat the model as a living document, and update it as the design, connections, or threats change. It feeds directly into security requirements and the architecture views described later.

b. Cybersecurity Risk Assessment

Security risk assessments must be fully integrated into the overall quality system. They should cover risks beyond direct patient harm, such as data breaches and system availability problems. Security risk management should connect to, but not be replaced by, your safety risk management process. The FDA recommends established frameworks, including AAMI TIR57, ANSI/AAMI SW96, and AAMI TIR97, to manage risk across the device lifecycle from development through post-market.

c. Interoperability Considerations

Interoperability between devices and other IT systems creates specific security concerns.

• Evaluate all interoperable functions, such as connections to electronic health records (EHRs), smartphones, and cloud platforms.
• Use risk assessments to determine how each connection could expose the device to threats.
• Implement security controls that allow safe data exchange without impeding interoperability or usability.
• Document interfaces, ports, and protocols, since this information also supports labeling and architecture views.

d. Third-Party Software Components

Manufacturers are responsible for identifying, validating, and managing the risks from third-party components, including commercial, open-source, and off-the-shelf software. These components should be treated as part of the device's design controls, with traceable supplier oversight. Plan ahead for patching or replacing software that is nearing end of support.

e. Software Bill of Materials (SBOM)

An SBOM lists the software components and dependencies in a device. It plays a critical role in identifying affected products when a vulnerability is disclosed.

• Manufacturers of cyber devices must include a machine-readable SBOM in premarket submissions.
• It should list component names, versions, and suppliers, and be paired with an assessment of known vulnerabilities in those components.
• The FDA also recommends information on each component's support status and end-of-support date.
• Keep the SBOM current when components change, and use it to support timely risk response and remediation.

f. Security Assessment of Unresolved Anomalies

Not every software anomaly found during testing can be fixed before release. Manufacturers must assess the security implications of unresolved anomalies to decide how they affect device safety and effectiveness. Document the assessment and the rationale for releasing with the anomaly still open.

g. TPLC Security Risk Management

Security risk management does not end at release. Manufacturers must continuously monitor emerging threats, reassess vulnerabilities, and update security controls. This includes revisiting threat models, SBOMs, and risk assessments as part of ongoing vigilance.

For cyber devices, Section 524B requires a postmarket plan to monitor, identify, and address vulnerabilities, including a coordinated vulnerability disclosure process. It also requires the ability to provide updates and patches, both on a regular cycle and out of cycle for critical vulnerabilities. Some vulnerabilities may also trigger reporting obligations under 21 CFR Part 806, so build these decisions into your procedures.

h. Implementation of Security Controls

Security controls form the foundation of a resilient device. They may include:

• Authentication and authorization
• Cryptographic data protection
• Integrity verification
• Event logging and monitoring
• Secure software updates

Controls should be designed in from the start and matched to the device's risks, then traced back to security requirements and threat models.

i. Cybersecurity Testing

Cybersecurity testing shows the device can withstand real-world threats. It includes:

• Security requirements and threat mitigation: evidence of implemented design inputs, boundary assumptions, and effective risk controls.
• Vulnerability testing: robustness checks, fuzz testing, abuse and misuse scenarios, attack surface analysis, and static and dynamic code analysis.
• Penetration testing: simulated attacks by testers who try to exploit the device.
• Incident response validation: confirming your response process works.
• Verification and validation of implemented security controls.

Testing reports should be included in premarket submissions to support the risk mitigation claims the manufacturer makes.

2. Designing for Security

The FDA evaluates device cybersecurity in premarket submissions based on how well a product meets core security objectives:

• Authentication
• Authorization
• Cryptography
• Code, data, and execution integrity
• Confidentiality
• Event detection and logging
• Resiliency and recovery
• Updatability and patchability

Design considerations must reflect the device's intended use, connectivity, and operating environment. That means identifying all system interfaces and connections, evaluating risks such as those from hospital networks or cloud infrastructure, and building security controls into the design process rather than adding them afterward.

The FDA recommends including security architecture views in premarket submissions:

These views should combine diagrams and explanations that trace security controls to system requirements and threat models. That lets the FDA assess the device's safety and effectiveness from a cybersecurity perspective.

3. Cybersecurity Transparency:

Manufacturers must share enough information for users, system integrators, and healthcare providers to manage risk on their side. This includes:

• Information about known vulnerabilities, and about newly discovered ones through a coordinated vulnerability disclosure process
• A description of communication interfaces and ports
• Use of third-party software, for example through an SBOM
• Update mechanisms and secure configuration instructions

Clear labeling supports secure deployment and maintenance, and helps the device remain resilient through its lifecycle. Insufficient disclosure can lead to a device being considered misbranded.

4. Submission Documentation

The amount of cybersecurity documentation in a premarket submission should reflect the device's cybersecurity risk. Devices with network connectivity, or that integrate into larger systems, generally carry higher risk. They need more robust controls and more supporting evidence. The FDA's guidance has described a tiered approach, with more documentation expected for higher-risk devices, so check the current version for how it applies to yours.

Documentation should include:

• Threat modeling and risk assessments
• A description of the security architecture, including the architecture views
• Evidence of verification and validation of cybersecurity features
• Alignment with design controls under an SPDF

For cyber devices, the submission should also cover the Section 524B elements: the SBOM, the postmarket monitoring and vulnerability handling plan, and cybersecurity labeling. Missing cybersecurity documentation for a cyber device can delay or stall review, so plan this work early.

Medical Device Cybersecurity Best Practices

• Start early. Build security into requirements and architecture at the design stage, not as an add-on.
• Adopt an SPDF. Use a documented framework so security is repeatable across products.
• Integrate with your QMS. Link security risk management to your design controls, supplier controls, CAPA, and change control.
• Keep the threat model current. Revisit it after every significant design, interface, or environment change.
• Manage your software supply chain. Maintain an accurate SBOM, monitor components for new vulnerabilities, and track end-of-support dates.
• Test like an attacker. Combine fuzzing, code analysis, and independent penetration testing.
• Plan for updates. Make sure the device can be patched securely, and define how and when patches will be released.
• Set up vulnerability management. Have a coordinated disclosure policy, a monitoring process, and clear decision paths for reporting.
• Be transparent. Give users the security information they need in the labeling and supporting documents.
• Train your teams. Make sure engineering, quality, regulatory, and service staff understand their security responsibilities.
• Track the standards and guidance. FDA guidance and industry standards are changing, so review them regularly.

Together, these practices show that cybersecurity and medical devices work best as a continuous discipline built into everyday development and quality processes, rather than a one-time checklist item before submission.

Frequently Asked Questions About Cybersecurity in Medical Devices

1. What are the biggest cybersecurity risks for medical devices?

The most serious risks come from connectivity and from software that is not kept up to date:

• Ransomware and other malware: These can disrupt hospital operations, take devices offline, and delay diagnosis or treatment.
• Unpatched vulnerabilities: Known flaws in operating systems and third-party software stay exploitable when a device can't be updated, or when a component reaches end of support.
• Weak authentication and access control: Default or hard-coded passwords, shared accounts, and missing role-based access let attackers or unauthorized users change device behavior.
• Insecure interfaces: Connections to electronic health records, smartphones, cloud services, and hospital networks can expose the device if data exchange isn't protected.
• Insecure update mechanisms: If updates aren't authenticated and verified, an attacker can install malicious code.
• Multi-patient harm: One breach that affects a whole fleet of devices can harm many patients at once.
• Data breaches and lost availability: Exposed patient data and devices that stop working both create safety and privacy problems.
• Supply chain risk: Third-party and open-source components bring vulnerabilities you didn't write.

These risks are a central reason regulators treat cybersecurity and medical devices as inseparable. Manage them through a security risk assessment connected to your ISO 14971 safety risk process. Established frameworks such as AAMI TIR57, ANSI/AAMI SW96, and AAMI TIR97 help.

2. When should cybersecurity be considered during medical device development?

From the very start, and throughout the total product lifecycle. Adding security at the end is costly and rarely effective. Following a Secure Product Development Framework (SPDF) means building security into every stage:

• Concept and requirements: Define the intended use, connections, and use environment, and set security requirements.
• Design: Do threat modeling, choose the architecture, and design controls such as authentication, encryption, and secure updates.
• Development: Manage third-party components. For device software, this fits alongside IEC 62304 activities, including handling off-the-shelf software.
• Verification and validation: Run vulnerability scans, fuzz testing, and penetration testing, and confirm security controls work.
• Release: Prepare the SBOM, labeling, and the postmarket plan.
• Postmarket and decommissioning: Monitor for new threats, issue patches, disclose vulnerabilities responsibly, and plan for end of support.

Cybersecurity work belongs inside your quality system. Under ISO 13485 and 21 CFR Part 820, now the QMSR, it sits in design and development, risk management, purchasing and supplier controls, and change control, and the results go into the design and development file.

Security controls also need to be usable. Login, alert, and update steps that confuse clinicians can create use errors. Include them in usability engineering, with formative evaluation during design and summative evaluation of the final interface.

The guidance applies to every device with software, whatever its medical device classification. Higher-risk and connected devices simply need more evidence.

3. What is the role of an SBOM in medical device cybersecurity?

A software bill of materials (SBOM) lists the software components and dependencies inside a device, including commercial, open-source, and off-the-shelf software. Its main job is speed and transparency. When a vulnerability is announced in a component, you, your customers, and hospitals can quickly see which products are affected.

Key points:

• It is required for cyber devices. Manufacturers of cyber devices must include a machine-readable SBOM in premarket submissions.
• What it should contain: component names, versions, and suppliers, plus support status and end-of-support dates, together with an assessment of known vulnerabilities in those components.
• It must stay current. Update it whenever components change, and keep an SBOM for each released software version.
• It supports quality processes. It backs supplier controls under ISO 13485, the management of off-the-shelf software in IEC 62304 (often called SOUP), and postmarket monitoring.
• It supports transparency. Sharing SBOM information helps users, integrators, and hospitals manage their own risk.

Keep version naming consistent across your SBOM, your labeling, and your GUDID record so each released version can be traced.

4. How does cybersecurity affect medical device FDA submissions?

Cybersecurity documentation is part of the premarket submission for devices with software. Section 524B of the FD&C Act requires manufacturers of cyber devices to provide:

• A plan to monitor, identify, and address postmarket vulnerabilities, including a coordinated vulnerability disclosure process
• Processes that give reasonable assurance the device and related systems are cybersecure, including the ability to deliver updates and patches
• An SBOM

The FDA's premarket cybersecurity guidance, revised in early 2026 to align with the QMSR, describes what to include. In practice this means:

• Threat modeling and security risk assessments
• Security architecture views, such as the global system view, multi-patient harm view, updateability and patchability view, and security use case views
• Evidence of testing, including vulnerability and penetration testing
• Cybersecurity labeling and transparency information
• The postmarket management plan and the SBOM

This applies whether you file an FDA 510(k), a De Novo request, or a premarket approval (PMA) application. Missing cybersecurity documentation can delay or stall review. How much you provide should match the device's cybersecurity risk.

Cybersecurity also affects software documentation. In the FDA's software guidance, the chance that a device can be compromised through weak cybersecurity is one factor in deciding whether Basic or Enhanced documentation applies. For the EU, cybersecurity evidence also belongs in your technical documentation and supports the clinical evaluation report (CER) where safety and performance depend on secure operation.