For hospitals · Facilities and biomedical engineering
What an OT finding means on the ward floor.
Wardhelm assesses one named facilities-OT control path — medical gas monitoring, building management and HVAC, electrical and UPS — from a SPAN / mirror feed or a capture file you provide. We never transmit on your network, never write to a device, and never sit in the packet path. You receive one signed findings report: for each observed write path, what it changes in the building, which of your existing controls covers it, and what the capture could not establish.
Facilities-OT only. Clinical devices and clinical protocols are out of scope.
Figure 1
One direction only.
Traffic comes to us. Nothing goes back. There is no return path in this drawing because there is none in the engagement.
Five lines of synthetic laboratory capture from a facilities-OT segment: three read operations and a broadcast discovery message, plus one write operation to an alarm-threshold register, which is flagged as the single finding.
Sent back to your network 0 packets Not a policy setting, not a mode we run in. There is no transmit path in the engagement to switch on.
01 · Translation
A network finding is not yet a patient-safety statement.
Security tooling reports the network fact. It stops there. The sentence your biomedical and facilities engineers need is the one on the right — and getting from the left column to the right one is engineering work on your equipment, not a scan.
Illustrative worked examples — synthetic, not findings from any engagement
| Stated as a network finding | Stated as a consequence in the building |
|---|---|
| Write-capable function codes reach the air-handling controller from a segment shared with general IT. | The pressure relationship of an isolation or protective-environment room can be changed by something outside the facilities network — and the change looks like a normal setpoint edit. |
| The medical-gas alarm gateway accepts unauthenticated reads and writes on the same port it uses for polling. | The threshold that decides whether a line-pressure alarm reaches ward staff sits on a path with no authentication in front of it. |
| The UPS and transfer-switch controllers are polled unauthenticated across a flat segment. | The equipment that governs whether a theatre or ICU rides through a transfer is addressable by anything that can reach that segment. |
Knowing a controller is vulnerable is not the same as knowing what it does. A CVE tells you a flaw exists in a product line. It does not tell you that this controller, on this floor, holds the setpoint for that room — and that is the only version of the sentence a clinical-risk conversation can actually use.
02 · Scope
System class by system class — in scope and out.
The line is drawn by system class and protocol, not case by case. Anything that is part of patient diagnosis, monitoring or treatment is outside the engagement, and stays outside it.
Scope schedule — confirmed against your estate during scoping
| System class | Protocols typically carried | In a Wardhelm assessment |
|---|---|---|
| Medical gas monitoring and alarm panels — the monitoring and alarm layer, not the delivery equipment | Modbus/TCP, Modbus RTU via serial gateway, BACnet | In scope |
| Building management, HVAC, and room pressure control | BACnet/IP, BACnet MS/TP, Modbus/TCP | In scope |
| Electrical: UPS, generator and transfer-switch monitoring, panel metering | Modbus/TCP, SNMP | In scope |
| Central plant: chillers, boilers, steam, sterilizer and laundry utilities | BACnet/IP, Modbus/TCP, vendor gateways | In scope |
| Imaging modality traffic and the imaging archive | DICOM — C-STORE, C-FIND, modality worklist | Out of scope |
| Clinical interfaces and the interface engine | HL7 v2 ADT / ORM / ORU, FHIR | Out of scope |
| Patient monitoring, infusion, ventilation, laboratory analysers, and any device regulated as a medical device | Vendor and clinical protocols | Out of scope |
Why the clinical side is excluded
Because the assessment would have nothing honest to add there, and because the moment a regulated medical device is in scope you are into validation, vendor agreements and clinical-risk process that a network capture cannot answer. We assess the facilities estate, where the control paths are ours to read and the consequence is a building state.
What “out of scope” means concretely
Clinical protocols are not decoded, not analysed and not reported on. If clinical traffic is present on a mirror you provide, it is filtered at ingest and excluded from the analysis set; the report states which filters were applied. No agent, no probe and no configuration change ever touches a clinical device, because nothing is ever placed anywhere.
03 · Operations
It runs while the hospital runs.
Nothing is installed, restarted, or cut over: the capture is a copy of traffic that is already flowing. The one exception is enabling a mirror port on your switch, which is a configuration change on your equipment and may need a change record or a window under your policy — and which you can avoid entirely by handing us a capture file your own network team takes.
- No downtime. No system is stopped, restarted, or taken out of service at any point.
- No agent, appliance, tap or software is installed on any hospital system.
- No configuration is written to a controller, a gateway, a workstation or a panel.
- Nothing is placed in the packet path, so there is no failure mode of ours that your control traffic can inherit.
- No remote access. We do not hold credentials to, or a connection into, your environment.
- Analysis happens off your network, on the copy — not on the live segment.
- A change freeze does not stop the analysis, because the analysis touches nothing that a freeze governs.
The one change request — and how to avoid even that
Enabling a mirror port on a managed switch is itself a configuration change on your equipment, and we will not pretend otherwise. If your policy requires a change record or a window for a switch configuration change, that is the only one this engagement needs. If you would rather not raise it at all, hand us a capture file taken by your own network team, on your own schedule, and the engagement proceeds with zero changes to your estate. Either route reaches the same report.
04 · Responsibilities
Your biomedical engineer red-lines the map.
The consequence map is not a document you are asked to approve. It is a draft of your own building, written by an outsider, and it will contain errors that only your staff can see. Their corrections are the point of the exercise, not an objection to it.
Biomedical / clinical engineering
Reads the draft consequence map and marks it up: this register is not that setpoint; this panel was decommissioned; this alarm already routes somewhere else. Every red line is incorporated and attributed. Where a correction changes a finding, the finding changes.
Facilities engineering
Owns the plant behind the control paths — the air handling, the medical gas monitoring, the electrical distribution. Names which control path matters most, and confirms what the physical worst case actually is for the equipment as it is installed here.
Network / infrastructure
Decides the capture route: configure a mirror on the relevant switch, or produce a capture file directly. Confirms the segment boundaries so the conduit is a named path between two agreed endpoints, not a vague area of the network.
Security / CISO
Receives the signed findings report and the statement of what could not be established. Nothing in the engagement asks for a security exception, a firewall rule, or an inbound connection, because nothing needs one.
Accountability
The person on the scoping call writes the report.
Wardhelm assessments are founder-led. There is no delivery team behind the sales conversation, no analyst pool, and no subcontractor. The founding engineer scopes the work, does the analysis and signs the findings — and is the person your biomedical engineer argues with about register 40122.
05 · Limits
What a passive capture cannot establish.
A capture is a record of what crossed one point on the network during one window. Treating it as a complete picture of the estate is the mistake this section exists to prevent — so every statement in the report carries the grounds it rests on.
Every finding is labelled by how it is known
- Known — observed directly in the capture, with the packet reference to show it.
- Inferred — reasoned from what was observed plus documented device behaviour, and marked as reasoning rather than observation.
- Asserted — told to us by your staff or taken from your documentation, attributed to its source, not independently checked.
- Unknown — not determinable from this capture. Named explicitly rather than left as an absence a reader might mistake for coverage.
Named blind spots
- A mirror at one point does not see a serial leg, a direct RS-485 run, or a link that never crosses that switch.
- A vendor's dial-in, cellular gateway or maintenance laptop that was not connected during the window does not appear in the capture at all.
- A device that was silent throughout the window is not documented as safe. It is documented as unobserved.
- Configuration state that is never transmitted — a controller's stored logic, its local settings — is not visible to a network capture at any length.
- A longer window sees more. It does not see everything, and the report will not claim a percentage of coverage it cannot substantiate.
The report states these limits in its own body, next to the findings they bound — not in a disclaimer at the back.
Start with one control path.
Pick the facilities-OT path you would least like to be wrong about — medical gas monitoring, the air handling behind your isolation rooms, the electrical transfer that carries your theatres. One named path between two agreed endpoints, assessed passively, written up once and signed. Fixed price, agreed after scope confirmation.
The scoping call establishes the endpoints, the capture route, and what is excluded. Nothing is priced before that conversation, and nothing is captured before it is agreed in writing.