FDA premarket cybersecurity for medical devices: Section 524B explained

Section 524B, "Ensuring Cybersecurity of Devices," was added to the FD&C Act by the Consolidated Appropriations Act, 2023 (Public Law 117-328, Division FF, Title III, Section 3305), enacted 29 December 2022. The amendment took effect 90 days after enactment, on 29 March 2023; submissions made before that date are not subject to it. It is codified at 21 U.S.C. § 360n-2.

Section 524B(c) defines a cyber device as 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 validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.

All three conditions apply together. A device with embedded software but no network connectivity at all falls outside the definition; FDA's own FAQ page uses this same three-part description.

How broadly does FDA read "ability to connect to the internet"?

Broadly. Section VII.B of FDA's February 2026 premarket guidance says a device has this ability if it can connect "whether intentionally or unintentionally, through any means." FDA also counts firmware and programmable logic as software. Its illustrative list of qualifying features:

• network, server or cloud service provider connections;
• radio-frequency links such as Wi-Fi, cellular, Bluetooth and Bluetooth Low Energy;
• magnetic inductive communications, for example between an implant and its external programmer;
• hardware connectors that can reach the internet, such as USB, Ethernet and serial ports.

A footnote covers the common edge case. A device serviced over USB, even briefly, "is therefore considered to have the ability to connect to the internet." Most products with a service port therefore fall in scope.

FDA's plain-language summary of the Section 524B(b) duties groups them as:

See vulnerability disclosure policy template for a starting point on the coordinated disclosure piece, and firmware SBOM for building the SBOM itself when source code is incomplete.

FDA has reissued and retitled its main premarket cybersecurity guidance more than once as it folds in statutory and quality-system changes: a 2014 original, a 27 September 2023 final version titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," a 27 June 2025 update adding a section specifically on Section 524B cyber devices, and a further retitling to "...Quality Management System Considerations..." to align with FDA's new Quality Management System Regulation (21 CFR Part 820). The current version on FDA's guidance page was issued on 3 February 2026 under docket FDA-2021-D-1158. It states that it supersedes the 27 June 2025 version, and it ties its recommendations to ISO 13485 subclauses as incorporated by the QMSR. Always check FDA's live guidance page for the current version and date before citing a specific title or date, since this document has already been superseded multiple times.

SBOM format: machine-readable, not a mandated schema

The guidance does not mandate CycloneDX or SPDX by name. It asks for a machine-readable SBOM consistent with the minimum elements identified in NTIA's October 2021 "Framing Software Component Transparency" document, and states that industry-accepted SBOM formats are encouraged. In practice, CycloneDX and SPDX are the two formats most device makers already use to meet that machine-readable expectation; see firmware SBOM for how each compares for embedded devices.

What must the SBOM documentation add?

Section V.A.4 of the guidance asks for more than the component list. For each component, and for the device as a whole, the submission should cover:

Source: FDA, Cybersecurity in Medical Devices (3 February 2026), Section V.A.4(b).

FDA also wants the SBOM kept "as part of the device's configuration management" and updated whenever the software in marketed devices changes. The SBOM minimum elements guide covers the newer CISA field baseline, which goes further than the NTIA 2021 document FDA cites.

Appendix 4 of the guidance collects the recommended documents in one table. It also says documentation should "scale with the cybersecurity risk" of the device: a product with one USB port needs fewer architecture views than a networked, cloud-connected system. Mapped to the three statutory duties:

The "mainly supports" column is SoftWSP's reading of Section VII.C; FDA says Appendix 4 as a whole demonstrates the 524B(b)(2) assurance.

The three metrics FDA recommends tracking are the percentage of identified vulnerabilities that are updated or patched, the time from identification to patch, and the time from patch availability to deployment in fielded devices.

FDA recommends that the statutory plan contain what Section VI.B of the guidance lists for a cybersecurity management plan:

• personnel responsible;
• sources, methods and frequency for monitoring vulnerabilities, for example researchers, NIST NVD and third-party software makers;
• identifying and addressing vulnerabilities in CISA's Known Exploited Vulnerabilities Catalog;
• periodic security testing;
• timeline to develop and release patches, and the update process;
• patching capability, meaning the rate at which an update can reach devices;
• the coordinated vulnerability disclosure process;
• how forthcoming remediations, patches and updates will be communicated to customers.

