Section 524B of the FD&C Act, added by the Consolidated Appropriations Act 2023, requires manufacturers of cyber devices to submit a Software Bill of Materials, a vulnerability handling plan, and a cybersecurity lifecycle strategy with their FDA premarket submissions. The MDR reaches the same territory through Annex I §17.2, §17.4, and the cybersecurity expectations elaborated in MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022. The frameworks converge on substance but diverge on mechanism — understanding both lets a startup build one cybersecurity programme that serves both markets.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Section 524B of the FD&C Act was added by the Consolidated Appropriations Act 2023 and applies to cyber devices submitted to the FDA.
  • A "cyber device" under 524B is a device that includes software validated, installed, or authorised by the sponsor and has the ability to connect to the internet, and contains features that could be vulnerable to cybersecurity threats.
  • 524B requires an SBOM, a vulnerability disclosure and handling plan, a monitoring and update lifecycle plan, and reasonable assurance of cybersecurity throughout the lifecycle.
  • The MDR reaches similar outcomes via Annex I §17.2 (software lifecycle) and §17.4 (IT security measures), supported by MDCG 2019-16 Rev.1 and harmonised via EN IEC 81001-5-1:2022.
  • The EU framework is arguably broader in scope (all software in devices, not just connectable devices) but less prescriptive about specific submission content.
  • A single cybersecurity programme built around EN IEC 81001-5-1:2022 and a SBOM-first posture satisfies the core of both regimes.

Why this matters

Cybersecurity is one of the few MedTech regulatory areas where the FDA moved faster than the EU on specific submission content. Section 524B of the FD&C Act created enforceable premarket content requirements for cyber devices — no SBOM, no clearance. The MDR got there via a different route: general safety and performance requirements in Annex I that the Notified Body interprets in light of MDCG 2019-16 Rev.1 and increasingly expects to see backed by EN IEC 81001-5-1:2022 evidence.

For a startup building a connected medical device — a wearable, a remote monitoring platform, an imaging AI that integrates with hospital PACS — cybersecurity is now a hard gate in both regimes. Treating it as a compliance checklist is a trap. Treating it as a lifecycle engineering discipline is the path that survives inspection.

What the regulations actually say

FDA side — Section 524B. The PATCH Act provisions were enacted via the Consolidated Appropriations Act 2023 and added Section 524B to the Federal Food, Drug, and Cosmetic Act. The section applies to sponsors of cyber devices submitting premarket submissions (510(k), De Novo, PMA). Key obligations:

  1. Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure.
  2. Design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and make available postmarket updates and patches.
  3. Provide a Software Bill of Materials, including commercial, open-source, and off-the-shelf software components.
  4. Comply with such other requirements as the FDA may establish through regulation.

The FDA's premarket cybersecurity guidance (the September 2023 final guidance, with subsequent updates) expands on what the agency expects in each of these areas — threat modelling, security risk management, architectural views, security testing, SBOM format expectations (SPDX, CycloneDX), and postmarket vulnerability management.

MDR side. Annex I Chapter II §17.2 of Regulation (EU) 2017/745 requires that software forming part of a device or that is itself a device "shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation." Annex I §17.4 requires manufacturers to "set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended."

MDCG 2019-16 Rev.1 elaborates what this means in practice — secure design, threat modelling, vulnerability management, secure update mechanisms, and lifecycle security. EN IEC 81001-5-1:2022 is the harmonised standard for health software and health IT system security activities in the product life cycle; it is the most concrete evidence route for showing compliance with §17.2 and §17.4.

Where they converge. Both regimes want evidence of: - A threat model and security risk analysis integrated with the overall risk management process. - A SBOM covering all software components including SOUP/OTS and open-source. - A vulnerability management process with defined SLAs for triage, assessment, and remediation. - Secure update mechanisms. - A postmarket cybersecurity lifecycle plan. - Coordinated vulnerability disclosure arrangements.

Where they diverge. The FDA is more prescriptive about submission content — Section 524B makes the SBOM and vulnerability handling plan mandatory premarket deliverables, and the FDA guidance specifies format expectations in substantial detail. The MDR approach is outcome-focused: demonstrate compliance with §17.2 and §17.4 through any adequate means, though in practice using EN IEC 81001-5-1:2022 gives presumption of conformity and is the cleanest path.

The EU scope of "security requirements" technically covers any device with software, not just connectable ones — though the depth of expected evidence scales with risk and connectivity. The FDA scope under 524B is specifically cyber devices (connectable, software-containing, cybersecurity-vulnerable).

A worked example

A startup makes a Class IIa wearable cardiac event recorder with a Bluetooth-connected phone app and a cloud backend. They plan a simultaneous FDA 510(k) submission and MDR technical documentation submission to their Notified Body.

Their cybersecurity evidence package, built once, includes:

  1. Threat model — STRIDE-based, covering the device, the app, the backend, and the communication channels. Integrated with their EN ISO 14971 risk management file so that security risks feed the same risk register as safety risks.
  2. SBOM — generated automatically from their CI/CD pipeline in CycloneDX format, updated on every release. Covers firmware, mobile app, and backend services.
  3. Vulnerability management procedure — defines triage SLAs (critical within 72 hours, high within 7 days), monitors NVD and vendor advisories for SBOM components, and includes a coordinated vulnerability disclosure policy published on the company website.
  4. Security testing — penetration testing of the Bluetooth interface, static analysis of the firmware, dynamic testing of the backend API. Reports archived and referenced in the technical file.
  5. Secure update mechanism — signed firmware updates, rollback protection, and a documented update deployment playbook.
  6. Postmarket cybersecurity plan — monitoring, patching, user communication, and decommissioning procedures.

