Medical Device Cybersecurity: FDA Requirements, SBOM, Threat Modeling, and Compliance Guide

Why Cybersecurity Matters for Medical Devices

A connected insulin pump delivers a precise dose of insulin to a diabetic patient. A cloud-based algorithm analyzes a chest X-ray and flags a suspected pneumothorax. A networked infusion system titrates chemotherapy drugs across an entire oncology ward. Every one of these devices depends on software, and every one of them is a potential target for cyberattack.

Medical device cybersecurity is no longer a theoretical concern. It is a regulatory requirement, a patient safety imperative, and an engineering discipline that must be embedded into the entire product lifecycle. When a medical device is compromised, the consequences are not limited to data breaches — they extend to direct physical harm, delayed treatment, and erosion of trust in the healthcare system.

The convergence of several trends has made cybersecurity an urgent priority:

• Increasing connectivity: Modern medical devices connect to hospital networks, cloud platforms, mobile apps, and other devices. Each connection point is a potential attack vector.
• Software complexity: A modern medical device may incorporate hundreds of third-party software components, each with its own vulnerability surface.
• Evolving threat actors: Nation-state actors, ransomware groups, and independent researchers are all actively targeting healthcare infrastructure. The healthcare sector experienced more ransomware attacks than any other critical infrastructure sector in 2024.
• Regulatory enforcement: Both the FDA and EU regulators now treat cybersecurity failures as patient safety failures, with direct consequences for market access.

The Real-World Threat Landscape

The scale of the problem is significant and growing. In 2023, remote code execution and privilege escalation exploits in medical devices surged by 437%. A 2025 industry index found 162 new medical device vulnerabilities in a single year. These are not hypothetical risks — they are documented, exploited, and have caused real patient harm.

• WannaCry (2017): The WannaCry ransomware attack paralyzed 65 hospitals across the United Kingdom's National Health Service. MRI scanners, blood storage refrigerators, and surgical theater displays went offline. Over 19,000 appointments were cancelled. While WannaCry targeted Windows operating systems broadly, its impact on networked medical devices demonstrated how a single vulnerability in underlying software could cascade across an entire healthcare delivery system.

• St. Jude Medical / Abbott Pacemakers (2017): The FDA confirmed cybersecurity vulnerabilities in RF-enabled implantable cardiac pacemakers manufactured by St. Jude Medical (acquired by Abbott). If exploited, the vulnerabilities could allow an unauthorized user to access a patient's device, modify programming commands, cause rapid battery depletion, or deliver inappropriate pacing. The FDA approved a firmware update as a corrective action (recall) affecting approximately 465,000 pacemakers in the United States alone.

• Medtronic MiniMed Insulin Pumps (2019): The FDA issued a safety communication warning that certain Medtronic MiniMed insulin pumps had cybersecurity vulnerabilities that could allow an unauthorized person to change pump settings and control insulin delivery, potentially leading to hypoglycemia or diabetic ketoacidosis — both life-threatening conditions.

• Change Healthcare (2024): The BlackCat/ALPHV ransomware attack on Change Healthcare became the most significant healthcare data breach to date, impacting over 190 million individuals. While Change Healthcare is not a medical device, the attack disrupted claims processing, pharmacy operations, and care delivery across the U.S. healthcare system for months — illustrating how cybersecurity failures in health IT infrastructure cascade to devices and care.

• Johnson & Johnson / Abiomed Heart Pump (2024): The FDA recalled a heart pump controller over cybersecurity concerns, advising users to disconnect the device from their network until a security fix was available. When a life-sustaining device must be disconnected from its network to remain safe, cybersecurity has become a patient safety issue of the first order.

• Contec Patient Monitors (2025): CISA identified vulnerabilities (CVE-2025-0626 and CVE-2025-0683) in Contec imaging systems that enabled unauthorized remote code execution and exfiltration of Protected Health Information. The manufacturer's patch disabled networking entirely — effectively sacrificing device connectivity to address the security flaw.

The bottom line: Among healthcare organizations that experienced medical device cybersecurity incidents, 46% required manual processes to maintain operations, 44% reported delayed diagnoses or procedures, and nearly a quarter (24%) required patient transfers to other facilities. Cybersecurity failures in medical devices are patient safety events.

The Evolution of Medical Device Cybersecurity Regulation

Before diving into current requirements, it helps to understand how we arrived here. Medical device cybersecurity regulation has evolved rapidly:

Year	Milestone
2005	FDA issues initial draft guidance on cybersecurity for medical devices
2014	FDA finalizes "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices" — the first formal premarket cybersecurity guidance
2016	FDA issues "Postmarket Management of Cybersecurity in Medical Devices" — establishing the post-market framework
2017	WannaCry attack demonstrates catastrophic impact on healthcare; Abbott/St. Jude pacemaker recall
2018	FDA releases Cybersecurity Medical Device Action Plan; establishes partnership with DHS for coordinated vulnerability disclosure
2019	MDCG publishes MDCG 2019-16 guidance on cybersecurity for EU medical devices
2021	IEC 81001-5-1 published — first international standard dedicated to health software cybersecurity
2022	Consolidated Appropriations Act, 2023 signed (December 29), adding Section 524B to FD&C Act
2023	Section 524B takes effect (March 29); FDA issues updated final premarket guidance (September 27); RTA enforcement begins (October 1)
2024	NIST CSF 2.0 released; Japan enforces IEC 81001-5-1; multiple high-profile medical device cybersecurity incidents
2025	FDA issues updated cybersecurity guidance (June 27) aligned with QMSR; Illumina $9.8M False Claims Act settlement — first FCA case for medical device cybersecurity (July); DOJ Civil Cyber-Fraud Initiative recovers $52M across nine cybersecurity FCA settlements in FY2025; IEC publishes 81001-5-1 interpretation sheet (December)
2026	QMSR takes effect (February 2); FDA issues Level 2 revised cybersecurity guidance (February 3) replacing June 2025 version with QMSR/ISO 13485 alignment; cybersecurity integrated into harmonized quality system requirements

This timeline illustrates a clear trajectory: cybersecurity has moved from optional best practice to mandatory statutory requirement in approximately a decade.

FDA Cybersecurity Regulatory Framework

The United States has the most prescriptive regulatory framework for medical device cybersecurity in the world. Understanding it requires knowing three layers: the statute (law), the FDA guidance (policy), and the enforcement mechanism (Refuse to Accept).

Section 524B of the FD&C Act — The Statutory Foundation

On December 29, 2022, the Consolidated Appropriations Act, 2023 (the "Omnibus") was signed into law. Section 3305 of the Omnibus — sometimes referred to informally as the PATCH Act, after the earlier standalone bill it was derived from — amended the Federal Food, Drug, and Cosmetic (FD&C) Act by adding Section 524B: Ensuring Cybersecurity of Devices.

The amendments took effect 90 days later, on March 29, 2023. This marked the first time that cybersecurity requirements for medical devices were codified in federal statute, rather than existing solely as FDA guidance recommendations.

Section 524B applies to "cyber devices" — defined as devices that:

1. Include software validated, installed, or authorized by the sponsor as a device or in a device
2. Have the ability to connect to the internet
3. Contain technological characteristics that could be vulnerable to cybersecurity threats

For cyber devices, Section 524B requires the sponsor of a premarket submission to:

Requirement	Description
Post-market monitoring plan	Submit a plan to monitor, identify, and address post-market cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure
Security by design	Design, develop, and maintain processes and procedures to provide reasonable assurance that the device and related systems are cybersecure
Patch and update capability	Make available post-market updates and patches to the device and related systems to address cybersecurity vulnerabilities
Software Bill of Materials (SBOM)	Provide an SBOM, including commercial, open-source, and off-the-shelf software components

Critical distinction: Section 524B is a statutory requirement — it is law, not guidance. FDA cannot waive it. Manufacturers cannot argue that they followed alternative approaches. If your device meets the definition of a cyber device, compliance with Section 524B is mandatory for premarket clearance or approval.

FDA interprets "cyber device" broadly. Any device that contains software, or is software, with connectivity capabilities — including Wi-Fi, Bluetooth, or any network interface — is considered a cyber device whether or not it is actively network-enabled in clinical use. The FDA has also expanded the scope of its cybersecurity guidance to include CBER (Center for Biologics Evaluation and Research) submission types and combination products, not just CDRH device submissions.

Post-market enforcement under Section 301(q). Failure to maintain cybersecurity measures after market authorization can now result in violations under Section 301(q) of the FD&C Act, which classifies such lapses as prohibited acts. This means post-market cybersecurity is not merely a best practice — it carries independent legal enforcement authority beyond the premarket RTA mechanism.

FDA Guidance: "Cybersecurity in Medical Devices" (September 2023 / June 2025)

The FDA issued the final guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" on September 27, 2023. This guidance superseded the 2014 cybersecurity guidance and provided detailed recommendations on what manufacturers should include in premarket submissions to satisfy both the Section 524B statutory requirements and the FDA's expectations for device safety and effectiveness.

On June 27, 2025, the FDA issued an updated version of this guidance incorporating select updates to align with the Quality Management System Regulation (QMSR) that harmonizes FDA's quality system requirements with ISO 13485.

On February 3, 2026, the FDA issued a further revised version — a Level 2 update under 21 CFR 10.115(g)(4) — superseding the June 2025 guidance. This revision was driven by the QMSR taking effect on February 2, 2026. The February 2026 guidance replaces all legacy 21 CFR Part 820 (QSR) references with corresponding QMSR citations and ISO 13485:2016 subclauses. Substantively, the cybersecurity requirements under Section 524B remain unchanged, but the quality system framework underpinning them has shifted: cybersecurity processes must now be demonstrably generated from controlled QMS processes aligned with ISO 13485. Specifically, threat models must trace to Subclause 7.3 (design and development) controls, security validation must be anchored in Subclause 7.3.7, and vulnerability handling must sit within Subclause 8.5 (improvement) processes. The February 2026 guidance is the current operative document.

Key elements of the guidance include:

• Secure Product Development Framework (SPDF): The FDA expects manufacturers to deploy an SPDF — a set of processes that identify and reduce vulnerabilities throughout the total product lifecycle (TPLC), from design through decommissioning
• Threat modeling and cybersecurity risk assessment as integral parts of device design
• Security architecture documentation
• SBOM requirements with specific format and content expectations
• Cybersecurity testing evidence (penetration testing, fuzz testing, vulnerability scanning)
• Post-market cybersecurity management plans
• Coordinated vulnerability disclosure policies

Refuse to Accept (RTA) — Enforcement Mechanism

The FDA implemented a phased enforcement approach:

• March 29, 2023 – September 30, 2023: Grace period. FDA worked collaboratively with sponsors on cybersecurity deficiencies rather than issuing RTA decisions based solely on missing Section 524B information.
• October 1, 2023 – present: FDA may issue Refuse to Accept decisions for premarket submissions of cyber devices that do not include the information required by Section 524B.

An RTA decision means the FDA will not review your submission at all. The submission is returned without review, and your regulatory timeline resets. This is not a deficiency letter — it is a refusal to even begin review.

The practical impact has been significant. Since October 2023, FDA reviewers have routinely issued Additional Information (AI) requests for submissions with incomplete cybersecurity documentation. Common deficiencies that trigger AI requests or RTA decisions include:

• Missing or incomplete SBOMs (non-machine-readable formats, missing dependencies, outdated version information)
• Undefined threat model boundaries, especially for cloud-connected devices
• Absent or inadequate coordinated vulnerability disclosure policies
• Lack of evidence of cybersecurity testing
• Missing post-market monitoring plans

