Medical Device Cybersecurity Compared: FDA §524B vs EU MDR/MDCG/CRA

A comprehensive regulatory comparison of medical device cybersecurity requirements under US FDA Section 524B and the EU MDR, MDCG 2019-16, and Cyber Resilience Act (CRA).

How FDA §524B and EU MDR/CRA Cyber Regulations Compare

As medical devices become increasingly connected, regulatory bodies worldwide have shifted from treating cybersecurity as a post-market afterthought to enforcing it as a binding, premarket gateway. In the United States, the Food and Drug Administration (FDA) enforces cybersecurity under Section 524B of the Food, Drug, and Cosmetic (FD&C) Act, establishing a strict, statutory premarket gatekeeper. Non-compliance leads to an immediate Refuse-to-Accept (RTA) decision. In the European Union, medical device cybersecurity is governed by the General Safety and Performance Requirements (GSPRs) of the Medical Device Regulation (EU MDR 2017/745), detailed in the MDCG 2019-16 guidance. The EU's broader Cyber Resilience Act (CRA) (Regulation (EU) 2024/2847) largely exempts medical devices themselves from its scope (to avoid double regulation with the MDR/IVDR) but applies directly to non-medical digital products that connect to them, such as companion apps and cloud portals.

The primary difference between the two systems lies in their regulatory enforcement models:

The US FDA model relies on centralized premarket review of standardized eSTAR templates, requiring a Software Bill of Materials (SBOM), a post-market vulnerability-management plan, and a coordinated vulnerability disclosure (CVD) policy prior to commercial authorization.
The EU model relies on a decentralized conformity assessment framework where independent Notified Bodies audit technical documentation against harmonized standards (such as IEC 81001-5-3). Because the MDR/IVDR GSPRs already cover device cybersecurity, the CRA carves medical devices out of its essential cybersecurity requirements and instead catches the surrounding non-medical software ecosystem.

To help regulatory affairs managers, software engineers, and compliance officers align their global strategies, this article breaks down the operational differences, provides a side-by-side comparison matrix, outlines the 12 key premarket deliverables, and discusses the evolving EU CRA integration.

What are the binding statutory requirements for cybersecurity under FDA Section 524B?

Enacted under the Consolidated Appropriations Act of 2023, Section 524B of the FD&C Act (21 U.S.C. 360c-2) represents a fundamental shift in FDA's authority. Previously, the FDA issued cybersecurity expectations through guidance documents. Section 524B elevates these expectations into binding statutory law. It applies to any "cyber device," which the FDA defines as any device that:

Contains software or firmware (including Software as a Medical Device, or SaMD);
Has the ability to connect to the internet, local networks, or other devices (via Wi-Fi, Bluetooth, cellular, USB, or serial ports); and
Contains technological characteristics that could make it vulnerable to cybersecurity threats.

The Three Statutory Pillars of §524B

Under Section 524B(b), sponsors submitting a premarket application—including 510(k), Premarket Approval (PMA), De Novo, or Humanitarian Device Exemption (HDE) submissions—must provide "reasonable assurance" that the device is secure. This assurance requires three main deliverables:

The Software Bill of Materials (SBOM): A machine-readable, nested inventory of all software components used in the device. This must include commercial, open-source, and off-the-shelf (OTS) software.
Post-Market Vulnerability Management Plan: A formal, documented procedure within the manufacturer's Quality Management System (QMS) outlining how they will monitor, identify, and address post-market vulnerabilities and exploits in a "reasonable time."
Coordinated Vulnerability Disclosure (CVD) Policy: A public-facing protocol allowing external security researchers, clinicians, and users to report vulnerabilities directly to the manufacturer, alongside internal triage procedures to analyze and remediate those reports before they are publicly disclosed.

The eSTAR Premarket Gate: 12 Key Deliverables

The FDA's electronic Submission Template and Resource (eSTAR) enforces these requirements through an interactive checklist. If the required documentation is missing, the submission will trigger a Refuse-to-Accept (RTA) decision, stopping the review process.

A complete eSTAR cybersecurity package requires 12 specific deliverables:

