CTEM for OT/ICS: Why IT-Centric Exposure Management Falls Short
CTEM was built for IT. Here is what changes when you apply continuous threat exposure management to OT and ICS, and why industrial environments differ.
By Piscium Security Team
TL;DR
- CTEM (Continuous Threat Exposure Management) is a five-phase program Gartner introduced in 2022: scoping, discovery, prioritization, validation, and mobilization, run continuously instead of once a quarter.
- The framework was written with IT in mind. In OT and ICS, three things break the usual playbook: safety and uptime outrank everything, most equipment is old and cannot be patched on demand, and the protocols were designed with no security at all.
- Active vulnerability scanning, routine in IT, can crash a fragile PLC. That is why discovery in OT has to start passive, and why validation has to be bounded so it never touches the physical process.
- Piscium Radius applies the five CTEM phases to OT/ICS with passive-first discovery, protocol-aware asset mapping, safety-bounded validation, and closed-loop remediation. It is an early-stage platform, and the numbers in our examples are modeled or illustrative.
"Continuous Threat Exposure Management" is a mouthful, but the idea underneath it is simple: stop checking your security once a quarter and start checking it continuously. Gartner coined the term in 2022 and described it as a set of processes that let an organization keep evaluating how accessible, exposed, and exploitable its assets are, then fix what matters most, over and over.
That works cleanly in a data center. It gets complicated the moment the "asset" is a programmable logic controller running a turbine, a water pump, or a bottling line. This piece walks through what CTEM is, why the IT version of it struggles in industrial environments, and what changes when you apply it to OT and ICS.
What CTEM actually is
Gartner's framework has five phases, meant to run as a loop rather than a one-time checklist:
| Phase | What happens |
|---|---|
| Scoping | Decide what you are protecting, in business terms, and which attack surfaces are in play. |
| Discovery | Find the assets, vulnerabilities, misconfigurations, and exposures inside that scope. |
| Prioritization | Rank what you found by real business impact and exploitability, not by CVSS score alone. |
| Validation | Test whether the exposures you flagged are actually exploitable. |
| Mobilization | Get the fixes done, with owners, deadlines, and a way to confirm they held. |
The phase that separates CTEM from ordinary vulnerability management is validation. A scanner tells you a vulnerability exists. Validation tells you whether an attacker could actually use it in your environment. Gartner has projected that organizations that prioritize their security spending around a CTEM program will be three times less likely to suffer a breach by 2026. That figure is a Gartner projection rather than a measured result, but the logic behind it is hard to argue with: proof beats a severity score.
Why IT-centric exposure management struggles in OT
Take that five-phase loop, point it at a plant, and it starts to strain in specific, predictable ways.
Safety and uptime come first, not confidentiality. In IT, the usual priority is protecting data. In OT, the priority is keeping the process running and keeping people safe. A technique that is routine in IT, like probing a host until it answers, is unacceptable if that host controls a boiler.
Most of the equipment cannot be patched on demand. Industrial controllers often run for a decade or more, frequently on software the vendor no longer updates. Patching means downtime, and downtime on a production line or a substation has to be planned far in advance. The result is a large installed base of devices with known weaknesses that will not be fixed any time soon.
The protocols were built without security. The languages these devices speak predate the modern threat model. Modbus, still one of the most common, has no authentication, no encryption, and no integrity checking, so anything on the network can read traffic and issue commands. DNP3 was originally unauthenticated; secure authentication was added later as an option (DNP3-SA, in IEEE 1815-2012) but is not deployed everywhere. OPC UA can be secured, yet is often configured without it. When the protocol itself offers no proof of who is talking, "exposure" means something different than it does on a web server.
Scanning can be the attack. An active vulnerability scan floods a device with traffic it was never built to handle. On a fragile legacy PLC, that alone can cause a fault or a shutdown. This is why passive monitoring, watching a mirror of network traffic without sending anything to the controllers, is the standard first move in OT, and why lifting an IT scanner straight into a plant is a bad idea.
The network is supposed to be layered. OT networks are modeled on the Purdue reference architecture, which sorts systems into levels from the physical process (Level 0) up to enterprise IT (Levels 4 and 5), with a DMZ in between. The whole point is that the lowest levels should be hard to reach from outside. As IT and OT converge, those boundaries blur, and an exposure that looks minor in isolation can become the first step on a path down toward the process.
None of this is hypothetical. The record of OT-specific malware is short but serious: Stuxnet damaged uranium-enrichment centrifuges in 2010; Industroyer helped cut power in Ukraine in 2016; TRITON went after the safety controllers at a petrochemical plant in 2017; and in 2022 both Industroyer2 and the reusable PIPEDREAM/INCONTROLLER toolkit showed that industrial malware is now built to be pointed at more than one target. Each of these reached the process by moving through the kind of exposures a CTEM program is meant to find first.
What changes in each CTEM phase for OT
Applying CTEM to OT is less about adding phases and more about running each one differently.
- Scoping starts from the physical process, not an IP range. The question is which processes, if disrupted, cause a safety or production event, and then which digital assets support them.
- Discovery has to be passive first. You learn the environment by watching traffic and fingerprinting protocols, and you only send anything to a controller when someone has explicitly signed off on it.
- Prioritization weighs where an asset sits in the Purdue model. A medium-severity flaw on a Level 1 controller that drives a physical process can matter far more than a critical one on a Level 4 laptop.
- Validation has to be bounded. The goal is to prove an attack path is real without ever touching the process, which means safe emulation with hard limits, not a live exploit against a running plant.
- Mobilization accepts that patching is often off the table. When you cannot fix the device, the fix becomes a compensating control, a segmentation change, or a monitoring rule, and the loop has to confirm that control actually closed the path.
Where Piscium Radius fits
Piscium Radius is our approach to running that loop in industrial environments. A few honest specifics:
- Discovery is passive-first. Radius maps assets by watching traffic and fingerprinting industrial protocols, including Modbus/TCP, EtherNet/IP, OPC UA, DNP3, IEC 61850, PROFINET, BACnet, and S7comm. It does not send packets to production controllers unless active probing is explicitly authorized.
- Validation is safety-bounded. Autonomous agents emulate attacker techniques with configurable limits that keep them away from the physical process, and Radius runs no destructive tests. Findings come with evidence (screenshots, packet captures, audit trails) and map to MITRE ATT&CK.
- Remediation is closed-loop. Radius builds fix plans, opens tickets in tools like ServiceNow and Jira, tracks them to closure, and re-validates to confirm the exposure is actually gone. It deploys as managed SaaS, hybrid, or fully on-premises for air-gapped sites.
Two things worth stating plainly. Piscium is an early-stage company, and any before-and-after numbers in our material are modeled or illustrative, tied to a reference environment rather than a production customer. We align our own testing to the OWASP Autonomous Penetration Testing Standard (APTS); we do not claim compliance certifications we have not earned.
Frequently asked questions
Is CTEM different from vulnerability management? Yes. Vulnerability management finds and tracks known weaknesses. CTEM adds prioritization by business impact and validation that proves which weaknesses are actually exploitable, then drives them to a confirmed fix.
Can you run CTEM in an OT environment without disrupting production? You can, but only if discovery is passive by default and validation is bounded so it never reaches the physical process. Lifting an IT scanner into a plant is the fast way to cause the outage you were trying to prevent.
Does CTEM replace OT monitoring tools like an intrusion detection system? No. Detection tools tell you when something is happening now. CTEM works ahead of that, finding and closing the exposures an attacker would use before they are used. The two are complementary.
How long does it take to see results in OT? With Piscium Radius, passive asset discovery can begin within hours of deployment, and first validated findings are estimated within about 48 hours depending on how complex the environment is. Those are design targets, not guarantees.
For a plain-language primer on the framework itself, see What is CTEM? and ASM vs. CTEM. For the vendor picture, see how the CTEM and OT security categories fit together.
Sources
- Gartner introduced CTEM in 2022 and projects three-times-lower breach likelihood for adopters by 2026: Gartner, "How to Manage Cybersecurity Threats, Not Episodes".
- CISA advisory on the PIPEDREAM/INCONTROLLER ICS toolset (April 2022): CISA AA22-103A.
- Protocol security details reflect the Modbus specification, the DNP3 / IEEE 1815-2012 standard, and OPC UA security guidance.
Curious how the CTEM loop runs inside your OT constraints? Schedule a technical demo to see how Piscium Radius discovers, validates, and remediates exposure across OT, IT, and cloud.