Compensating controls for unpatchable devices in OT and IoMT

At a glance

What this is: This is an analyst guide to securing OT, IoMT, and end-of-life systems that cannot safely be patched, with compensating controls as the main response.

Why it matters: It matters because identity-based segmentation, brokered access, and audit-ready control documentation change how IAM-adjacent governance is applied to devices that behave like persistent non-human assets.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Elisity's guide to compensating controls for unpatchable OT and IoMT devices

Context

Devices that cannot be patched create a security governance problem rather than a simple remediation backlog. In OT, healthcare, and other long-life environments, the asset stays in service while the software flaw stays open, so access control, containment, and evidence become the meaningful control points. This article is really about compensating control design for unpatchable systems, not about patch management.

The identity angle is real because these devices behave like persistent non-human assets with fixed roles, limited trust boundaries, and remote access pathways that must be controlled. That makes segmentation, privilege restriction, and session brokering the functional equivalent of lifecycle governance for machines that cannot be brought into a normal remediation cycle.

The starting position described here is common in mature industrial and clinical environments. The constraint is usually uptime, validation, and vendor support, not a lack of awareness about risk.

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 legacy devices require identity-based segmentation instead of subnet-based rules?

A: Subnet-based rules are too coarse for devices whose legitimate communication pattern is narrow and stable. Identity-based segmentation lets teams tie access to the device’s function and lifecycle, which is the only practical way to reduce exposure without changing the asset. That matters most for unpatchable systems that must remain operational for years.

Q: How do security teams know if compensating controls are actually working?

A: They should test whether segmentation, privilege reduction, and monitoring can stop movement before the vulnerable path reaches critical assets. A control is working when an assumed exploit can be contained without broad access, not when the patch finally lands. Tabletop exercises and red-team validation should prove that containment happens inside the exposure window.

Q: Who is accountable when an unpatchable asset causes a security incident?

A: Accountability sits with the system owner, the operational team, and the security function that approved the compensating control. If the environment is regulated, the question also becomes whether the control was documented, reviewed, and demonstrably enforced. A dated, auditable control is easier to defend than an undocumented exception.

Technical breakdown

Why unpatchable devices need compensating controls

An unpatchable device is one whose software flaw cannot be closed on a normal schedule, either because the asset cannot be taken offline or because no vendor fix exists. In OT and medical environments, the operational requirement is to keep the device live while reducing what an attacker can do if they reach it. That means the security model shifts from remediation to containment. Identity-based segmentation, allow-listing, and remote session brokering do the work patching cannot. The core design principle is to limit reachable paths, not to pretend the asset has become easier to maintain.

Practical implication: Treat each unpatchable asset as a containment problem and enforce policy on the network layer rather than waiting for a maintenance window.

Identity-based segmentation for legacy OT and IoMT systems

Identity-based segmentation ties policy to device identity and function, not to the subnet or the IP address. That matters for controllers, imaging consoles, and end-of-life Windows hosts because their network location may change, but their legitimate destinations usually do not. The point is to define the flows the device actually needs, then deny everything else. This is not a patch substitute and it does not eliminate insider abuse or authorized-path misuse. It does, however, sharply narrow lateral movement options when the vulnerable device remains online for years.

Practical implication: Build allow-lists around workflow requirements and remove unnecessary east-west access before the device is exposed to a flat network.

Brokered remote access and segment-level monitoring

Unpatchable assets usually cannot host an agent, and they often produce little useful telemetry. That pushes the control plane outside the device. Brokered remote access time-boxes and records sessions so privileged interaction becomes reviewable. Segment-level monitoring then captures flow data, first-seen connections, and protocol use around the asset. Together, these controls create visibility where the device itself cannot. For OT and IoMT, that visibility is the difference between knowing a session occurred and being able to prove what was allowed, when, and by whom.

Practical implication: Require every remote session into an unpatchable asset to pass through a broker and ensure the segment produces audit-ready flow records.

Threat narrative

Attacker objective: The attacker wants to turn a long-lived, hard-to-patch device into a durable foothold for lateral movement, disruption, or data access.

1. Entry occurs when an attacker reaches an exposed legacy device, often through default credentials, weak remote access, or an over-permissive network path.
2. Escalation follows when the device can talk to more of the environment than its function requires, allowing the attacker to pivot through trusted protocols or adjacent systems.
3. Impact appears as lateral movement, unauthorized process access, or outage conditions that are hard to attribute because the asset itself produces limited telemetry.

NHI Mgmt Group analysis

