How to Secure Devices That Cannot Be Patched: 10 Compensating Controls for OT, IoMT and End-of-Life Systems

Key takeaways: ten controls for devices that cannot be patched

Controls 1 through 3 are prerequisites. Controls 4 through 8 are the containment layer. Controls 9 and 10 close the gap between what you enforced and what an auditor will ask you to prove.

Why patches don’t get applied: the constraint is downtime, not negligence

Ask a controls engineer why a PLC is three firmware versions behind and the answer is almost never that nobody noticed. The patch exists. The maintenance window doesn’t. A firmware update on a device that runs a filling line, a chiller plant, or a linear accelerator means a validated change, a vendor sign-off, and a production stop that somebody has to authorize.

The survey evidence says the same thing. In TuxCare’s Open Source Landscape Report 2026, the factor cited most often as causing major delays in the Linux vulnerability patching process was the inability to take critical systems down (J.P. Morgan, p.15, reproducing TuxCare). That survey measures Linux and open-source estates, not OT, and it should be read as such. The constraint it names is the one your plant and clinical engineering teams already live with.

TuxCare also puts 61% of reported incidents as associated with unapplied but available patches (J.P. Morgan, p.18, citing TuxCare). Read that number carefully. It doesn’t say the patch was unavailable. It says the patch was sitting there and the window never opened.

You aren’t managing a discipline problem. You’re managing a scheduling constraint that no amount of patch-management tooling removes.

How much of your estate can actually take a patch? The J.P. Morgan benchmark

J.P. Morgan Research estimated in April that only 55%-65% of industrial network hardware may be able to be patched (Patchmageddon, J.P. Morgan Asset Management, 22 July 2026, p.19). Keep the hedge. That sentence carries its own footnote, to “In the garden of good and evil,” J.P. Morgan Industry & Policy Thematics, 29 April 2026. It is a modelled estimate, not a measured survey of installed devices, and it should be reported as a well-sourced estimate rather than as a count.

The full table breaks the estate into four layers.

Source: “Industrial networks at cost as a percentage of non-patchable”, J.P. Morgan, Patchmageddon, p.19. J.P. Morgan cites company filings (Siemens, Schneider, Rockwell, ABB, Honeywell), IDC, Grandview, NIST, World Bank, BEA, and engineering BOM data, 2026.

Two things about this table. It is labelled at cost, not by device count, so it describes where the money sits rather than how many endpoints are involved. And the three columns are independently estimated ranges, not a partition. They do not sum to 100 in either direction, so don’t subtract one from another to derive a complement.

The devices behind the operational technology row are named. J.P. Morgan lists programmable logic controllers, distributed control systems, supervisory control and data systems, microcontrollers, computer numeric control machines, system drives, and control boards (p.19).

The other J.P. Morgan number worth your attention is the one about time in service. Cloud-based systems are replaced every 4 to 5 years, while operational infrastructure that manages physical processes often remains in service for 10 to 18 years (p.19). That’s the point most patch-centric programs miss. A device commissioned in 2014 is still running the line, and it will still be running the line in 2030.

Unpatchable is two different problems: a patch exists but cannot be applied, or no patch will ever exist

J.P. Morgan’s table splits non-patchable hardware into two separate columns, “Unpatchable” (12-20%) and “No patch” (20-30%). Neither column is defined anywhere in the report’s prose: “No patch” appears only as that column header, and “unpatchable” appears only in its own column header, the section heading above the table, and the table of contents. In our reading of that data, the split maps to two operationally different problems, and we own these definitions rather than attributing them to J.P. Morgan.

Unpatchable: a patch exists, but you can’t apply it. The vendor shipped firmware. Applying it requires revalidation, a vendor engineer on site, or a production stop nobody will approve this quarter. The fix is real and out of reach. Examples: a validated infusion pump, a DCS controller inside a safety-instrumented function, a CNC machine under a vendor maintenance contract that voids on unauthorized changes.

No patch available: the fix will never exist. The vendor is gone, the product line is discontinued, or the flaw is in silicon and firmware that no longer has an owner. Examples: an unsupported Windows workstation driving a 2011 imaging modality, a serial-to-Ethernet gateway from a defunct manufacturer, a building controller whose OEM was acquired twice.

The distinction matters because it changes what you commit to. For the first, your compensating control is a bridge with an end date. For the second, the compensating control is the permanent security posture for that asset, and it should be funded, reviewed, and audited as one.

Why legacy systems are a segmentation problem, not a patching backlog

Microsegmentation for legacy systems works because enforcement happens on the network rather than on the asset. The assets generating this backlog are the ones least able to absorb a fix: a CNC machine or a sealed HMI has nowhere to put an agent, and re-addressing it means touching a validated configuration. An identity-based policy on the switching they already connect to limits what each one can reach, without touching the device or its firmware.