Threat Model: A comprehensive diagram and narrative identifying assets, system boundaries, threat agents, and potential attack paths (typically following STRIDE or similar methodologies).
Software Bill of Materials (SBOM): Generated in standard formats such as CycloneDX or SPDX, detailing component names, versions, license types, and dependency relationships.
Security Requirements Document: A specification listing all security controls (e.g., authentication, encryption, integrity verification) mapped to the risks identified in the threat model.
Security Architecture Design: A block diagram and protocol description showing how data flows between the device, local networks, companion mobile apps, and cloud servers.
Vulnerability Assessment / Penetration Testing Report: Proof of active testing, including static application security testing (SAST), dynamic testing (DAST), software composition analysis (SCA), and manual penetration testing.
Unresolved Anomalies Table: A complete log of all known software bugs and vulnerabilities that remain in the release version, along with a documented risk justification explaining why they do not compromise patient safety.
Post-Market Vulnerability Management Plan: Procedures detailing how the manufacturer will monitor threat intelligence feeds, scan for vulnerabilities (e.g., matching the SBOM against the National Vulnerability Database), and distribute patches.
Coordinated Vulnerability Disclosure (CVD) Program: A link to the manufacturer's public CVD portal and the internal standard operating procedure (SOP) for triage.
Secure Update and Patching Mechanism: Technical documentation describing how patches are digitally signed, verified, and installed on the device without introducing integrity risks.
User Instructions for Security: A customer-facing security guide detailing network configuration requirements, password management policies, and incident response contacts.
Cybersecurity Labeling and Instructions for Use: Customer-facing labeling and security instructions detailing network configuration requirements, password management policies, how to receive security updates, and incident-response contacts.
Declaration of Conformity to Cybersecurity Standards: Formal statements confirming alignment with FDA-recognized consensus standards, such as ANSI/AAMI SW96:2023 (Medical Devices - Security, risk management, and security-by-design).

Integration of SPDF under the Quality Management System Regulation (QMSR)

On February 2, 2026, the FDA's new Quality Management System Regulation (QMSR) became fully effective, incorporating ISO 13485:2016 by reference and replacing the old Quality System Regulation (21 CFR Part 820). To align the cybersecurity guidance with QMSR, the FDA issued an updated final guidance on February 3, 2026 (Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions), which superseded the June 27, 2025 version and replaces 21 CFR 820 citations with QMSR citations. This update has critical implications for how manufacturers structure their Secure Product Development Framework (SPDF):

Design Controls (ISO 13485 Clause 7.3 / 21 CFR 820.30): Cybersecurity requirements must be integrated directly into design inputs. Security specifications cannot be treated as separate documents; they are treated as product requirements that must be verified through testing and validated under simulated use conditions.
Risk Management (ISO 13485 / ISO 14971): Security risk management must follow the same lifecycle structure as safety risk management. Under the QMSR, manufacturers must prove that their security controls do not introduce clinical safety hazards (e.g., ensuring an encryption routine does not increase processor load to the point where telemetry alerts are delayed).
Control of Nonconforming Product (ISO 13485 Clause 8.3): A cybersecurity vulnerability identified post-market is classified as a nonconforming product. Manufacturers must use their corrective and preventive action (CAPA) systems to investigate, implement fixes, and verify that the vulnerability has been closed.

How does the EU MDR and MDCG 2019-16 govern medical device cybersecurity?

Unlike the US, where cybersecurity is governed by a standalone statute (§524B), the European Union regulates cybersecurity as an integral component of the general safety and clinical performance of the device. Under the EU Medical Device Regulation (EU MDR 2017/745), cybersecurity requirements are embedded in the General Safety and Performance Requirements (GSPRs) of Annex I:

GSPR 17.2: Requires manufacturers to design software-enabled devices to ensure repeatability, reliability, and performance. It mandates that manufacturers take into account the principles of development lifecycle, risk management (including information security), verification, and validation.
GSPR 17.4: Explicitly requires manufacturers to set out minimum requirements concerning hardware, IT networks, and security measures against unauthorized access, including protection against tampering.
GSPR 22.2: Mandates that devices connectable to other systems or networks must be designed to prevent unauthorized modifications or data breaches.

The Role of MDCG 2019-16 Rev 1

Because the GSPRs are high-level legislative requirements, the Medical Device Coordination Group (MDCG) published MDCG 2019-16 Rev 1 (Guidance on Cybersecurity for Medical Devices) to provide an operational framework.

MDCG 2019-16 Rev 1 maps the GSPRs to international consensus standards, primarily IEC 81001-5-3 (Health software — Part 5-3: Security — Secure lifecycle activities). The guidance emphasizes that cybersecurity must be managed within the manufacturer's QMS under ISO 13485 and integrated with the medical device risk management process under ISO 14971.

