FDA 524B: What Section 524B Actually Requires

Section 524B has required the same four things since March 2023. The guidance interpreting it has been replaced three times since then, most recently in February 2026.

FDA 524B is short. Four requirements, a three-part definition of the devices it covers, and a clause letting FDA exempt some of them. What makes it hard is not the statute. It is that most of what gets written about medical device cybersecurity compliance describes a guidance document rather than the law, and the guidance keeps moving.

Four guidance documents in twelve years, three of them since 524B took effect: October 2014, September 2023, June 2025, and February 2026. Each revision resets the cross-references and the internal checklist someone built against the last one. Section 524B(b) has not changed a word.

Below is what the statute says and when it took effect, the three-prong test that decides whether your device is a cyber device, the four requirements quoted from the text, which premarket submissions trigger them, why Congress wrote it, what Section 524A is (it is not what people searching for it expect), and the place where 524B programs most often break.

The guidance is the moving part. The statute is the durable one. Build the program against the statute.

What is FDA 524B?

FDA had been publishing premarket cybersecurity guidance for medical devices since 2014. None of it was independently enforceable. Section 524B runs about 300 words and changed that.

Section 524B of the Federal Food, Drug, and Cosmetic Act is codified at 21 U.S.C. 360n-2 under the heading "Ensuring Cybersecurity of Devices." Congress added it through Public Law 117-328, the Consolidated Appropriations Act, 2023, at Division FF, Title III, Section 3305(a), signed December 29, 2022. Division FF is the Food and Drug Omnibus Reform Act, or FDORA. Calling 524B a product of "the omnibus bill" is technically true and useless in a submission, so use the citation.

Two dates matter. The section took effect 90 days after enactment, on March 29, 2023, per section 3305(d) of the same public law. Enforcement arrived separately. In a Federal Register notice dated March 30, 2023, FDA stated that it "generally intends not to issue RTA decisions for premarket submissions submitted for cyber devices based solely on information required by section 524B of the FD&C Act before October 1, 2023, but instead, work collaboratively with sponsors of such premarket submissions as part of the interactive and/or deficiency review process."

Refuse to Accept is the mechanism worth understanding. An RTA is an acceptance-stage decision, made before substantive review begins. A 524B deficiency is not a disagreement with a reviewer about whether your controls are adequate. It is the submission failing to get into the queue.

What counts as a cyber device under 524B

Two beliefs put more devices out of scope than the statute does. The product does not ship with connectivity enabled. The risky code came from a supplier. Neither survives the test.

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 any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats."

All three prongs must be met, and FDA's own FAQ restates the same test without narrowing it. Fail any prong and 524B does not attach, though your quality system obligations and FDA's broader cybersecurity recommendations still do. Falling outside 524B is not falling outside scrutiny.

Prong two is about capability. The text says "has the ability to connect to the internet," not "connects to the internet" and not "is configured to connect." A device with a service port, a paired gateway, or a connectivity path a customer can turn on has the ability whether or not anyone uses it.

Prongs one and three both hinge on the same phrase: "validated, installed, or authorized by the sponsor." You do not have to have written the software. Authorizing a supplier's component into your device makes that component yours for the purpose of this definition. That phrase is also why the SBOM requirement is harder than it reads, which the last section takes up.

If all three are true, everything in the next section applies to your next submission.

The four requirements in Section 524B(b)

Every summary of 524B lists four requirements. Most of them flatten the second one, which is where the two patch clocks live.

Two of these get consistently misread.

Requirement one names coordinated vulnerability disclosure inside the statutory sentence. It asks for "a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures." CVD is not an extra that guidance bolted on. It sits in the law, next to the monitoring obligation.

The document is the easy half. The obligation is a staffed intake path, which raises a question a policy PDF cannot answer: who owns the disclosure queue this week, by name, and what happens in the first twenty-four hours after a researcher sends you working exploit code against a device already in service?

Requirement two is one provision carrying two clocks. It asks for processes and procedures giving reasonable assurance the device is cybersecure, and for postmarket updates and patches addressing "(A) on a reasonably justified regular cycle, known unacceptable vulnerabilities" and "(B) as soon as possible out of cycle, critical vulnerabilities that could cause uncontrolled risks." Two categories, two cadences. The consequence is that you have to be able to defend which bucket a given finding lands in, and "reasonably justified" means the justification is an artifact you can produce, not a call you make once and forget. Triaging by exploitability rather than severity alone is what makes that defensible at portfolio scale.

The remaining two are shorter and get less attention than they deserve. Requirement three names the categories an SBOM has to cover, commercial, open-source, and off-the-shelf, and says nothing at all about format. Every format expectation you have read comes from guidance. Requirement four is the rulemaking hook, FDA's standing authority to add obligations by regulation without returning to Congress.

