Interoperability vs. Security: Balancing the IoMT Paradox

The Internet of Medical Things has spent the last decade trying to solve two problems at once. The first is interoperability: getting infusion pumps, patient monitors, imaging systems, wearables, and electronic health records to speak a common language so that clinicians have a complete picture of the patient. The second is security: making sure that the same connections do not become the route by which ransomware, data theft, or device tampering reaches the bedside. Every honest practitioner in this field has felt the tension. Open the device up and it becomes useful. Open it too far and it becomes a liability.

Why the paradox is real

For most of the history of medical devices, security was provided by isolation. A ventilator sat behind a clinical engineering wall. An imaging modality talked only to its own workstation. A bedside monitor was a closed appliance. The trust model was implicit: if the device was physically on a hospital floor, it was trustworthy enough to operate.

Modern care has dissolved that perimeter. Hospitals run HL7 and FHIR interfaces so that a vitals reading can land in the EHR within seconds. DICOM endpoints accept studies from referring clinics. Wearables stream from a patient’s home into a remote monitoring platform. Each new integration is justified by a real clinical benefit, and each one widens the surface that an attacker can probe. The paradox is not that security and interoperability are philosophically opposed. It is that every interoperability decision has a security consequence, and most organisations make the first decision faster than they make the second.

What the attack surface actually looks like

It helps to be specific about where the risk lives. In a typical IoMT deployment the surface has four layers, and each one needs its own thinking.

The device itself. Firmware, bootloader, debug ports, embedded credentials, third-party components with known vulnerabilities. Many fielded devices were certified years ago against a software bill of materials that is now partly end-of-life.
The local network. Clinical VLANs, wireless segments, and the gateways that bridge proprietary protocols to IP. A flat network turns one compromised infusion pump into a foothold against every device on the floor.
The integration layer. HL7, FHIR, DICOM, MQTT, and vendor APIs. These speak in clinical semantics, which means a successful injection here can change a medication order or a lab result, not just leak data.
The cloud and partner ecosystem. Manufacturer telemetry, remote monitoring services, analytics vendors, and the identity systems that tie them together. A breach upstream of the hospital can reach every customer at once.

Why the standard answers are not enough

The instinctive response to this picture is to harden the perimeter: more firewalls, more segmentation, more VPNs. These help, but they do not resolve the paradox, because the whole point of interoperability is to let data flow through those boundaries. A segmented network that nothing useful can cross is just an expensive way to recreate the old isolation model.

The other instinctive answer is to demand stronger device security from manufacturers. This is also necessary, but slow. The installed base in a typical hospital includes devices that will still be in service in 2035. Waiting for the fleet to be replaced is not a strategy. The security posture has to be improved around devices that cannot themselves be upgraded.

A more honest framing

The useful reframe is to stop treating interoperability and security as a single tradeoff dial and start treating them as two independent design problems that meet at well-defined interfaces. Interoperability is about what data can be exchanged and in what form. Security is about who is allowed to exchange it, under what conditions, and with what auditability. A mature IoMT program decides both at the same time, for the same interface, with the same people in the room.

Concretely, this means that every new integration request — a new FHIR endpoint, a new vendor cloud connection, a new wearable program — should arrive with answers to a fixed set of questions before it ships. What data crosses this boundary? Who is the verified caller on each side? How is that identity established and rotated? What happens when the boundary fails open versus fails closed? What is logged, and who reviews the logs? These are not exotic questions. They are simply the questions that get skipped when the clinical pressure to ship is high.

Five practices that hold both

A few patterns recur in IoMT programs that manage to be both open and defensible. None of them are novel. All of them require organisational discipline more than new technology.

Treat every device as untrusted. Apply zero-trust principles inside the clinical network. A monitor on the floor should authenticate to the integration layer just like a cloud service would, not be trusted because of its IP address.
Make the integration layer the security control point.A well-designed FHIR or HL7 gateway is the right place to enforce authentication, authorisation, schema validation, and rate limits. It can do for the fleet what individual devices cannot do for themselves.
Maintain a live software bill of materials. Know which devices contain which components, and which of those components have open vulnerabilities today. Without an SBOM the weekly CVE feed is just noise; with one it becomes a work queue.
Segment by clinical function, not by vendor. Group devices that legitimately need to talk to each other and isolate those that do not. Lateral movement from a coffee-shop tablet to a surgical robot should require crossing several explicit boundaries.
Rehearse the failure modes. Tabletop the day a remote monitoring vendor is breached, the day a firmware update bricks a class of pumps, the day an HL7 feed starts emitting plausible but wrong values. The organisations that recover quickly are the ones that have already argued about who decides what.

Where regulation is heading

Regulators have noticed the paradox too. Health Canada’s pre-market cybersecurity guidance under SOR/98-282 and PIPEDA’s safeguards obligations set the baseline in Canada; the FDA’s Section 524B expectations around premarket cybersecurity documentation now sit alongside it in the US; and the EU’s MDR, NIS2, and Cyber Resilience Act regimes round out the picture in Europe. All of them push in the same direction: device makers must demonstrate that they have thought about the connected lifecycle, not just the box. This is good news for hospitals, because it gradually shifts some of the burden upstream. It is not a substitute, however, for the operational work on the hospital side. A perfectly compliant device on a poorly designed network is still exposed.

A working answer to the paradox

Interoperability and security are not opposites. They are two properties of the same system, and they are best designed together by people who understand both. The organisations that get this right tend to share a few traits. Their clinical engineering, IT security, and clinical informatics teams sit in the same governance forum. Their integration platform is treated as critical infrastructure with its own roadmap and budget, not as plumbing. Their procurement process asks security questions early enough to influence vendor choice, not late enough to merely document risk. And they accept that the work is never finished, because every new device, every new partner, and every new clinical workflow changes the surface.

The IoMT paradox dissolves the moment you stop trying to choose between connected and safe and start designing for connected and safe. That is harder than picking a side. It is also the only answer that survives contact with how modern care actually works.

Hardware

Biocompatible Implantable Sensors and the SafetyPatch: A Future Vision

Biodegradable SpO2, temperature, and blood pressure implants paired with a skin-worn SafetyPatch for calibration and alerting.

Software

Agentic Care at the Edge: Should the Phone Decide, or the Cloud?

Where agentic AI belongs in point-of-care monitoring — on-device, in the cloud, or tiered across both.