IoT & OT Security

The Top Ten Threat Debt Projects

Where exploitable risk actually concentrates — and why patching is rarely the lever

THE SHORT VERSION 
Threat Debt is the accumulated, uncontained, exploitable risk an organization carries at any given time. It can be modeled across six measurable dimensions, and when ORDR applies device-type-based analysis to a typical large environment, a remarkably consistent pattern emerges: ten device categories account for the overwhelming majority of operational risk. The categories repeat across hundreds of deployments. And in eight of the ten, the right intervention is not faster patching — it is structural containment: segmentation, isolation, access restriction. This is the working list, the drivers behind it, and the containment levers that actually move the needle. 

Why Device-Type Analysis Matters 

Connected-device environments do not accumulate risk evenly. A small number of device categories carry a disproportionate share of the operational exposure, and the same categories show up at the top of the list across hospitals, manufacturers, utilities, and large enterprises. The pattern is structural, not coincidental. The devices that drive risk are the ones whose vulnerabilities persist longest, whose blast radius is largest, and whose compromise causes the most direct disruption to the business. 

This matters because the conventional approach to risk reduction, vulnerability scanning, CVSS ranking, patch when possible, treats every device as roughly equivalent and every vulnerability as the same problem. It is not. A high-severity CVE on a legacy x-ray modality is not the same problem as the identical CVE on a corporate laptop, because the constraints are different (FDA restrictions on the modality, EDR coverage on the laptop), the network position is different (the modality talks to PACS and vendor cloud destinations; the laptop talks to everything), and the available levers are different (the modality cannot be patched; the laptop can). 

Device-type-based Threat Debt analysis is the operationalized version of this insight. Threat Debt itself is modeled across exploitability, exposure, reachability, operational criticality, compensating controls in place, and time-to-remediation, and tracked over time at the device, category, and environment level. The output is a prioritized program of structural improvements rather than a list of patches to install. And when that program is generated, it consistently surfaces the same ten device-category projects. 

This article is Part 2 of a three-part series on proactive AI in connected-device security. Part 1 made the case for AI as a prevention engine rather than a productivity tool. This post is the operational proof: where the prevention work actually lives. 

The Top Ten Projects 

Below is the working list of the top ten device-category projects ORDR surfaces in priority order, with the dominant Threat Debt driver and the containment lever that meaningfully reduces it. The ordering reflects where Threat Debt concentrates most operationally. Medical and OT devices top the list because their vulnerabilities persist longest, and their compromise causes the most direct disruption. Rogue devices follow because invisible debt is the most dangerous kind. The remaining categories are weighted by exposure, reachability, and the realistic ability to apply structural controls. 

Device Category 

Primary Threat Debt Driver 

Containment Lever (ORDR) 

Medical & Clinical Devices (IoMT) 

Legacy OS, FDA-restricted patching, unpatchable vulnerabilities on patient-critical systems 

Safe Zero Trust segmentation; recall-aware grouping; least-privilege paths 

Operational Technology (OT/ICS) 

Flat IT/OT boundaries, legacy protocols, availability-first constraints 

Operationally safe IT/OT segmentation; protocol-aware policy 

Rogue & Unauthorized Devices 

Invisible Threat Debt — malware ingress, exfiltration paths, audit blind spots 

Real-time agentless discovery; automated containment via CMDB and incident workflow 

Office Infrastructure (printers, cameras, badge readers, IP phones) 

Persistent footholds outside standard patch cycles 

VLAN visibility and change automation; context-aware access 

Laptops, Endpoints & Workstations 

EDR coverage gaps, phishing-driven credential theft, configuration drift 

EDR posture validation; Zero Trust access based on device state 

Servers & Virtualized Workloads 

East-west movement risk, privileged admin protocols (SMB/Telnet) 

Protocol-aware policy; allow-only-necessary communication maps 

Mobile Devices 

BYOD data leakage; unmanaged access to sensitive systems 

Network behavior correlated with MDM posture; access restriction 

Network Infrastructure (switches, routers, firewalls, APs) 

EOS/EOL gear, misconfiguration, enforcement gaps 

Turn existing infrastructure into context-aware enforcement points 

Facilities & Building Systems 

Legacy protocols, vendor remote access, IT/OT convergence pain 

Discovery, isolation, monitored vendor access paths 

10 

Consumer & Smart IoT 

Weak built-in security, uncontrolled cloud egress 