Premarket Cybersecurity Requirements in Detail

The FDA's guidance describes approximately 12 categories of cybersecurity documentation expected in premarket submissions. Each element is described below with practical implementation guidance.

Device Classification: Tier 1 vs. Tier 2

The FDA's cybersecurity guidance classifies devices into two tiers based on their cybersecurity risk profile:

Tier 1 — Higher Cybersecurity Risk:

• Devices capable of connecting (wired or wirelessly) to other medical or non-medical products, networks, or the internet
• Devices that are considered cyber devices under Section 524B
• Devices where a cybersecurity incident could directly result in patient harm

Tier 2 — Standard Cybersecurity Risk:

• Devices that do not meet Tier 1 criteria
• Devices that are not considered cyber devices but still contain software

Tier 1 devices require the full scope of cybersecurity documentation described below. Tier 2 devices require a reduced documentation set, though the FDA still expects a cybersecurity risk assessment and basic security design documentation.

Practical tip: When in doubt, treat your device as Tier 1. The cost of preparing comprehensive cybersecurity documentation is far less than the cost of an RTA decision or an Additional Information request that delays your review by months.

Threat Modeling

Threat modeling is the systematic identification, enumeration, and prioritization of potential threats to a medical device system. The FDA expects threat modeling documentation to demonstrate how the manufacturer analyzed the device to identify security risks that could impact safety and effectiveness.

What the FDA expects:

• Documentation of the threat modeling methodology used (e.g., STRIDE, PASTA, Attack Trees, LINDDUN)
• Identification of all system boundaries, trust zones, data flows, and entry/exit points
• Enumeration of potential threats, including network-based attacks, physical access scenarios, supply chain compromises, and insider threats
• Assessment of the likelihood and impact of each threat
• Mapping of threats to specific mitigations (design decisions, security controls)
• Rationale for the methodology selected

Practical guidance:

The FDA does not prescribe a specific threat modeling methodology. It allows manufacturers to choose their approach, provided they document the rationale. However, the most commonly used frameworks in medical device cybersecurity include:

Framework	Strengths	Typical Application
STRIDE	Systematic categorization of threat types (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)	General-purpose; well-suited for software-heavy devices
PASTA (Process for Attack Simulation and Threat Analysis)	Risk-centric; aligns well with ISO 14971 risk management	Complex systems with multiple stakeholders
Attack Trees	Visual representation of attack paths; good for communicating with non-technical stakeholders	Focused analysis of specific attack scenarios
MITRE ATT&CK	Comprehensive knowledge base of adversary tactics and techniques	Post-market threat intelligence; mapping known threat actor behaviors

Practical tip: Threat modeling is not a one-time activity. The FDA expects manufacturers to update threat models as the threat landscape evolves, as new vulnerabilities are discovered, and as the device or its operating environment changes. Build threat modeling into your SDLC, not just into your premarket submission process.

Cybersecurity Risk Assessment

The cybersecurity risk assessment extends the ISO 14971 risk management process to cybersecurity-specific hazards. The FDA expects manufacturers to evaluate both the exploitability of vulnerabilities and the severity of harm that could result from successful exploitation.

Key expectations include:

• Pre-mitigation risk assessment: Identification of all cybersecurity risks before security controls are applied
• Post-mitigation risk assessment: Residual risk after security controls, demonstrating that the benefit-risk profile is acceptable
• Risk acceptance rationale: For any residual cybersecurity risks that are accepted, documentation of why the risk is acceptable
• Integration with safety risk management: Cybersecurity risks must be linked to the device's overall risk management file — they are not a separate, siloed analysis

The FDA's guidance explicitly states that cybersecurity risk assessment should consider not only the device itself but also the broader system in which it operates, including network infrastructure, cloud services, mobile applications, and interoperable devices.

Security Architecture

The FDA expects manufacturers to document the security architecture of the device, including:

• System diagrams showing all components, interfaces, data flows, and trust boundaries
• Security controls implemented at each layer (hardware, firmware, operating system, application, network, cloud)
• Cryptographic implementations: Algorithms used, key management procedures, certificate handling
• Authentication and access control: User authentication mechanisms, role-based access control, session management
• Data protection: Encryption at rest and in transit, data integrity mechanisms
• Audit logging: What events are logged, where logs are stored, how logs are protected from tampering
• Secure boot and firmware integrity: Mechanisms to ensure only authorized code executes on the device
• Network segmentation: How the device isolates itself from or interacts with the broader network environment

The security architecture documentation should clearly identify the trust boundaries of the system. A trust boundary is any point where data or control crosses between components with different trust levels — for example, between the device and an external network, between the application and the operating system, or between the device and a cloud backend. Each trust boundary should have documented security controls that verify, validate, or restrict the data and commands that cross it.

Practical tip: Start your security architecture documentation with a data flow diagram (DFD) that shows all external entities, processes, data stores, and data flows. Then overlay trust boundaries and enumerate the security controls at each boundary. This visual approach makes it easier for FDA reviewers to understand your security posture and for your own team to identify gaps.

Software Bill of Materials (SBOM)

The SBOM has become one of the most visible and frequently discussed cybersecurity requirements for medical devices. Section 524B mandates that manufacturers provide an SBOM "including commercial, open-source, and off-the-shelf software components."

What must be included:

The FDA references the NTIA Minimum Elements for a Software Bill of Materials as the baseline expectation. At minimum, an SBOM must include:

SBOM Element	Description
Supplier name	The entity that created or distributes the component
Component name	The name of the software component as defined by its supplier
Component version	The version identifier used by the supplier
Unique identifier	A unique identifier for each component (e.g., CPE, PURL)
Dependency relationships	How components relate to each other (e.g., component A depends on component B)
Author of SBOM data	The entity that created the SBOM
Timestamp	When the SBOM was created
End-of-Support (EOS) dates	Target dates when the manufacturer or component supplier will stop providing security support for each component
Level of support	The current support status of each component (active, limited, end-of-life)

Format requirements:

The FDA expects SBOMs in machine-readable formats — specifically SPDX (Software Package Data Exchange) or CycloneDX. PDF documents listing software components do not satisfy the requirement. The SBOM must be parseable by automated tools to enable vulnerability correlation.

Depth requirements:

The SBOM must include all levels of the dependency tree, not just top-level components. If your application uses a library, and that library uses three other libraries, all four must appear in the SBOM with their dependency relationships documented.

Known vulnerabilities:

The SBOM should either include or reference known vulnerabilities (CVEs) associated with each component. For components with known vulnerabilities, the manufacturer must document the risk assessment and mitigation strategy.

Update obligations:

The SBOM is not a static document. Manufacturers must update the SBOM whenever the software is modified — whether through a planned update, a security patch, or a component upgrade. The updated SBOM must be made available to customers and, upon request, to the FDA.

Common pitfall: The most frequent deficiency in SBOM submissions is incomplete dependency enumeration. Automated SBOM generation tools (e.g., Syft, Trivy, FOSSA, Black Duck) should be integrated into the build pipeline to ensure completeness. Manual SBOM creation for modern software with hundreds of transitive dependencies is impractical and error-prone.

FDA cross-referencing: In 2025-2026, the FDA has been actively cross-referencing submitted SBOMs against public vulnerability databases (NVD, GitHub Advisories). If an FDA reviewer identifies a known CVE applicable to a component in your SBOM that you have not disclosed or addressed in your risk assessment, it raises serious concerns about the adequacy of your entire Secure Product Development Framework. Do not "filter" your SBOM before submission — total transparency is expected.

IMDRF N73 — SBOM Best Practices: The International Medical Device Regulators Forum published IMDRF/CYBER WG/N73 ("Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity") in April 2023, providing globally harmonized guidance on SBOM generation, management, and distribution. N73 complements the earlier IMDRF N60 guidance on medical device cybersecurity and provides recommendations for both manufacturers and healthcare providers on using SBOMs for vulnerability management throughout the Total Product Lifecycle. Manufacturers seeking to align with global expectations should reference N73 alongside the FDA's NTIA-based SBOM requirements.

SBOM for different device types:

Device Type	SBOM Scope	Typical Challenges
Embedded firmware	RTOS, drivers, middleware, application code, bootloader	Binary analysis may be needed for third-party components without source access
SaMD (cloud-hosted)	Application frameworks, libraries, container base images, cloud service SDKs, ML frameworks	Dependency trees can be extremely deep; cloud service dependencies need documentation
Desktop software	OS dependencies, runtime environments, application libraries, installer components	OS-level dependencies may not be under manufacturer control
Mobile applications	Mobile OS SDK, third-party libraries, analytics frameworks, networking libraries	App store distribution adds complexity; SDK updates may change SBOM

Vulnerability Exploitability eXchange (VEX):

Alongside the SBOM, manufacturers should consider providing a VEX document — a companion artifact that communicates which known vulnerabilities in SBOM components actually affect the device and which do not. For example, if a component has a known CVE that only affects a feature the device does not use, the VEX statement would indicate "not affected." VEX reduces alert fatigue for healthcare organizations performing vulnerability management and demonstrates that the manufacturer has assessed each vulnerability rather than simply listing components.

Cybersecurity Testing

The FDA expects manufacturers to provide evidence of cybersecurity testing as part of premarket submissions. The guidance identifies three primary categories of testing:

Vulnerability scanning: Automated scanning of the device and its software components for known vulnerabilities (CVEs). This includes scanning the operating system, third-party libraries, network services, and application code. The FDA expects vulnerability scans to be performed against current vulnerability databases and for results to be documented with corresponding risk assessments and mitigations.

Penetration testing: Manual and/or automated testing that simulates real-world attacks against the device. The FDA recommends that penetration testing have a level of independence from the development team — ideally performed by a separate firm or by an internal team that was not involved in the device's design or development. Critically, penetration testing must be performed on the final, production-equivalent version of the device — not on earlier prototypes or development builds. It should cover all system elements, not just the regulated device components.

Penetration testing should cover:

• Network-based attacks (port scanning, protocol exploitation, man-in-the-middle)
• Application-level attacks (injection, authentication bypass, privilege escalation)
• Physical access attacks (debug port access, firmware extraction, hardware tampering)
• Wireless protocol attacks (Bluetooth, Wi-Fi, Zigbee, proprietary RF)

Every finding in a penetration test report should be treated as a newly identified risk that must be managed through the risk assessment process. If a vulnerability is not fixed, the manufacturer must provide a documented justification for why the residual risk is acceptable. For high-risk findings that are mitigated, the FDA expects evidence of a retest to verify the fix was effective — both the original and retest reports should be provided to demonstrate lifecycle coverage.

Fuzz testing (fuzzing): Dynamic testing that provides random, malformed, or unexpected inputs to the device's interfaces to identify crashes, memory corruption, assertion failures, or other unexpected behavior. Fuzzing is particularly important for devices that process external data (e.g., DICOM images, HL7/FHIR messages, proprietary protocols).

Static Application Security Testing (SAST): Although not explicitly called out in the FDA guidance as a separate requirement, static analysis of source code is an expected component of a mature SPDF. SAST tools analyze source code or binaries without executing them, identifying coding patterns known to introduce vulnerabilities (buffer overflows, format string vulnerabilities, SQL injection, use-after-free). Results should be documented and integrated into the cybersecurity risk assessment.

Software Composition Analysis (SCA): SCA tools analyze the device software to identify all third-party and open-source components, correlate them against vulnerability databases, and flag components with known security issues. SCA is closely related to SBOM management — in many toolchains, the SCA tool generates the SBOM.

