Skip to main content
← BlogUS

FDA §524B in plain English

Since 29 March 2023, most US medical device submissions must include cybersecurity documentation. The requirement is section 524B of the FD&C Act. This post explains it in plain English: who it applies to, what it asks for, and what happens if the section is incomplete.

Who it applies to

Section 524B applies to submissions under 510(k), De Novo, PMA, PDP and HDE. It does not apply to an Investigational Device Exemption (IDE) — a clinical study submission is not a §524B submission, although FDA still recommends a reduced cybersecurity set for IDEs.

It attaches to a "cyber device" — a device that meets all three of these:

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

The second point is read more broadly than most people expect. FDA counts connectivity whether it was intended or not, and its illustrative list includes USB, ethernet and serial ports — not just Wi-Fi and cloud. FDA states that even a brief USB service connection means the ability is present. The test is ability, not practice: "we never actually network it" is not a way out.

One more point that surprises people: whoever submits the application carries the §524B obligations — including for parts of the device built by somebody else. The obligation follows the submission, not the manufacture.

The four obligations

The sponsor of a cyber device submission must:

  1. Submit a plan to monitor, identify and address postmarket cybersecurity vulnerabilities — including coordinated vulnerability disclosure, which is a statutory requirement here, not just good practice
  2. Have processes giving reasonable assurance the device and related systems are cybersecure, with updates and patches made available — known unacceptable vulnerabilities on a regular cycle, and critical vulnerabilities that could cause uncontrolled risks as soon as possible, out of cycle
  3. Provide a software bill of materials (SBOM) covering commercial, open-source and off-the-shelf components
  4. Comply with any further requirements FDA sets by regulation

The SBOM point everyone gets wrong

The statute requires an SBOM and specifies no format. A machine-readable SBOM, benchmarked to NTIA's October 2021 minimum elements, is what FDA's premarket cybersecurity guidance (February 2026) recommends. One is law, the other is an expectation. They are worth keeping apart, because they change what you must argue in a submission — and because "FDA requires a machine-readable SBOM in an approved format" is repeated all over the internet and is not what the statute says.

What FDA expects to see

Beyond the four statutory items, the guidance describes the evidence FDA expects in the submission: a threat model with the reasoning behind it, a security risk assessment linked to the ISO 14971 risk file, four security architecture views (diagrams with explanatory text), security controls shown to be implemented and tested, and security testing — including penetration testing, with the testers' independence and scope stated.

The volume scales with risk. FDA says this expressly: a device with a single hardware connection sits at the light end of the range. A cloud-connected multi-patient platform sits at the other.

What happens if the section is incomplete

Since October 2023, every 510(k) goes through FDA's electronic submission system, eSTAR. A submission whose cybersecurity section lacks accurate responses and the relevant attachments is placed on a Technical Screening hold. That is not a rejection on the merits — it is calendar time, and for a funded company waiting on clearance, calendar time is the expensive part.

The practical advice is unexciting: prepare the cybersecurity content before submission, sized to the device, rather than in response to a hold.

If your device is built on someone else's platform

A common situation: the assay or application is yours, but the instrument and its software come from a vendor. FDA anticipates this. Source code is not required in premarket submissions, and the guidance describes what to provide where you do not control the software lifecycle — component documentation, supplier controls, a plan for updating or replacing components if support ends, and labelling that tells users what they need to manage the residual risk.

What that means in practice: the vendor's cooperation shapes the work more than any technical factor. Support commitments, architecture detail and permission to security-test are contract terms worth settling early — you are their customer.

Kaitara Security prepares the cybersecurity evidence for US premarket submissions — threat model, architecture views, SBOM, testing and the submission section itself. The regulatory advisor leads the submission; FDA reviews it. Details: FDA Premarket Cybersecurity (§524B).