On this page
Published: July 30, 2026
Your Indications for Use statement determines cybersecurity scope more than most teams expect. It fixes the use environment, the user population, and the severity of harm if the device is compromised, and all three feed the threat model, the architecture views, and the penetration test boundary. Predicate choice then sets the baseline you are compared against, so every connectivity feature added beyond the predicate needs an explicit cybersecurity delta narrative.
Two identical devices can owe completely different cybersecurity packages. The only difference is a sentence on the Indications for Use form.
Regulatory teams treat the Indications for Use statement as a clinical and marketing artifact. Security teams rarely read it at all. That gap is where 510(k) cybersecurity deficiencies come from, because the reviewer reads both documents together and expects them to agree.
Why this matters
The FDA's final premarket cybersecurity guidance of February 3, 2026 frames security risk in terms of patient harm, not information-security abstractions. Risk is a function of exploitability and the severity of harm that exploitation could cause. Severity of harm is a clinical judgment, and the clinical judgment is anchored in what the device claims to do, for whom, and where.
That makes the Indications for Use statement an input to the security risk assessment, not a parallel document. A monitor indicated for use by trained clinicians inside a managed hospital network sits behind institutional controls. The same monitor indicated for unsupervised home use over a patient's own network has no such perimeter, so the device itself must carry controls the hospital version could inherit from its environment.
Section 524B, meanwhile, is indifferent to your indication. The statute attaches to the definition of a cyber device, meaning software validated, installed, or authorized by the sponsor, an ability to connect to the internet, and technological characteristics that could be vulnerable to threats. Narrowing your indication does not narrow that definition.
How Indications for Use map to cybersecurity scope
| Indications for Use element | What it drives in the security package |
|---|---|
| Use environment (hospital, clinic, home, ambulance) | Trust boundaries, assumed network controls, physical access threats |
| User population (clinician, caregiver, patient) | Authentication design, usability of security controls, labeling depth |
| Patient population (adult, pediatric, critical care) | Severity of harm ratings in the ISO 14971 chain |
| Life-supporting or life-sustaining claim | Availability threats become safety threats, not nuisance findings |
| Multi-patient use | The multi-patient harm architecture view becomes central |
| Remote monitoring or remote adjustment | Adds a cloud and transport attack surface plus command-integrity threats |
| Interoperability claim | Every named interface is in pen test scope |
The security use case view and the multi-patient harm view in the February 3, 2026 guidance both depend on facts stated in the Indications for Use. If the views contradict the indication, expect a deficiency.
Predicate choice and the cybersecurity delta
In a 510(k) you are arguing substantial equivalence to a predicate. Reviewers read your cybersecurity evidence against that same frame, and the most common cybersecurity deficiency in 510(k) review is unaddressed predicate divergence.
The pattern is predictable. The predicate cleared years ago as a standalone device. Your version adds Bluetooth, a companion app, and a cloud dashboard. The clinical argument for equivalence is sound because the diagnostic output is unchanged. The cybersecurity argument is missing entirely, because nobody wrote the narrative explaining what attack surface the new interfaces introduce and how it is controlled.
What the narrative needs to contain:
- Every interface and data flow present in your device but absent from the predicate.
- The threats those additions create, mapped through STRIDE per element.
- The controls mitigating each threat and the verification evidence for each control.
- The residual risk after controls, tied back into the ISO 14971 risk file.
- Any indication difference that changes severity of harm relative to the predicate.
Reviewers do not expect you to retroactively cyber-document an old predicate. They expect you to be explicit about the delta.
When an Indications for Use change forces a new 510(k)
For a marketed device, an Indications for Use change is evaluated under the FDA's device modifications guidance. The cybersecurity question is whether the change affects safety or effectiveness through a security pathway.
Changes that usually require a new 510(k):
- Moving from professional use to home use, which removes the assumed managed network.
- Adding remote monitoring, remote configuration, or remote therapy adjustment.
- Extending to a life-sustaining or critical care population, raising the harm ceiling.
- Extending to multi-patient use, which changes the harm scale from one patient to many.
Changes that can often be documented in a letter to file:
- Narrowing an indication without touching the architecture.
- Clarifying wording where the use environment and connectivity are unchanged.
- Adding a patient subpopulation with no new interfaces and no severity increase.
See also: Types of 510(k): Traditional, Special, Abbreviated, Mining FDA Databases for Cybersecurity Precedent, and Letter to File vs New 510(k).
The test is not whether you touched code. It is whether the modification could significantly affect safety or effectiveness, and new attack surface routinely can.
Is a Special 510(k) available for a security-relevant change?
Sometimes, but less often than sponsors hope. A Special 510(k) requires that the change be one where the sponsor can evaluate the effect using well-established methods and the results are summarizable in a way that is reviewable through a summary format.
Security patches to an existing, already-documented architecture often qualify. Adding a wireless interface or a cloud service usually does not, because there is no pre-existing verification method that covers a surface the device never had. When in doubt, the decision belongs in a pre-submission rather than in a gamble on the acceptance review.
Our pathway crosswalk tool walks the letter to file, Special 510(k), and new 510(k) decision against the cybersecurity factors reviewers weigh.
How Blue Goat Cyber approaches this
We start every premarket engagement by reading the Indications for Use statement before we look at the architecture. The statement tells us the use environment, the user population, and the harm ceiling, and those three facts determine the trust boundaries we draw in the data flow diagrams and the severity ratings in the risk file.
We then build the predicate-comparison cybersecurity narrative as its own artifact rather than a paragraph buried in the summary. It enumerates every interface your device has that the predicate did not, the threats each adds, the controls applied, and the verification evidence, so a reviewer can see the delta without reconstructing it.
Where the indication and the technical documentation disagree, we flag it before submission. That disagreement is cheap to fix in draft and expensive to fix in a deficiency response.
FAQ
CTA
If your Indications for Use and your threat model were written by different people who never compared notes, that gap will surface in review. We read both together and rebuild the predicate-comparison narrative before it becomes a deficiency letter. Book a discovery session to walk through your submission scope.
About the author
Christian Espinosa, MBA, CISSP · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 250+ FDA medical device submissions; no client has failed to clear due to cybersecurity. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.