The FDA expects the testing documentation to include:

• Scope and methodology of each test type
• Tools used and version information
• Findings, severity classification (using CVSS or equivalent), and evidence of triage
• Remediation actions taken for each finding
• Evidence that identified vulnerabilities were resolved or risk-assessed
• Residual risk assessment for any findings accepted without remediation

Security Controls Documentation

Beyond architecture documentation, the FDA expects detailed documentation of specific security controls, including:

• Secure update mechanisms: How the device receives and validates software updates, including code signing, integrity verification, and rollback capabilities
• Anomaly detection: How the device detects and responds to anomalous behavior (e.g., unexpected network traffic, unauthorized access attempts)
• Fail-safe modes: How the device behaves when a cybersecurity event is detected — does it degrade gracefully, alert the user, or shut down?
• User notification: How the manufacturer communicates cybersecurity risks, patches, and mitigations to device users and healthcare organizations

Appendix 1: Eight Security Control Categories

The FDA's premarket guidance includes Appendix 1, which defines eight categories of security controls that the FDA expects manufacturers to address for Tier 1 devices. In 2026, the FDA is treating Appendix 1 as a mandatory checklist — submissions missing one or more categories without robust technical justification are being flagged with deficiencies.

Category	Description
1. Authentication	Mechanisms to verify the identity of users, devices, and services before granting access. Includes multi-factor authentication, certificate-based authentication, and device-to-device authentication.
2. Authorization	Role-based access controls that restrict users and processes to the minimum privileges necessary for their function. Includes separation of clinical user, administrator, and service roles.
3. Cryptography	Implementation of cryptographic algorithms for data protection, including encryption at rest and in transit, key management, certificate handling, and use of current, non-deprecated algorithms.
4. Code, Data, and Execution Integrity	Mechanisms to ensure that only authorized code executes on the device, including secure boot, code signing, firmware integrity verification, and runtime integrity checks.
5. Confidentiality	Protection of sensitive data (PHI, PII, device configurations, cryptographic keys) from unauthorized disclosure, both at rest and in transit.
6. Event Detection and Logging	Audit logging of security-relevant events (authentication attempts, configuration changes, software updates, anomalous behavior) with tamper-resistant log storage and appropriate log retention.
7. Resiliency	The device's ability to maintain safe operation during and after a cybersecurity event, including fail-safe modes, graceful degradation, automated recovery, and backup/restore capabilities.
8. Firmware / Software Updatability	Secure mechanisms for delivering, validating, and applying software and firmware updates, including code signing, integrity verification, rollback capabilities, and authenticated update channels.

Practical tip: Audit your design history file (DHF) against all eight categories before submission. If a category is not applicable to your device (e.g., a standalone device with no network connectivity may not require certain authentication controls), document the rationale explicitly. The FDA expects either implementation evidence or a justified exclusion for each category.

Cybersecurity Labeling Requirements

Cybersecurity labeling has become a core regulatory expectation. Section VI.A of the FDA's cybersecurity guidance defines fourteen elements that device labeling must address. The labeling serves as a bridge between the manufacturer's security design and the end user's ability to securely deploy, configure, operate, maintain, and decommission the device.

Who uses cybersecurity labeling: Hospital IT administrators, clinical engineers, biomedical engineers, healthcare information security officers, and in some cases clinicians — not just regulatory reviewers.

Core elements the FDA expects in cybersecurity labeling include:

• Device instructions and product specifications: Clear instructions for secure setup, installation, and operation, including hardware and software specifications needed for safe use
• Communication interfaces: Disclosure of all connectivity interfaces (Wi-Fi, Bluetooth, Ethernet, USB, serial, proprietary RF) — including interfaces disabled by default
• Known residual risks and compensating controls: Cybersecurity risks that remain after design mitigations, and the compensating controls end users should implement
• SBOM reference: A reference to the device's SBOM or inclusion of the SBOM itself, enabling healthcare organizations to perform their own vulnerability management
• Security configuration guidance: Instructions for securely configuring the device, including default settings, password policies, network configuration, and firewall rules
• Secure update and patch procedures: How software updates are delivered, how users verify update integrity, and how to roll back failed updates
• Backup and restore procedures: How to back up device data and configuration and restore after a cybersecurity event
• Support lifetime statement: The expected duration for which the manufacturer will provide security patches and vulnerability support
• End-of-life and decommissioning: Procedures for securely decommissioning the device, including data sanitization, credential removal, and certificate revocation
• Anomaly detection and response: How the device detects and responds to cybersecurity anomalies, and what users should do when alerts are generated
• User-configurable security options: If the device allows users to adjust security settings, the labeling must enumerate options and explain the consequences of selecting lower-security configurations
• Anti-malware considerations: Whether the device supports anti-malware software, and if not, the compensating controls that provide equivalent protection
• Minimum IT network requirements: The minimum requirements for the IT network environment in which the device is intended to operate, including security measures the healthcare organization must implement
• MDS2 form: The Manufacturer Disclosure Statement for Medical Device Security (MDS2, ANSI/NEMA HN 1-2019) — a standardized form that communicates the device's security capabilities, data flows, and network requirements to healthcare organizations

Practical tip: Do not treat cybersecurity labeling as an afterthought. The FDA is flagging submissions where labeling fails to provide actionable information for end users to securely configure and operate the device. Hospital IT teams rely on this documentation to make deployment and risk management decisions. Ensure your cybersecurity labeling is reviewed by both regulatory and clinical engineering stakeholders before submission.

Interoperability and Integration Security

Interoperability between medical devices, hospital networks, electronic health record (EHR) systems, PACS, and other clinical systems introduces additional cybersecurity considerations that the FDA expects manufacturers to address in premarket submissions.

Key considerations include:

• Interface security assessment: Every connection point between the device and external systems (HL7, FHIR, DICOM, proprietary protocols) must be assessed for cybersecurity risks including data integrity, authentication, and confidentiality
• Trust boundaries across systems: When the device exchanges data with external systems, the trust boundary analysis must extend beyond the device itself to include the communication channel and the receiving system
• Network configuration requirements: The manufacturer must document the minimum network security requirements for safe device operation, including firewall rules, VLAN requirements, and protocol restrictions
• Authentication and authorization for interoperable functions: How the device authenticates to external systems and how external systems authenticate to the device
• Data validation: How the device validates incoming data from external sources to prevent injection attacks, malformed data processing errors, or corruption of clinical data

Post-Market Cybersecurity

Premarket cybersecurity documentation establishes the baseline. Post-market cybersecurity management is where the ongoing work happens — and where many manufacturers struggle.

Vulnerability Monitoring and Management

The FDA expects manufacturers to continuously monitor for new vulnerabilities affecting their devices throughout the product lifecycle. This includes:

• Monitoring vulnerability databases: NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures), and vendor-specific security advisories
• Monitoring SBOM components: Automated correlation of SBOM contents against newly published CVEs
• Subscribing to threat intelligence feeds: Industry-specific feeds (H-ISAC, Health Information Sharing and Analysis Center) and general feeds (CISA alerts, US-CERT)
• Internal vulnerability research: Ongoing security testing, code review, and architecture assessment

When a new vulnerability is identified, the manufacturer must:

1. Assess the vulnerability's exploitability and potential impact on device safety and effectiveness
2. Classify the vulnerability by severity (using frameworks such as CVSS — Common Vulnerability Scoring System)
3. Determine whether the vulnerability is controlled or uncontrolled
4. Remediate or mitigate within a timeframe commensurate with the risk level
5. Communicate findings and mitigations to customers and, where applicable, to the FDA

CVE Management Workflow

Practical CVE management for medical device manufacturers follows a structured workflow:

1. Ingest: Automated tools correlate SBOM components against vulnerability databases (NVD, vendor advisories, CISA KEV) on a continuous basis — daily at minimum
2. Triage: Each newly identified CVE affecting an SBOM component is triaged for applicability. Is the affected function used by the device? Is the vulnerable code path reachable? Is the device deployed in an environment where the attack vector is feasible?
3. Score: Applicable CVEs are scored using CVSS (Common Vulnerability Scoring System) in the context of the device. A CVE scored as Critical (CVSS 9.0+) in the general context may score lower in the device context if compensating controls exist, and vice versa.
4. Prioritize: CVEs are prioritized for remediation based on device-contextualized severity, exploitability, and the availability of a fix
5. Remediate: Remediation may involve patching the component, upgrading to a non-vulnerable version, implementing compensating controls, or — in rare cases — accepting the risk with documented justification
6. Verify: Remediation is verified through regression testing, security testing, and risk assessment update
7. Communicate: Affected customers are notified per the manufacturer's communication plan. CISA coordination is initiated if appropriate.
8. Document: The entire workflow is documented in the vulnerability management system for audit trail and regulatory purposes

Practical tip: Invest in tooling that automates steps 1-3. Manual CVE triage is unsustainable for devices with SBOMs containing hundreds of components. Tools like Dependency-Track, Grype, or commercial platforms (Finite State, MedCrypt, Cybellum) can automate SBOM-to-CVE correlation and provide contextualized risk scoring.

Coordinated Vulnerability Disclosure (CVD)

Section 524B requires manufacturers to establish a coordinated vulnerability disclosure process. This is a formalized program through which external security researchers, healthcare organizations, and other parties can report vulnerabilities to the manufacturer.

A CVD program must include:

• A publicly accessible vulnerability reporting mechanism (e.g., a security contact page, a security.txt file, a bug bounty program)
• A defined process for receiving, triaging, and responding to vulnerability reports
• A commitment to acknowledging reports within a defined timeframe
• A process for coordinating disclosure with the reporter before public announcement
• Integration with CISA's coordinated vulnerability disclosure process when applicable

Practical tip: Many manufacturers start with a simple security@company.com email address and a published vulnerability disclosure policy. As the program matures, consider establishing a formal bug bounty program or partnering with organizations like HackerOne or Bugcrowd. The key is that the channel exists, is publicly documented, and is actively monitored.

Patch Management

Manufacturers of cyber devices must be capable of providing security patches and updates throughout the supported lifecycle of the device. The FDA's expectations include:

• Critical vulnerability patches: Immediate out-of-cycle patches for vulnerabilities that could lead to uncontrolled risks
• Routine security updates: Regular scheduled updates addressing accumulated lower-severity vulnerabilities
• Validated update mechanisms: Updates must be validated before deployment and must not introduce new safety risks
• Customer notification: Manufacturers must notify customers within a defined timeframe (the 2025 guidance references 30 days for vulnerability discovery notification) and provide clear guidance on applying patches
• End-of-support planning: Manufacturers must communicate when they will stop providing security updates for a device and provide guidance on decommissioning or transitioning to supported alternatives

CISA Advisories and ICS-CERT

The Cybersecurity and Infrastructure Security Agency (CISA), through its ICS-CERT (Industrial Control Systems Cyber Emergency Response Team), publishes security advisories for vulnerabilities identified in medical devices and healthcare IT systems. These advisories are a key input to post-market cybersecurity management.

The FDA expects manufacturers to:

• Monitor CISA advisories relevant to their devices and components
• Respond promptly to advisories that affect their products
• Coordinate with CISA when vulnerabilities in their devices are reported
• Ensure that vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog are addressed with high priority — the FDA's guidance states that KEV-listed vulnerabilities should be "designed out of the device" because they are already being actively exploited

EU MDR Cybersecurity Requirements

The European Union's approach to medical device cybersecurity differs structurally from the FDA's but reaches similar practical conclusions. While the U.S. has a dedicated statute (Section 524B) and prescriptive guidance, the EU embeds cybersecurity requirements within the broader General Safety and Performance Requirements (GSPRs) of the Medical Device Regulation (MDR 2017/745).

