FDA 524B cybersecurity testing requirements

What does section 524B actually require of a submission?

Three duties, written into the statute as things the sponsor does. Section 524B of the FD&C Act sits at 21 U.S.C. 360n-2 under the heading "Ensuring cybersecurity of devices", and its subsection (b) sets them out in order.

The three duties section 524B(b) of the FD&C Act places on a device sponsor, each quoted in the statute's own words.

Duty at 524B(b)	The statute's own words
A plan	"to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits"
Processes and procedures	"design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure"
A list	"provide to the Secretary a software bill of materials, including commercial, open-source, and off-the-shelf software components"

The same subsection attaches a timing obligation to the second duty, and the section on the update path below is about that obligation.

Secondary summaries of the statute list the submission types named in 524B(a) as 510(k), 513, 515(c), 515(f) and 520(m). That list was not confirmed against the statutory text when the material for this page was collected, so treat it as what those sources report and check your own route before you rely on it.

Each duty lands differently on a test plan. A plan is a document and can be reviewed on its own. A process has to be exercised before anyone can say it works. A bill of materials is a list whose only real property is whether it matches the thing you built. The rest of this page is about the second and the third, because those are the two a reviewer can find contradicted by your own records.

Is your product a cyber device?

The definition is at section 524B(c), and it has three parts joined by "and". A cyber device is 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 cybersecurity threats".

Two phrases in that text set the scope of the work that follows. "Validated, installed, or authorized by the sponsor" draws the boundary at what you authorized, so a component an installer pulls in, a runtime the device ships with, and an optional module a customer enables under your instructions are all inside it. "Ability to connect" is written as a capability. A deployment where the interface is switched off in configuration has not obviously removed the ability, and the reasoning behind whichever answer you give belongs in the file next to the answer.

If the determination comes out negative, write the negative determination down with the same care. It is the sentence a reviewer will test first, and the argument is much harder to reconstruct two years later from an architecture that has changed since.

How do you show that the device can be updated and patched?

By running the update on the device as it is fielded and keeping the result. section 524B(b)(2) asks for updates and patches to be made available on "a reasonably justified regular cycle" for known unacceptable vulnerabilities, and "as soon as possible out of cycle" for critical vulnerabilities. Two separate things have to be evidenced there. The cycle needs a justification, which is a written argument about your product and its use environment. The out-of-cycle capability needs a demonstration, because a statement that you could ship an emergency patch is a claim about machinery nobody has operated.

Step 6 is the one that turns the exercise into evidence. What each test record has to contain, and why the job output of a pipeline is not that record, is set out at CI/CD for medical device software, and nothing here changes those contents. The addition 524B makes is the subject: the runs above are evidence about the delivery mechanism itself, which a functional suite never exercises because the product works without it.

What does a software bill of materials get checked against?

Three things, and the list is wrong when any of the three disagrees with it.

Three sources a software bill of materials for an FDA section 524B submission is checked against, and what a mismatch with each means.

Check the bill of materials against	What a mismatch means
The signed artefact you actually ship	The list describes a build that was not the one submitted
The inventory in your design file	A component is under regulatory control on one document and absent from the other
What is loaded and running on the device	A component reaches patients with no entry anywhere

The statutory wording is what makes the first row bite. 524B(b)(3) names "commercial, open-source, and off-the-shelf software components" together, so a list built from open-source dependency declarations alone has answered one third of the sentence. Commercial libraries under licence, vendor SDKs and firmware blobs are named in the same breath as the packages a scanner finds.

The second row is where the device world differs from everywhere else. IEC 62304 already treats third-party code as SOUP and attaches standing obligations to every item of it, at 5.3 for the requirements each item has to meet and at 7.1 for the evaluation of published anomaly lists. Building that inventory and attaching evidence to each entry belongs to testing SOUP components; how the safety class decides which of those clauses bind is on the IEC 62304 testing requirements page. What 524B adds is a second document with a different audience, and the pair has to agree. A component that is a SOUP item in the design file and missing from the bill of materials is a contradiction inside one submission.

A list also goes wrong quietly, in ways that survive a read-through. An entry carries a package name and no version pin. Build tooling appears although it never ships to a customer. A version is declared in the manifest while the linker resolved a different one. Each of those is caught by generating the list from the build output and comparing it with the list you submitted, which costs one job in the pipeline and is almost never wired up.

Can a test demonstrate a vulnerability disclosure process, or only assert one?

It can demonstrate it, by putting a report through the process and following where the report goes. section 524B(b)(1) asks for a plan to monitor, identify and address postmarket vulnerabilities and exploits "in a reasonable time". Reasonableness is measured on records, so the rehearsal has to leave records that carry times.

Environments used for these rehearsals are ordinary test environments and are built the same way. We do not need production PHI to test. Environments run on synthetic and de-identified data. We sign a Business Associate Agreement before any engagement that touches PHI. Two of the questions a CTO asks about an outside team reaching an environment are still recorded as unanswered on how we work with protected health information, and they are published there next to the five that have answers.

Why does a clean security test report not answer 524B on its own?

Because finding no bugs and producing evidence are different outputs, and the statute asks for the second. A report that lists findings by severity describes what a tool reached on a date. What a reviewer reads a submission for is whether the duties in 524B(b) are operating, which means the version each result was obtained on, the scope that was in and out, the decision recorded against each finding, and the place in your file that decision lives.

The estimation method is the other difference, and FDA has stated it in a document about a standard you already use. In its recognition record for ISO 14971:2019, FDA notes that the standard's probabilistic model does not carry over to security work, and points instead at exploitability as the basis for estimating security risk. A finding register that reports a probability column and nothing else is answering a question the reviewer did not ask. Where the criteria for acceptability come from, and why no standard supplies them, is on the ISO 14971 page: ISO 14971:2019 states in its own scope that it "requires manufacturers to establish objective criteria for risk acceptability but does not specify acceptable risk levels".

The engagement that produces findings in a form a risk file can absorb is described at PHI security testing. Which documents the submission itself carries, at which documentation level, is a separate question covered at 510(k) software documentation.

Sources for this page: the definition of a cyber device and the three duties are quoted from 21 U.S.C. 360n-2 as published by the Cornell Legal Information Institute and read on 10 September 2026. The IEC 62304 clause titles are from Edition 1.1 and the ISO 14971:2019 scope sentence from the publisher preview, both read on 2 September 2026. FDA's cybersecurity note is from its recognised consensus standards record for ISO 14971:2019, which cites 21 USC 360n-2 and the guidance "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", issued February 2026. Two statements on this page rest on secondary sources and are marked where they appear: the enactment of 524B through Public Law 117-328 on 29 December 2022 with refuse-to-accept decisions from 1 October 2023, and the list of submission types named in 524B(a).

Which gaps does a reviewer find first?

• The cyber device determination is negative and no reasoning was written down.
• The regular update cycle is described and never justified against the product and its use environment.
• The out-of-cycle route has no run behind it, although 524B(b)(2) names it alongside the regular cycle.
• The bill of materials lists open-source packages and omits commercial and off-the-shelf components the same sentence of the statute names.
• The bill of materials and the SOUP inventory in the design file name different versions of the same component.
• The disclosure policy publishes an intake route nobody has sent a report to.
• Findings are ranked by a vendor severity score, with no exploitability assessment for the device in its own use environment.
• Update test runs exist as tickets, with no record naming the version installed and the version replaced.