A backlog is something you work down. A 15-year service life is something you design around. If your remediation plan for legacy systems is a queue of outstanding patches, the queue never empties, because the assets generating it will still be in production after three replacement cycles of everything else you own.

Microsegmentation for legacy systems answers a different question than patching does. Patching asks whether the flaw is closed. Segmentation asks what the device is permitted to reach if the flaw stays open. An HMI that talks to four PLCs and one historian doesn’t need reachability to the domain controller, the file share, or the other 900 hosts on its VLAN, and removing that reachability doesn’t require the device to change at all.

Replacement is still a legitimate path, and J.P. Morgan says so directly. On p.25 the report recommends targeted “rip-and-replace” incentives where obsolete systems create national-level risk, described as a “cash for clunkers” program for infrastructure, alongside federal financing and expanded CISA technical assistance. Segmentation isn’t an argument against replacing legacy equipment. It’s the control that governs the asset between now and the day the capital project lands, and for the “No patch” population, after it.

How we selected these ten controls

We selected these ten controls by starting from the constraint rather than the product. Anything requiring firmware changes, endpoint software, or a maintenance window was excluded, however good it is in an IT estate.

Each control also had to map to a named clause in a published standard, not just to a standard’s name. You’ll find the specific clause under the “What standard this satisfies” heading in every control, and the consolidated mapping to NIST SP 800-82r3, NIST SP 800-207, IEC 62443, NCSC obsolete-product guidance, FDA 524B, and the CISA Cross-Sector Cybersecurity Performance Goals later on this page.

On vendor neutrality. Elisity sells identity-based microsegmentation, so some of these ten controls sit inside a category Elisity competes in and others sit well outside it. Where a control needs a tool Elisity doesn’t make, this page names the category, and the vendors in it where a short list is meaningful. The final section states which controls are an Elisity purchase and which four are not.

Control 1: Inventory by device class and patch status, not by IP address

An inventory that lists IP addresses can’t tell you which devices cannot be patched. Record every asset by device class, firmware version, vendor support status, and patch state, so the unpatchable population becomes a named list rather than a guess. J.P. Morgan’s 10-actions guidance asks for a “comprehensive continuously updated inventory of all hardware, software and cloud assets” (p.23).

The inventory bullet is one of ten actions published by J.P. Morgan’s Global Technology Leadership Team in April 2026, and it says nothing about patch state (J.P. Morgan, p.23). Adding patch state is the step that turns a general asset inventory into a working list of devices that cannot be patched. Without it, an end-of-life imaging modality and a fully supported one look identical in the record.

Which devices this applies to

Programmable logic controllers, distributed control systems, supervisory control and data acquisition systems, microcontrollers, CNC machines, system drives, and control boards. In healthcare, add infusion pumps, imaging modalities, patient monitors, and clinical workstations running unsupported Windows.

How to implement it

1. Pull the existing lists first: the CMDB, the CMMS or EAM, the clinical engineering database, and the OT historian.
2. Add passive network discovery to find assets that no system of record lists, and reconcile the two views.
3. Classify each asset by device class using the vendor’s own term, not a category like “IoT device.”
4. Record firmware or OS version alongside the vendor’s published support end date.
5. Assign every asset one of three patch states: a patch exists and can be applied, a patch exists but cannot be applied, or no patch will be issued.
6. Re-run the reconciliation monthly, and treat any change in vendor support status as an inventory event.

What standard this satisfies

CISA Cross-Sector Cybersecurity Performance Goal 1.A, Asset Inventory, which asks for a regularly updated inventory of all organizational IT and OT assets. NIST SP 800-53 Rev. 5 control CM-8, System Component Inventory, covers the same ground for federal and federally aligned programs.

Where this control fails: Passive discovery only sees assets that talk, so serial-connected devices sitting behind a protocol gateway stay invisible until someone walks the plant floor with a clipboard.

Control 2: Rank the fleet by network exposure, not by CVSS score

A CVSS 9.8 on a PLC that talks to one HMI is a smaller problem than a CVSS 7.1 on an engineering workstation that reaches every cell on the floor. Rank unpatchable assets by what they can reach and who reaches them. Exposure is the variable you control. The severity score isn’t.

The counter-argument to any severity-driven program sits inside the J.P. Morgan report. Reported vulnerabilities keep rising, “of which 1.5%-2.0% get exploited each year” (Zero Day Clock, cited in J.P. Morgan, p.5). A queue sorted by CVSS is therefore a queue sorted mostly by things that will never be used against you, and on an unpatchable asset the queue has no exit anyway. Reachability is the property that changes the outcome.

Which devices this applies to

Engineering workstations, HMIs, historians, and jump hosts first, because those reach the most. Then RTUs, PLCs, DCS controllers, building management controllers, and unsupported Windows workstations that hold domain credentials.