The statute tells you what to achieve. The February 2026 guidance tells you how FDA expects you to demonstrate it. Only one of those documents is binding, and it is the shorter one.

Which submissions 524B applies to, and why legacy is not a free pass

Section 524B is not retroactive. That sounds like relief until you read the mechanism.

Per FDA's FAQ, the requirements apply to 510(k) submissions including Special and Abbreviated 510(k)s, PMAs, Product Development Protocols, De Novo requests, and Humanitarian Device Exemptions, plus PMA and HDE supplements. The statute itself names FD&C Act sections rather than submission types, referencing 510(k), 513, 515(c), 515(f), and 520(m), and the FAQ does the translation. The overlooked entries are the supplements and the Special 510(k), the exact routes a change to an existing product travels.

On retroactivity, FDA is unambiguous: "the cybersecurity requirements do not apply to an application or submission submitted to the FDA before March 29, 2023." The same FAQ supplies the corollary. If a previously authorized cyber device is modified in a way that requires premarket review, 524B applies to that new submission.

So the grandfather clause is a function of product inactivity. A device sits outside 524B for exactly as long as you file nothing for it. Any product line under active development walks into scope on its own schedule, and the trigger is an engineering decision rather than a regulatory event. Genuinely dormant products may never trigger it, and your quality system still governs them.

Depth is calibrated separately from scope. FDA notes that "the information we recommend that manufacturers of cyber devices provide will generally differ based on the type of change and whether such change impacts the cybersecurity of the device." A submission pulls you into 524B. What the change touches decides how much you show.

If a product has a submission anywhere on its two-year roadmap, treat it as in scope today. The artifacts take longer to build than the submission takes to file.

Why the FDA introduced Section 524B

FDA issued four medical device cybersecurity safety communications between 2013 and 2017. It issued fourteen between 2018 and January 2025.

Those figures come from a 2026 analysis in Frontiers in Digital Health that reviewed every FDA cybersecurity safety communication from June 2013 through January 2025. Eighteen in total, 94% of them classified high-risk. The honest counterweight belongs here too: FDA has said no patient injuries or fatalities have been confirmed from these alerts to date.

The case for 524B was never a body count. Exposure kept widening while the only instrument FDA held was a recommendation.

That is the gap 524B closed. A reviewer could ask a sponsor for cybersecurity documentation and be declined, because a recommendation is all a guidance document can be. Moving four requirements into statute and attaching them to the acceptance decision removed the option.

In January 2025, CISA and FDA issued a joint advisory, ICSMA-25-030-01, on the Contec CMS8000 patient monitor. Claroty's Team82 examined the firmware and found hardcoded public IP addresses used for firmware updates and patient data transmission, then demonstrated root code execution by impersonating that address. Team82 also pushed back on the "backdoor" framing in the coverage and called it insecure design instead.

That distinction is the useful part. The finding was a design decision sitting in shipped firmware, and nothing short of examining that firmware would have surfaced it.

Section 524B did not raise the bar. It made the existing bar a condition of entry.

FDA 524A vs FDA 524B: what the difference actually is

Search for 524A expecting an earlier or milder version of the cybersecurity rule and you will not find one. Section 524A is real. It has nothing to do with devices.

Letters get appended in the order provisions are added to the Act, not by subject matter. One door down, Section 524 is the tropical disease priority review voucher program from 2007. Section 524A came in through the GAIN Act provisions of FDASIA in 2012 and rewards developers of qualifying antibacterial and antifungal drugs with faster review. Device cybersecurity arrived a decade after that, as 524B.

The practical use of knowing this is diagnostic. If a checklist, a compliance guide, or a vendor datasheet claims to address "524A cybersecurity requirements," the author has read neither provision, and that tells you what to assume about the rest of the document. There is no 524A obligation to reconcile with your 524B package.

Where 524B programs break: the SBOM you cannot build from source

Most teams generate the SBOM from the build. It comes out clean, it validates against the schema, and it describes a different artifact than the one FDA is asked to clear.

The February 2026 guidance asks two things a build manifest cannot supply. First, depth. A robust SBOM covers manufacturer-developed and third-party components plus, in FDA's words, "the upstream software dependencies that are required/depended upon by proprietary, purchased/licensed, and open-source software." Second, per-component lifecycle data: "the software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned)" and "the software component's end-of-support date."

Your build manifest lists what you declared. The binary contains what shipped. When a contract manufacturer swaps a library version, a supplier image carries an undeclared dependency, or a component arrives statically linked inside a supplier's blob, the manifest cannot know. This is also why application security SCA tools struggle on firmware: they were built to read repositories, and a device is not a repository.