For the FDA submission, they package the above into the 524B-required sections of the 510(k) (SBOM, vulnerability handling plan, lifecycle plan). For the MDR technical documentation, they map the same evidence to Annex I §17.2 and §17.4 via their EN IEC 81001-5-1:2022 conformity report.

One engineering programme, two submission-ready packages. The team saved an estimated eight weeks of duplicated documentation work by designing the evidence structure around both regimes from the start.

The Subtract to Ship playbook

Step 1 — Build SBOM generation into CI/CD on day one. Do not treat the SBOM as a pre-submission document. Generate it automatically on every build, in a standard format (CycloneDX or SPDX), and store it as an artefact. This is cheap if you do it from the start and expensive if you retrofit.

Step 2 — Adopt EN IEC 81001-5-1:2022 as your cybersecurity backbone. The standard gives you the process scaffolding — security requirements, secure design, implementation, verification, release, and postmarket activities. Use it as your SOP source and map both MDR and FDA expectations to its clauses.

Step 3 — Integrate security risk into your ISO 14971 risk management process. Do not maintain a separate cybersecurity risk register. Extend the existing one with security-specific hazards, threats, and controls. Your Notified Body and the FDA both want to see integration, not parallelism.

Step 4 — Write one vulnerability handling procedure that serves both regimes. It should include monitoring sources, triage SLAs, assessment criteria, remediation decision logic, disclosure timing, and user communication templates. Reference it from both your MDR technical documentation and your 524B submission.

Step 5 — Publish a coordinated vulnerability disclosure policy. A public CVD policy is an FDA expectation under 524B and an implicit MDR expectation under state-of-the-art. Keep it simple: a security.txt file on your website pointing to a reporting address and a stated response SLA.

Step 6 — Plan postmarket cybersecurity activities as a product function, not a compliance artefact. Monitoring, patching, updating, and decommissioning are ongoing activities that need budget and headcount. Include them in your product roadmap and your PMS plan.

Step 7 — Run a tabletop exercise before your first audit. Simulate a critical vulnerability disclosure and walk through your entire response process. Gaps become visible in rehearsal that never surface in document review.

The subtraction move: one threat model, one risk file, one SBOM pipeline, one vulnerability procedure, one disclosure policy. Do not build two cybersecurity programmes.

Reality Check

  1. Is your SBOM generated automatically from your build pipeline, or is it a manually maintained spreadsheet?
  2. Can you show a threat model that covers the device, the communication channels, and any backend services, and that is integrated with your EN ISO 14971 risk file?
  3. Do you have a documented vulnerability management procedure with defined triage SLAs, or do you handle vulnerabilities reactively?
  4. Have you published a coordinated vulnerability disclosure policy that a security researcher could act on today?
  5. Can your device receive signed, authenticated updates with rollback protection, or is updating a manual process?
  6. Is your cybersecurity evidence structured around EN IEC 81001-5-1:2022 clauses so it maps cleanly to both MDR §17.2/§17.4 and FDA 524B expectations?
  7. Does your postmarket surveillance plan explicitly include cybersecurity monitoring and response activities?
  8. Have you rehearsed your vulnerability response process end-to-end?

Frequently Asked Questions

Does Section 524B apply to my device? Section 524B applies to "cyber devices" — devices that contain software validated, installed, or authorised by the sponsor, have the ability to connect to the internet, and contain technological features that could be vulnerable to cybersecurity threats. A fully offline standalone device without connectivity is typically outside 524B scope. A connected wearable, cloud-backed app, or hospital-networked device is in scope.

Do I need a SBOM for MDR even though the MDR does not explicitly require one? In practice, yes. Notified Bodies increasingly expect a SBOM as evidence of component traceability and vulnerability management capability under Annex I §17.2 and §17.4. It is also required under EN IEC 81001-5-1:2022. Treat the SBOM as de facto mandatory for any software-containing device.

What SBOM format should I use? CycloneDX and SPDX are the two widely accepted formats. The FDA accepts both. The EU does not mandate a format but these are the industry standards. Pick one and stick with it across your programme.

Is MDCG 2019-16 still current? MDCG 2019-16 Rev.1 (July 2020) remains the primary MDCG guidance on cybersecurity for medical devices. Check the European Commission's MDCG page for any superseding revision before submission.

How strict are FDA and Notified Bodies on postmarket vulnerability response times? Neither regulator publishes fixed SLAs, but both expect reasonable and documented timelines proportionate to risk. A critical vulnerability in a connected device should be triaged in hours, assessed in days, and remediated in a defined window that you can justify. Document your SLAs and follow them.

Can I rely on a third-party cloud provider's security controls? You can rely on them, but you cannot delegate your obligation. The FDA and the Notified Body hold you responsible for the security of the device and related systems, including cloud backends. You need to evidence due diligence on the provider, clear contractual responsibilities, and your own monitoring.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter II §17.2, §17.4.
  2. Section 524B of the Federal Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act 2023.
  3. MDCG 2019-16 Rev.1 (July 2020) — Guidance on Cybersecurity for medical devices.
  4. EN IEC 81001-5-1:2022 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle.
  5. US FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions — final guidance (September 2023).