What makes a device a ‘cyber device’ under Section 524B

A device doesn't become a “cyber device” because it runs software, or because it has a wireless radio, or because a security researcher could theoretically poke at it — it becomes one when it clears a specific three-part definition Congress wrote into Section 524B of the FD&C Act, and clearing that definition is what triggers three separate, named obligations in every 510(k), PMA, PDP, De Novo, or HDE submitted for it. The section arrived through the Consolidated Appropriations Act, 2023, signed December 29, 2022, and its submission requirements took effect March 29, 2023 — ninety days later, a statutory clock FDA doesn't control and can't extend. A submission built around general cybersecurity language, without first running the device through the three-part test the statute actually poses, is answering a question 524B never asked.

A conjunctive test, not a device category

Section 524B(c) defines a cyber device as one that meets three conditions at once: 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. All three have to be true together. A device that includes software but has no connectivity at all doesn't clear the bar under this test, whatever cybersecurity hygiene its developers practice anyway — and a device with a network port but no vulnerable characteristic the sponsor itself validated into the design doesn't clear it either. The definition is written to catch a specific combination, not to sweep in every device with a chip in it.

What clearing it then requires, in three places

Section 524B(b) attaches three specific obligations to a submission for a device that clears the definition, and none of them is satisfied by a general narrative about taking security seriously. The sponsor has to submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits within a reasonable time, including a coordinated vulnerability disclosure process; design, develop, and maintain processes and procedures that provide reasonable assurance the device and its related systems are cybersecure, along with a mechanism for making postmarket updates and patches available; and provide a software bill of materials covering the commercial, open-source, and off-the-shelf software components the device contains. Each of the three answers a different question — how you'll find out about a problem, how you'll fix the device generally, and what's actually inside it — and a submission that answers one well and leaves the other two as boilerplate has satisfied a third of the section.

The guidance explaining the statute already moved once

FDA's first final guidance interpreting 524B, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, issued September 27, 2023, read in places as a framework a sponsor was expected to follow rather than a set of binding minimums. The guidance FDA finalized on June 27, 2025, under the same title, added a new Section VII specifically addressing 524B and tightened that reading considerably — among other things, it treats SBOM submission for a cyber device as a strict precondition rather than a best practice, consistent with FDA's own enforcement posture since October 1, 2023, when it began refusing to accept cyber-device submissions missing one. A cybersecurity section built against the 2023 guidance and never checked against the 2025 update is citing a document FDA itself has since superseded — the same drift any mapped resource has to watch for.

The bill of materials is a format claim, not just a list

FDA's guidance recommends the SBOM arrive in a machine-readable format — SPDX and CycloneDX are the two it points to — carrying each component's version, supplier, and dependency relationships, not a prose paragraph describing the software stack in general terms. A table in a PDF listing library names without version numbers, with no machine-readable export behind it, satisfies the instinct behind the requirement without satisfying the requirement itself — the same gap a checklist item that's present but not actually checkable leaves behind everywhere else in a submission.

A different question from the one IEC 62304 asks

A device can carry a Class C software safety classification under IEC 62304 and still fail the 524B cyber-device test, and the reverse holds just as easily — 62304's classification sorts software by the harm it could cause if it malfunctions, a question about failure, while 524B sorts a device by whether it has a connected, potentially vulnerable attack surface, a question about exposure. A single device file can owe both records, and treating a completed IEC 62304 classification as evidence the cyber-device question has also been answered is confusing two tests that ask about different things.

A cyber-device determination record built around this structure — the three-part 524B(c) test run explicitly rather than assumed, the three 524B(b) obligations each documented on its own, and a citation checked against FDA's 2025 guidance rather than its 2023 one — is previewed in the launch catalog. If your program runs the definition differently, the shelf takes that correction directly.