How to read a device cybersecurity submission

Cybersecurity used to be a topic a reviewer might raise. For a growing set of devices it’s now a required part of the submission, with a statute behind it — and a documentation package that has to show a real plan, not a paragraph about taking security seriously.

What the package has to show

A threat model has to map the device’s actual interfaces — a wireless radio, a service port, a network connection — to who could realistically exploit them and what control addresses that specific path. It’s the same discipline as a risk management file, applied to a hazard category that keeps changing after the device ships. The SBOM has to function as a living artifact rather than a one-time snapshot, since the components inside a device don’t stay fixed once code ships and a snapshot from early development tells a reviewer almost nothing true by clearance. Verification activities appropriate to the device — vulnerability testing, static and dynamic analysis, penetration testing where warranted — have to back up the threat model rather than stand in for it. And the package needs a credible answer for what happens after clearance: who monitors for new vulnerabilities, how a fix actually reaches a device already installed at a hospital, and what the process looks like when an outside researcher reports something. The 510(k) building-the-file work covers where this fits inside a submission alongside the rest of the testing burden.

What a thin package looks like

An SBOM that reads like a template filled in generically, rather than a real inventory of this device’s actual components, is the most common tell. A threat model that lists generic categories — malware, unauthorized access — without ever connecting them to the device’s actual attack surface doesn’t hold up under a close read either. And a postmarket section that describes a philosophy about taking vulnerabilities seriously, without describing an actual mechanism for how a patch reaches a device that’s already in the field, leaves the most consequential question in the whole package unanswered.

The requirement is relatively new, but the underlying discipline isn’t — it’s the same trace from hazard to control to verification that a risk management file demands everywhere else. The difference is that this hazard category keeps changing after the device ships, which is exactly why the plan for what happens next carries as much weight as the analysis that came before it.