Is my device a cyber device? What the FDA guidance actually says.

You're working through the eSTAR. You reach the cybersecurity testing section and find the line that gives every small team a moment of hope: "Alternatively, provide a justification for why particular testing was not performed."

Your device is modest. The only way anything gets in or out is a single USB port, used to load firmware updates and export an operation log onto a memory stick. No Wi-Fi, no network jack, no cloud. It never touches the internet. So the thought forms naturally: surely all this cybersecurity testing isn't meant for us?

It's a fair question, and asking it is the right instinct. Checking whether an obligation actually applies to your device before spending money on it is exactly what a good regulatory adviser will do with you, and the statutory definition looks, at first read, like it might be amenable. So let's take the question seriously and walk it through properly, because the answer is written down, and it's been written down for longer than most people realise.

What "cyber device" actually means

The term comes from Section 524B of the FD&C Act. A device is a cyber device if it meets three conditions, joined by "and": it includes software validated, installed, or authorised by the sponsor as a device or in a device; it has the ability to connect to the internet; and it has technological characteristics, validated, installed, or authorised by the sponsor, that could be vulnerable to cybersecurity threats.

All three must be true, and that "and" is where the question gets interesting. On a plain reading of the statute, a USB port isn't an internet connection. A device that only ever meets a memory stick, the reasoning goes, fails the second condition, so it's not a cyber device, and the cybersecurity documentation requirements don't apply.

That's a legitimate reading of the words Congress wrote, and working through the three-limb test with your adviser is the right first step for any device. The reason it doesn't end the story is that the FDA has told us, in writing, how it reads limb two.

What the guidance says, and has been saying for years

The FDA's interpretation isn't new, and it isn't drifting. Section 524B has applied to premarket submissions since March 2023, and since October 2023 the FDA has been able to refuse to accept submissions that ignore it. The agency put its reading of "ability to connect to the internet" on the public record in its 2024 draft updates to the premarket cybersecurity guidance, finalised it in 2025, and kept it in the February 2026 revision. Two revisions on, this isn't a position the agency is experimenting with. It's settled.

Here it is in the FDA's words: "FDA also 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 (including at any point identified in the evaluation of the threat surface of the device and the environment of use)."

The reasoning is blunt: "It is well-demonstrated that if a device has the ability to connect to the Internet, it is possible that it can be connected to the Internet, regardless of whether such connectivity was intended by the device sponsor." The agency's footnoted example is WannaCry, which encrypted hospital devices nobody had intended to expose.

And in case any doubt survives that passage, the guidance lists the features it considers to confer the ability to connect. Alongside network and cloud connections and radio-frequency communications such as Wi-Fi, cellular, and Bluetooth, the list includes "Hardware connectors capable of connecting to the internet (e.g., USB, ethernet, serial port)".

There's even a footnote for precisely our scenario. A device may need to be serviced via a USB connection, it notes, and while the connection may be brief, "the ability to connect is present and the device is therefore considered to have the ability to connect to the internet."

Read together, that settles it. A USB port is a general-purpose data interface: with an adapter it becomes a network connection, and plugged into a laptop it becomes a bridge to whatever that laptop touches. The memory stick carrying your firmware update was almost certainly written on an internet-connected machine. Your device doesn't need to touch the internet today. The ability is the trigger, and a USB port is the ability.

What arguing actually costs

Suppose you write the justification anyway. Manufacturers have tried this route, including teams whose devices had nothing but a USB port and a supplied memory stick, and the accounts that reach me all end the same way: the FDA treats the device as a cyber device and asks for the documentation it expected in the first place. Given what the guidance says in black and white, that shouldn't surprise anyone.

That request typically arrives as an Additional Information request (missing cybersecurity content can also surface earlier, as a technical screening hold in eSTAR, which carries the same 180-day clock), and this is where the real cost sits. An AI request places your submission on hold and starts a fixed clock: the FDA must receive a complete response to every deficiency within 180 days, with no extensions. Miss it and the submission is considered withdrawn and deleted, and you start again with a new 510(k).

So the justification route doesn't remove the work. It defers the work into a compressed window, after you've already spent time on the argument, and puts your whole submission behind it. Teams in this position end up building a threat model, testing evidence, and vulnerability documentation at speed while the clock runs. When clearance is the milestone between you and your next funding round, that's an expensive way to lose an argument the guidance had already decided.

The good news: for a USB-only device, the work is small

Here's the part that gets lost in the horror stories. If your device's entire external interface is one USB port, your attack surface is genuinely small, and the cybersecurity package scales with it.

The work concentrates in two places. First, the security of the update mechanism itself: signed firmware, verification on the device before anything installs, and a bootloader that won't run code it can't trust. Second, constraining the port to its intended functions, so it accepts firmware updates and exports logs and does nothing else, with evidence that the constraint holds.

That's a bounded engineering task, not a research programme. Threat modelling it is measured in days, not months. The six-figure disaster stories you may have seen are real, but they're stories about discovering the obligation late, inside that 180-day window, and rebuilding a submission under pressure. They're not stories about what the work costs when you scope it into the project from the start.

How you'd genuinely take a USB port out of scope

If you truly want the port outside cyber-device scope, the credible routes are physical, not rhetorical.

A tamper-evident seal over the port. The port is unavailable in normal operation and any use is visible. A reviewer can understand this control, and it carries labelling and quality system consequences you'll need to document.