Compensating control governance is now the real security model for unpatchable systems. The article correctly treats patching as an availability constraint, not a policy failure. For OT, IoMT, and end-of-life Windows estates, the question becomes what can be contained, brokered, and evidenced when remediation is structurally delayed. The practitioner conclusion is that governance must track control duration, not patch intent.

Identity-based segmentation is the closest analogue to lifecycle control for devices that cannot be modernised. These assets behave like persistent non-human endpoints with fixed functions and limited trust boundaries, so the control surface is access and flow, not software state. That aligns with the logic behind NIST SP 800-207 Zero Trust Architecture and the kind of non-human governance captured in the Ultimate Guide to NHIs. The practitioner conclusion is to manage reachable privilege, not device optimism.

Auditability matters because unpatchable assets create a control proof problem as much as a security problem. The post’s emphasis on documenting and dating compensating controls is the right one, because a control that cannot be evidenced is hard to defend in regulated environments. In practice, this is where NIST SP 800-53 Rev 5 security and privacy controls become relevant, especially around access control, monitoring, and configuration management. The practitioner conclusion is to make the compensating control part of the governance record.

Legacy device sprawl: the longer an asset stays in service, the more its security depends on network enforcement and session governance rather than patch cycles. That is the named concept this article surfaces most clearly. It explains why OT, healthcare, and industrial environments need a durable containment architecture, not a backlog of deferred fixes. The practitioner conclusion is to classify long-life devices as governed exposure, not temporary exceptions.

Brokered access is the control that turns a risky exception into a reviewable process. When an engineer must reach an unpatchable asset, the session itself should become the governed object. That shifts practice toward least privilege, short duration, and forensic recordkeeping. The practitioner conclusion is to treat privileged access into legacy environments as a managed workflow, not a direct connection.

What this signals

Legacy device sprawl will keep pushing security teams toward compensating controls as a permanent operating model. The immediate programme implication is that industrial, clinical, and facilities teams need a repeatable containment standard for systems that cannot be patched or replatformed on normal cycles. The relevant policy question is not whether remediation is desirable, but how exposure is bounded while the asset remains in service.

Identity governance is expanding into machine-containment governance. When a device cannot host an agent or tolerate downtime, enforcement has to move to the network and the access broker. That makes least privilege, session control, and change evidence part of the same control chain, with NIST SP 800-207 Zero Trust Architecture providing the clearest external reference point.

Compensating controls need lifecycle discipline, not one-time approval. A dated exception without ownership becomes an invisible risk register item, especially when the asset survives multiple refresh cycles. Teams should track review dates, control drift, and allowed destinations as operational metrics, not as paperwork.

For practitioners

• Inventory by device class and patch status Build a register of PLCs, imaging modalities, HMI panels, and end-of-life Windows hosts, then tag each asset by whether a patch exists, whether it can be applied, and whether it has any supported path to remediation.
• Segment unpatchable assets by function Place each legacy system in an identity-based segment that follows the device, define the minimum required flows, and deny all other east-west and inbound paths by default.
• Broker and record every remote session Force privileged access to flow through a broker, time-box the session, log the operator identity and destination, and retain the recording alongside the change record.
• Remove default credentials and internet exposure Eliminate boundary-device defaults, block direct internet access from unsupported hosts, and only permit outbound connections to named vendor endpoints that are operationally required.
• Document compensating control expiry dates Assign each control a review date and owner so auditors can verify that the containment measure is current, tested, and still aligned to the system’s operational reality.

Key takeaways

• Unpatchable OT, IoMT, and end-of-life systems are a containment problem, not a patching problem.
• Identity-based segmentation, brokered access, and documented control dates are the controls that materially reduce risk when firmware cannot be changed.
• The strongest governance model treats legacy devices as long-lived non-human assets whose access must be constrained, observed, and periodically revalidated.

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 Segmentation: The practice of separating identities by workload, environment, and risk so one credential cannot easily move across unrelated systems. For machine identities, segmentation is a blast-radius control as much as a least-privilege measure, because shared dependencies can turn a single compromise into a wider operational event.
• 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.

What's in the full article

Elisity's full post covers the operational detail this post intentionally leaves for the source:

• Device-by-device control ordering for OT, IoMT, and end-of-life systems, including where each compensating control fits in the sequence.
• Protocol-specific allow-list guidance for Modbus, DNP3, EtherNet/IP, and BACnet in constrained environments.
• Implementation detail on brokered remote access, segment instrumentation, and audit evidence for exceptions.
• The article's practical distinctions between systems that can be patched later and systems that need a permanent compensating posture.

👉 Elisity's full post covers the control sequence, segmentation detail, and audit considerations for legacy systems.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is designed for practitioners who need to connect identity controls to broader security operations and governance.