Annex I GSPR Requirements

The MDR's Annex I contains several GSPRs directly applicable to cybersecurity:

GSPR	Requirement Summary
Section 14.1	Devices incorporating electronic programmable systems must be designed to ensure repeatability, reliability, and performance in accordance with their intended use. Software must be developed and manufactured in accordance with the state of the art, taking into account the principles of the development lifecycle, risk management, verification and validation.
Section 14.2 (d)	Devices shall include measures to address cybersecurity risks, including protection against unauthorized access needed to ensure the device functions as intended.
Section 17.2	Devices that incorporate software or that are software must be designed to ensure repeatability, reliability, and performance. IT security measures must be taken, including protection against unauthorized access.
Section 17.4	Manufacturers shall set out minimum requirements concerning hardware, IT networks, and IT security measures, including protection against unauthorized access, necessary to run the software as intended.

MDCG 2019-16: Guidance on Cybersecurity for Medical Devices

The Medical Device Coordination Group (MDCG) published MDCG 2019-16 (Revision 1), a guidance document that helps manufacturers interpret the MDR's cybersecurity-related GSPRs. The guidance covers:

• Security requirements specification: Manufacturers should define cybersecurity requirements based on the intended use, reasonably foreseeable misuse, and the state of the art
• Secure development lifecycle: Alignment with IEC 62443-4-1 and IEC 81001-5-1 for secure development processes
• Risk management: Integration of cybersecurity risks into the ISO 14971 risk management process
• Verification and validation: Testing of cybersecurity controls, including penetration testing
• Post-market surveillance: Monitoring for new vulnerabilities, incident reporting, and Field Safety Corrective Actions (FSCAs)
• Information to be supplied with the device: Instructions for use must include cybersecurity-relevant information for healthcare organizations

IVDR Cybersecurity Requirements

The In Vitro Diagnostic Regulation (IVDR 2017/746) contains parallel cybersecurity requirements in its Annex I, specifically Sections 1, 4, and 16.2. IVD devices that incorporate software or network connectivity must meet the same cybersecurity expectations as MDR devices. The MDCG 2019-16 guidance applies to both MDR and IVDR devices.

Key Differences from FDA

The EU MDR approach differs from the FDA's in several important ways:

• No dedicated statute: Cybersecurity requirements are embedded in the GSPRs rather than codified in a separate law
• State of the art: The MDR requires cybersecurity measures to reflect the "state of the art" — a term that creates an evolving standard rather than a fixed requirement. This means the cybersecurity bar rises continuously as technology and threats evolve.
• Harmonized standards: The EU uses harmonized standards (currently IEC 81001-5-1 is on the harmonization path, expected formally by May 2028) to create a presumption of conformity
• Notified Body assessment: For higher-risk devices (Class IIb, Class III, and certain Class IIa devices), Notified Bodies assess cybersecurity documentation as part of the conformity assessment — adding an independent third-party review layer that does not exist in the FDA process for most device classes
• Broader scope: The EU approach does not limit cybersecurity requirements to "cyber devices" — all devices incorporating electronic programmable systems are in scope, regardless of internet connectivity
• Essential Requirements for IFU: The EU requires that instructions for use include specific cybersecurity information — residual risks, necessary compensating controls, minimum IT requirements, and guidance for healthcare organizations on integrating the device securely into their IT environment

Critical point: The "state of the art" requirement in the EU MDR means that cybersecurity measures considered adequate at the time of initial CE marking may become insufficient as the threat landscape evolves. Manufacturers must continuously update their cybersecurity measures, not just maintain the baseline established at initial market entry. This has direct implications for post-market surveillance and GSPR conformity over time.

IEC 81001-5-1: Health Software Security Standard

IEC 81001-5-1:2021 (Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle) is the international standard specifically designed for cybersecurity in health software. It defines lifecycle requirements for the development and maintenance of secure health software.

Scope and Applicability

IEC 81001-5-1 applies to:

• Medical device software (both SaMD and SiMD)
• Health IT software used in healthcare settings
• Software components within medical device systems

The standard builds on IEC 62443-4-1 (Secure Product Development Lifecycle Requirements) and adapts its requirements for the specific needs of health software. It introduces 64 additional cybersecurity requirements beyond what IEC 62443-4-1 provides.

Key Process Areas

Process Area	Description
Security requirements management	Defining, analyzing, and maintaining cybersecurity requirements throughout the lifecycle
Security risk management	Identifying, analyzing, evaluating, and treating cybersecurity risks — aligned with ISO 14971
Secure design	Applying security principles (defense in depth, least privilege, secure defaults) to architecture and detailed design
Secure implementation	Secure coding practices, code review, static analysis
Security verification and validation	Testing security controls, vulnerability assessment, penetration testing
Security release management	Ensuring that release processes maintain security integrity
Security response management	Managing vulnerabilities discovered post-release, including patch management and communication
Security update management	Processes for developing, validating, and deploying security updates

Regulatory Status

• EU MDR: IEC 81001-5-1 is on the EU harmonization application list, with formal harmonization expected by May 27, 2028. Once harmonized, compliance with IEC 81001-5-1 will create a presumption of conformity with the MDR's cybersecurity GSPRs.
• FDA (United States): The FDA references IEC 81001-5-1 in its cybersecurity guidance and recognizes it as a relevant standard, though it is not listed as a recognized consensus standard as of early 2026.
• Japan (PMDA): Japan has enforced IEC 81001-5-1 for medical device approvals since 2024.

December 2025 Interpretation Sheet

In December 2025, the IEC released an interpretation sheet to clarify key aspects of IEC 81001-5-1, including how security responsibilities are defined throughout the software lifecycle and how risk transfer should occur once a product is deployed. This interpretation is particularly important for SaMD manufacturers deploying in multi-tenant cloud environments where security responsibility is shared between the manufacturer, cloud provider, and healthcare organization.

IEC 62443: Industrial Cybersecurity and Medical Device Relevance

The ISA/IEC 62443 series of standards was originally developed for industrial automation and control systems (IACS) cybersecurity. However, its relevance to medical devices has grown substantially.

Why IEC 62443 Matters for Medical Devices

• FDA recognition: In 2014, the FDA recognized IEC 62443 as relevant to medical devices and added it to their recognized consensus standards list
• BSI recommendation: The British Standards Institute has recommended IEC 62443 for medical devices
• IEC horizontal standard: In 2021, the IEC recognized the 62443 series as a horizontal standard, formally acknowledging its applicability across industries including medical devices
• Foundation for IEC 81001-5-1: IEC 81001-5-1 builds upon IEC 62443-4-1, so understanding the parent standard is essential

Most Relevant Parts for Medical Device Manufacturers

Standard	Title	Relevance
IEC 62443-4-1	Secure Product Development Lifecycle Requirements	Process requirements for building secure products — the foundation that IEC 81001-5-1 extends
IEC 62443-4-2	Technical Security Requirements for IACS Components	Component-level security requirements (authentication, authorization, data integrity, etc.) applicable to device design
IEC 62443-3-3	System Security Requirements and Security Levels	System-level security requirements; useful for defining security levels for connected medical device systems
IEC 62443-2-4	Requirements for IACS Service Providers	Relevant for manufacturers providing ongoing security services, managed updates, or cloud-based device management

IMDRF Cybersecurity Guidance (N60, N70, N73)

The International Medical Device Regulators Forum (IMDRF) has published three key cybersecurity documents that provide globally harmonized guidance and are referenced by regulators worldwide including the FDA, Health Canada, Australia's TGA, and Japan's PMDA.

IMDRF N60 — Principles and Practices for Medical Device Cybersecurity (2020)

IMDRF/CYBER WG/N60 (finalized March 2020) establishes the foundational international framework for medical device cybersecurity. The FDA co-chaired the IMDRF working group that produced this document. N60 covers:

• Total Product Lifecycle (TPLC) approach: Cybersecurity risk management across design, manufacturing, deployment, maintenance, and decommissioning
• Shared responsibility model: Defines cybersecurity responsibilities for manufacturers, healthcare providers, regulators, and patients
• Security capabilities: Authentication, authorization, audit/logging, data confidentiality, data integrity, secure communications, system hardening, and device integrity
• Customer security documentation: What manufacturers should provide to healthcare organizations, including SBOMs, security configuration guides, and MDS2 forms
• Legacy device management: Framework for managing devices that can no longer be reasonably protected against current cybersecurity threats

IMDRF N70 — Legacy Medical Devices (2023)

IMDRF/CYBER WG/N70 (published April 2023) specifically addresses the cybersecurity challenges of legacy medical devices and builds on the TPLC framework established in N60. N70 is discussed in detail in the Legacy Device Cybersecurity Management section of this guide.

IMDRF N73 — SBOM for Medical Device Cybersecurity (2023)

IMDRF/CYBER WG/N73 (published April 2023) provides detailed guidance on SBOM generation, management, distribution, and use for medical device cybersecurity. N73 is discussed in detail in the SBOM section of this guide.

NIST Cybersecurity Framework for Medical Devices

The National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) provides a high-level, risk-based framework that the FDA encourages manufacturers to use as a model for designing secure medical device lifecycles.

NIST CSF 2.0 (2024)

NIST CSF 2.0, released in 2024, expanded the framework from five to six core functions:

Function	Description	Medical Device Application
Govern (new in 2.0)	Establish and monitor cybersecurity risk management strategy, expectations, and policy	Define organizational cybersecurity policies for medical device development; assign roles and responsibilities
Identify	Understand cybersecurity risks to systems, assets, data, and capabilities	Asset inventory, SBOM management, threat landscape assessment, supply chain risk identification
Protect	Implement safeguards to ensure delivery of critical services	Encryption, authentication, access control, secure boot, code signing, network segmentation
Detect	Identify cybersecurity events in a timely manner	Anomaly detection, audit logging, intrusion detection, vulnerability monitoring
Respond	Take action regarding detected cybersecurity events	Incident response procedures, coordinated vulnerability disclosure, communication plans
Recover	Restore capabilities impaired by cybersecurity events	Patch deployment, system recovery procedures, fail-safe modes, backup and restore capabilities

NIST SP 800-213

NIST Special Publication 800-213 provides guidelines specifically for securing IoT devices, including medical IoT devices such as infusion pumps and imaging systems. It serves as a practical companion to the CSF for device-level security implementation.

Mapping NIST CSF to FDA Expectations

While the NIST CSF is a voluntary framework, it provides a useful organizational structure for medical device cybersecurity programs. The FDA does not require adherence to the NIST CSF, but many manufacturers find it valuable as a way to structure their security programs. The mapping between NIST CSF functions and FDA cybersecurity expectations is natural:

• Govern maps to SPDF governance, cybersecurity policies, and organizational roles
• Identify maps to threat modeling, asset inventory, and SBOM management
• Protect maps to security architecture, access controls, and encryption
• Detect maps to anomaly detection, audit logging, and vulnerability monitoring
• Respond maps to coordinated vulnerability disclosure and incident response
• Recover maps to patch deployment, system recovery, and fail-safe operation

Using the NIST CSF structure can help manufacturers demonstrate a comprehensive approach to cybersecurity that is familiar to both FDA reviewers and healthcare organization IT security teams.

Cybersecurity and SaMD / AI-ML Devices

Software as a Medical Device (SaMD) and AI/ML-enabled medical devices present unique cybersecurity challenges that extend beyond traditional connected device security.

SaMD-Specific Cybersecurity Concerns