How to implement it

1. Map the actual east-west flows for each unpatchable asset, using span, netflow, or your enforcement point’s own telemetry.
2. Count two numbers per asset: how many distinct destinations it reaches, and how many distinct sources reach it.
3. Weight any asset that is reachable from the corporate network, from a vendor remote path, or from the internet above everything else.
4. Rank the fleet on those numbers, then apply severity only as a tiebreaker within a rank band.
5. Publish the ranked list to the OT and clinical engineering owners who control change windows, not only to the security team.

What standard this satisfies

IEC 62443-3-2, ZCR 5, which calls for a detailed cyber security risk assessment performed per zone rather than per CVE, and ZCR 4, which asks whether the initial risk exceeds tolerable risk before design decisions are made.

Where this control fails: On a flat network everything reaches everything, so exposure ranking returns a flat list until some segmentation already exists to differentiate the assets.

Control 3: Remove internet exposure and default credentials from boundary devices

Before any compensating control, take away the routes that don’t need a vulnerability at all. Find every OT asset reachable from the internet, remove or firewall that exposure, and replace default and shared credentials on firewalls, VPN concentrators, remote access gateways, and jump hosts. This applies to your whole OT estate, not only the unpatchable part.

J.P. Morgan states the problem plainly: “Internet-facing control system components, insecure remote access pathways, default credentials and poorly protected boundary devices continue to create direct routes into industrial environments” (p.19). None of those four routes requires an unpatched CVE. CISA reported in April 2026 that Iran-affiliated actors targeted internet-facing Rockwell Automation and Allen-Bradley PLCs across US water, wastewater, and energy infrastructure, reproduced in the J.P. Morgan report from a CISA advisory dated April 2026 (p.19). CISA publishes these at its cybersecurity advisories index.

Which devices this applies to

Perimeter firewalls, VPN concentrators, remote access gateways, cellular routers, protocol gateways, and jump hosts. Also any PLC, RTU, HMI, or building controller with a routable public address, and any historian or SCADA server published for vendor access.

How to implement it

1. Scan your own public IP ranges and ASN for OT protocols, including Modbus TCP 502, EtherNet/IP 44818, DNP3 20000, and BACnet 47808.
2. Cross-check the result against external attack surface data so shadow circuits and cellular gateways surface too.
3. Remove or firewall every OT protocol path that terminates on the internet.
4. Replace default, shared, and vendor-installed credentials on every boundary device, and record the date of each change.
5. Enforce MFA on every remaining remote path into the OT network.
6. Re-scan quarterly and after every firewall or ISP change.

What standard this satisfies

CISA Cross-Sector Cybersecurity Performance Goal 2.A, Changing Default Passwords, and IEC 62443-3-3 SR 1.5, Authenticator management, which requires that default authenticators be changed at installation.

Where this control fails: Some vendor support contracts depend on the exposed pathway, so removing it without a brokered replacement means the vendor stops supporting the asset you were trying to protect.

Control 4: Place unpatchable assets in identity-based segments that follow the device, not the subnet

Segmentation is the compensating control that applies when no patch is coming. Give each unpatchable asset a policy tied to its identity, class, and function, enforced wherever it plugs in, so an end-of-life device keeps the same least-privilege rules after it moves cabinets, changes VLANs, or picks up a new IP address.

Microsegmentation for legacy systems is usually described as a networking project, and that framing is what stalls it. The buyer’s question is narrower: this MRI, this PLC, this Windows 7 workstation will never take another patch, so what should it be allowed to reach on your network tomorrow? Policy bound to an IP address breaks the first time the asset moves. Policy bound to the asset’s identity survives the move, which is why identity is the anchor rather than the subnet. For the deployment-model comparison, see best NAC for industrial OT networks and top microsegmentation solutions for 2026.

Which devices this applies to

PLCs, DCS controllers, HMIs, RTUs, CNC machines, system drives, and control boards on the plant side. Infusion pumps, imaging modalities, patient monitors, and lab analyzers on the clinical side. Unsupported Windows workstations and legacy application servers on both.

How to implement it

1. Group unpatchable assets by device class and by production or clinical function, not by where they’re cabled.
2. Baseline the flows each group actually uses over a full production or clinical cycle, including monthly and quarterly jobs.
3. Write the allow-list policy from that baseline, naming the destinations and protocols the workflow requires.
4. Deploy the policy in observe mode and review every flow it would have denied with the process owner.
5. Enforce one group at a time, starting with the group carrying the highest exposure rank from Control 2.
6. Bind the policy to identity attributes so it follows the asset across switch ports, VLANs, and wireless.

What standard this satisfies

IEC 62443-3-2, ZCR 3, which requires partitioning the system under consideration into zones and conduits, and NIST SP 800-207 tenet 6, which requires that resource authentication and authorization be dynamic and strictly enforced before access is allowed.

