Isolation is what an organization does when it cannot patch or replace a device quickly enough. It is a control, not a cure. The difference matters because an isolation project that is not documented, tested and reviewed is only a network diagram with good intentions.

Why Isolation Is a Last Resort, Not a First

Isolation is a last resort because it limits functionality and adds operational complexity. Patching, upgrading or replacing the device is usually the better control; isolation is for the period when those options are not available.

A legacy device may be clinically essential and cannot be taken out of service for an upgrade. In that case, isolation buys time. It should be treated as a temporary compensating control with an owner, a review date and a plan to remove the underlying risk.

The distinction matters for the audit trail. An organization that isolates a device and calls the risk closed is not managing the risk; it is documenting a workaround. An isolation project can also create a false sense of security. A device on a separate VLAN is still reachable by anyone who can route to that VLAN, and a firewall rule that is too broad can leave the exposure unchanged. The record should say that the device remains unsupported and that replacement is planned. The regulatory context varies by market, from FDA rules and the EU Medical Device Regulation 2017/745 to MHRA, TGA and PMDA requirements, while WHO guidance frames the shared principles; the isolation record should reflect the market and the deployment.

Inventory Before Architecture

Inventory comes first because segmentation without knowing what is on the network produces rules that block clinical traffic or leave the device exposed. The inventory should identify the device, its operating system, its owner, its network connections and its clinical criticality.

Each device should have a record of its IP address, MAC address, open ports, protocols, connected systems and remote-support features. The record should also identify the data the device stores or transmits and the users who need access.

An inventory that lists only the device model is not enough. Two units of the same model can have different software, different network configurations and different clinical roles. The inventory should be at the unit level, not the product level. The inventory should be reconciled with the network\’s own discovery data. A device that is not in the inventory but is visible on the network is a gap, and it may be the one that matters. The reconciliation should happen before the segmentation rules are designed. The inventory should also record the device\’s end-of-support date and the manufacturer\’s recommended compensating controls.

Segmentation Options Compared

Segmentation options range from physical separation to logical controls on a shared network. The choice depends on the device, the clinical workflow, the network architecture and the risk appetite. Physical isolation is the strongest option, but it is rarely practical for a device that needs to send images or results. The choice should be driven by the data flow, not by the label on the network diagram.

Virtual LANs and Firewalls in Practice

A VLAN separates broadcast domains, but it does not secure the device if the network routes between VLANs without restriction. The firewall or access control list is what turns the segment into a boundary.

The rules should follow a default-deny approach: allow only the traffic the device needs, from the systems that need it, on the ports and protocols the manufacturer documents. A broad \”allow all\” rule between the clinical VLAN and the device VLAN is a label, not a control.

The rules should be tested after they are applied. A clinical workflow that stops working is a sign that the rule set is wrong, and a device that remains reachable from the general network is a sign that the segmentation is incomplete.

Remote Access and Vendor Connections

Remote access is often the weakest part of an isolation design. A vendor connection that bypasses the segmentation can reopen the exposure the organization just closed.

Vendor access should be time-limited, authenticated, logged and routed through a controlled jump host or gateway. The organization should know who is connecting, from where, to which device and for what purpose. A shared vendor account with a permanent VPN is not a controlled connection. Vendor access should be requested per session, not granted permanently. The vendor should explain what it needs to do, and the organization should approve the specific connection. A standing VPN account is a permanent exposure.

The device\’s own remote-support features should be reviewed as well. A modem, a cloud service or an always-on support tunnel may be enabled by default. The organization should confirm whether it can be disabled and, if not, whether the vendor supports the resulting configuration.

Monitoring What You Cannot Patch

If the device cannot be patched, monitoring becomes the control that detects misuse or compromise. Network flow logs, intrusion detection, authentication logs and alerts on unusual traffic can provide the visibility that the device itself cannot.

The monitoring should be tuned to the device\’s normal behavior. A legacy device that communicates with one server at a fixed interval is easier to monitor than one with broad network access. The baseline should be documented so that a change is visible.

Alerts need an owner and a response procedure. A dashboard that nobody reviews is not monitoring. The organization should define who receives the alert, what they check and when the device is isolated or taken out of service. The monitoring should include the device\’s outbound traffic as well as inbound. A device that starts contacting an unknown address may be compromised even if no one has logged in. The baseline should be updated after a software or network change.

Documenting the Compensating Control

The documentation should let an auditor, insurer or successor team understand why the control exists and how it is operated. It should describe the risk, the control, the scope, the owner and the evidence. The record should be written for someone who was not in the room. A future auditor or insurer will not know why the device was isolated or what was accepted; the document has to explain it without the original team. The control record should also state what would make the control fail: a network change, a new vendor connection, a disabled firewall rule or an expired certificate. Those failure modes are the basis for the review triggers. In practice, the record should be dated and signed by the control owner.

Review Triggers

The control should be reviewed when the device changes, the network changes or a new vulnerability is published. It should also be reviewed when the manufacturer ends support, when a vendor connection changes or when an incident occurs.

A scheduled annual review is useful, but it is not enough on its own. The triggers should be written into the control record so that the review happens when the risk changes, not only when the calendar turns.

The review should confirm that the device is still needed, that the segmentation still matches the network, that the remote access is still limited and that the replacement plan is still funded. If the control has become permanent without a plan, the risk has been normalized rather than managed. The review should also ask whether the device can be replaced or upgraded now. If the answer is yes, the isolation should end. If the answer is no, the organization should record the decision and the next review date.

The remote software upgradeability guide covers the update side, and the Knowledge section has related software and records guides. If you are planning an isolation project and want the control evidence reviewed, send the device list and network plan to the HHG team.