FDA Cybersecurity for Medical Devices: What Section 524B Requires

Section 524B of the FD&C Act took effect on March 29, 2023, and since then anyone submitting a 510(k), PMA, PDP, De Novo, or HDE for a device that meets the statutory definition of a "cyber device" has had to include three things: a plan to monitor, identify and address postmarket cybersecurity vulnerabilities including coordinated vulnerability disclosure, processes and procedures providing a reasonable assurance that the device and related systems are cybersecure, and a software bill of materials covering commercial, open-source and off-the-shelf components (21 U.S.C. 360n-2). FDA's refuse-to-accept transition policy expired on October 1, 2023, and FDA states that from that date it expects sponsors to have had sufficient time to prepare compliant submissions; an eSTAR submission goes on technical screening hold if the cybersecurity section is not complete. One thing most content on this topic still gets wrong as of August 2026: the operative guidance is no longer the June 27, 2025 edition. FDA replaced it on February 3, 2026 with "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", and the new title is a hint about what changed.

Below: how to tell whether your product is a cyber device, which submissions carry the obligation, what the three requirements actually ask for, why the February 2026 edition matters, and when this article does not apply to you at all.

Key takeaways

• Section 524B applies to cyber devices submitted under 510(k), PMA, PDP, De Novo, or HDE. It has been in force since March 29, 2023.
• FDA reads "ability to connect to the internet" broadly enough to include a USB or ethernet port, whether or not connectivity was intended.
• The three statutory deliverables are a postmarket vulnerability plan with coordinated disclosure, cybersecure design processes with a patch cadence, and an SBOM.
• The refuse-to-accept transition policy expired October 1, 2023; incomplete eSTAR cybersecurity sections now draw a technical screening hold.
• The current guidance edition is dated February 3, 2026 and supersedes the June 27, 2025 one. If your regulatory file cites the older edition, it is citing a superseded document.

Is your product a cyber device? The test, read broadly

The statutory definition at section 524B(c) has three prongs, and a device has to meet all of them. FDA quotes it 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."

Read each prong the way FDA reads it, because the agency's interpretation is considerably wider than a plain reading suggests.

On software, FDA "considers a 'cyber device' to include devices that are or contain software, including software that is firmware or programmable logic". Firmware counts. Programmable logic counts. A team that thinks of its product as hardware with a control board is very often inside the definition.

On connectivity, FDA considers the ability to connect to the internet "to include devices that are able to connect to the internet, whether intentionally or unintentionally, through any means", and the guidance's illustrative list includes network, server or cloud connections, radio-frequency communications such as Wi-Fi, cellular, Bluetooth and Bluetooth Low Energy, magnetic inductive communications, and "hardware connectors capable of connecting to the internet (e.g., USB, ethernet, serial port)". The guidance spells out the case that catches people: a device serviced over USB has the ability to connect even though the connection is brief and was never meant to reach the internet. FDA's stated reasoning is that if a device can be connected, it is possible that it will be, regardless of sponsor intent.

The practical filter, then, is not "did we build a connected product". It is "does anything in this device run code, and is there any port, radio or service interface on it". If both answers are yes, scope your submission as a cyber device and argue the exception later, with evidence, rather than discovering the position during review.

Which submissions carry the obligation

FDA is specific: under section 524B(a), a person who submits a premarket application or submission under 510(k), PMA, PDP, De Novo, or HDE for a device meeting the cyber device definition must include the information FDA requires to show the device meets the 524B(b) requirements. The guidance notes that 510(k) here covers original, special and abbreviated submissions, and that PMA and HDE cover originals and supplements.

Two consequences follow that teams miss.

Supplements and special 510(k)s are in scope. The obligation attaches to the submission, not to the product's launch. A modification that requires a new submission requires the 524B package with it.

Devices exempt from premarket submission do not acquire a 524B obligation, because there is no submission for it to attach to. That does not make them exempt from the rest of FDA's cybersecurity expectations, nor from your quality system obligations, which is a distinction worth keeping straight when someone tells you "we are 510(k) exempt so this does not apply".