Where this control fails: Identity-based segmentation is only as good as the classification behind it. An unpatchable asset filed under the wrong device class inherits the wrong policy, and nobody finds out until the flow it should never have had gets used.

Control 5: Broker, time-box and record every remote session into an unpatchable asset

Vendor and engineer remote access is a routine path into an unpatchable asset, and it’s often standing rather than scheduled. Route every session through a broker that authenticates the person, opens the path only for an approved window, scopes it to one asset and one protocol, and records what happened. Standing remote access into end-of-life equipment is itself the exposure.

One of the ten actions J.P. Morgan’s Global Technology Leadership Team published in April 2026 reads, verbatim, “Manage remote access and segment where possible” (J.P. Morgan, p.23). The hedge is theirs, and it’s worth keeping. It’s one bullet among ten in a list that also covers software currency, outbound filtering, and standing privileges, and it isn’t a recommendation to segment unpatchable devices specifically. What it does establish is that a bank’s own technology leadership puts remote access management and segmentation in the same sentence.

Which devices this applies to

Any asset a vendor touches remotely: PLCs and DCS controllers reached through engineering software, imaging modalities and linear accelerators under service contract, building automation controllers, industrial robots, and unsupported Windows workstations running vendor applications.

How to implement it

1. Inventory every remote path into your OT and clinical networks, including vendor VPNs, cellular gateways, dial-up modems, and installed remote-desktop tools.
2. Consolidate those paths onto a single brokered entry point and decommission the rest.
3. Require named accounts and MFA at the broker, and stop issuing shared vendor logins.
4. Time-box each session to the approved change window, with automatic termination at expiry.
5. Scope each session to one target asset and one protocol, granted at connect time rather than held standing.
6. Record the session and retain the recording for as long as your incident-response and regulatory retention policies require.

What standard this satisfies

IEC 62443-3-3 SR 1.13, Access via untrusted networks, which requires monitoring and control of all methods of access to the control system from untrusted networks, and SR 2.6, Remote session termination, which requires that a remote session be terminated after a defined period of inactivity or on request.

Where this control fails: A brokered session still runs with full engineering privileges on the target, so a compromised vendor laptop reaches the unpatchable asset through the approved path with every action recorded and none of it blocked.

Control 6: Enforce allow-list east-west policy for Modbus, DNP3, EtherNet/IP and BACnet

Write east-west policy in the protocol’s own terms. A default-deny allow-list between zones, permitting only the Modbus, DNP3, EtherNet/IP, and BACnet flows a documented process actually requires, contains an unpatchable controller without touching its firmware. Port-level rules aren’t enough. These protocols carry no authentication, so the policy has to name source, destination, and function.

Most zoning guidance stops at the zone. NIST and the NCSC both tell you to segment industrial networks; neither one names the protocols or the shape of the rule. That gap is where your policy either holds or leaks, because an attacker operating inside an allowed conduit is speaking valid Modbus, and a living-off-the-land technique in OT looks exactly like engineering traffic to a firewall watching ports.

Which devices this applies to

PLCs, RTUs, DCS controllers, HMIs, engineering workstations, protection relays, variable frequency drives and system drives, and BACnet building controllers running chillers, air handlers, and access control panels.

How to implement it

1. Baseline every east-west flow in listen-only mode across at least two full production cycles, including a scheduled changeover and a maintenance window.
2. Draw zones by process function, not by VLAN or IP range, so the policy survives a re-address.
3. Write each conduit as an allow-list per protocol: this historian to these PLCs over Modbus TCP, this engineering workstation to this DCS over EtherNet/IP, default deny for everything else east-west.
4. Restrict write-capable and program-download function codes to named engineering workstations, and time-box them to change windows.
5. Filter outbound traffic from the production zone. J.P. Morgan’s Global Technology Leadership Team lists “Aggressively filter outbound traffic from production systems” as one of its 10 actions (p.23).
6. Enforce one zone at a time, in monitor mode first, using the approach described in segmenting IT and OT without downtime.

What standard this satisfies

IEC 62443-3-3 SR 5.2 (zone boundary protection) and SR 5.4 (application partitioning), plus NIST SP 800-82r3 §5.2, Network Segmentation and Segregation.

Where this control fails: An allow-list can’t authenticate a protocol that has no authentication. If an attacker takes the historian you permitted, the policy forwards their Modbus writes to the PLC exactly as designed.

Control 7: Contain end-of-life Windows without rebuilding the network

Contain end-of-life Windows by placing the machine in its own identity-based segment that permits only the handful of destinations its application needs, then brokering whatever administrative access remains. You don’t have to re-address the network, rebuild a VLAN, or move the workstation to do it.

