Accountability is shared between healthcare delivery organizations and medical device manufacturers. Hospitals should evaluate network security, protect their systems, and manage devices in use. Manufacturers should build security into design, prepare for updates, and communicate device risks clearly. Shared responsibility only works when each side owns its part of the lifecycle, from manufacture to deployment and maintenance.
Who Owns IoMT Security in Practice?
IoMT security is not owned by a single team. Healthcare delivery organisations own the environment the device operates in, including network segmentation, asset inventory, access control, monitoring, and safe deployment. Manufacturers own the security characteristics they ship, including secure design, vulnerability handling, update capability, and clear risk communication. The important point is that accountability follows control of the lifecycle, not just who uses the device day to day.
That division matters because IoMT devices often sit at the boundary between clinical operations and product security. If one side assumes the other is handling hardening, patching, or risk acceptance, the device can remain exposed for its full service life. Shared accountability works only when each party has a defined set of decisions it can actually make.
NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it gives structure to the controls the hospital must operationalise across access, audit, configuration, and system integrity.
How Responsibilities Split Across the Device Lifecycle
The cleanest way to divide responsibility is by lifecycle stage. Before procurement, healthcare organisations should assess whether the device fits their network, patching, logging, and segmentation model. During deployment, they should place the device in the right trust zone, restrict who can reach it, and verify the vendor’s update process. During operation, they should monitor for drift, expired support, and unusual behaviour.
Manufacturers are responsible for making the device supportable in the real world. That includes secure default settings where feasible, documented hardening guidance, timely vulnerability disclosure, authenticated updates, and a realistic end-of-support plan. If the vendor cannot patch or even describe the device’s security properties, the organisation cannot safely operate it at scale.
RFC 9700: Best Current Practice for OAuth 2.0 Security is not an IoMT standard, but it reinforces the broader principle that authentication and token handling only work when the implementation owner and the platform owner both enforce the control boundaries.
What Good Accountability Looks Like in Clinical Environments
Good accountability is explicit, documented, and testable. The hospital should know which devices are approved, who owns each clinical asset, how connectivity is governed, and who approves exceptions. The manufacturer should publish security contacts, support timelines, update channels, and the conditions under which a device should be withdrawn or isolated.
The handoff points matter as much as the technical controls. Procurement should not treat security as a post-purchase issue, and clinical teams should not be left to interpret patch notices on their own. A workable model assigns the hospital ownership of local risk decisions and the manufacturer ownership of product security decisions, with both sides contributing to incident response when a device issue affects patient care.
OWASP Non-Human Identity Top 10 provides a useful adjacent lens for the credentials and access paths that often underpin device connectivity, especially where devices or supporting systems rely on long-lived secrets or weak lifecycle control.
Risk and Threat Considerations
IoMT creates shared risk because security failures can come from either side of the relationship. A hospital can expose devices through flat networks, weak segmentation, or poor inventory control, while a manufacturer can leave devices exposed through weak update design, unsupported software, or unclear vulnerability disclosure. When those failures combine, the result is not just data exposure, but possible interruption to clinical operations and patient safety.
Failure mechanism: Attackers and operational failures both exploit the gap between who runs the device and who can actually secure it. If patching, isolation, and lifecycle ownership are not assigned, the device can remain reachable, vulnerable, and difficult to remediate.
Impact: The likely outcome is prolonged exposure, slower containment during incidents, and a higher chance that a device issue becomes a wider clinical or network event rather than a contained product defect.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IoMT programs depend on credential lifecycle control for devices and supporting systems. |
| AC-4 — Information Flow Enforcement | Hospital ownership includes constraining how IoMT devices communicate on clinical networks. | |
| SI-2 — Flaw Remediation | Manufacturer accountability includes timely vulnerability handling and patch availability for devices. | |
| Recommendation — Manage device and system credentials with defined issuance, rotation, storage, and revocation rules. Enforce network flow restrictions around IoMT devices and isolate them from unnecessary reachability. Track device flaws and apply or coordinate remediation before exposure becomes persistent. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | IoMT accountability depends on how vulnerabilities are identified, communicated, and remediated. |
| A.5.23 — Information security for use of cloud services | Many IoMT ecosystems depend on vendor-managed services, update channels, or remote support paths. | |
| Recommendation — Require vulnerability handling and remediation responsibilities for deployed medical devices. Define security requirements for any external service used to manage or support IoMT devices. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Hospitals must harden and maintain IoMT configurations after deployment. |
| CIS-13 — Network Monitoring and Defense | Monitoring is essential to detect unusual IoMT behaviour and segmentation failures. | |
| Recommendation — Standardise secure IoMT configurations and verify they remain unchanged over time. Monitor IoMT traffic and alert on unexpected connections or protocol use. | ||
Practitioner Guidance
What to prioritise: Start with the devices that combine network reachability, clinical criticality, and weak update support. Those are the assets where unclear ownership creates the highest operational and patient-safety exposure.
What to verify: Confirm who can approve network placement, who can rotate or revoke credentials, who receives vulnerability notices, and who can actually deploy a fix. If those answers are not explicit, the accountability model is not real yet.
Practitioner takeaway: IoMT security fails when accountability is shared in theory but fragmented in practice, so the operating model must assign each lifecycle decision to the party that can genuinely execute it.
Related resources from NHI Mgmt Group
- Who is accountable when passwordless access fails in a healthcare workflow?
- Who is accountable when an AI agent takes a harmful action in healthcare?
- Who is accountable when healthcare data is exposed through weak access governance?
- Who should be accountable for device and API authentication in healthcare programmes?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
