Notifications
Clear all
Topic starter
30/07/2026 11:21 pm
TL;DR: Devices that cannot be patched need compensating controls, not exceptions: inventory by device class and patch status, rank by exposure, segment by identity, broker remote access, and document the control date, according to Elisity. The governance problem is not patch failure but service-life reality, where containment and proof become the only durable security model.
NHIMG editorial — based on content published by Elisity: How to Secure Devices That Cannot Be Patched: 10 Compensating Controls for OT, IoMT and End-of-Life Systems
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Elisity's guide to compensating controls for unpatchable OT and IoMT devices →
Unpatchable OT and IoMT devices: what controls actually work?
Explore further
30/07/2026 11:23 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Compensating controls for unpatchable devices in OT and IoMT