Extended Security Updates matter here and are worth separating out first. Microsoft’s ESU program carries Windows 10 past its October 2025 end of support for a fee, which buys a defined runway. The machines with no ESU path are the ones that need a permanent compensating control, not a delayed patch plan.

Which devices this applies to

Unsupported Windows 10 workstations, Windows 7 and Windows Server 2012 R2 application servers, Windows XP Embedded and Windows CE HMI panels, CNC controllers, lab analyzer PCs, and the imaging modality consoles that ship as a sealed appliance with a Windows build the vendor won’t let you touch.

How to implement it

1. Split the list into hosts with an ESU path and hosts without one. Treat the second group as permanent.
2. List the actual destinations each application needs: the database, the license server, the print queue, the vendor update host.
3. Assign each end-of-life host to a segment keyed to device identity rather than subnet, so its IP address and its application config stay untouched.
4. Deny inbound SMB and RDP from user VLANs and from every other workstation, then allow administrative access only through a broker.
5. Block outbound internet from unsupported hosts except to named vendor endpoints.
6. Re-run the flow baseline 30 days after enforcement and remove the destinations nobody used.

What standard this satisfies

NCSC obsolete products guidance, specifically the mitigation to segregate the obsolete product from the rest of the network, and PCI SSC FAQ 1130, which allows unsupported operating systems in scope where documented compensating controls isolate them.

Where this control fails: Segmentation doesn’t stop the user in front of the machine. An unsupported Windows workstation that opens a malicious attachment or mounts an infected USB drive is compromised on the inside of the segment you built.

Control 8: Instrument the segment, because the device cannot tell you anything

An unpatchable device won’t run an agent and often won’t produce a usable log. Instrument the segment around it instead: record every flow crossing the conduit, retain it, and alert on the first connection the policy has never seen. The segment becomes the sensor the device cannot be.

Dragos, in its 2026 Operational Technology Cybersecurity Year in Review, found that 30% of incident response cases in 2025 started not with a detected intrusion or a ransom note, but with someone observing that something seemed wrong (J.P. Morgan, p.20). In most of those cases, per Dragos, the data needed to answer whether cyber was involved had never been collected. Dragos states the constraint directly: “OT network telemetry is transient; if you are not recording it when it happens, it is gone.”

Which devices this applies to

PLCs, RTUs, protection relays, sealed HMI panels, infusion pumps, patient monitors, imaging modalities, building management controllers, and any asset whose vendor contract voids support if you install software on it.

How to implement it

1. Enable flow records at the enforcement point rather than on the device, so nothing has to be installed on the asset.
2. Attach device identity to every record: make, model, firmware version, and process role, not just an IP address.
3. Retain east-west flow data for a defined window, and set the window against your own incident response plan rather than a storage budget.
4. Alert on first-seen source and destination pairs inside a zone, which is the signal a flat network cannot produce.
5. Forward the records to the SIEM with the segment name intact so a responder can scope the blast radius without a network diagram.
6. Test the pipeline against a known event, such as a scheduled vendor maintenance session, and confirm it appears.

What standard this satisfies

IEC 62443-3-3 SR 6.2 (continuous monitoring), and the system monitoring control SI-4 in NIST SP 800-53 as applied to industrial environments by NIST SP 800-82r3.

Where this control fails: Flow telemetry records that a connection happened, not what the payload did. An attacker using an authorized path with valid protocol traffic produces a record that looks correct.

Control 9: Apply virtual patching and protocol-aware inspection where segmentation cannot reach

Virtual patching places an inspection point in front of a device that can’t take the fix and blocks the exploit traffic rather than closing the flaw. Use it where a known CVE has a published detection rule and the asset sits behind a chokepoint you control. It’s a different product category from segmentation, and it’s bought separately.

Elisity doesn’t do this, and it’s worth saying plainly. Neither do Illumio, Akamai Guardicore, or Zero Networks. Deep packet inspection and OT virtual patching belong to ICS-specialist platforms including Claroty, Nozomi Networks, Dragos, TXOne Networks, Tenable OT Security, Forescout eyeInspect, and Cisco Cyber Vision, alongside inline IPS from Palo Alto Networks and Fortinet. The category comparison is covered in leading vendors for securing OT and industrial control systems.

Which devices this applies to

Internet-facing or DMZ-adjacent PLCs and RTUs, safety instrumented systems, protocol gateways, SCADA servers, and legacy HMIs carrying a published CVE with no vendor firmware release.

How to implement it

1. Confirm the specific CVE has a signature or protocol rule from the inspection vendor before buying anything for it.
2. Place the inspection point at the conduit boundary the traffic already crosses, so the control loop gains no new hop.
3. Run detect-only through at least one full production cycle, including startup and shutdown sequences.
4. Measure false positives against normal process traffic and tune before enforcing, with process engineering signing off on added latency.
5. Record each virtual patch against the CVE and the asset, with a review date tied to the vendor’s firmware roadmap.

