Compensating controls for unpatchable devices in OT and IoMT

At a glance

What this is: Elisity argues that OT and IoMT assets that cannot be patched should be secured with compensating controls built around identity-based segmentation, brokered access, and auditable containment.

Why it matters: That matters because IAM and security teams must govern device reachability and remote access for assets that will remain in service long after conventional patching windows have closed.

Context

Unpatchable devices create a governance problem, not just a technical one: the control model has to work when the asset cannot be modified, cannot host software, and cannot be taken out of service for routine remediation. In OT and IoMT environments, the question shifts from closing every flaw to constraining what the device can reach and proving that constraint to auditors and operators. That is also where identity becomes central, because the enforcement point is often the network policy attached to a device identity rather than the device itself.

For OT, clinical, and embedded estates, patch exceptions are not a durable operating model. The practical challenge is to keep legacy systems, medical devices, and production controllers functional while preventing lateral movement, unauthorized remote access, and uncontrolled protocol exposure. The right control set is therefore compensating containment: classify the asset, limit its permitted flows, broker privileged access, and maintain evidence that the restriction remained in force.

Key questions

Q: What breaks when unpatchable OT or IoMT devices are left on flat networks?

A: Flat networks turn a single vulnerable device into a lateral movement path. If the asset cannot be patched, attackers only need one reachable service, one weak credential, or one trusted protocol to pivot. The control failure is not the flaw itself, but the absence of network containment around a long-lived device that cannot be remediated in place.

Q: Why do unpatchable industrial devices create higher lateral movement risk?

A: They often sit in trusted operational paths and must keep speaking to adjacent systems, historians, or vendor services. If an attacker reaches one of those devices, the authorised flows can become a bridge into broader operational or clinical networks unless segmentation narrows the path first.

Q: How do security teams decide when to use compensating controls instead of replacement?

A: Use compensating controls when replacement, revalidation, or downtime would break the business or clinical process, and the asset still needs to remain online. Replacement is still the preferred long-term option, but containment becomes the operating model when the lifecycle will outlast the remediation window.

Q: What should teams do immediately when an unpatchable device is exposed?

A: Remove unnecessary remote access first, then restrict the device to the smallest possible set of approved destinations and protocols. After that, capture evidence of the enforced policy so the control can be validated during incident review or audit.

Technical breakdown

Why unpatchable devices require containment instead of remediation

An unpatchable asset is one where the flaw is known but the fix cannot be safely applied. In OT and IoMT, that usually means a validated production or clinical system, a vendor-controlled appliance, or an end-of-life platform that cannot be modified without breaking support or uptime. The security problem is not the absence of a patch alone. It is the persistence of exposure across a long service life. Because the device cannot be turned into a normal endpoint, the control boundary has to move outward to the network, identity, and remote-access layers.

Practical implication: Treat the device as a long-lived exposure that must be contained, not as a temporary exception waiting for a patch window.

How identity-based segmentation reduces blast radius

Identity-based segmentation enforces policy around the asset instead of on the asset. That matters when a PLC, HMI, imaging modality, or embedded controller cannot run an agent and should not be reconfigured just to satisfy security tooling. The segment should allow only the protocols, destinations, and sessions required for its function, while denying generic workstation traffic and unnecessary east-west movement. This approach does not fix the vulnerability. It limits how far compromise can travel if the device is probed, abused, or reached through an exposed service.

Practical implication: Use device identity and required flows to define the segment, then block everything else by default.

Why brokered remote access and protocol allow-listing matter

Remote access is one of the highest-risk paths into unpatchable environments because it often bypasses normal user controls and lands directly on an operational asset. A brokered session forces access through a controlled path, where the session can be time-boxed, recorded, and tied to a named requester. Protocol allow-listing adds a second layer by restricting what the device may speak on the wire, such as Modbus, DNP3, EtherNet/IP, or BACnet. Together, these controls reduce both unauthorized entry and noisy lateral movement without requiring the device itself to be changed.

Practical implication: Broker every administrative session and allow-list only the industrial protocols the asset actually needs.

Threat narrative

Attacker objective: The attacker wants durable access to an operationally trusted device so they can move laterally, disrupt processes, or reach adjacent systems.