Under this European model, conformity is assessed by Notified Bodies (such as TÜV SÜD, BSI, or DQS). Notified Bodies audit the Technical Documentation (TD) as part of the CE marking process. A manufacturer cannot place a Class IIa, IIb, or III device on the market without a Notified Body certificate confirming that the GSPR cybersecurity requirements have been met.

Post-Market Obligations in the EU

Under the EU MDR, post-market clinical follow-up (PMCF) and post-market surveillance (PMS) are highly structured. Manufacturers must establish a PMS plan that actively collects cybersecurity feedback. If a vulnerability represents a serious public health threat or requires a field safety corrective action (FSCA), it must be reported to the national competent authorities (such as BfArM in Germany or ANSM in France) through the EUDAMED database or via national vigilance channels.

How does the EU Cyber Resilience Act (CRA) overlay existing MDR requirements?

To strengthen the cybersecurity of all digital products sold in the single market, the EU enacted the Cyber Resilience Act (CRA) (Regulation (EU) 2024/2847). The CRA applies to all "products with digital elements"—including connected hardware and standalone software.

The Exemption Boundary and the Double-Regulation Risk

The CRA includes a carve-out for medical devices. Article 2(2) of Regulation (EU) 2024/2847 exempts products governed by the MDR (2017/745) and IVDR (2017/746) from the CRA's essential cybersecurity requirements, to prevent double regulation — their cybersecurity is already covered by the MDR/IVDR GSPRs. However, this carve-out creates a practical boundary that manufacturers must navigate carefully:

The Core Device: The medical device itself (e.g., an insulin pump) is exempt from the CRA's essential requirements.
The Digital Ecosystem: Companion apps, remote monitoring cloud portals, or update servers that do not meet the definition of a medical device but connect to it are not exempt. They fall directly under the CRA, forcing manufacturers to maintain dual compliance tracks.

For more details on this initial boundary, refer to our comprehensive EU Cyber Resilience Act (CRA) and NIS2 guide.

The December 2025 MDR/IVDR Simplification Proposal (and the CRA Exemption Today)

On 16 December 2025, the European Commission published a targeted simplification package (Proposal COM(2025) 1023 final) amending the MDR (2017/745) and IVDR (2017/746). The proposal is aimed at reducing administrative burden and does not remove the CRA's medical-device carve-out. Its cybersecurity-relevant measures instead focus on the MDR/IVDR framework itself:

Software Classification: Amendment of MDR Rule 11 so that more medical-device software (MDSW) can qualify as Class I, lowering conformity-assessment burden for lower-risk software.
Risk-Based Re-Certification: Removal of the fixed five-year notified-body certificate validity in favor of a risk-based re-certification approach.
Digitalisation: Expanded use of electronic instructions for use (eIFU) and digital compliance tools, plus timelines for completing conformity assessments.
Innovation Pathways: New routes for breakthrough and orphan devices, and broader in-house device flexibility for health institutions.

The CRA's exemption for medical devices therefore remains in force: under CRA Article 2(2), products covered by the MDR (2017/745) and IVDR (2017/746) are outside the CRA's essential cybersecurity requirements, and their cybersecurity is instead governed by the MDR/IVDR GSPRs and MDCG 2019-16. Note that this proposal is still moving through the ordinary legislative procedure (European Parliament and Council) and is not yet law — expected adoption is around 2027 — so manufacturers continue under the existing MDR/IVDR frameworks and the CRA as currently in force.

US FDA §524B vs. EU MDR/CRA: Side-by-Side Comparison Matrix