What standard this satisfies

IEC 62443-3-3 SR 3.2, malicious code protection, applied as a compensating countermeasure at the zone boundary, together with SR 5.2, zone boundary protection, for the inspection point itself.

Where this control fails: A virtual patch needs a vulnerability someone has already published and written a rule for. It does nothing for a flaw that hasn’t been disclosed, and inline inspection is not an option on every deterministic control loop.

Control 10: Document and date the compensating control so it survives an audit

Write the compensating control down as a dated record: the asset, the vulnerability it compensates for, the control applied, the person who accepted the residual risk, and the date the decision expires. A compensating control with no expiry date becomes a permanent exception by accident, and your auditor will find it before you do.

Controls 1 through 9 are technical. Control 10 is administrative, and it decides whether the other nine count for anything in front of an assessor, an insurer, or a regulator.

Which devices this applies to

Every asset where the honest answer to “when does this get patched” is “it doesn’t”: end-of-life Windows workstations, PLCs and DCS controllers past vendor support, imaging modalities under a frozen validation, building controllers, and CNC machines older than the security program.

How to implement it

1. Record one row per asset with make, model, firmware, the CVE or unsupported OS, the control applied, and the named owner.
2. Name the individual who accepted the residual risk, at a level with budget authority over replacement.
3. Set an expiry date rather than a review flag. Twelve months or the next process shutdown, whichever comes first.
4. Attach the evidence a third party will ask for: the policy export, the flow records, the brokered session logs.
5. Re-underwrite at expiry and record whether the asset is still in service, which is the moment a rip-and-replace case either gets made or gets dropped.
6. Report the count of expired compensating controls still in force to the risk committee, as its own line.

What standard this satisfies

PCI DSS v4.0 Appendix B, which requires each compensating control be documented, validated, and reviewed at least annually, and NIST SP 800-53 CA-5 (plan of action and milestones).

Where this control fails: Documentation doesn’t reduce risk by itself. A well-written compensating control worksheet describing a policy nobody has tested since the day it was written is a paper answer to a live exposure.

How the ten controls map to NIST SP 800-82r3, NIST SP 800-207, IEC 62443, NCSC obsolete-product guidance, FDA 524B and CISA CPGs

J.P. Morgan states the principle plainly: “The critical controls laid out by organizations like the National Institute of Standards and Technology and the UK’s National Cyber Security Centre are now all the more important since they improve security without depending on any single patch landing in time” (J.P. Morgan, p.23). Read the next sentence before you quote that one. The three examples J.P. Morgan gives are hardening network default configurations, enforcing multi-factor authentication, and keeping comprehensive logs. Segmentation is not among those three examples. The report’s own ten-action list does include “Manage remote access and segment where possible,” hedge intact, but that is one bullet among ten rather than a NIST or NCSC critical control.

The mapping below is Elisity’s, built against the published clause text of each framework, and should not be cited as J.P. Morgan’s. CISA goal numbering follows the Cross-Sector Cybersecurity Performance Goals Checklist v1.0.1 (March 2023), which remains the current published checklist. CISA released CPG 2.0 in December 2025, adding a GOVERN function and renumbering every goal; the crosswalk is below the table. For framework-by-framework compliance depth, see Microsegmentation Compliance Requirements: A Six-Framework Guide.

CPG 2.0 crosswalk (CISA, December 2025, report p.9): 1.A Asset Inventory becomes 2.A Manage Organizational Assets; 1.E Mitigating Known Vulnerabilities becomes 2.B Mitigate Known Vulnerabilities; 2.A Changing Default Passwords becomes 3.A Change Default Passwords; 2.F Network Segmentation becomes 3.I Implement Logical/Physical Network Segmentation; 2.H becomes 3.F Implement Multifactor Authentication (MFA), dropping the phishing-resistant qualifier; 2.O Document Device Configurations becomes 3.N Establish Change Management Processes, a retitling that shifts the goal from documentation to change control; 2.P Document Network Topology becomes 2.E; 2.T Log Collection and 2.U Secure Log Storage merge into 3.Q Maintain Log Collection & Storage; 2.W and 2.X merge into 3.S Secure Internet-Facing Devices; and 3.A Detecting Relevant Threats and TTPs is deleted in 2.0, consolidated under 4.B Identify Adverse Events.

A clause reference is not an audit result. An assessor will ask you for the written policy, the traffic evidence that the policy is enforced, and the date it was last reviewed, which is the entire job of Control 10.

What this looks like in a live deployment

Two Elisity healthcare deployments are published in enough detail to be useful here, and neither one patched a device.

