On this page
Published: September 17, 2026
Key Takeaways
- The health delivery organization environment supplies compensating controls that a home environment does not, and your risk file may only credit controls that actually exist.
- Every environmental assumption in the threat model is a claim the FDA can ask you to substantiate in the security architecture views.
- Home use pushes authentication, key management, update delivery, and end-of-life data destruction onto the device itself.
- Labeling is the weakest control in the ISO 14971 hierarchy, and an untrained home user is the least reliable place to put a security requirement.
- A dual-environment indication means engineering to the weaker environment rather than maintaining two sets of assumptions.
- Expanding a cleared professional-use device into home use adds attack surface and generally triggers a new 510(k) rather than a letter to file.
A hospital device inherits network segmentation, managed identity, physical access control, and biomed-led patching from the health delivery organization, so its security risk file can credit those controls. A home use device inherits none of them and must carry authentication, secure boot, encrypted transport, automatic update delivery, and secure decommissioning itself. The February 3, 2026 premarket cybersecurity guidance expects your threat model to name the assumed use environment and to defend every control you hand to the user.
Two devices can run the same firmware, expose the same interfaces, and still need different security packages. The difference is where the device is indicated to operate.
A hospital deployment sits inside an environment somebody else secures. A patient's living room does not. When the intended use environment moves from a health delivery organization to a home, the controls a manufacturer was quietly relying on disappear, and the FDA reviewer notices when the threat model still assumes they are there.
Section 524B applies to both. The difference is not whether you owe a cybersecurity package, it is which assumptions that package is allowed to make.
Why This Matters
The FDA final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued February 3, 2026, asks for security architecture views that show trust boundaries and the controls at each one. A trust boundary is defined by the environment on either side of it, which means the views cannot be drawn without first fixing the intended use environment.
That is where use environment stops being a regulatory affairs detail. If your data flow diagram shows a device on a segmented clinical VLAN behind institutional authentication, you have credited controls owned by the health delivery organization. If the Indications for Use statement also permits unsupervised home use, those credits are unearned for a large share of your installed base, and the residual risk in the ISO 14971 file is understated.
Home-use growth makes this common rather than exotic. Remote patient monitoring, home dialysis, home ventilation, continuous glucose monitoring, and at-home infusion all place networked devices on consumer routers with no security staff behind them. The device is the perimeter.
ISO 14971 puts inherent safety by design first, protective measures second, and information for safety last. IEC 60601-1-11 already sets requirements specific to the home healthcare environment, and AAMI TIR57 expects the security risk process to reflect the real operational context. A control that only works when a trained biomed technician applies it is not a control in a house.
What does the hospital environment give you that the home does not?
The health delivery organization supplies a layered environment that absorbs a meaningful part of the device's risk. Your device benefits from it whether or not you wrote it down.
| Control | Hospital environment | Home environment |
|---|---|---|
| Network segmentation | Clinical VLANs, firewalls, medical device isolation | One flat consumer router, shared with everything else |
| Identity and access | Managed directory, badge access, role separation | One household, often one shared login |
| Physical security | Locked rooms, staffed floors, asset tracking | Unrestricted access by anyone in the house |
| Patching | Biomed and IT teams with maintenance windows | The patient, if they notice at all |
| Monitoring | Security operations, network detection, asset inventory | None |
| Procurement review | MDS2 forms, security questionnaires, contractual controls | No review at all |
Any control listed in the hospital column that your risk file relies on must be replaced by a device-resident control before the same product can be indicated for home use.
Which assumptions break the moment a device goes home?
Five assumptions fail immediately, and each one shows up as a deficiency when the threat model still carries it.
The network is trusted. A home router may be unpatched, running default credentials, or already compromised. Treat the local network as hostile and authenticate and encrypt accordingly.
The operator is trained. A clinician follows procedure and escalates anomalies. A patient may hand the device to a family member, reuse a password, or ignore an alert entirely.
Physical access is controlled. Visiting relatives, children, housemates, and eventual resale on a secondhand marketplace all count as physical access to your device and whatever data it retains.
Updates will be applied. Nobody in the house is scheduling a maintenance window. If the update is not automatic, assume it does not happen.
The device stays with one patient. Home devices are returned, refurbished, loaned, and resold. Residual patient data and residual credentials travel with them.
Which controls move onto the device itself?
Everything the environment used to provide has to be designed in. That is the practical cost of a home-use indication.
- Device-side authentication that does not depend on an enterprise directory, with a credential recovery path a patient can complete without a help desk.
- Secure boot and firmware integrity verification, because physical access is now realistic and tamper detection has no staff to alert.
- Encrypted transport to your cloud with certificate validation, assuming an untrusted local network end to end rather than TLS terminated at a trusted gateway.
- Automatic, signed, resumable updates with rollback protection, delivered without user action and tolerant of intermittent residential connectivity.
- Secure decommissioning, including a factory reset that removes patient data and unbinds credentials, verifiable by the manufacturer rather than trusted to the user.
- Caregiver and multi-user access modeled explicitly, so shared household use does not become one permanent shared credential.
Each of these belongs in the security architecture views and the control traceability, not only in the design history file.
How does the use environment change the threat model and testing?
See also: FDA AI Cybersecurity Threats: 7 Attacks, Infusion Pump Cybersecurity: FDA, and Indications for Use, Predicates, and Cybersecurity Scope.
The use environment sets the attacker you are defending against, which changes both the threat model and the test plan.
In a hospital model, the relevant adversaries are typically a compromised workstation on the clinical network, a malicious insider, and a lateral-movement path from the enterprise side. In a home model, add a compromised consumer router, a hostile household member, an attacker with unlimited physical access and time, and a purchaser who acquired the device secondhand.
That difference lands directly in penetration testing scope. A home use engagement should include physical and hardware attack paths such as debug ports, storage extraction, and firmware dumping, alongside pairing and provisioning flows, credential recovery abuse, and the mobile app and cloud backend that most home devices depend on.
If your indication permits home use, the penetration test scope has to include physical attack paths. A network-only test against a device an attacker can hold in their hands does not match the threat model you filed.
Availability also changes character. In a hospital a dropped connection meets staff and backup procedures. At home an availability failure may go unnoticed for hours, which raises the harm rating for denial-of-service threats in the risk assessment.
Need to see how this feeds the submission? Our medical device threat modeling service builds the views and trust boundaries around the environment you actually claim.
What happens when you claim both environments?
Design to the weaker environment. A device indicated for both professional and home use does not get to maintain two sets of assumptions, because the FDA evaluates the residual risk for the full indicated population.
In practice that means the home-use control set becomes the baseline, and the hospital deployment simply benefits from additional layers it does not have to rely on. Writing it the other way around, with the home configuration as a reduced variant, is what produces the mismatch reviewers catch.
Expanding an existing cleared device into home use deserves particular care. It removes the assumed managed network, adds physical access threats, and usually adds a consumer app or cloud service. Those are new attack surface and new risk, which normally means a new 510(k) rather than a letter to file. Our pathway crosswalk tool walks that decision against the cybersecurity factors reviewers weigh, and the indications for use and predicate scope post covers how the statement itself drives submission scope.
How Blue Goat Cyber Approaches This
We read the intended use environment before we look at the architecture, because the environment determines which controls your risk file is allowed to credit. Our team holds medical device and offensive security credentials and works only on regulated devices, so the trust boundaries we draw reflect how these products are actually deployed.
For a home use or dual-environment device we build the threat model against the weaker environment first, then document where the hospital deployment adds layers on top. We enumerate every assumption the model makes about the network, the user, and physical access, and we mark each one as either a device-resident control or an environmental dependency. Environmental dependencies that cannot survive a home deployment get raised during design, not after a deficiency letter.
Testing follows the same logic. Home use engagements include hardware and physical attack paths, provisioning and recovery abuse, and the companion app and cloud backend, because that is the surface the filed threat model describes. Where the security risk assessment leaves a control to the user, we say so plainly and document why that placement is defensible under ISO 14971.
FAQ
CTA
If your device is moving from the clinic into the home, the assumptions in your threat model probably moved with it. We rebuild the model against the environment you are actually claiming and scope testing to match. Book a discovery session to walk through your use environment and 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 275+ 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.