Two patch clocks. Section 524B(b)(2)(A) requires updates for "known unacceptable vulnerabilities" on a "reasonably justified regular cycle." Section 524B(b)(2)(B) requires updates for critical vulnerabilities that could cause uncontrolled risks "as soon as possible out of cycle." FDA asks the plan to state the timeline for each, with the justification. Its own example contrasts a connected thermometer with a surgical robot: the regular cycle depends on risk.

For how industry groups set concrete deadlines, see the HSCC Joint Security Plan. For the disclosure policy, start from the VDP template.

Section V.C of the guidance lists test types to consider for the submission, beyond standard software verification:

• Security requirements testing, with evidence that each design input was implemented, plus boundary analysis.
• Threat mitigation testing against the threat models and architecture views.
• Vulnerability testing as described in ANSI/ISA 62443-4-1: abuse and misuse cases, malformed inputs, robustness and fuzz testing, attack surface analysis, vulnerability chaining, closed box scanning for known vulnerabilities, "software composition analysis of binary executable files," and static and dynamic code analysis, including checks for hard-coded and default credentials.
• Penetration testing, with a report that states tester independence and expertise, scope, duration, methods and results.

For third-party test reports, FDA asks for the original report. For every finding, the manufacturer gives its assessment, including why a fix is not implemented or is deferred to a later release.

Section 524B applies to every 510(k), PMA, PDP, De Novo or HDE submission for a cyber device, including modifications. Section VII.D of the guidance scales the content to the change:

Either way, FDA says it will "take into account known cybersecurity concerns" for the device during review.

FDA backed Section 524B with a specific refuse-to-accept (RTA) policy, published as a Federal Register notice on 30 March 2023 (88 FR 19148, Docket FDA-2023-D-1030). FDA described a transition period during which it generally did not issue RTA decisions for premarket submissions based solely on missing Section 524B information, instead working with sponsors through the interactive or deficiency-review process, before full RTA enforcement began on 1 October 2023. From that date, a cyber device submission that lacks the required cybersecurity information can be refused before FDA even begins substantive review, which is a harder stop than a deficiency letter during review.

Section 524B's premarket duties sit alongside FDA's older "Postmarket Management of Cybersecurity in Medical Devices" guidance (final, December 2016), which covers how manufacturers should manage cybersecurity risk after a device is marketed and distributed: monitoring, risk assessment, and timely patching across the product's life. A cyber device's premarket vulnerability-monitoring plan is, in effect, the forward-looking commitment that the 2016 postmarket guidance expects manufacturers to execute on.

The shape of Section 524B — an SBOM, a vulnerability-handling and disclosure process, and a patching duty — closely parallels the EU Cyber Resilience Act's Annex I Part II requirements (SBOM, coordinated vulnerability disclosure, fixing without delay); see CRA Annex I explained. Medical devices are explicitly excluded from the EU's RED cybersecurity delegated act and EN 18031 (Regulation (EU) 2017/745 and 2017/746 devices are carved out of Delegated Regulation (EU) 2022/30); see EN 18031 explained for firmware teams for that exclusion. In other words, a connected medical device maker selling into both the US and EU needs the FDA 524B package and a separate, CRA-aligned package — the underlying engineering work (SBOM, disclosure process, patch pipeline) overlaps heavily, but the legal submissions do not substitute for each other.

SoftWSP's firmware pipeline builds the machine-readable SBOM Section 524B requires, then matches each identified component against known CVE, CISA KEV and EPSS data. AI-assisted analysis drafts the plain-language vulnerability report from those matches — which component, which CVE, whether it's KEV-listed or carries a high EPSS score — so an engineer can decide what belongs in the submission's vulnerability-monitoring narrative faster than manual component research allows. Every drafted finding is reviewed before it reaches a report, and the AI never invents a finding the underlying scan didn't produce. SoftWSP's AI does not write the coordinated-disclosure policy or the secure-update process Section 524B also requires.

SoftWSP builds SBOMs from device firmware, matches components against known vulnerabilities, and helps structure the vulnerability-monitoring and disclosure processes a cyber device submission needs: see device firmware security and PSIRT as a service.

This guide is general information, not legal advice. It does not constitute FDA regulatory or legal counsel; confirm current guidance documents and submission requirements directly with FDA before relying on them.