Main Line Health runs identity-based microsegmentation across an estate Elisity’s published case study describes as 5 hospitals, 6 health centers, and more than 40 offices. Elisity’s published figures put the deployment at three days and the protected estate at more than 100,000 IoT, OT and IoMT devices under 6,000+ actively enforced policies, with blocking rules created and implemented the day after the first site went live. St. Luke’s University Health Network runs the same enforcement model across 15 hospitals, 350 physician group practices, and roughly 85,000 production devices, on existing switching, with no agents installed and no new hardware purchased. Major segmentation buckets were completed in about 46 days.

On containment speed, Elisity’s published healthcare figure is a reduction in mean time to contain from 4-6 hours to under 10 minutes. That is a vendor-reported outcome built on customer-reported baselines, and it should be read as one.

None of that says a single PLC, infusion pump, or unsupported Windows workstation was patched. The devices are the same devices. What changed is the number of destinations each one is permitted to reach, and how quickly that number can be cut to zero. If you run hospitals or plants, read both deployments in full before you model your own timeline, along with Elisity’s published Southern Illinois Healthcare deployment.

How to report unpatchable risk to the board

“Corporate network defenders should shorten their patch testing and deployment timelines” (J.P. Morgan, p.23). Put that sentence in the board deck first, ahead of anything about compensating controls. The patch program is the primary control, the compensating controls cover what the patch program can’t reach, and a metric set that quietly swaps one for the other won’t survive a competent audit committee.

The reporting problem is narrower than it looks. Patch compliance percentage answers a question about the patchable estate, and gets read as an answer about the whole estate. Four metrics fix that, and the fifth is the one you already report.

The metric set and the verdicts are Elisity’s. The 55%–65% estimate is J.P. Morgan, Patchmageddon, p.19, and carries J.P. Morgan’s own hedge, “may be able to be patched.”

Your board should be able to answer one question when the slide comes down: how much of the estate that will never take a patch is currently constrained, and by what?

What these ten controls do not solve

Segmentation doesn’t remove a vulnerability. A PLC with an exploitable firmware flaw still has that flaw after the policy is written, and an attacker who reaches it along an authorized path reaches it anyway. Every control on this page constrains reachability. None of them changes the code on the device. That cuts both ways: only 1.5%-2.0% of reported vulnerabilities get exploited in a given year (Zero Day Clock, cited in J.P. Morgan, p.5), so the flaw left open on a well-constrained asset is usually not the one that matters.

The timing is not forgiving either. Dragos puts the median time from disclosure to public exploit for industrial control system vulnerabilities at 24 days, and finds 4% of ICS vulnerabilities already under active exploitation on the day they are disclosed (J.P. Morgan, p.20, citing the Dragos 2026 OT Year in Review).

Read that figure for what it measures. Public exploit availability is the moment working code becomes obtainable. First in-the-wild exploitation is the moment someone uses it against a live system. Those are different events on different populations, and for general software the medians on that second measure have collapsed: from roughly one year in 2021 to one day in 2026, with almost 80% of exploitation now occurring on or before the day of disclosure (Zero Day Clock, cited in J.P. Morgan, p.9). The gap is not a defender’s cushion. It is a property of industrial control systems, where building a working exploit still takes vendor-specific protocol knowledge and, often, the physical hardware. That advantage narrows as soon as an attacker can generate the exploit from the patch itself, which is the capability the J.P. Morgan report is about. Any end-of-life Windows host in the same estate never had the advantage to begin with; it sits in the one-day population, not the 24-day one. If you put both figures on the same slide, say which is which. AI-accelerated vulnerability discovery, the subject of the J.P. Morgan report and of Elisity’s own analysis of AI-driven vulnerability discovery and unpatchable devices, changes how many findings arrive and how fast. It does not change what an unpatchable device is allowed to reach.

J.P. Morgan is direct about who these controls are for. “Small and under-resourced operators often run end-of-life technology they cannot afford to replace,” and the problem “is most acute in operational technology, where equipment stays in service for long periods and may be difficult or impossible to patch” (J.P. Morgan, p.25). The policy options in that same paragraph include federal financing and targeted rip-and-replace incentives.

Lead times are context for the interval before replacement, not an argument against it. J.P. Morgan Tech Infrastructure put servers at 6 months or more, storage at 4-5 months, buildings and modules at 18-24 months, and power substations and electrical equipment at 24-36 months (J.P. Morgan, p.23). Those are data center supply chains rather than PLC replacement schedules, and they read as a floor on how fast capital equipment moves. That interval is the window these ten controls exist to cover.

The report’s own closing frame is the honest one for this page: “resilience planning for cases where patches do not arrive in time” (J.P. Morgan, p.25).

Where Elisity fits, and where it does not

Elisity publishes this page, so here is the disclosure as structure rather than as a claim.