Feature / Requirement	US FDA (Section 524B / eSTAR)	EU MDR (GSPR 17.2, 17.4) + CRA Overlay
Statutory Basis	FD&C Act §524B (codified statutory law)	Regulation (EU) 2017/745 (MDR) + Regulation (EU) 2024/2847 (CRA)
Enforcement Mechanism	Premarket review by FDA; Refuse-to-Accept (RTA) hold for incomplete eSTAR templates	Conformity assessment by independent Notified Bodies; CE marking authorization
Pre-market Deliverables	12 eSTAR deliverables (Threat Model, SBOM, CVD, etc.)	Technical Documentation (TD) mapping GSPRs; conformity certificate
SBOM Formats & Standards	Machine-readable cycloneDX or SPDX mandatory	Recommended under MDCG 2019-16; mandatory under CRA integration
Post-market Plan	Mandatory submission of a detailed Vulnerability Management Plan	Mandatory integration into QMS PMS/PMCF plans
CVD Expectations	Public-facing portal and triage SOP required	Required under CRA; managed through national CSIRTs and EUDAMED
Vulnerability Reporting	Disclosed through CVD; mandatory reporting only if it triggers a recall (21 CFR 806) or adverse event (21 CFR 803)	Early warning to ENISA/CSIRTs within 24h, full notification within 72h (CRA Art. 11, from 11 Sept 2026)
Patch Management Guidance	Exempt from 510(k) if patch does not alter device intent; requires 21 CFR 820.30 logs	Routine maintenance documented under design controls; major patches require NB notification
Primary Standard Alignment	ANSI/AAMI SW96:2023, AAMI TIR57, UL 2900-1	IEC 81001-5-3, ISO 14971, ISO 13485
Compliance Deadlines	§524B effective 29 March 2023; guidance updated 27 June 2025 and 3 Feb 2026 (QMSR-aligned)	MDR in force; CRA reporting applies from 11 Sept 2026, full application by 11 Dec 2027

Strategic Implementation: A Unified Secure Product Development Framework (SPDF)

To avoid duplicating engineering work, global manufacturers should implement a unified Secure Product Development Framework (SPDF) that satisfies both the FDA's eSTAR deliverables and the EU's GSPRs simultaneously.

+-----------------------------------------------------------------------+
|                       Global QMS (ISO 13485)                          |
+-----------------------------------------------------------------------+
                                   |
         +-------------------------+-------------------------+
         |                                                   |
         v                                                   v
+------------------+                               +--------------------+
|  US FDA §524B    |                               | EU MDR / CRA GSPRs |
+------------------+                               +--------------------+
| - eSTAR Template |                               | - IEC 81001-5-3    |
| - CycloneDX SBOM |                               | - Notified Body TD |
| - CVD Public SOP |                               | - ENISA Reporting  |
+------------------+                               +--------------------+
         |                                                   |
         +-------------------------+-------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|               Unified Product Threat Model & Security Controls        |
+-----------------------------------------------------------------------+

Steps to Build a Harmonized SPDF

1. Standardize on IEC 81001-5-3

The FDA recognizes IEC 81001-5-3 as a consensus standard, and it is the primary benchmark for EU Notified Bodies. By structuring your software lifecycle (from requirements through testing to decommissioning) around this standard, you build a documentation trail that satisfies both jurisdictions.

2. Design a Single Machine-Readable SBOM

Do not maintain separate SBOMs for different markets. Generate a single, automated SBOM in CycloneDX format at every software build. Ensure the SBOM captures:

Author/Manufacturer name
Component name and version
Unique identifiers (CPE or PURL)
Dependency relationships (e.g., component A contains component B)
Cryptographic hashes of components

3. Align Risk Assessments (ISO 14971 + AAMI TIR57)

Integrate cybersecurity risk assessments directly with your clinical risk assessments. A cybersecurity vulnerability should map to its potential clinical impact:

Use AAMI TIR57 (Principles for medical device security—Risk management) to evaluate security threats.
Use ISO 14971 to determine if those security threats can lead to an unacceptable clinical hazard (e.g., a dosing error or delayed therapy).

4. Establish a Single Global CVD Portal

Maintain a single, public-facing Coordinated Vulnerability Disclosure portal (e.g., security.yourcompany.com). Your internal SOP should route incoming reports to a unified triage committee. This committee can then assess whether a report triggers a 24-hour ENISA notification in the EU, or a design control record under the FDA's 21 CFR 820.30.

Exceptions, Risk Boundaries, and Edge Cases

While the regulations are broad, manufacturers must navigate several technical edge cases:

Legacy Devices

US FDA: If a manufacturer submits a new 510(k) or PMA for an update to a legacy device, the entire device may be subject to Section 524B review. Simply adding a new software feature to a device cleared in 2018 can trigger a complete cybersecurity review of the base platform.
EU MDR: Legacy devices (MDD-certified devices sold under MDR transition periods) are generally exempt from Notified Body cybersecurity audits until they undergo a significant change in design or intended purpose. However, they remain subject to general post-market vigilance requirements.

