Every other cybersecurity document in a medical device submission assumes an answer to one question, and it is the question most companies settle in a hallway conversation. Is this thing a cyber device?
Section 524B(c) of the Federal Food, Drug, and Cosmetic Act defines the term, and the definition is a three-part test. A cyber device is one that:
- includes software validated, installed, or authorized by the sponsor, either as a device or in a device;
- has the ability to connect to the internet; and
- contains technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.
The three parts are conjunctive. All of them have to be true. Fail one and 524B does not attach.
What the definition leaves out matters as much as what it says. Nothing requires the device to be continuously connected. Nothing requires it to transmit patient data. Nothing requires it to be primarily software.
Being outside 524B is narrower relief than it sounds
Teams reach the end of this analysis hoping for a no, and a no is worth less than they expect.
Section 524B is one statutory hook. It is not the whole of what FDA expects on cybersecurity, and it is nowhere near the whole of what your quality system obliges you to do. A product outside the definition still has software that can fail, still has a design history file, and still has customers who will ask security questions in their own language on their own schedule. The relief is from a specific set of submission contents, not from the subject.
Worth saying up front rather than at the end, because wanting a particular answer is what corrupts the work that produces one.
Prong one is usually settled in a sentence
Software validated, installed, or authorized by the sponsor, as a device or in a device.
Firmware counts. Programmable logic counts. Software that runs on general purpose hardware and is regulated as the device itself counts. If you wrote it, or you chose it and shipped it, or you told a customer to install it, prong one is met. Very few products in the modern catalog get out here, and time spent arguing this one is time taken from the prong that actually decides the question.
Prong two is where the errors are
The statutory word is ability. Not connection, not present connectivity, not active use of the internet. The ability to connect.
That reading is broader than the plain-English one people apply to their own product. It reaches a USB port used for data transfer. A service laptop that a field engineer attaches to pull logs. A gateway or intermediary that relays device data onward, even where the device itself never touches the internet and has no concept of it.
So the absence of Wi-Fi and Bluetooth settles nothing. A product can have no radio of any kind, sit on a bench, and still land inside the definition through a path its designers think of as maintenance rather than as connectivity.
The method that works starts by refusing the obvious source. Do not reason from the marketing description, the datasheet, or the block diagram in the design file. Those describe the product somebody intended to ship. Enumerate the actual data paths in and out of the thing you built, including the ones used only in servicing and provisioning, and evaluate each one against the prong separately.
Two sources feed that list. The first is the physical inventory. A cellular radio on the board is a possible service path whether or not anyone in the room thinks of it as one, and the same goes for every connector, header, and interface that exists because a component arrived with it. The second, and the one I lean on, is the firmware. The code does not lie. A document tells you what the device is supposed to do. The build tells you what it does.
The path that gets missed most reliably is a module everyone believes is disabled. It was disabled by decision, then enabled in firmware to get a test to run, and it never went back off. Nobody is hiding anything - the document was accurate the day it was written, the divergence is old, and none of it is visible from the outside. You find that by reading the build, or you do not find it.
Prong three is nearly always met
Technological characteristics, validated or installed or authorized by the sponsor, that could be vulnerable to cybersecurity threats.
Anything carrying software of meaningful complexity meets this. The prong is written in the conditional, and no serious engineering argument gets you to a categorical no on a product that has a parser, a network stack, an update path, or a credential. Companies occasionally try to win the scoping question here, because it feels like the technical prong and therefore the one where technical people have leverage. It is a poor use of the energy. Spend it on prong two, where the answer is genuinely contestable.
What being in scope actually triggers
The obligations are specific, and they are covered in full in what Section 524B requires of a premarket submission. In summary, a cyber device submission carries:
- a plan to monitor, identify, and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure procedures;
- processes and procedures providing a reasonable assurance that the device and related systems are cybersecure, along with making postmarket updates and patches available for known unacceptable vulnerabilities and, on a shorter timeframe, for critical ones; and
- a software bill of materials.
This applies across 510(k), De Novo, PMA, and HDE, and it applies to supplements as well as to original submissions. A change to a cleared device that requires a new submission brings the cybersecurity content along with it, which is a separate question from whether the change requires a new 510(k) in the first place.
The determination is not finally yours
You do the analysis. FDA's interpretation decides it.
That is not a reason to skip the analysis, and it is not a reason to be paralyzed by it. It is a reason to use the mechanism that exists. FDA invites manufacturers to make contact when they are unsure, and the Q-Submission route is built for questions of this shape. Being told in a pre-submission that you are in scope is inconvenient and cheap. Being told during review is neither.
If you land on the line, build to it anyway
The genuinely ambiguous cases are not rare, and they resolve badly under deadline pressure, because the incentive at that moment runs one direction only.
Assume you are in scope. Threat model the product, write the requirements, run the testing, produce the plan. If it later turns out you did not strictly need the package, you have spent effort on work that answers customer security questionnaires, satisfies your own quality system, and makes the next submission faster. Guess the other way and get it wrong, and you find out at review, on a clock, with the whole chain of documents missing at once.
The next question, once you are inside the definition, is where all of that content comes from. It comes from the threat model, which every other cybersecurity document in the submission derives from.
This is engineering guidance, not legal or regulatory advice. A scoping determination for a specific product belongs with your regulatory lead.
This is the work I do - FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.