SaMD products — cloud-hosted diagnostic algorithms, mobile clinical decision support tools, remote monitoring platforms — typically have:

• Larger attack surfaces: Cloud infrastructure, APIs, mobile apps, web interfaces, and data pipelines all present potential attack vectors
• Shared responsibility models: Security responsibility is distributed between the SaMD manufacturer, cloud provider (AWS, Azure, GCP), and healthcare organization
• Continuous data flows: SaMD products often process real-time patient data, creating ongoing exposure rather than point-in-time risk
• Rapid update cycles: SaMD products may be updated frequently, requiring continuous SBOM management and security validation

AI/ML-Specific Threat Vectors

AI/ML-enabled medical devices face novel cybersecurity threats that traditional security frameworks do not fully address:

Threat	Description	Potential Impact
Training data poisoning	Injecting malicious or biased data into training datasets	Model produces incorrect outputs, leading to misdiagnosis or inappropriate treatment
Adversarial attacks	Crafted inputs designed to fool the algorithm (e.g., imperceptibly modified images)	Algorithm produces confident but incorrect results — a manipulated chest X-ray classified as normal when pneumothorax is present
Model inversion	Techniques to extract sensitive training data from a deployed model	Patient data used in training could be reconstructed, violating privacy
Model theft	Unauthorized copying or reverse-engineering of the model	Intellectual property theft; unauthorized deployment of unvalidated copies
Data pipeline attacks	Compromising the data flow between data sources and the AI/ML model	Corrupted or manipulated input data leading to incorrect clinical outputs

Regulatory Expectations for SaMD/AI-ML Cybersecurity

The FDA expects SaMD and AI/ML manufacturers to address these unique threats in their premarket submissions:

• Threat models must specifically address cloud infrastructure, API security, and data pipeline integrity
• SBOMs must include cloud service dependencies and ML framework components
• Security testing must cover the full stack — not just the device software, but the cloud environment, data pipelines, and model serving infrastructure
• Post-market monitoring must include model performance monitoring for signs of adversarial attack or data integrity issues
• Predetermined Change Control Plans (PCCPs) for AI/ML devices should include cybersecurity considerations for model updates

Cloud Security Considerations for SaMD

SaMD products deployed in cloud environments must address the shared responsibility model that cloud providers use:

Security Domain	Cloud Provider Responsibility	Manufacturer Responsibility
Physical infrastructure	Data center security, hardware maintenance	Selecting appropriate cloud regions and compliance certifications
Network infrastructure	Backbone network security, DDoS protection	VPC configuration, network ACLs, security groups
Operating system	Host OS patching (for managed services)	Guest OS patching (for IaaS); container image security
Application	N/A	Application security, authentication, authorization, encryption
Data	Storage infrastructure security	Data encryption, access controls, data classification, PHI handling
Identity and access	IAM service availability	IAM configuration, MFA enforcement, least-privilege access

The manufacturer's cybersecurity documentation must clearly delineate what the manufacturer controls versus what the cloud provider controls, and how the manufacturer verifies that the cloud provider meets the required security posture (e.g., SOC 2, HITRUST, ISO 27001 certifications).

Legacy Device Cybersecurity Management

Legacy medical devices — those that were designed and cleared/approved before modern cybersecurity requirements existed — present one of the most challenging problems in medical device cybersecurity. These devices may run outdated operating systems (Windows XP, Windows 7), use unencrypted communication protocols, lack secure update mechanisms, and have hardcoded credentials.

The Scale of the Problem

Many medical devices have operational lifetimes of 10-20 years. A device cleared in 2010 may still be in active clinical use in 2026, running on an operating system that has not received security patches since 2020. The IMDRF published "Principles and Practices for the Cybersecurity of Legacy Medical Devices" (N70) in April 2023 to address this challenge.

Manufacturer Responsibilities for Legacy Devices

• Continued monitoring: Even for devices no longer under active development, manufacturers should monitor for vulnerabilities affecting the device's software components
• Compensating controls: Where direct patching is not feasible, manufacturers should provide guidance on compensating controls (network segmentation, access restrictions, monitoring)
• End-of-support communication: Clear communication to healthcare organizations about when cybersecurity support will end and what steps should be taken to manage residual risk
• Transfer of responsibility documentation: When a device transitions from manufacturer support to healthcare organization self-management, documentation of known vulnerabilities, recommended mitigations, and risk assessment should be provided
• Retrofit assessment: For legacy devices that can be upgraded, manufacturers should assess whether cybersecurity improvements can be retrofitted without requiring a new premarket submission

Common Legacy Device Vulnerabilities

Legacy medical devices frequently exhibit the following cybersecurity weaknesses:

Vulnerability Category	Examples	Risk
Unsupported operating systems	Windows XP, Windows 7, outdated Linux kernels	No security patches available; known vulnerabilities remain permanently unpatched
Hardcoded credentials	Default passwords that cannot be changed; embedded service account credentials	Unauthorized access using publicly known credentials
Unencrypted communications	HTTP instead of HTTPS; unencrypted serial protocols; plaintext data transmission	Data interception; man-in-the-middle attacks; PHI exposure
No secure update mechanism	Firmware updates via USB without signature verification; no over-the-air update capability	Inability to deploy security patches; risk of malicious firmware installation
Open network services	Unnecessary ports and services running; Telnet, FTP, or other insecure protocols enabled	Expanded attack surface; exploitation of known service vulnerabilities
No audit logging	No record of access attempts, configuration changes, or operational events	Inability to detect or investigate security incidents

Healthcare Organization Responsibilities

Healthcare delivery organizations (HDOs) also bear responsibility for legacy device cybersecurity:

• Network segmentation: Isolating legacy devices from the broader network to limit attack surface
• Monitoring: Implementing network monitoring around legacy devices to detect anomalous behavior
• Access control: Restricting physical and network access to legacy devices
• Risk acceptance: Formally documenting and accepting the residual cybersecurity risks associated with continued use of legacy devices
• Asset inventory: Maintaining a current inventory of all connected medical devices, including software versions, network connections, and known vulnerabilities

Shared Responsibility Between Manufacturers and HDOs

The IMDRF N70 document emphasizes that legacy device cybersecurity is a shared responsibility between manufacturers and healthcare organizations. Manufacturers have deeper knowledge of the device's software architecture and vulnerabilities, while HDOs have control over the network environment and operational context. Effective legacy device cybersecurity requires active collaboration between both parties.

In practice, this means manufacturers should provide:

• Manufacturer Disclosure Statements for Medical Device Security (MDS2 forms)
• Security configuration guides
• Lists of open ports, protocols, and services
• Known vulnerability disclosures with risk assessments
• Compensating control recommendations

And HDOs should implement:

• Network segmentation based on manufacturer recommendations
• Monitoring for anomalous device behavior
• Incident response plans that account for legacy device limitations
• Replacement planning for devices approaching end-of-support

Cybersecurity Incident Response for Medical Devices

When a cybersecurity incident occurs — whether a vulnerability is discovered, exploited, or a device is compromised — manufacturers need a structured incident response process that accounts for the unique regulatory and safety considerations of medical devices.

Incident Response Plan Components

A medical device cybersecurity incident response plan should include:

• Incident classification: Define severity levels specific to medical device cybersecurity (e.g., Level 1: no patient safety impact, data only; Level 2: potential patient safety impact, no exploitation confirmed; Level 3: confirmed exploitation with patient safety implications)
• Notification timelines: Define who must be notified at each severity level, including internal stakeholders (engineering, regulatory, quality, executive leadership), external parties (customers, FDA, CISA), and potentially patients
• Assessment procedures: Structured assessment of the incident's scope, impact, root cause, and the effectiveness of existing controls
• Containment and remediation: Immediate actions to contain the incident (e.g., network isolation guidance for customers), followed by remediation (patches, configuration changes, component replacement)
• Communication templates: Pre-drafted communication templates for customer notifications, FDA reporting, and CISA coordination to enable rapid response
• Post-incident review: After the incident is resolved, conduct a formal review to identify lessons learned and process improvements

FDA Reporting Obligations

The FDA's post-market cybersecurity guidance establishes that most cybersecurity routine updates and patches are considered device enhancements that improve device safety — and therefore do not require premarket review or MDR (Medical Device Report) filing. However, if a cybersecurity vulnerability results in a reportable event (death, serious injury, or malfunction that could cause harm), standard MDR reporting requirements apply.

If a manufacturer determines that a cybersecurity vulnerability or exploit creates an uncontrolled risk requiring a field action, the manufacturer should report it as a recall (correction or removal) to the FDA. The cybersecurity context does not exempt the manufacturer from existing post-market reporting obligations.

Supply Chain Cybersecurity

The cybersecurity of a medical device depends not only on the manufacturer's own software but also on the security of every component in the supply chain. Third-party software libraries, contract manufacturers, cloud service providers, and hardware component suppliers all contribute to the device's overall security posture.

Software Supply Chain

The software supply chain is the primary concern for most medical device manufacturers:

• Open-source components: Modern medical device software typically incorporates dozens to hundreds of open-source libraries. Each library has its own development community, security practices, and vulnerability history. The Log4Shell vulnerability (CVE-2021-44228) demonstrated how a single vulnerability in a widely-used open-source library could affect millions of devices across every industry.
• Commercial off-the-shelf (COTS) software: Operating systems, databases, middleware, and other commercial components introduce dependencies on vendor security practices and patch release schedules.
• Third-party SDKs and APIs: Cloud service SDKs, analytics libraries, and integration APIs expand the attack surface and introduce dependencies on external service availability and security.
• Development tools: Compromised development tools (compilers, build systems, CI/CD pipelines) can introduce malicious code during the build process without the manufacturer's knowledge — as demonstrated by the SolarWinds supply chain attack.

Managing Software Supply Chain Risk

Manufacturers should implement:

• Vendor security assessment: Evaluate the security practices of significant third-party software suppliers
• Component selection criteria: Define security criteria for selecting open-source and commercial components (maintenance status, vulnerability history, community size, license terms)
• Automated vulnerability monitoring: Continuously monitor SBOM components for newly disclosed vulnerabilities
• Patch tracking: Track vendor patch releases and assess applicability to the device
• Supplier communication: Establish channels for receiving security notifications from component suppliers

Practical tip: Not all third-party components carry equal risk. Prioritize security assessment for components that process untrusted input, handle sensitive data, implement cryptographic functions, or operate at elevated privilege levels. A low-risk utility library requires less scrutiny than a networking stack or cryptographic library.

False Claims Act Enforcement and Cybersecurity Liability

Medical device cybersecurity failures now carry enforcement risk beyond the FDA's traditional regulatory mechanisms. The U.S. Department of Justice (DOJ) has established cybersecurity noncompliance as a viable basis for False Claims Act (FCA) enforcement against medical device manufacturers.

The Civil Cyber-Fraud Initiative

In October 2021, the DOJ launched the Civil Cyber-Fraud Initiative (CCFI) to pursue cybersecurity fraud under the False Claims Act. The initiative targets organizations that knowingly provide deficient cybersecurity products or services, misrepresent their cybersecurity practices, or fail to monitor and report cybersecurity incidents. In fiscal year 2025, the CCFI recovered more than $52 million across nine cybersecurity-related FCA settlements — more than tripling the prior year's total. The DOJ has confirmed that cybersecurity fraud remains a key FCA enforcement priority.

Illumina Settlement — First Medical Device Cybersecurity FCA Case

