FDA section 524B: cyber-device requirements

Sytance · Updated

Section 524B of the FD&C Act sets statutory cybersecurity requirements for certain FDA premarket submissions involving cyber devices. It requires plans and processes for managing vulnerabilities, updates and patches, together with an SBOM.

Cyber-device criteria

A cyber device is a medical device that meets all three statutory criteria. The device must include sponsor-validated, sponsor-installed or sponsor-authorised software as a device or in a device. It must have the ability to connect to the internet. It must also contain sponsor-validated, sponsor-installed or sponsor-authorised technological characteristics that could be vulnerable to cybersecurity threats.

Section 524B(c) of the FD&C Act defines "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 any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to the cybersecurity threats.

FDA FAQ on section 524B, quoting FD&C Act section 524B(c) (original English)

FDA reads the connection element broadly. Firmware and programmable logic count as software for this purpose. Internet capability can be direct or indirect, intended or unintended, and can arise through the device threat surface and environment of use.

Software element

The criterion is about software in or as the device, including firmware and programmable logic, when the sponsor validates, installs or authorises it.

Connection element

FDA examples include network, server, cloud, Wi-Fi, cellular, Bluetooth, magnetic inductive communication, USB, Ethernet and serial-port paths.

Threat element

The technological characteristics must be capable of being vulnerable to cybersecurity threats. The question is not limited to whether the product is marketed as connected.

Submission pathways

Section 524B applies to the person who submits a covered FDA premarket application or submission for a cyber device. FDA identifies 510(k), PMA, product development protocol, De Novo and HDE pathways, including relevant supplements and Special or Abbreviated 510(k) submissions.

The statutory requirements do not apply to applications or submissions sent to FDA before 29 March 2023. FDA's FAQ states that, beginning 1 October 2023, FDA expected sponsors to have had enough time to prepare cyber-device submissions with the required section 524B information. If a previously authorised cyber device requires a new submission for a modification through a covered pathway, that new submission must meet section 524B.

Required submission information

The submission must show how the cyber device meets section 524B(b). FDA's final premarket guidance explains how design, risk-management and testing information can support those statutory requirements.

Boundary with FDA guidance

The cyber-device definition is not the boundary of all FDA cybersecurity expectations. FDA's February 2026 final guidance addresses premarket cybersecurity design, labelling and documentation for devices with cybersecurity risk, and says section 524B cyber devices are a subset of devices within the guidance scope.

  • A device can need FDA cybersecurity risk management evidence even if the sponsor concludes that section 524B does not apply.
  • A non-internet-connected device can still raise cybersecurity issues through software, local ports, removable media, update mechanisms or its operating environment.
  • A cyber-device conclusion does not by itself prove reasonable assurance of safety, effectiveness or cybersecurity.
  • FDA guidance is non-binding guidance, while section 524B is statutory law for qualifying submissions.

Modifications and fielded versions

Section 524B information may differ by change type. FDA's least burdensome framing means a cyber-device modification submission should focus on the cybersecurity impact of the change, the current device architecture, the affected fielded versions and the required statutory elements. A change that does not affect cybersecurity will not need the same depth as a change to connectivity, update infrastructure, authentication, encryption, cloud services or third-party software.

Fielded configurations

If not every device receives an update automatically, the risk file should recognise different software configurations in the field.

Related systems

The analysis should include related systems when their security affects the cyber device, especially update servers, connected services and manufacturer-controlled software functions.

Sources