FDA Medical Device Cybersecurity Under Section 524B: Premarket Requirements, SBOMs, and Enforcement Findings

FDA medical device cybersecurity under section 524B: premarket requirements, SBOMs, unsupported components and enforcement findings

Section 524B of the FD&C Act turned medical device cybersecurity from a guidance expectation into a statutory requirement for "cyber devices." FDA's current interpretation sits in the final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 3, 2026) ⁵⁵. That guidance follows the draft Select Updates for the Premarket Cybersecurity Guidance: Section 524B of the FD&C Act (March 13, 2024) ⁵⁶¹¹⁶. The postmarket framework traces back to Postmarket Management of Cybersecurity in Medical Devices (December 28, 2016) ⁶⁵. Over the same period, FDA warning letters and Form 483 observations have cited cybersecurity failures under design verification, design validation and risk analysis, CAPA, corrections and removals, and 510(k) requirements.

Key takeaways

• Since March 29, 2023, sponsors of a 510(k), PMA, PDP, De Novo or HDE for a cyber device must include information showing that the device meets section 524B(b) ^135136137. Under FDA's transition policy, refuse-to-accept decisions based solely on missing 524B information began on October 1, 2023.
• Section 524B(b) has three paragraphs that together set four obligations: a postmarket vulnerability plan (b)(1), secure-by-design processes and patches and updates (b)(2), and a software bill of materials (SBOM) covering commercial, open-source and off-the-shelf components (b)(3) ^139140141143.
• For cyber devices, failing to comply with the section 524B(b)(2) requirements on device cybersecurity is a prohibited act under section 301(q) ²⁶⁷.
• FDA expects the SBOM to be machine-readable and to give, for each component, its level of support and end-of-support date ¹⁶⁴¹⁶⁶.
• Enforcement findings most often cite 21 CFR 820.30(g) (risk analysis within design validation) and 820.100(a) (CAPA). FDA has also cited 820.30(f), Part 806 and 807.81(a)(3)(i) in cybersecurity cases ^{180182186187265269281}.

Which devices are "cyber devices"

A device is a cyber device only if it meets all three statutory criteria ¹³⁸:

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

FDA reads "ability to connect to the internet" broadly. The final guidance lists network, server or cloud connections; radio-frequency links such as Wi-Fi, cellular, Bluetooth and Bluetooth Low Energy; magnetic inductive communications; and hardware connectors capable of reaching the internet, such as USB, Ethernet or serial ports ²⁵⁸. The connection does not have to be continuous. FDA's example is a USB port used only briefly for servicing, which still counts as the ability to connect ²⁵⁹.

The obligation falls on whoever submits the application, including the manufacturer. It also applies to a modification of a cyber device when that modification requires a 510(k), PMA, PDP, De Novo or HDE submission ^135136137.

The four statutory requirements of section 524B(b)

FDA states that failing to comply with any section 524B(b)(2) requirement on ensuring device cybersecurity is a prohibited act under section 301(q) of the FD&C Act ²⁶⁷.

Premarket documentation FDA expects

Security risk management

FDA asks for a set of connected, traceable analyses rather than a standalone security section. The security risk management report should cover threat modeling, the cybersecurity risk assessment, the SBOM, component support information, vulnerability assessments and assessments of unresolved anomalies. It should be traceable to the threat model, the risk assessment, the SBOM and testing ³¹.

• Threat modeling. Threat modeling should run throughout design and cover all elements of the medical device system. The submission should document pre- and post-mitigation risks, assumptions about the system and use environment, and risks arising from the supply chain and other lifecycle activities. It should also explain why the chosen methodology was used ³².
• Cybersecurity risk assessment. The assessment should state how risk is scored before and after mitigation, the acceptance criteria, and how security risks are transferred into the safety risk process. It should cover residual risk from both intentional and unintentional cybersecurity failures ³³³⁴.
• Exploitability, not probability. FDA separates cybersecurity risk assessment from probabilistic safety risk management. The security assessment asks whether a vulnerability can be exploited, rather than estimating the likelihood of an incident from historical data. FDA treats the two processes as distinct but connected ³⁶.
• Security architecture views. At a minimum, FDA recommends a Global System View, a Multi-Patient Harm View, an Updateability/Patchability View and one or more Security Use Case Views. Each should trace architecture elements to security requirements. A view that is omitted should be explained ³⁵¹¹.

Cybersecurity testing

Submissions should include security testing documentation with reports or assessments. This covers fuzz testing, attack surface analysis and closed-box scanning for known vulnerabilities ¹¹⁰¹¹¹. Penetration test reports should state the testers' independence from the developers, their technical expertise, the scope, duration, methods and findings ¹¹². For all testing, FDA wants the manufacturer's assessment of the findings, including the rationale for any finding that was not fixed or was deferred to a later release. Where a third party performed the testing, the original third-party report should be provided ¹¹³¹¹⁴.

Quality system, SPDF and labeling

FDA describes a secure product development framework (SPDF) as a set of lifecycle processes, running from design through decommissioning, that reduce vulnerabilities. It recommends using QMSR/ISO 13485 design processes to implement an SPDF ²⁰⁶²⁰⁷. Security risk management should be integrated into the quality management system alongside safety risk management but kept distinct from it ²⁰⁸. Software validation and risk management may need cybersecurity-specific processes, and quality-system records can support the premarket demonstration ²⁰⁹.

Labeling should tell users about relevant cybersecurity controls and risks. This includes communication interfaces, third-party software, known vulnerabilities, and how to configure and update the device securely ²¹⁰⁵⁰.

SBOM expectations

For cyber devices the SBOM is a statutory requirement. For other devices FDA still recommends one ¹⁶²¹⁴³. FDA also notes that a robust SBOM covers manufacturer-developed components and upstream dependencies ¹⁶³. The guidance recommends:

• Format. A machine-readable SBOM consistent with the NTIA minimum elements ("baseline attributes"), in an industry-accepted format ¹⁶⁴¹⁶⁵.
• Support status. For each component, its level of support (actively maintained, no longer maintained or abandoned) and its end-of-support date. This can be in the SBOM itself or in an addendum ¹⁶⁶.
• Known vulnerabilities. All known vulnerabilities in the device and its components, including entries in CISA's Known Exploited Vulnerabilities Catalog. For each, the submission should say how it was discovered and give a safety and security risk assessment of the device and system impacts ⁵¹.
• Omissions. If SBOM information cannot be provided, the submission should justify why ¹⁶⁷.

Unsupported and end-of-support software components

FDA expects manufacturers to plan for components losing support rather than assume they will stay secure without maintenance.

• Premarket disclosure. Support level and end-of-support date should be documented for every SBOM component ¹⁶⁶. Known component vulnerabilities and support information belong in the security risk management materials ⁵¹⁵².
• Lifecycle planning. Submissions should describe plans to update or replace third-party components if support ends. Where supplier support may end before the device's intended support life, FDA suggests considering access to the supplier's source code ⁵⁰⁴⁹.
• Communicating end of support. Users should be told about known or anticipated end of support or end of life for the device and its components ⁵³.
• Risk transfer. For devices that stay in service after support ends, there should be a pre-established, communicated process for transferring risk. That process should make clear that users' cybersecurity risk can be expected to increase over time. Risk should be transferred only after the relevant risks have been assessed and communicated ⁵³⁵⁴.

Postmarket management and patch timelines

Manufacturers are expected to monitor for vulnerabilities and threats, reassess risk, mitigate before exploitation where possible, validate remediations and communicate residual risk ^146147148149. A coordinated vulnerability disclosure policy should, at a minimum, acknowledge receipt of a vulnerability report to the person who submitted it ^150151152.

FDA classifies risk of patient harm as controlled or uncontrolled, based on exploitability and severity after taking existing controls into account ¹⁵³¹⁵⁴. Changes made only to address controlled-risk vulnerabilities, and routine cybersecurity patches, are generally treated as device enhancements rather than recalls ¹⁵⁵¹⁵⁶. The cybersecurity management plan should set a patch release timeline, and the plan should generally justify the length of the regular update cycle. The guidance does not set a fixed number of days for either regular-cycle or out-of-cycle patches ^157158159.

Device modifications

For changes that may affect cybersecurity, a modification submission for a cyber device should include the full required and recommended documentation. For changes unlikely to affect cybersecurity, FDA recommends a narrower package. That package includes a 524B(b)(1) plan if none was filed before, or a reference to the prior submission and a summary of changes to the plan if one was ¹⁹⁰. FDA's review generally focuses on changes to cybersecurity controls, but FDA will consider known cybersecurity concerns regardless of the proposed change ¹⁹¹.

What FDA inspections and warning letters have cited

Patterns across the enforcement record

• Risk analysis that ignores known vulnerabilities is the most common design-control finding. Three of the warning letters above cite 820.30(g) for cybersecurity risk analysis or security testing gaps: St. Jude/Abbott, BD/CareFusion and Contec ^182187265. The St. Jude 483 shows the same theme ⁴². In the BD letter, FDA specifically faulted the lack of an exploitability and patient-harm severity process ¹⁸⁷. That is the same exploitability-based approach the 2026 guidance describes ³⁶.
• Verification must test negative cases. In both the St. Jude 483 and the Abbott letter, FDA objected that testing confirmed authorized access but not that unauthorized access was blocked ⁴¹¹⁸⁰.
• CAPA must reach the whole installed base. The Medtronic, Draeger, BD and Contec letters show that open vulnerability tickets, incomplete field actions and unexecuted cybersecurity management plans are cited as CAPA failures ^262184186266.
• Cybersecurity fixes can trigger reporting obligations. The Beta Bionics letter shows that a security patch for a vulnerability with patient-harm potential can require a Part 806 report ²⁶⁹. This is consistent with FDA's guidance position that only controlled-risk fixes are generally treated as enhancements ¹⁵⁵¹⁵⁶.
• Architecture changes can require a new 510(k). The O.N. Diagnostics letter treats a move to a web-based, network-exposed architecture as a change that required a new premarket notification. FDA specifically noted the absence of a reviewed SBOM ²⁸⁰²⁸¹.

These letters cite the Part 820 section numbers in force at the time (for example 820.30 and 820.100). The 2026 guidance frames its quality-system expectations in terms of the QMSR and ISO 13485 design and development requirements ²⁰⁶²⁰⁹.

Practical implications for submissions and quality systems

• Decide early whether the device is a cyber device using FDA's broad connectivity reading. Hardware ports used only for servicing still count ²⁵⁸²⁵⁹.
• Build the SBOM as a controlled, machine-readable record with support status and end-of-support dates. Map it to the known-vulnerability analysis, including CISA's Known Exploited Vulnerabilities Catalog ^16416651.
• Keep security risk management traceable from the threat model through the risk assessment, the SBOM and testing, and score risk on exploitability ³¹³⁶.
• Include negative and boundary security tests, such as unauthorized interfaces, segmentation and zone boundaries. These are the gaps FDA cited at St. Jude/Abbott and Contec ¹⁸⁰²⁶⁵.
• Set and justify patch cycles in the postmarket plan ¹⁵⁷¹⁵⁸. Assess each security fix for controlled versus uncontrolled risk to decide whether Part 806 reporting applies ^153155269.
• Document end-of-support planning and the process for transferring risk to users for components that will outlive supplier support ⁵⁰⁵³⁵⁴.