On July 31, 2025, the DOJ announced a $9.8 million settlement with Illumina, Inc. — a leading manufacturer of genomic sequencing systems — to resolve allegations that it misrepresented compliance with federal cybersecurity requirements for medical device software. The case arose from a whistleblower (qui tam) complaint filed by a former Illumina employee; the DOJ intervened and the whistleblower received $1.9 million.

The DOJ alleged that Illumina sold genomic sequencing systems with known cybersecurity vulnerabilities to federal agencies and falsely represented that its software adhered to cybersecurity standards. Critically, the FCA claim was based on allegations that Illumina failed to follow the FDA's non-binding cybersecurity guidance — meaning that even guidance-level (non-statutory) cybersecurity expectations can serve as the basis for FCA liability when compliance is represented to the government.

Other Notable Cybersecurity FCA Settlements

• Health Net Federal Services / Centene Corporation (February 2025): Agreed to pay $11.25 million to resolve allegations of falsely certifying compliance with cybersecurity requirements under TRICARE military health benefits contracts, including failure to perform required vulnerability scanning and ignoring internal audit warnings
• Booz Allen Hamilton (January 2025): Agreed to pay $15.875 million to resolve FCA allegations related to cybersecurity compliance

Implications for Medical Device Manufacturers

The convergence of FDA cybersecurity requirements and FCA enforcement creates a new risk calculus:

• Representations matter: Any representation to a government customer (directly or through procurement certifications) that a device meets cybersecurity standards creates potential FCA exposure if the representation is materially false
• Guidance is not optional: Even though FDA guidance is technically non-binding, representing compliance with guidance when the device does not meet the guidance's recommendations can constitute a false claim
• Whistleblower risk: FCA cases are frequently initiated by former employees (whistleblowers/relators) who receive a percentage of the recovery — typically 15-30%. This creates strong incentives for insiders to report cybersecurity noncompliance
• No breach required: The DOJ has pressed FCA theories where cybersecurity deficiencies existed even absent an actual data breach or security incident — the false representation itself is the violation
• Criminal exposure: In December 2025, a grand jury indicted a former senior manager of a government contractor for fraud related to misrepresenting cybersecurity compliance, demonstrating that individual criminal liability is possible

Critical point: Medical device manufacturers selling to government customers (DoD, VA, HHS, NIH, CDC) face dual enforcement exposure — FDA regulatory action for cybersecurity deficiencies and DOJ FCA enforcement for misrepresenting cybersecurity compliance. The practical implication is that cybersecurity compliance must be accurate and verifiable, not aspirational.

Broader Privacy and Security Regulatory Landscape

Medical device cybersecurity does not exist in a regulatory vacuum. Manufacturers must navigate overlapping federal and state requirements that affect how devices handle, store, and transmit health data.

HIPAA

While the FDA does not regulate privacy or patient data security directly, medical device manufacturers and healthcare organizations that handle Protected Health Information (PHI) must comply with the Health Insurance Portability and Accountability Act (HIPAA). HIPAA's Security Rule requires administrative, physical, and technical safeguards for electronic PHI. In 2025, the HHS Office for Civil Rights (OCR) imposed 21 enforcement actions — the second-highest annual total — with a particular focus on risk analysis failures and ransomware incidents. Penalties ranged from $10,000 to $1.5 million per resolution.

Manufacturers should consider HIPAA requirements when designing devices that process, store, or transmit PHI, and should provide documentation to help healthcare organizations meet their HIPAA obligations when deploying the device.

FTC Health Breach Notification Rule

The Federal Trade Commission (FTC) Act and the FTC's updated Health Breach Notification Rule apply to health apps and connected technologies not covered by HIPAA. Medical device manufacturers developing consumer-facing or direct-to-patient products should assess whether FTC requirements apply to their data practices.

State Privacy Laws

An expanding patchwork of state comprehensive privacy statutes may apply to connected medical devices, including laws in California (CCPA/CPRA), Colorado, Connecticut, Maryland, and other jurisdictions that impose requirements related to data minimization, security safeguards, transparency, and individual rights. Nevada and Washington also maintain specific consumer health privacy laws that may be triggered by device functionality, data types collected, or downstream uses of health information.

Practical tip: Build privacy and security compliance into your device design from the start — not just FDA cybersecurity compliance. A single device incident can trigger FDA inquiry, DOJ FCA investigation, HIPAA enforcement, FTC examination, state attorney general scrutiny, and class action litigation simultaneously.

Total Product Lifecycle (TPLC) Approach to Cybersecurity

The FDA's cybersecurity framework is built on the concept of the Total Product Lifecycle (TPLC) — the principle that cybersecurity is not a premarket checkbox but an ongoing responsibility that spans from initial concept through device decommissioning.

TPLC Cybersecurity Activities by Phase

Lifecycle Phase	Key Cybersecurity Activities
Concept and planning	Define security requirements; identify applicable regulations and standards; select SPDF; establish CVD policy
Design and development	Threat modeling; security architecture; secure coding; SBOM generation; security requirements verification
Verification and validation	Penetration testing; fuzz testing; vulnerability scanning; security control validation; SBOM vulnerability correlation
Premarket submission	Compile cybersecurity documentation; prepare threat model, risk assessment, SBOM, test reports, and post-market plan
Manufacturing and release	Secure supply chain management; manufacturing environment security; release integrity verification
Post-market surveillance	Vulnerability monitoring; SBOM maintenance; CVE correlation; CISA advisory monitoring; coordinated vulnerability disclosure
Maintenance and updates	Security patch development and validation; SBOM updates; customer notification; field safety corrective actions
End of life / decommissioning	End-of-support notification; data sanitization guidance; legacy device transition planning

Secure Product Development Framework (SPDF)

The SPDF is the operational framework through which the TPLC approach is implemented. The FDA describes it as "a series of processes that identify and reduce the number and severity of vulnerabilities inherent to a product's design and features." An SPDF should encompass:

• Risk management processes (integrated with ISO 14971)
• Secure development practices (aligned with IEC 62443-4-1 and IEC 81001-5-1)
• Configuration management and change control
• Supply chain security management
• Vulnerability management processes
• Incident response and communication procedures

Cybersecurity Documentation for 510(k), De Novo, and PMA Submissions

The practical question for most manufacturers is: what exactly do I need to include in my premarket submission? The following is a consolidated summary of the cybersecurity documentation expected by the FDA, organized as it would typically appear in a submission.

Documentation Checklist

Document	Content Summary
1. System / device description	Overall description of the device, its connectivity, its operating environment, and its cybersecurity-relevant features
2. Threat model	System diagrams, trust boundaries, data flows, threat enumeration, attack vectors, mitigations
3. Cybersecurity risk assessment	Pre- and post-mitigation risk analysis, risk acceptance criteria, residual risk evaluation
4. Security requirements	Functional security requirements derived from threat model and risk assessment
5. Security architecture	Architecture diagrams, security controls at each layer, cryptographic implementations
6. SBOM	Machine-readable (SPDX or CycloneDX), complete dependency tree, known vulnerability assessment
7. Security testing reports	Vulnerability scan results, penetration test reports, fuzz test results, remediation evidence
8. Security controls documentation	Detailed description of each security control, its implementation, and its verification
9. Secure update/patch mechanism	How updates are delivered, validated, and applied; rollback capabilities
10. Post-market cybersecurity management plan	Vulnerability monitoring plan, patch management plan, communication plan
11. Coordinated vulnerability disclosure policy	Published CVD policy, reporting mechanism, response timeline commitments
12. Interoperability and integration security	How the device securely interacts with other systems (EHR, PACS, hospital networks)

Practical tip: The FDA's eSTAR (electronic Submission Template and Resource) system provides a structured format for cybersecurity documentation in premarket submissions. Use eSTAR to ensure you address each expected element and to streamline the review process.

Traceability

The FDA expects clear traceability between cybersecurity documentation elements:

• Each threat in the threat model should trace to one or more risks in the risk assessment
• Each risk should trace to one or more security requirements
• Each security requirement should trace to one or more security controls in the architecture
• Each security control should trace to one or more test cases in the testing documentation
• Each test case should trace to test results demonstrating the control's effectiveness

This traceability matrix is not optional — it is how FDA reviewers verify that the cybersecurity analysis is complete and internally consistent.

Key Cybersecurity Standards and Guidance Documents

Manufacturers must navigate a complex landscape of standards, guidance documents, and technical reports. The following table provides a consolidated reference:

Standard / Guidance	Full Title	Relevance
IEC 81001-5-1:2021	Health software and health IT systems safety, effectiveness and security — Part 5-1: Security	Primary cybersecurity process standard for health software; covers the full SDLC
IEC 62443-4-1	Secure Product Development Lifecycle Requirements	Foundation standard for secure development processes; parent of IEC 81001-5-1
IEC 62443-4-2	Technical Security Requirements for IACS Components	Component-level security technical requirements
ISO 14971:2019	Medical devices — Application of risk management	Risk management framework; cybersecurity risks must be integrated
AAMI TIR57:2016/(R)2023	Principles for medical device security — Risk management	Bridge between ISO 14971 and cybersecurity risk analysis
IEC 62304:2006+A1:2015	Medical device software — Software lifecycle processes	Software lifecycle standard; cybersecurity activities integrate with lifecycle processes
NIST CSF 2.0	Cybersecurity Framework	High-level risk-based framework for organizing cybersecurity activities
NIST SP 800-213	IoT Device Cybersecurity Guidance	Specific guidance for securing IoT devices including medical IoT
ANSI/AAMI SW96:2023	Standard for Medical Device Security — Security Risk Management for Device Manufacturers	Normative standard (not a technical information report) for security risk management; the formal standard counterpart to AAMI TIR57
AAMI TIR97:2019	Principles for medical device security — Postmarket risk management	Post-market cybersecurity risk management guidance
UL 2900-1	Software Cybersecurity for Network-Connectable Products — Part 1	Testing and assessment standard for software cybersecurity
FDA Cybersecurity Guidance (2025)	Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions	Primary FDA guidance document for premarket cybersecurity
FDA Post-Market Guidance (2016)	Postmarket Management of Cybersecurity in Medical Devices	FDA guidance for post-market cybersecurity management
MDCG 2019-16 Rev.1	Guidance on Cybersecurity for Medical Devices	EU guidance interpreting MDR/IVDR cybersecurity requirements
UL 2900-2-1	Software Cybersecurity for Network-Connectable Products — Part 2-1: Particular Requirements for Healthcare and Wellness Systems	Healthcare-specific testing and assessment requirements building on UL 2900-1
IMDRF N60	Principles and Practices for Medical Device Cybersecurity	Global harmonized framework for medical device cybersecurity across the TPLC
IMDRF N70	Principles and Practices for the Cybersecurity of Legacy Medical Devices	Global guidance on managing cybersecurity for legacy medical devices
IMDRF N73	Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity	Global guidance on SBOM generation, management, and distribution
ANSI/NEMA HN 1-2019	Manufacturer Disclosure Statement for Medical Device Security (MDS2)	Standardized form for communicating device security capabilities to healthcare organizations
IEC TR 80001-2-2	Application of risk management for IT-networks incorporating medical devices — Guidance for the communication of medical device security needs, risks and controls	Framework for communicating device security capabilities across stakeholders

Building a Medical Device Cybersecurity Program: Implementation Roadmap

For manufacturers approaching medical device cybersecurity for the first time — or restructuring an existing program to meet current requirements — the following implementation roadmap provides a practical sequence of activities.

Phase 1: Foundation (Months 1-3)