Physically disabling or omitting the connector. The strongest position, because there's nothing to connect to.

A charging-only port. A port used purely for power has a credible argument, because the guidance's list is about hardware connectors capable of carrying data to a network. But that's a claim about the hardware, and claims need evidence: you'd show the USB data lines are disabled by design and back it up with verification testing. "It's only for charging" is an assertion; the test report is what a reviewer can accept.

Disabling the port in software. The weakest route. It can work, but you'd need strong evidence that the interface can't be re-enabled, re-flashed, or bridged by anyone with physical access. Producing that evidence is itself cybersecurity engineering, which rather defeats the purpose.

And then there's the catch that usually ends the conversation. Seal or remove the port and you've also removed your route for delivering firmware updates in the field. For a device that will need firmware updates across its lifetime, that's rarely a trade you can accept. Most teams, seeing it clearly, keep the port. Which means the device stays in scope, and the real task isn't avoiding the work but doing it proportionately and well.

The update mechanism is an attack vector in its own right

There's one more reason the "it's only for updates" framing undersells the problem. The update path isn't just what brings the device into scope. It's an attack surface, and your threat model needs to treat it as one.

Think about what an unprotected firmware update path offers an attacker: install their own code, tamper with an image in transit, read the firmware to hunt for other weaknesses, or push the device back to an older version with known holes. These are well-documented categories of attack on embedded devices, not hypotheticals.

If your team is new to threat modelling, you don't need to invent the threats yourself. MITRE EMB3D is a free, openly published threat model built specifically for embedded devices, and it catalogues the update-path threats directly. The entries worth working through for a USB update mechanism:

Inadequate bootloader protection and verification (TID-201). If the bootloader will load whatever it finds, everything downstream is built on sand. Secure boot anchors the whole update chain.

Unauthenticated firmware installation (TID-211). The device accepts firmware without verifying a cryptographic signature, so a crafted image installs without challenge. The mitigation a reviewer expects is signed firmware, verified on the device.

Faulty update integrity verification (TID-213). The device checks integrity, but the check can be bypassed or isn't consistently enforced. Verification has to actually hold.

Unencrypted updates (TID-215). The firmware image travels and sits in the clear, free to be extracted and studied. Encryption protects the image and, with it, the rest of your attack surface.

Firmware update rollbacks allowed (TID-216). The device accepts an older, weaker version of its own firmware. Rollback protection closes that door.

Untrusted external storage (TID-111). The memory stick itself. Anything the device reads from removable media is input from an untrusted source, however carefully your process manages the sticks.

Work through these and you get two things at once: a more secure device, and a threat model you can put in front of a reviewer. That's the difference between documentation that reads as box-ticking and documentation that reads as engineering.

What if it isn't a USB port?

USB catches people out because it feels innocuous. The same logic applies, usually more obviously, to everything else.

Bluetooth and BLE. Wireless connectivity is the clearest trigger of all. "Local only" pairing is still a connection, and the guidance's radio-frequency wording covers it without strain.

Wi-Fi. In scope, and frequently a direct route to the internet rather than an indirect one.

Ethernet and other network ports. Named in the guidance's list of hardware connectors.

Serial and debug interfaces (UART, JTAG). These are there for your engineers, not your users, which is exactly why they get overlooked at submission time. They're still external interfaces an attacker with physical access can use. Harden or disable them, and document the decision.

Cellular and NFC. Wireless, in scope.

Magnetic inductive communications. The guidance names these too, which matters for implantables and their external programmers.

The useful question is rarely "does this device touch the internet today?" It's "does this device have software, plus any interface that could be reached or bridged?" If the answer is yes, plan on cyber-device obligations from the start. Designing for them is far cheaper than arguing against them at submission, and your regulatory adviser would much rather help you build the package than draft the appeal.

What you'll actually submit

If the sections above have moved you from "can we justify this away?" to "what does the package look like?", here's the shape of it for a cyber device. For a USB-only device, each item is smaller than its title suggests.

A threat model. The update-path analysis above feeds straight into it. EMB3D gives you the threat catalogue; your job is to show which threats apply and how the design addresses them.

A cybersecurity risk assessment. Security risks assessed and managed through a process that sits alongside the ISO 14971 risk management your QMS already runs, with the two kept coherent.

An SBOM, with support and end-of-support analysis. The SBOM itself is statutory: 524B(b)(3) requires a software bill of materials covering commercial, open-source, and off-the-shelf components. The guidance adds the expectation that you know the level of support and end-of-support date for each component. This is the piece Threat Detective automates: upload your SBOM, see the gaps against FDA expectations, and produce a submission-ready vulnerability report in minutes rather than days.

Security testing evidence. Security requirements testing, threat mitigation testing, and vulnerability testing, with penetration testing proportionate to the device. For one USB port, this is a bounded exercise.

Security architecture views. Diagrams and descriptions of the security-relevant design. For a USB-only device, mercifully short.

A cybersecurity management plan. How you'll monitor, identify, and address postmarket vulnerabilities, including coordinated vulnerability disclosure, required under 524B(b)(1).

Labelling. The cybersecurity information a user needs to operate the device securely, consistent with the rest of the submission.

None of these documents is large for a device this simple, and most of them draw on work your team is doing anyway.

This article discusses regulatory expectations in general terms and is not regulatory or legal advice for your specific device.