We spent three years embedded inside NHS hospitals trying to understand why connected medical devices fail in ways that are hard to pin down.
What we learned was uncomfortable, then clarifying.
When something fails inside a hospital, a CT scanner whose images never reach PACS, an infusion pump that cannot pull its drug library, a patient alarm that does not arrive at the nursing station, no one in the building has the full picture of what is actually happening. Clinical engineering knows the device. IT knows the enterprise network. The cyber team knows the threat landscape. The vendor knows their own component. Each team has tools. Each team sees a fragment. None sees the system.
The result is a particular kind of failure that any operator in any complex environment will recognise. Symptoms surface; cause does not. Escalation is sequential, slow and defensive. Vendors say not us. IT says not us. The buck stops nowhere. Eventually someone agrees a probable cause. A configuration is changed. The system comes back up. No one is sure why it broke. Everyone knows it will happen again.
We saw this pattern often enough, in environments serious enough, to start asking why it keeps happening. The answer turned out to be structural.
No one sees the whole. Everyone sees a piece.
This is not a complaint about the people who run critical infrastructure. They are doing serious work under real constraints. The person who knows the equipment (the plant, reliability or clinical engineer, depending on the sector) is not the person who knows the enterprise network, and neither of them is the person who knows the threat landscape. Each is years of expertise in its own right, and the technologies and threats evolve faster than any workforce can cross-train to cover.
So the fragmentation is structural. It cannot be solved by hiring better people, by training harder or by adding more dashboards. It is a property of how connected critical infrastructure is built: many vendors, many generations of technology, cheap connected components alongside long-lived industrial equipment, each specialist domain with bounded visibility into a single layer.
Inside that fragmentation, failures live. They live at the device layer, in the gap between how a piece of equipment is documented to behave and how it actually behaves in context, with its peers, over time, after firmware drift and configuration sprawl. In practice it is mundane and physical: a device still carrying its default password, a link left unencrypted because the vendor shipped it that way, a wireless card that drops its connection whenever the equipment beside it draws current. None of it shows up as a threat or a bad packet, and all of it changes how the thing behaves. The network sees packets. The vendor sees a healthy status. The cyber team sees no known threats. The operational engineer sees that the system is broken but cannot say why in language anyone else accepts.
That gap is mostly invisible until you have the right instrument to see into it.
What we built
Plenty of good tools already watch this estate: the network, the vendor dashboards, the maintenance models, the threat feeds. Operators rely on all of them. But they work from outside the device, and none produces independent evidence of how the device itself is actually behaving. That is the gap.
Iris is a hardware diagnostic instrument that closes it. Brought to the device itself, it produces independent evidence of how that equipment is actually behaving, which no tool working from the outside can do. It looks at three things together: how the device itself behaves, how it is configured and how it communicates with everything around it. A fault can sit in any of them, so Iris looks across all three, the cross-functional view that no single team holds. When reality disagrees with a vendor dashboard or a network view, that is what gives the operator the evidence to settle it.
Nothing about that is done to an estate. It is done by an operator, in control at every step. The discipline is workshop first: reproduce and test off the live estate wherever possible. Where a fault will not surface there, Iris climbs a ladder of access one rung at a time, by operator decision, beginning with the gentlest form of observation. Interaction with live equipment is the last rung, reached only when the gentler ones have not answered the question, and never without the operator preparing the environment and explicitly authorising the step. The operator always knows exactly what Iris is doing and what risk it carries.
Why this matters now
Two forces make this urgent.
The first is regulatory. In the UK, the NIS Regulations and the NCSC's Cyber Assessment Framework already ask designated operators to demonstrate resilience rather than assert it, and the Cyber Security and Resilience Bill before Parliament widens that net, bringing data centres and large load controllers into scope. The common thread is a demand for demonstrable assurance, which the existing toolchain cannot fully produce.
The second is workforce. The OT and IT skills gap is structural and permanent. No single discipline covers the breadth required, training a specialist takes years, and headcount alone cannot close it. Tools have to, but only tools that respect what operational engineers actually own and what they cannot.
Both pressures point the same way: estates are getting more connected and more complex while the means to understand them at the device level are not keeping up. The gap between what is happening and what the existing tools see widens with every device added.
Where we actually are
What began as a brief on a hospital network turned into something much wider. Iris is a working prototype, shaped by every failure mode we met in the field.
We are starting where the pattern is sharpest and the estates are growing fastest, in grid-scale storage and data centres, with advanced manufacturing and the wider energy, utilities and transport estates following. We are looking for a small number of design partners. The relationship is collaborative, not transactional. We share what we have learned. They share their environment and their honest reactions. We work with operators, not at them, and we are explicit about what we know, what we are still testing and what we have not yet proven.