• Gap assessment: Evaluate current development processes, documentation, and security capabilities against FDA guidance and IEC 81001-5-1 requirements
• Organizational structure: Designate a Product Security Officer or cybersecurity lead. Define roles and responsibilities for cybersecurity across engineering, regulatory, quality, and post-market teams
• SPDF selection: Choose and document your Secure Product Development Framework. Many manufacturers align with IEC 62443-4-1 or IEC 81001-5-1 as the process framework
• Tool selection: Select SBOM generation tools, vulnerability scanning tools, static analysis tools, and threat modeling tools. Integrate them into existing CI/CD pipelines where possible
• Training: Ensure development teams understand secure coding practices, common vulnerability types (OWASP Top 10, CWE Top 25), and the regulatory context for cybersecurity requirements

Phase 2: Process Integration (Months 3-6)

• Threat modeling process: Establish a repeatable threat modeling process with defined inputs, outputs, roles, and review gates
• Secure coding standards: Adopt and enforce secure coding standards appropriate to your technology stack
• SBOM automation: Integrate automated SBOM generation into your build pipeline so that every build produces a current, machine-readable SBOM
• Vulnerability management process: Define how vulnerabilities are identified, triaged, assessed, remediated, and tracked
• CVD policy: Publish your coordinated vulnerability disclosure policy and establish the reporting mechanism

Phase 3: Validation and Documentation (Months 6-9)

• Security testing: Conduct penetration testing, fuzz testing, and vulnerability scanning on current products. Remediate findings.
• Documentation preparation: Compile cybersecurity documentation for premarket submissions — threat model, risk assessment, SBOM, architecture, test reports
• Traceability verification: Ensure end-to-end traceability from threats through risks, requirements, controls, and test results
• Management review: Present cybersecurity program status and risk posture to management as part of the QMS management review process

Phase 4: Ongoing Operations (Continuous)

• Post-market monitoring: Implement continuous vulnerability monitoring for all marketed devices
• Patch management: Develop, validate, and deploy security patches as vulnerabilities are identified
• SBOM maintenance: Keep SBOMs current with every software update
• Metrics and improvement: Track cybersecurity metrics (time to patch, vulnerability counts, CVD response times) and drive continuous improvement

Practical tip: Do not try to build a perfect cybersecurity program before your first submission. Start with the minimum viable program that addresses the FDA's core requirements, then iterate and improve. The FDA does not expect perfection — it expects a systematic, documented approach that demonstrates the manufacturer takes cybersecurity seriously and has the processes to manage it throughout the device lifecycle.

AAMI TIR57: Principles for Medical Device Security Risk Management

AAMI TIR57:2016/(R)2023 provides specific guidance on applying risk management principles to medical device cybersecurity. It serves as a bridge between ISO 14971 (risk management for medical devices) and cybersecurity-specific risk analysis methodologies.

Key contributions of AAMI TIR57:

• Cybersecurity risk assessment process: A structured process for identifying cybersecurity threats, vulnerabilities, and the potential for patient harm
• Asset identification: Guidance on identifying security-critical assets within the device and its operating environment
• Threat and vulnerability analysis: Methods for enumerating threats (using frameworks like STRIDE) and identifying vulnerabilities (using sources like NVD, CWE)
• Risk scoring: Guidance on scoring cybersecurity risks using likelihood of exploitation and severity of impact, integrated with the ISO 14971 framework
• Residual risk evaluation: How to assess whether residual cybersecurity risks are acceptable after controls are applied

AAMI TIR57 is explicitly referenced in the FDA's cybersecurity guidance and is recognized as a useful companion to ISO 14971 for cybersecurity risk management. Many manufacturers use it as the foundation for their cybersecurity risk assessment process.

FDA vs. EU vs. International Cybersecurity Requirements: Comparison

Aspect	FDA (United States)	EU MDR	Japan (PMDA)	Canada (Health Canada)
Primary legal basis	Section 524B of FD&C Act	MDR Annex I GSPRs (Sections 14, 17)	MHLW Ordinance; PMDA guidance	MDSAP; Health Canada cybersecurity guidance
Key guidance	"Cybersecurity in Medical Devices" (2025)	MDCG 2019-16 Rev.1	IEC 81001-5-1 enforcement	Pre-market cybersecurity expectations within MDSAP
SBOM requirement	Mandatory (statutory)	Not explicitly mandated; recommended as best practice	Required per IEC 81001-5-1	Expected in premarket submissions
Scope	"Cyber devices" (software + internet connectivity + vulnerability)	All devices with electronic programmable systems	Software-containing devices	Software-containing devices
Cybersecurity testing	Penetration testing, fuzz testing, vulnerability scanning expected	Testing expected; specific methods not prescribed	Per IEC 81001-5-1	Per MDSAP audit criteria
Post-market monitoring	Mandatory plan required by statute	Required under post-market surveillance obligations	Required	Required
CVD requirement	Mandatory (statutory)	Recommended in MDCG guidance	Not explicitly required	Expected
Key standards referenced	IEC 62443, IEC 81001-5-1, NIST CSF, AAMI TIR57	IEC 81001-5-1, IEC 62443, ISO 14971	IEC 81001-5-1 (enforced since 2024), IEC 62443	IEC 62443, ISO 14971
Enforcement mechanism	Refuse to Accept (RTA)	Notified Body assessment; non-conformity findings	Approval conditions	MDSAP audit findings
Legacy device guidance	FDA/MITRE guidance; IMDRF N70	State-of-the-art obligation applies to all devices on market	IMDRF N70 referenced	IMDRF N70 referenced

Additional International Cybersecurity Requirements

Beyond the major regulatory jurisdictions above, several other countries and international bodies have established or are developing medical device cybersecurity requirements:

Jurisdiction	Key Requirements
Singapore (HSA)	Cybersecurity Labelling Scheme for Medical Devices (CLS(MD)) — a tiered, four-level framework providing increasing security assurance. Singapore was among the first countries to implement a structured cybersecurity labeling scheme specifically for medical devices.
Australia (TGA)	The Therapeutic Goods Administration references IMDRF N60 and expects cybersecurity documentation as part of conformity assessment. Australia participates actively in IMDRF working groups and aligns its expectations with the global harmonized approach.
South Korea (MFDS)	The Ministry of Food and Drug Safety has established cybersecurity requirements for software-containing medical devices and network-connected devices, with increasing alignment to IEC 81001-5-1.
China (NMPA)	The National Medical Products Administration published guidelines on medical device cybersecurity registration review in 2022, requiring cybersecurity risk analysis, security testing, and vulnerability management documentation in registration submissions.
United Kingdom (MHRA)	Post-Brexit, the MHRA is developing its own medical device regulatory framework. The UK Medical Devices Regulations are expected to incorporate cybersecurity requirements aligned with international standards. The MHRA currently references BSI recommendations and IEC 62443.
Brazil (ANVISA)	ANVISA has incorporated cybersecurity considerations into its medical device registration requirements, with increasing alignment to IMDRF guidance.
GDHP (Global Digital Health Partnership)	Published the Guidance for Medical Device Cybersecurity (GMDC) in October 2024, providing an openly available framework with four tiered levels of cybersecurity provisions for both manufacturers and healthcare organizations.

Cybersecurity and the Quality Management System

The February 2026 implementation of the FDA's Quality Management System Regulation (QMSR) — which harmonizes FDA quality system requirements with ISO 13485 — has direct implications for how cybersecurity is managed within the manufacturer's QMS.

Integration Points

Cybersecurity processes must be integrated into the QMS at several points:

• Design and development: Cybersecurity requirements, threat modeling, and security architecture must be part of the design and development process, with defined inputs, outputs, reviews, and verification/validation activities
• Risk management: Cybersecurity risk management must be integrated with the overall risk management process (ISO 14971), not maintained as a separate, disconnected activity
• Supplier controls: Third-party software component security assessment must be part of supplier qualification and evaluation processes
• Change control: Security patches, vulnerability remediations, and SBOM updates must follow the change control process, with appropriate review, verification, and documentation
• CAPA: Cybersecurity incidents and vulnerability discoveries may trigger Corrective and Preventive Action (CAPA) processes when they indicate systemic issues
• Management review: Cybersecurity posture, vulnerability metrics, and incident summaries should be included in management review inputs
• Internal audit: The cybersecurity program should be subject to internal audit to verify compliance with procedures and regulatory requirements

Documentation Requirements Under QMSR

Under the QMSR, cybersecurity procedures, work instructions, and records must be controlled within the QMS document control system. This includes threat modeling procedures, vulnerability management SOPs, CVD policies, incident response plans, and SBOM management procedures. The June 2025 FDA cybersecurity guidance was specifically updated to align with QMSR terminology and expectations.

Common Cybersecurity Submission Deficiencies

Based on publicly available FDA feedback and industry experience, the most common cybersecurity-related deficiencies in premarket submissions include:

Deficiency	Description	How to Avoid
Incomplete SBOM	Missing transitive dependencies, non-machine-readable format, missing version information	Automate SBOM generation in CI/CD pipeline; validate completeness before submission
Vague threat model	Threat model does not define clear system boundaries, omits relevant attack vectors, or lacks specificity	Use a structured methodology (STRIDE, PASTA); document assumptions and scope explicitly
Missing traceability	No clear link between threats, risks, requirements, controls, and test results	Build a traceability matrix and review it for completeness before submission
Inadequate testing evidence	Penetration testing performed by development team; no fuzz testing; vulnerability scans run against outdated databases	Use independent testers; document tools, scope, and timing; run scans against current databases
Absent CVD policy	No published coordinated vulnerability disclosure policy or reporting mechanism	Publish a CVD policy on your website before submission; include it in the submission
Generic post-market plan	Post-market monitoring plan lacks specifics — no defined monitoring sources, response timelines, or escalation criteria	Define specific data sources, monitoring frequency, severity-based response timelines, and responsible personnel
Unaddressed known vulnerabilities	SBOM components have known CVEs with no documented risk assessment or mitigation plan	Assess every known CVE affecting SBOM components; document risk assessment and mitigation for each
Missing cloud security documentation	For cloud-hosted SaMD, no documentation of shared responsibility model or cloud provider security posture	Document cloud security architecture, shared responsibility delineation, and provider certifications
Incomplete Appendix 1 coverage	Missing one or more of the eight security control categories (Authentication, Authorization, Cryptography, Code/Data Integrity, Confidentiality, Event Detection/Logging, Resiliency, Updatability) without technical justification	Audit your DHF against all eight categories; provide implementation evidence or documented exclusion rationale for each
Insufficient penetration test evidence	Penetration testing not performed on production-equivalent device; unresolved findings without documented risk acceptance; no retest evidence for mitigated high-risk findings	Use production-equivalent builds; document mitigation or acceptance for every finding; provide original and retest reports
Inadequate cybersecurity labeling	Labeling fails to provide actionable security configuration information for end users; missing interface disclosures, support lifetime statements, or decommissioning procedures	Address all 14 FDA labeling elements (Section VI.A); ensure labeling is reviewed by clinical engineering stakeholders
Missing End-of-Support dates in SBOM	SBOM does not include End-of-Support (EOS) target dates or level-of-support status for components	Include EOS dates and support level for all components, especially those approaching end-of-life

Key Takeaways

1. Cybersecurity is now statutory law in the United States. Section 524B of the FD&C Act made cybersecurity a mandatory premarket requirement for cyber devices as of March 29, 2023. This is not guidance — it is law. Submissions that do not comply can be refused before review begins.

2. The SBOM is the single most actionable requirement. Every cyber device submission must include a machine-readable SBOM in SPDX or CycloneDX format, covering all software components including transitive dependencies. Automate SBOM generation in your build pipeline.