The three things Section 524B actually requires

A postmarket vulnerability plan, including coordinated disclosure. Section 524B(b)(1) requires 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". FDA's reading of coordinated vulnerability disclosure covers three flows: disclosure of vulnerabilities found by outside parties including third-party software suppliers and researchers, disclosure of ones you find yourself, and the procedures by which you actually carry out those disclosures. If you have no route for a security researcher to reach you, that is a documentable gap in a statutory requirement, not a nice-to-have.

Processes providing reasonable assurance the device and related systems are cybersecure. Section 524B(b)(2) has two limbs and they are not the same. Under (b)(2)(A) you make updates and patches available for known unacceptable vulnerabilities "on a reasonably justified regular cycle". Under (b)(2)(B) you make them available "as soon as possible out of cycle" for critical vulnerabilities that could cause uncontrolled risks. The guidance is explicit that the justification for your regular cycle belongs in the cybersecurity management plan, and that the appropriate cycle length depends on risk. Its own example contrasts an interconnected thermometer with an interconnected surgical robot, and then makes the sharper point that a low-risk device can still be a route into a higher-risk environment.

A software bill of materials. Section 524B(b)(3) requires an SBOM "including commercial, open-source, and off-the-shelf software components". For cyber devices this is required by statute, not recommended. The guidance points you to its own SBOM content recommendations for what to include.

On testing, the guidance recommends that cybersecurity testing occur throughout the secure product development framework, and that after release "cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually)". That is a recommendation in a nonbinding guidance rather than a statutory cadence, and it is worth reading in exactly that register. It is also the point where device work meets the same penetration testing discipline the rest of the market uses, and the same scoping questions we cover in does HIPAA require penetration testing apply here: the framework recommends, the evidence is what gets read.

The February 2026 edition, and why the date matters

The guidance PDF states it plainly on its cover: "Document issued on February 3, 2026" and "This document supersedes 'Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions,' issued June 27, 2025."

Note the title change. Quality System became Quality Management System, which tracks FDA's alignment of device quality requirements with the quality management system regulation. If your regulatory strategy document, your consultant's deck, or the checklist your team is working from cites the June 2025 edition, it is working from a superseded document. That is not automatically a substantive error, since much of the content carries over, but it is the kind of citation a reviewer notices and it tells you the material has not been refreshed since early 2026.

This is also the reason we keep a regulatory radar rather than writing evergreen regulatory summaries. The premarket cybersecurity guidance has now been revised at least twice in under three years. Any article that tells you what FDA requires without naming an edition and a date is asking you to trust that nothing has moved.

Modifications: the obligation follows the submission

The guidance is direct about device changes. Because 524B attaches to a submission under one of the enumerated pathways, a manufacturer submitting for a device modification under one of those pathways complies with 524B as part of it.

What differs is the depth of documentation, and FDA sorts changes into two buckets. Changes that may impact cybersecurity, which the guidance illustrates with changes to authentication or encryption algorithms, new connectivity features, or changes to the software update mechanism, draw the full documentation set. Changes unlikely to impact cybersecurity, illustrated with materials changes, sterilization method changes, or an algorithm change that does not touch architecture, software structure or connectivity, draw a lighter set: if the 524B(b)(1) plan was provided before, reference the prior submission and summarize what changed.

That is a genuinely useful lever. Teams that maintain a current cybersecurity management plan and a current SBOM turn each subsequent submission into a reference and a delta. Teams that rebuild the package per submission pay for it every time.

What this does not do, and when not to hire anyone

Against our own interest, three honest limits.

524B is a submission requirement, not a security program. Satisfying it means your paperwork is complete and your processes are described. It does not mean your device is secure, and FDA's own guidance is careful to frame the recommendations as supporting the statutory obligations rather than substituting for engineering. If you buy a consultant to assemble the documents and change nothing about how you build, you have bought a filing, not safety.