Behavioral baselining; strict segmentation with controlled outbound 

Two things matter about this list. First, the ordering is not arbitrary — it reflects where Threat Debt actually concentrates operationally, not a generic best-practices checklist. Second, the right intervention is rarely “patch faster.” In eight of the ten categories, the primary lever is structural containment — segmentation, isolation, access restriction — not remediation. 

Why Structural Containment, Not Patching 

The pattern in the list above runs against the dominant security narrative, which still equates risk reduction with vulnerability remediation. For most of these device categories, that equation does not hold. 

Medical devices cannot be patched on demand; FDA restrictions and clinical availability requirements mean the patching window is narrow and the patches themselves often lag the disclosure by months. OT and ICS systems prioritize availability over confidentiality and integrity, and many cannot tolerate the change-management overhead patching requires. Network infrastructure past end-of-support cannot be patched at all. Office infrastructure like printers, cameras, badge readers, has vulnerabilities that the manufacturer never updates. Rogue devices, by definition, are outside the patching workflow because they are outside the asset inventory. 

In each of these cases, the operationally honest answer is not “patch faster.” It is “apply structural controls so the unpatched device cannot do meaningful harm.” That means segmentation that limits where the device can reach, isolation that quarantines it from sensitive systems, access restriction that prevents lateral movement, and behavioral baselining that flags deviations from legitimate operation. None of these eliminate the vulnerability. All of them shrink the Threat Debt by removing the conditions under which the vulnerability can be exploited. 

And structural containment only works when it is device-type-aware. A generic firewall policy applied uniformly to imaging modalities, infusion pumps, and PLCs will break clinical and operational workflows on day one. This is where most segmentation efforts stall; not for lack of intent, but for lack of device intelligence deep enough to make the policy safe. The list above is a list of projects only if the platform underneath knows the difference between a Siemens SOMATOM CT scanner and a Philips PACS workstation, and knows which destinations each of them legitimately talks to. 

How to Use the List 

A few practical points for a CISO looking at this list as an operating plan: 

  • Start at the top, but not in isolation. The medical and OT projects are typically the highest-yield and the hardest. They are also the categories where the conventional vulnerability-management process is most likely to be inadequate, which is why proactive AI matters most here. Begin with discovery and behavioral baselining; structural containment follows from understanding the legitimate traffic first. 
  • Rogue device containment is faster than it looks. Project 3, rogue and unauthorized devices, often delivers visible Threat Debt reduction within weeks rather than months, because the work is closer to discovery and policy than to negotiation with clinical or operational stakeholders. It also tends to produce dramatic findings that build organizational momentum for the harder projects above it. 
  • Treat the network infrastructure project (8) as enabling, not isolated. The switches and firewalls in the environment are the enforcement points for the other nine projects. Turning them into context-aware enforcement points is a prerequisite, not a parallel workstream. 
  • Measure Threat Debt reduction, not project completion. The board-relevant metric is the reduction in exploitable, reachable, operationally critical exposure — not the number of devices segmented or policies created. The point of the work is the risk delta. 

The Bottom Line 

Connected-device security has been organized around the wrong unit of work for a long time. Vulnerability lists, CVSS rankings, and patch programs treat the device as a uniform object and the vulnerability as a uniform problem, and the resulting work product is a queue of remediation tickets that the security team cannot keep up with and the operational team often cannot accept. 

Device-type-based Threat Debt analysis reorganizes the work around what actually drives risk: the device category, the structural conditions that make it exploitable, and the containment levers that materially reduce the exposure. The top ten projects above are the result of that reorganization applied to real environments at scale. They are not a generic best-practices list. They are an operating plan. 

And they are the kind of operating plan a proactive AI platform was built to produce. The next post in this series shows what that looks like in practice: a CISO opens the platform, asks one question in plain language, and gets back a defensible, enforceable segmentation plan for radiology — grounded in the same device-type-based Threat Debt analysis underneath the list above. 

Next in this series: one prompt, one segmentation plan — a worked example of proactive AI applied to the highest-priority project in a real healthcare environment, with the closed-loop enforcement that turns the recommendation into an outcome. 

ABOUT THIS SERIES 

Three posts on how proactive AI changes connected-device security. 

PART 1  ·  AI for Prevention, Not Productivity 

PART 2  ·  The Top Ten Threat Debt Projects   (you are here) 

PART 3  ·  Proactive AI in Action: One Prompt, One Segmentation Plan 

ShareLinkedInX