Read Section 524B closely and a phrase keeps recurring. It is not “the device.” It is the device and related systems.
It appears in 524B(b)(2), in both of that subsection's clauses, and again in 524B(b)(4). Congress wrote it four times, which is usually a sign that the drafters meant it to carry weight. The statute does not define it, and that is where the guidance comes in.
What FDA puts inside the phrase
Section VII.C.2 of the February 2026 guidance is explicit:
“FDA considers related systems to include, among other things, manufacturer-controlled elements, such as other devices, software that performs ‘other functions’…, software/firmware update servers, and connections to healthcare facility networks.”
Take that at face value for a moment. The update server — the thing that hands your device its next firmware image — is named by FDA as a related system. So is the connection into the hospital network.
Neither of those is the device. Both are, for a manufacturer of a cyber device, inside the perimeter the statute describes.
Why that changes more than it first appears
If “related systems” only appeared in the design assurance clause, this would be a documentation question. It does not. It appears in the patching obligations too.
Section 524B(b)(2)(A) requires manufacturers to make available updates and patches to the device and related systems for known unacceptable vulnerabilities, on a reasonably justified regular cycle. Section 524B(b)(2)(B) requires the same, as soon as possible and out of cycle, for critical vulnerabilities that could cause uncontrolled risks.
So the cadence obligation does not stop at the device image. A critical vulnerability in the infrastructure that delivers your updates falls inside the same sentence as a critical vulnerability in the device itself.
That is a coherent position when you think about the threat. An update server is the highest-value target associated with a connected device, because whoever controls it controls what every unit in the field will trust and install next. It would be a strange regulation that secured the device and ignored the channel that writes to it.
The limiting principle, which matters
This is the point where it would be easy to overstate, so here is the guidance's own boundary, from footnote 64:
“For the purposes of this guidance, we refer to the evaluation of ‘related systems’ to the extent needed to determine that the device, as it interacts with related systems, remains cybersecure.”
Read that carefully, because it does real work. FDA is not asserting that your cloud account is a medical device, or that your entire infrastructure enters the quality system. The evaluation is scoped to what is needed to conclude that the device stays secure given how it interacts with those systems.
That is a proportionate standard. It is also not an exit. “To the extent needed” still requires you to have looked, to know what the interaction is, and to be able to explain why the conclusion holds.
Why small manufacturers miss this one
Not through negligence. Through org chart.
In a company of fifteen people, the update server usually lives in a cloud account that engineering set up, or that an outsourced development partner administers. It is infrastructure, and infrastructure has an owner who is not regulatory. It frequently does not appear in the device master record. It is often shared across products, sometimes across products that are not devices at all. Nobody thought to put it in the risk file because nobody thought of it as product.
Then the premarket submission asks for a security architecture view — a description of how the device interacts with the systems around it — and the diagram either includes the update path or it does not. If it does not, the submission is describing a device that apparently updates itself from nowhere.
That is the moment the question surfaces, and it surfaces at the worst possible time: with a filing date attached.
Three things worth checking now
- Does your architecture documentation show the update path at all? Not the feature — the path. Where the image comes from, who can publish to it, how the device decides to trust it.
- Who administers that infrastructure, and are they inside your quality system? If the answer is an outsourced partner, the follow-up is whether your agreement with them contemplates a patch you have to ship out of cycle because a vulnerability is causing uncontrolled risk.
- Is it shared? A server that serves both a Class II device and a wellness product is not automatically a problem, but it is a fact you want to have found yourself.
None of this is exotic security work. It is mostly writing down what is already true, in a place where a reviewer will look for it. The expensive version is discovering, three weeks before filing, that what is already true is not what you would have chosen.