If you are pre-submission and pre-architecture, you do not need a compliance firm yet. You need the SBOM tooling in your build pipeline and a decision about your update mechanism. Those are engineering choices, they are cheaper to make than to retrofit, and no external assessment will make them for you. Come back when you have an architecture to review.

If your only question is whether you are a cyber device, that is often a one-hour conversation with your regulatory lead, not an engagement. Run the three prongs against your product. If the answer is obviously yes, which it usually is, scope for it and move on.

The case for outside help is narrower: an existing submission that drew cybersecurity deficiencies, a device family where scoping the cyber device boundary is genuinely contested, or a company that has to stand up the postmarket disclosure and patch-cadence processes for the first time and has nobody who has run one.

Where Top Floor fits

We do the premarket cybersecurity documentation and the underlying process work under our FDA cybersecurity practice: threat modeling, SBOM generation and maintenance, the cybersecurity management plan, coordinated vulnerability disclosure procedures, and the security testing evidence that supports the submission. The device and system testing itself sits under penetration testing. Where a manufacturer needs someone to own the security program rather than a project, that is vCISO work.

We do not clear devices and we do not speak for FDA. Anyone who tells you their template guarantees acceptance is describing something FDA has never offered.

How to decide this week

Run the three-prong test on every product in your portfolio, including the ones you think of as hardware. Software or firmware or programmable logic, any means of connecting including a USB or ethernet port, and any characteristic that could be vulnerable. Write down the answer per product, because it is the scoping decision everything else hangs from.

Then check which guidance edition your team is working from. If the citation says June 27, 2025 or September 2023, replace it with the February 3, 2026 edition and re-read at least Section VII.

Then look at your next planned submission, including supplements and special 510(k)s, and ask whether the vulnerability plan, the patch-cadence justification and the SBOM exist today as maintained artifacts rather than as documents someone will write during the submission crunch. The teams that treat them as living artifacts file faster every time after the first.

Frequently asked questions

What is a "cyber device" under FDA rules?

Section 524B(c) of the FD&C Act defines a cyber device as a device that meets all three of the following: it includes software validated, installed, or authorized by the sponsor as a device or in a device; it has the ability to connect to the internet; and it contains technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. FDA reads the first prong to include firmware and programmable logic, and the second to include the ability to connect whether intentionally or unintentionally, through any means, with hardware connectors such as USB, ethernet or a serial port listed as examples.

Which FDA submissions require Section 524B information?

Section 524B applies to premarket submissions under the 510(k), PMA, PDP, De Novo, and HDE pathways where the device meets the cyber device definition. FDA's guidance notes that 510(k) covers original, special and abbreviated submissions and that PMA and HDE cover originals and supplements, so a modification requiring one of those submissions carries the obligation too. Devices that require no premarket submission at all, such as 510(k)-exempt devices, have no 524B submission requirement, though other FDA cybersecurity expectations and quality system obligations still apply.

Is an SBOM actually mandatory for medical devices?

For cyber devices, yes. Section 524B(b)(3) of the FD&C Act requires manufacturers of cyber devices to provide a software bill of materials including commercial, open-source, and off-the-shelf software components, and that is a statutory requirement rather than a guidance recommendation. FDA's premarket cybersecurity guidance describes the content it recommends the SBOM contain. Devices that fall outside the cyber device definition are not covered by that statutory requirement, though an SBOM is still commonly expected as good practice and by customers.

Which FDA cybersecurity guidance is current?

As of August 2026 the operative document is "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", issued February 3, 2026, under docket FDA-2021-D-1158. Its cover states that it supersedes the June 27, 2025 guidance of the nearly identical name, which in turn followed a September 2023 edition. Separately, the older "Refuse to Accept Policy for Cyber Devices and Related Systems" guidance is expired: its policy ran out on October 1, 2023, from which point FDA has expected sponsors to have had sufficient time to prepare submissions containing the section 524B information.