3. Threat modeling is a continuous process, not a document. The FDA expects threat models to be updated as the threat landscape evolves. Build threat modeling into your SDLC, not just your regulatory submission workflow.

4. Post-market cybersecurity is equally important as premarket. Vulnerability monitoring, patch management, coordinated vulnerability disclosure, and CISA advisory response are ongoing obligations that continue for the life of the device.

5. EU requirements are converging with FDA expectations. While structurally different, the EU MDR's cybersecurity GSPRs, combined with MDCG 2019-16 and the upcoming harmonization of IEC 81001-5-1, are driving toward comparable practical requirements.

6. IEC 81001-5-1 is the emerging global cybersecurity standard. Already enforced in Japan, on the EU harmonization path, and referenced by the FDA, IEC 81001-5-1 is the single standard most likely to serve as the international benchmark for medical device cybersecurity.

7. AI/ML devices face unique cybersecurity threats. Training data poisoning, adversarial attacks, and model theft are AI/ML-specific threat vectors that must be addressed in threat models and security architectures.

8. Legacy devices require active management. Devices designed before modern cybersecurity requirements still need vulnerability monitoring, compensating controls, and clear end-of-support communication.

9. Testing must be comprehensive and independent. The FDA expects penetration testing, fuzz testing, and vulnerability scanning — and recommends that penetration testing be performed by parties independent of the development team. Penetration testing must be on the production-equivalent device, with retest evidence for mitigated findings.

10. Traceability connects everything. The cybersecurity documentation in a premarket submission must demonstrate traceability from threats through risks, requirements, controls, and test results. Incomplete traceability is a common deficiency finding.

11. Cybersecurity failures now carry False Claims Act liability. The Illumina $9.8M settlement (July 2025) established that misrepresenting cybersecurity compliance to government customers can trigger FCA enforcement — even without a data breach. The DOJ recovered $52M in cybersecurity FCA cases in FY2025.

12. Cybersecurity labeling is a regulatory requirement, not an afterthought. Section VI.A of the FDA guidance defines fourteen labeling elements. Submissions are being flagged for labeling that fails to provide actionable information for hospital IT and clinical engineering teams to securely configure, operate, and decommission devices.

13. Appendix 1's eight security control categories are treated as mandatory. The FDA expects every Tier 1 submission to address Authentication, Authorization, Cryptography, Code/Data Integrity, Confidentiality, Event Detection/Logging, Resiliency, and Updatability — with implementation evidence or documented exclusion rationale.

Frequently Asked Questions

What qualifies as a "cyber device" under Section 524B?

A cyber device is a device that (1) includes software validated, installed, or authorized by the sponsor as a device or in a device, (2) has the ability to connect to the internet, and (3) contains technological characteristics that could be vulnerable to cybersecurity threats. All three criteria must be met. A purely mechanical device with no software is not a cyber device. A software device that operates entirely offline with no internet connectivity capability is not a cyber device. However, the definition is intentionally broad — most modern software-containing medical devices that have any network connectivity will qualify.

Does the SBOM requirement apply to all medical devices?

The statutory SBOM requirement under Section 524B applies only to cyber devices. However, the FDA's cybersecurity guidance recommends that manufacturers of all software-containing devices maintain an SBOM as a best practice, even if the device does not meet the cyber device definition. In the EU, while the MDR does not explicitly mandate SBOMs, the MDCG guidance and emerging harmonized standards effectively make SBOM maintenance a practical necessity for demonstrating conformity with cybersecurity GSPRs.

What SBOM format should I use — SPDX or CycloneDX?

Both SPDX (maintained by the Linux Foundation) and CycloneDX (maintained by OWASP) are acceptable to the FDA. The choice often depends on your existing toolchain and ecosystem. SPDX has broader adoption in the open-source community and is an ISO/IEC standard (ISO/IEC 5962:2021). CycloneDX has strong support in the security community and natively supports vulnerability correlation (VEX — Vulnerability Exploitability eXchange). Either format is acceptable; the critical requirement is that the SBOM is machine-readable, complete, and includes all required NTIA minimum elements.

Can the FDA refuse my submission solely for cybersecurity deficiencies?

Yes. Since October 1, 2023, the FDA may issue a Refuse to Accept (RTA) decision for premarket submissions of cyber devices that do not include the information required by Section 524B. An RTA means the FDA returns your submission without review. This is the most severe enforcement mechanism available at the premarket stage — your regulatory timeline resets entirely.

How often must I update my SBOM?

The SBOM must be updated whenever the device software is modified — whether through a planned feature update, a security patch, a third-party component upgrade, or any other change that alters the software composition. In practice, manufacturers with continuous integration/continuous deployment (CI/CD) pipelines should generate SBOMs as part of every build. The updated SBOM must be made available to customers and to the FDA upon request.

What is the relationship between cybersecurity risk assessment and ISO 14971?

Cybersecurity risk assessment should be integrated with the overall risk management process defined by ISO 14971. Cybersecurity threats are hazards that can contribute to hazardous situations leading to harm. The ISO 14971 framework — hazard identification, risk estimation, risk evaluation, risk control, and residual risk evaluation — applies to cybersecurity risks just as it does to other device risks. The FDA's guidance and AAMI TIR57 (Principles for medical device security — Risk management) provide specific guidance on integrating cybersecurity into the ISO 14971 framework.

Do I need to hire an external firm for penetration testing?

The FDA recommends, but does not mandate, that penetration testing be performed by parties independent of the development team. Using an external security testing firm is the strongest demonstration of independence, but an internal security team that was not involved in the device's design or development can also provide adequate independence. The key is that the testers have no vested interest in the test results showing a positive outcome.

How does cybersecurity interact with the new QMSR (Quality Management System Regulation)?

The QMSR, which takes effect in February 2026, harmonizes FDA's quality system requirements with ISO 13485. Under the QMSR, cybersecurity risk management must be integrated into the quality management system. This means cybersecurity processes — threat modeling, vulnerability management, patch management, incident response — must be documented within the QMS, subject to management review, and covered by internal audit. The June 2025 cybersecurity guidance was specifically updated to align with QMSR terminology and expectations.

What should I do if I discover a critical vulnerability in my device after market clearance?

Immediately assess the vulnerability's exploitability and potential impact on device safety and effectiveness. If the vulnerability presents an uncontrolled risk (a risk that is not adequately mitigated by existing controls and could lead to patient harm), you must take corrective action. This typically includes: (1) developing and validating a security patch, (2) notifying customers and providing interim mitigation guidance, (3) reporting to the FDA if the vulnerability could cause serious adverse health consequences, and (4) coordinating with CISA if appropriate. The FDA's post-market cybersecurity guidance provides a risk-based framework for determining when corrective actions and agency reporting are required.

How do international regulations interact — can I use a single cybersecurity submission for multiple markets?

While there is no single harmonized cybersecurity submission format accepted globally, the underlying technical requirements are converging. An SBOM, threat model, and risk assessment prepared for an FDA submission will substantially satisfy EU MDR, Japanese, and Canadian requirements. The key differences are in how the information is presented and evaluated — the FDA uses its own review process, the EU uses Notified Body assessment, and Japan uses PMDA review. Aligning your cybersecurity documentation with IEC 81001-5-1 provides the strongest foundation for multi-market submissions, as this standard is recognized or enforced across all major regulatory jurisdictions.

What is the difference between a "controlled" and "uncontrolled" cybersecurity risk?

This is a key concept in the FDA's post-market cybersecurity framework. A controlled risk is one where the residual risk from a vulnerability is adequately mitigated — either the vulnerability is not exploitable in the device's operating environment, the existing security controls prevent exploitation, or compensating controls reduce the risk to an acceptable level. An uncontrolled risk exists when a vulnerability could be exploited and the resulting harm is not adequately mitigated by existing controls. Uncontrolled risks require immediate remediation. The FDA's post-market guidance uses this distinction to determine whether a cybersecurity vulnerability requires agency reporting.

How does MDS2 (Manufacturer Disclosure Statement for Medical Device Security) fit into the cybersecurity landscape?

The MDS2 form is a standardized document that manufacturers provide to healthcare organizations describing the security characteristics of their devices. It covers areas such as data storage, network connectivity, authentication, audit controls, and software update capabilities. While MDS2 is not a regulatory submission document — it is not submitted to the FDA — it is a critical communication tool between manufacturers and healthcare organizations. Many hospitals and health systems require MDS2 forms as part of their device procurement process. The current version aligns with IEC 80001-1 and provides healthcare organizations with the information they need to perform their own risk assessments when integrating devices into their IT environments.

What happens if a third-party component in my SBOM has a critical vulnerability but the vendor has not yet released a patch?

This is a common scenario that the FDA expects manufacturers to address in their cybersecurity risk assessment. When a third-party component has a known critical vulnerability and no vendor patch is available, the manufacturer must: (1) assess whether the vulnerability is exploitable in the context of the device (many CVEs are not exploitable in every deployment), (2) implement compensating controls if the vulnerability is exploitable (e.g., disabling the affected feature, adding network-level controls, implementing input validation around the vulnerable component), (3) document the risk assessment and compensating controls, (4) monitor for vendor patch availability and plan for integration when available, and (5) communicate the risk and compensating controls to customers. The manufacturer cannot simply wait for the vendor to act — active risk management is required.

Can cybersecurity failures expose my company to False Claims Act liability?

Yes. The DOJ's Civil Cyber-Fraud Initiative has established cybersecurity noncompliance as a basis for FCA enforcement. In July 2025, Illumina agreed to pay $9.8 million to resolve allegations that it misrepresented cybersecurity compliance for its genomic sequencing systems sold to government agencies. Critically, this case was based on alleged noncompliance with FDA's non-binding guidance — not just statutory requirements. Any medical device manufacturer selling to government customers (DoD, VA, HHS, NIH) should ensure that cybersecurity compliance representations in contracts, procurement documents, and marketing materials are accurate and supportable by documented evidence.

What are the fourteen cybersecurity labeling elements required by the FDA?

Section VI.A of the FDA's cybersecurity guidance specifies fourteen elements that device labeling should address: device instructions and product specifications, communication interfaces, SBOM reference, security configuration guidance, secure update and patch procedures, backup and restore procedures, support lifetime statement, end-of-life and decommissioning procedures, known residual risks and compensating controls, anomaly detection and response, user-configurable security options, anti-malware considerations, minimum IT network requirements, and the MDS2 form. These elements ensure that healthcare organizations have the information needed to securely deploy, configure, operate, maintain, and decommission the device.

What changed in the February 2026 FDA cybersecurity guidance?

The February 2026 revision is a Level 2 update that replaces the June 2025 guidance to align with the Quality Management System Regulation (QMSR), which took effect on February 2, 2026. All legacy 21 CFR Part 820 (QSR) references were replaced with QMSR citations and ISO 13485:2016 subclauses. The substantive cybersecurity requirements under Section 524B remain unchanged, but the quality system framework underpinning them has shifted — cybersecurity processes must now be generated from controlled QMS processes aligned with ISO 13485. CI/CD pipelines are formally recognized as production controls under the QMSR.

Does Section 301(q) apply to post-market cybersecurity?

Yes. Failure to maintain cybersecurity measures after market authorization can result in violations under Section 301(q) of the FD&C Act, which classifies such lapses as prohibited acts. This gives the FDA independent enforcement authority for post-market cybersecurity noncompliance, beyond the premarket Refuse to Accept mechanism. This means that post-market cybersecurity is not merely a best practice — it is a legally enforceable obligation with potential consequences including warning letters, seizure, injunction, and civil monetary penalties.