Elisity doesn’t patch anything. Neither does Claroty, Armis, Nozomi Networks, Dragos, Illumio, Zero Networks, or ColorTokens. What network-layer enforcement decides is what an unpatched device is allowed to reach, which is a different job from closing the vulnerability and should be described as one.

Where the Elisity model applies: Controls 1, 4, 6, 7 and 8, plus the evidence half of Control 10. Identity-based policy enforced on access switches an organization already owns, with no agent on the device, no re-IP, and no new hardware. Legacy assets come under policy without installing software on them. Comparative detail on that category and its alternatives is in What Are the Top Microsegmentation Solutions for 2026.

Where it does not: Control 2 runs on vulnerability and exposure data that Elisity ingests rather than produces, from platforms like Claroty, Armis, Asimily, or Nozomi Networks. Control 3 is firewall, edge, and configuration work. Control 5 belongs to a privileged remote access product. Control 9 is an IPS and OT firewall function from vendors such as Palo Alto Networks, Fortinet, or TXOne. Four of the ten controls here are not an Elisity purchase.

Consideration: Elisity’s enforcement runs on campus and on-premises switching infrastructure. If your unpatchable estate sits behind a cell modem at an unstaffed remote site with no managed switch, there is no enforcement point to use, and that control belongs to a gateway or firewall instead.

Frequently asked questions

How do I secure devices that cannot be patched?

Apply compensating controls that constrain what the device is allowed to reach. Inventory it by device class and patch status, rank it by network exposure, place it in an identity-based segment enforced on existing switching, allow-list only the flows its function requires, broker and record remote access, monitor the segment, and document the control with a review date.

Best solutions for unpatchable device security

There is no single product. Unpatchable device security combines an OT and IoMT discovery platform such as Claroty, Armis, Nozomi Networks, or Asimily for classification, an agentless network-layer enforcement platform for least-privilege policy, a brokered remote access tool for vendor sessions, and protocol-aware inspection where enforcement cannot reach. Evaluate each layer on its own.

How do I protect PLCs and SCADA systems that can’t be patched?

Put every PLC, RTU, HMI, and engineering workstation into a defined zone, then permit only the conduits the control loop actually needs. Remove internet exposure and default credentials from boundary devices first. Allow-list Modbus, DNP3, and EtherNet/IP by source, destination, and function rather than by port. IEC 62443-3-3 SR 5.1 and SR 5.2 are the clauses an assessor will ask about.

How do I secure legacy industrial equipment?

Segment legacy industrial equipment by identity rather than by subnet. CNC machines, system drives, control boards, and unsupported HMIs can’t run agents and often can’t be re-addressed, so enforcement has to happen on the network infrastructure they already connect to. Run a discovery pass first, simulate the policy before enforcing it, and keep every exception dated.

How do I protect end-of-life Windows machines I can’t replace yet?

Contain the end-of-life Windows machine instead of rebuilding the network around it. Classify each unsupported Windows workstation, imaging console, and HMI by function, then enforce a policy allowing only the applications and destinations its workflow requires. Block SMB and RDP between peer workstations, record every remote session into the machine, and set a documented replacement date.

Best approaches for securing unsupported systems

Four approaches carry most of the load: network segmentation that follows device identity, allow-list east-west policy on the protocols the system actually speaks, brokered and recorded remote access, and segment-level monitoring, because an unsupported system produces almost no useful telemetry itself. NCSC obsolete-product guidance names segregation and restricted connectivity as its primary mitigations.

How do I secure industrial devices without agents?

Enforce policy on the network infrastructure instead of on the device. Agentless enforcement combines a discovery source, an identity-based policy engine, and existing access switches, so an industrial sensor, drive, or controller is secured without installing software on it. Confirm that your switch models support the enforcement method before you scope the project.

How to isolate vulnerable industrial systems

Isolation in practice means an allow-list, not an air gap. Define the zone the vulnerable industrial system belongs to, enumerate the flows its process requires, deny everything else, and monitor the boundary. Full physical isolation usually breaks the historian, the vendor support path, or the maintenance workflow, which is why it tends to get reversed within a year.

How do I protect medical and industrial devices that can’t be patched or taken offline?

Constrain reachability, because the device cannot change and the downtime window does not exist. Infusion pumps, imaging modalities, patient monitors, PLCs, and DCS controllers stay in production while an identity-based policy limits each one to the destinations its clinical or process function requires. Enforcement happens on the switching infrastructure, so nothing is installed on the device and nothing is taken offline.

Microsegmentation for legacy systems

Microsegmentation for legacy systems works when enforcement happens off the device. Legacy systems fail agent-based microsegmentation because they cannot host software, and they fail VLAN-based segmentation because re-addressing them is disruptive. Identity-based microsegmentation enforced on existing switching works on legacy systems without touching them. It does not patch them, and it will not stop movement along an authorized path.

About the author