How should security teams govern unagentable devices in OT and healthcare environments?

What unagentable means in OT and healthcare

Unagentable devices are endpoints that cannot realistically run a host agent for inventory, policy enforcement or telemetry. In OT, that often includes controllers, legacy HMIs and embedded appliances. In healthcare, it commonly includes medical devices and other regulated endpoints where the vendor stack or certification constraints limit change. The right governance model starts by accepting that these assets must be controlled from the network and the platform around them, not from inside the device.

That shift matters because these devices still create identity, access and segmentation decisions even when they cannot be instrumented locally. Security teams need a dependable record of what exists, where it lives, what it can talk to and which business function depends on it. In practice, OT asset visibility and device classification become the substitute for endpoint agents, while medical device security decisions have to account for safety, downtime and regulated change windows.

Governance also needs to distinguish the device itself from the access paths around it. In both OT and healthcare, unagentable assets are often managed through jump hosts, remote service channels, shared stations or vendor maintenance paths. The control problem is therefore less about installing software and more about constraining who can reach the device, from where, under what conditions and with what monitoring. That is why OT and ICS Identity and Access controls and healthcare identity security practices are relevant even when the endpoint itself remains uninstrumented.

How to build authoritative device truth without an agent

The first operational task is to create a trusted inventory from network and infrastructure telemetry. Passive discovery, protocol-aware classification and change detection give teams a better starting point than spreadsheets or CMDB entries that drift over time. The goal is to know which device is present, which subnet or zone it occupies, what protocol behavior it exhibits and whether its observed role matches the business record.

For OT environments, authoritative device truth is strongest when passive monitoring is paired with segmentation-aware mapping and periodic reconciliation against engineering records. For healthcare, the same approach helps distinguish a bedside device, a clinical workstation, a vendor-managed appliance or a networked imaging platform. OT security guidance and IoT security guidance both reinforce the need for passive discovery, segmentation and device identity before policy can be enforced with confidence.

Once the inventory is stable, security teams should classify devices by criticality, safety impact, owner, support status and allowed communications. That classification becomes the control plane for access decisions. A device that cannot be patched or instrumented may still be governable if it is placed in the right zone, allowed to speak only to known services and kept under continuous observation for unusual flows or configuration drift. The governance model is therefore lifecycle driven, not agent driven.

Which controls should enforce least privilege for unagentable devices

Least privilege for unagentable devices is enforced at the infrastructure layer. That usually means segmentation, tightly scoped allowlists, protocol-aware filtering, controlled administrative paths and strong separation between user networks, clinical networks, production control networks and vendor access paths. The objective is to reduce the device’s reachable surface area even when the device itself cannot inspect or restrict sessions.

In OT, this often means zones and conduits, industrial DMZ design, one-way paths where appropriate and strict control of engineering workstations and remote maintenance routes. In healthcare, the equivalent pattern is to separate medical device segments from general enterprise traffic and to avoid broad trust between clinical networks and third-party support channels. Edge device security is also relevant where the unagentable asset behaves like a network appliance that must be governed through its interfaces, logs and exposure profile rather than through host-based controls.

Policy should also define what “normal” means for each device class. A CT scanner, a PLC, a building management controller and a legacy infusion pump do not deserve the same communication model, even if they all lack agents. Security teams should therefore govern by device class and permitted workflow, not by a single enterprise default. That is the practical bridge between inventory data and enforceable access control.

Risk and Threat Considerations

Unagentable devices create blind spots if teams assume host-based tooling is the only way to manage them. The main risk is not just incomplete inventory, it is unbounded trust around devices that may be operationally critical, long-lived and difficult to patch. Attackers often target exactly those conditions because they can preserve access through weak segmentation, exposed management paths or vendor maintenance channels.

Failure mechanism: A device that cannot run an agent can still be reachable, misclassified or over-trusted, which lets unauthorised traffic, lateral movement or unsafe remote administration bypass normal controls. If the supporting network architecture is weak, the device becomes a durable foothold or a path to higher-value systems.

Impact: The result can be production disruption, unsafe device states, loss of visibility, or compromise of adjacent systems that rely on the same trust boundary. In healthcare, that can also create clinical downtime and operational risk; in OT, it can affect availability, process integrity and safety.

Practitioner Guidance

What to prioritise: Start with a device-class governance model, not a tooling project. Build the inventory, ownership and segmentation rules first, then decide where remote access, vendor support and exception handling are allowed. If you cannot describe a device’s approved network behaviour, you cannot safely govern it.

What to verify: Confirm that every unagentable device has an owner, a class, an allowed-communications profile and a documented failure path. Verify that passive telemetry actually sees the traffic you depend on, and that segmentation rules are enforced where the traffic crosses trust boundaries. If the record and the observed traffic disagree, treat the record as untrusted until reconciled.

Practitioner takeaway: The right control objective is not endpoint instrumentation, it is authoritative visibility plus network-enforced restraint. If teams can answer what the device is, where it is, and who may talk to it, they can govern it even when no agent is possible.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities in cloud environments?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?