FDA has conceded the hard part, stating that "manufacturers may not have control of source code due to licensing restrictions, terms of supplier agreements, or other challenges." Source code is not required in a premarket submission. What FDA does expect is a plan for how third-party components get updated or replaced when support ends.

Read that carefully. FDA excuses you from submitting source code. It does not excuse you from knowing what is in the component or planning around its end of support. Analyzing the shipped image closes that gap, needing neither source code nor supplier cooperation, which is also the only reliable way to check a supplier's SBOM against the binary they shipped you.

That gap reaches requirement two. Sorting a finding into "known unacceptable" or "critical, uncontrolled risk" asks whether the vulnerable code is present and reachable in what shipped, not whether a version string matched a CVE.

If your device is entirely first-party code you compile, a manifest-derived SBOM may hold up. If any of it arrived from a supplier as a binary, it will not.

Key takeaways

• Effective March 29, 2023, at 21 U.S.C. 360n-2. Refuse to Accept decisions on 524B grounds began October 1, 2023.
• Three prongs, all required. Prong two asks whether the device can connect to the internet, not whether it does.
• Four requirements. A vulnerability management plan with coordinated disclosure, secure development with a two-tier patch commitment, an SBOM covering commercial, open-source, and off-the-shelf components, and future rulemaking.
• The obligation attaches to the submission, not the device. A pre-2023 clearance holds only until the next filing.
• Section 524A is unrelated. It is a 2012 drug priority review provision, not an earlier cybersecurity rule.
• The February 2026 revision is the current guidance. Anything citing the June 27, 2025 version cites a superseded document.

One first move. Pull the SBOM you would file today and check two fields on every third-party component: support status and end-of-support date. A blank field, or one inherited from a supplier questionnaire, is your gap.

Our platform builds that SBOM from firmware and binaries, no source code required. If you would rather see that against your own device than plan it on a whiteboard, we can walk a product through with you.

FAQ

What is Section 524B of the Federal Food, Drug, and Cosmetic Act?

Section 524B, 21 U.S.C. 360n-2, titled "Ensuring Cybersecurity of Devices," requires sponsors of premarket submissions for cyber devices to provide a postmarket vulnerability management plan, secure design and maintenance processes with a patch commitment, and a software bill of materials. It took effect March 29, 2023.

Is FDA 524B a law or a guidance?

It is a law. Public Law 117-328 added Section 524B to the FD&C Act. The February 2026 premarket cybersecurity guidance is not a law: it states FDA's current thinking and binds no one. FDA's Quality Management System Regulation is a third thing, a binding regulation.

What is a cyber device under FDA 524B?

A device that includes software validated, installed, or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics the sponsor authorized that could be vulnerable to cybersecurity threats. All three prongs must be met, and prong two turns on capability, not configuration.

Does FDA 524B apply retroactively to devices already on the market?

No. FDA states the requirements do not apply to a submission filed before March 29, 2023. But the obligation attaches to the submission rather than the device, so modifying a cleared cyber device in a way that requires premarket review brings it into scope.

What is the difference between FDA 524A and FDA 524B?

Unrelated provisions that sit next to each other in the FD&C Act. Section 524A, added July 2012, grants priority review to qualified infectious disease products and concerns drugs. Section 524B, added December 2022, governs device cybersecurity. Letters are appended chronologically, not by subject.

Which premarket submissions does 524B apply to?

Per FDA: 510(k) submissions including Special and Abbreviated 510(k)s, PMAs, Product Development Protocols, De Novo requests, and Humanitarian Device Exemptions, plus PMA and HDE supplements. Supplements and Special 510(k)s are the most overlooked, since they carry changes to products already on the market.

What SBOM format does the FDA require for 524B?

FDA asks for a machine-readable SBOM in an industry-accepted format consistent with the October 2021 NTIA minimum elements. It does not mandate CycloneDX or SPDX by name, though both satisfy the criteria. The harder expectations are per-component support status and end-of-support dates.

What happens if a 524B submission is missing the SBOM?

The SBOM is a statutory requirement under 524B(b)(3), so its absence is an acceptance-stage deficiency rather than a review-stage debate. FDA can issue a Refuse to Accept decision, which stops the submission before substantive review begins. That policy has applied since October 1, 2023.

Can the FDA exempt a device from 524B?

Yes. Section 524B(d) authorizes the Secretary to identify devices, or categories and types of devices, exempt from the section's requirements, and requires FDA to publish and update that list in the Federal Register. Check the current list before assuming your class is covered.