Why the network has become the last line of defence for OT, IoT and medical equipment
Somewhere on your network, there is a device running an operating system that reached end-of-support before some of your colleagues finished school. It might be an ultrasound scanner, a building management controller, a badge reader, a production-line HMI, or a laboratory analyser that cost more than a company car. You know it is a risk. You have raised it. And you have been told, politely and repeatedly, that it cannot be patched.
That answer is usually correct. The manufacturer has not certified the update. Regulatory approval covers a specific software build and re-validating it could take months. The maintenance contract becomes void if you modify the image. The device runs 24/7 in a clinical or production environment, where a reboot is a scheduling exercise rather than a simple click. Or the vendor that made it no longer exists.
So the honest starting point for anyone running an enterprise network today is this: a meaningful proportion of the devices on your network will never be patched, will never run an endpoint agent, and will not be replaced within your current planning horizon. Every security control that assumes otherwise – EDR coverage, agent-based posture checks, automated patch compliance – has a blind spot precisely where your most operationally critical equipment sits.
If the endpoint can’t defend itself, the network has to do it instead.
Why the traditional answer stopped working
The classic response was to put these devices somewhere separate. A medical VLAN. A building services VLAN. A camera VLAN. Firewall them off from everything else, and move on.
It works until it stops scaling. Three things break it:
The device count. Segmenting by category was manageable when there were a few hundred devices. Converged campuses now carry thousands, with new devices arriving continuously. They are often installed by a facilities contractor or clinical engineering team who, quite reasonably, did not file a change request with the network team.
The static ACL problem. Every exception – the service partner’s support tunnel, the monitoring server that needs to reach every subnet, the new integration with the patient record system – becomes another rule. After a few years, nobody can safely remove anything, so the rulebase only grows. The segmentation exists on paper, while the effective policy has quietly become “mostly permit”.
Physical location no longer matches policy. A VLAN is tied to where a device connects. Devices move between departments, floors and buildings. Wireless devices move constantly. Policy tied to a switch port or SSID falls apart the moment the physical estate changes, and the workaround is always to widen the VLAN.
The result is familiar: a network that is segmented in the design document but flat in practice. And flat is exactly the condition ransomware needs.
The initial foothold is rarely the unpatchable device; it is usually a phished user account. The unpatchable device is what makes the difference between an incident affecting one department and an incident affecting the whole hospital.
Three capabilities that actually change the outcome
Know what is there, continuously. Not an annual inventory spreadsheet. Use passive profiling to identify devices by how they behave on the network – DHCP fingerprints, protocol usage, traffic patterns and MAC ownership – and flag anything that appears that you did not expect.
In almost every discovery exercise, the number of connected devices exceeds the number recorded in the CMDB. The gap is where the risk lives.
The scale of that gap is consistently underestimated. In a published runZero case study, York University, a campus with 54,000 students, gained visibility of 25,000 assets – roughly two and a half times as many as they had previously been able to identify. The CISO’s explanation is worth considering: their network management tools were good at managing the network, but not at seeing the devices connected to it.
Those are two different capabilities, and most organisations have only the first.
Decide what each device is allowed to communicate with. An infusion pump needs to reach three servers. A camera needs to reach the Network Video Recorder. A door controller needs its access control server. None of them needs the internet, the file server or any of the other devices.
Baseline the actual traffic first, then write the policy based on what you observe rather than what the vendor’s documentation claims. The reference architecture is almost always more permissive than the environment actually requires.
Enforce the policy at the point of attachment. This is what makes the model work. Policy should be tied to the device’s identity and applied at the access layer – the port or access point where it connects – rather than at a firewall three hops away.
When enforcement follows the device, moving it between buildings changes nothing. Lateral movement between two devices on the same switch is blocked rather than left invisible.
How to do it without taking down the business
The reason these projects stall is fear, and the fear is legitimate: nobody wants to be the person whose segmentation policy interrupted a procedure. Sequencing solves most of it.
- Discover passively before you enforce anything. Weeks, not days. Nothing changes on the network during this phase, so there is no risk to negotiate.
- Model policy in monitor mode. Run the intended rules and log what would have been blocked. This turns an argument about risk into a review of a report and it usually surfaces two or three legitimate flows nobody documented.
- Start with a device group that is high risk and low lateral reach. Cameras and building services are ideal first candidates: the security benefit is real and the operational stakes are lower than clinical or production kit.
- Bring the device owners in early. Clinical engineering, facilities, OT engineering. They know things the network can’t tell you, that the analyser uploads to the manufacturer overnight, that a supplier dials in quarterly to calibrate. They also hold an informal veto: the first time a policy is blamed for an operational problem it gets lifted, and once lifted it rarely comes back. The policy you impose without them lasts until the first incident. The policy you agree with them survives it.
- Expand by group, with a rollback path per group. Each step should be independently reversible.
Worth agreeing on measures up front, because “we’re more secure” doesn’t survive a budget conversation. Useful ones: time to identify an unknown device on the network, percentage of access ports under dynamic policy, and the number of destinations a compromised device in each group could reach – its blast radius, and watching it fall is the clearest evidence the programme is working.
The compliance angle, briefly
If you operate as a NIS2 essential or important entity, the requirements around asset management, access control and incident detection are difficult to meet effectively without this capability. You cannot report an incident within the required timeframe if it takes days to establish what a device is, where it is connected and what systems it has communicated with.
ISO/IEC 27001 and ENISA’s technical guidance reinforce the importance of these capabilities, while the national frameworks implementing NIS2 across member states translate them into local requirements.For many organisations, this means that the network segmentation work they have been postponing for security reasons is now also becoming a compliance priority. Pragmatically, that is often what finally unlocks the budget.
Where Damovo fits
We design and operate campus networks where this model is the default rather than a retrofit — device profiling and policy enforcement built into the access layer using the platforms our customers already run, including Cisco Identity Services Engine and Extreme Networks fabric and Universal ZTNA policy, with runZero for agentless asset discovery across IT, OT and IoT. We run the discovery and monitor-mode phases as a structured engagement so you see your real device inventory and your real traffic baseline before committing to enforcement, and we can operate the policy lifecycle as a managed service where the internal team doesn’t have the capacity to own it.
If you’d like to know how many devices are actually on your network, that’s the conversation to start with.