Software-only updates (Patching vs. New Submission)

FDA Gate: Under FDA guidelines, cybersecurity patches that do not change the device's intended use or control algorithm are typically exempt from premarket notification. They must be documented under the manufacturer's design controls (21 CFR 820.30).
EU Notified Body Gate: In the EU, a security patch that alters software architecture (e.g., replacing an outdated authentication library) may be considered a "significant change" under Article 120, requiring notified body review before deployment.

Standalone Software (SaMD) vs. Embedded Software

Embedded software is assessed as part of the physical device containment. Standalone Software as a Medical Device (SaMD)—such as an AI diagnostic algorithm running in a browser—faces higher cloud-security scrutiny. Threat models for SaMD must focus heavily on API endpoints, database security, and cloud infrastructure, whereas embedded software threat models focus on physical access ports and local wireless protocols.

Frequently Asked Questions

Can the FDA refuse to accept a 510(k) submission based solely on cybersecurity deficiencies?

Yes. The FDA's Refuse-to-Accept (RTA) policy includes a dedicated checklist for cybersecurity. If a submission for a "cyber device" does not contain an SBOM, a post-market vulnerability management plan, and evidence of secure design (such as a threat model), the FDA will issue an RTA hold. The submission will not proceed to substantive review until these documents are provided.

Does the EU Cyber Resilience Act (CRA) apply to medical devices already certified under the MDR?

No — for the device itself. Under CRA Article 2(2), medical devices governed by the MDR (2017/745) and IVDs under the IVDR (2017/746) are excluded from the CRA's essential cybersecurity requirements, because the MDR/IVDR GSPRs (interpreted via MDCG 2019-16) already regulate their cybersecurity. What the CRA does catch are the non-medical digital products that connect to the device — companion mobile apps, remote-monitoring cloud portals, and update servers that do not themselves meet the medical-device definition. The European Commission's December 2025 MDR/IVDR simplification proposal (COM(2025) 1023 final) does not change this carve-out; it focuses on software classification, re-certification, and digitalisation within the MDR/IVDR rather than on bringing devices into the CRA.

What is the reporting window for active cybersecurity exploits in the US vs. the EU?

In the US: The FDA does not require immediate notification of actively exploited vulnerabilities unless they lead to an adverse event (21 CFR 803) or require a voluntary correction or removal (21 CFR 806).
In the EU: Under the Cyber Resilience Act, from 11 September 2026 manufacturers must submit an early warning to national CSIRTs and ENISA within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, followed by a full notification within 72 hours and a final report within 14 days (vulnerabilities) or one month (severe incidents).

What role does the Software Bill of Materials (SBOM) play in post-market vulnerability monitoring?

The SBOM serves as the database schema for post-market monitoring. Without a machine-readable SBOM, manufacturers cannot automate vulnerability scanning. When a new vulnerability (CVE) is published in the National Vulnerability Database (NVD), the manufacturer's automated scanner matches the CVE's software identifiers (CPE/PURL) against the active SBOMs of all devices in the field. This allows the manufacturer to identify affected devices and initiate the remediation/patching workflow before an exploit occurs.

Conclusion: Cybersecurity as a Continuous Gate

Medical device cybersecurity is no longer a static checklist completed at the time of submission. It is a continuous regulatory gate. Under FDA Section 524B and the evolving EU MDR/CRA frameworks, manufacturers are legally obligated to maintain active vigilance over their software ecosystems.

By building a harmonized Secure Product Development Framework based on IEC 81001-5-3, maintaining automated CycloneDX SBOMs, and implementing a unified Coordinated Vulnerability Disclosure process, manufacturers can secure their products, protect patient safety, and maintain uninterrupted access to both the US and European markets.

References

US FDA Guidance: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (final guidance updated 27 June 2025 and 3 February 2026 to align with QMSR; supersedes the 27 September 2023 version). FDA Source
MDCG Guidance (2019-16 Rev 1): Guidance on Cybersecurity for Medical Devices. European Commission Source
EU Regulation (EU) 2024/2847: Regulation on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Eur-Lex Source
European Commission (16 December 2025): Proposal COM(2025) 1023 final to simplify the MDR and IVDR. European Commission — New Regulations
ANSI/AAMI SW96:2023: Medical devices — Security, risk management, and security-by-design.
IEC 81001-5-3: Health software — Part 5-3: Security — Secure lifecycle activities.