1. Entry occurs through exposed or unnecessary remote paths into an asset that cannot be patched or instrumented directly.
2. Credential or session abuse then enables access to a PLC, medical device, or end-of-life host that still accepts legitimate operational traffic.
3. Impact follows when the attacker can move through that device's allowed flows or use it as a foothold into adjacent systems and processes.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Compensating controls are now the primary security model for unpatchable assets. In OT and IoMT, the governance question is no longer whether every device can be remediated, but whether the organisation can enforce durable containment around assets that will stay in service for years. That shifts authority from patch management to control design, evidence, and exception discipline. Practitioners should treat containment as the control objective, not as a temporary workaround.

Identity-based segmentation is the named concept that matters here. It captures the reality that a device's risk is defined by what it can reach, not only by whether it is vulnerable. This is especially relevant where service life outlasts patch cycles and where the device itself cannot host modern security controls. The practitioner takeaway is to govern reachability as a first-class asset attribute, not a network afterthought.

Unpatchable is not one problem but two governance states. Some devices are patchable in theory but not in practice because downtime, validation, or support constraints block remediation, while others will never receive a fix again. Those are materially different risk conditions and they require different evidence, funding, and review cycles. Teams should document which assets are temporary compensating-control cases and which are permanent containment cases.

Operational security for OT and IoMT must be auditable, not just enforced. A control that cannot be proven has little value in environments where device change is slow and external scrutiny is high. Recording brokered access, documenting control dates, and retaining flow evidence turns containment into a governance artifact, not just a network rule. Practitioners should expect auditors to ask how they know the control still exists and still fits the asset's lifecycle.

OT and medical estates expose the limits of patch-centric thinking. The article's central lesson is that security programmes fail when they assume the device can be made normal before they secure it. In reality, the security boundary has to move to the places where identity, access, and protocol enforcement can still be controlled. The practical conclusion is to build for constrained trust, not perfect remediation.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity-based segmentation is becoming the practical control boundary for OT and IoMT estates, because the devices themselves often cannot be modified safely. Teams should expect governance to move from patch completion metrics toward enforced reachability, recorded remote access, and lifecycle evidence for every exception.

The service-life problem will keep outlasting patch cycles in environments that run PLCs, medical devices, and end-of-life hosts. That means the programme question is not whether a device has a vulnerability, but whether the organisation can continuously prove what it is allowed to reach and who may touch it.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. In estates that rely on brokered access and device-scoped policy, weak inventory visibility turns compensating controls into guesswork rather than governance.

For practitioners

• Inventory by device class and patch status Classify PLCs, imaging systems, medical devices, and end-of-life hosts by function, firmware state, and whether a patch path exists, then maintain that inventory as the basis for control placement.
• Assign each asset to an identity-based segment Create segments around the destinations and protocols the device actually requires, and deny generic east-west access, user VLAN access, and unnecessary internet reachability.
• Broker and record administrative sessions Force remote maintenance through a controlled jump path, time-box the session, record the activity, and retain the record long enough to support incident review and audit proof.
• Allow-list only required industrial protocols Restrict traffic to the specific protocol set the device uses, such as Modbus, DNP3, EtherNet/IP, or BACnet, and block everything else at the enforcement point.
• Document compensating controls with control dates Attach an owner, start date, review date, and replacement assumption to every control so the exception does not become an undocumented permanent state.

Key takeaways

• Unpatchable OT and IoMT devices should be governed as persistent exposure zones, not treated as temporary exceptions waiting for a maintenance window.
• The article's central control pattern is containment through identity-based segmentation, protocol allow-listing, and brokered access backed by audit evidence.
• The strongest programmes will prove control dates, session records, and permitted flows, because that is what makes compensating controls defensible over time.

Key terms

• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
• Identity-Driven Segmentation: Identity-driven segmentation is a control model that allows or denies communication based on verified identity rather than only on subnet, firewall, or VLAN placement. It is especially useful in operational environments where topology changes frequently and network paths no longer describe trust accurately.
• Brokered Access: Brokered access is a model where the user or workload proves identity to an intermediate control plane that issues short-lived access instead of exposing a reusable secret. For privileged operations, this shifts governance from secret storage to session control, auditability, and timely revocation.
• Unpatchable Asset: An unpatchable asset is a system that cannot safely receive a fix because downtime, validation requirements, vendor restrictions, or product end-of-life prevent normal remediation. Security teams must treat it as a standing exposure and govern it through containment and evidence.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is a practical fit for practitioners who need to connect identity controls to operational security outcomes.