Tool Vendors vs Control Vendors-Two Very Different Threat Models

 By Muhammad Ali Khan ICS/ OT Cybersecurity Specialist - AAISM | CISSP | CISA | CISM | CEH | ISO27001 LI | CHFI | CGEIT | CDCP

Why This Distinction Matters in OT

In IT security, vendor categories blur easily.
In Operational Technology (OT), confusing a tool vendor with a control vendor is not a harmless mistake; it is a fundamental threat-modeling failure.

Firewalls, EDRs, SIEMs, vulnerability scanners, and AI monitoring tools are tools.
PLCs, DCSs, RTUs, SIS, drives, and controllers, these run the process.

Treating both under the same security assumptions is how plants get disrupted, safety margins get eroded, and incidents quietly wait to happen.

This blog breaks down why tool vendors and control vendors face radically different threat models, and why OT security collapses when this reality is ignored.

1. Control Vendors: When Compromise Equals Process Control

What Control Vendors Actually Own

Control vendors (Siemens, Rockwell, Schneider, ABB, Emerson, Yokogawa, etc.) design and maintain:

• PLC and DCS firmware
  
  

• Control logic execution environments
  
  

• Safety Instrumented Systems (SIS)
  
  

• Proprietary industrial protocols
  
  

• Engineering workstations and compilers
  
  

They define how physics is controlled.

If their trust boundary is violated, the attacker is no longer “in the network.”
They are inside the process.

The Control Vendor Threat Model

A control vendor must assume:

• Compromise can cause physical damage
  
  

• Failures propagate silently
  
  

• Attacks may remain dormant for years
  
  

• Recovery may require shutdowns, rewrites, or recertification
  
  

• Safety systems may be bypassed without alarms
  
  

This is not theoretical.
Stuxnet, Triton, Industroyer, and CrashOverride all exploited control-layer trust.

Why Control Vendors Are High-Value Targets

• Long lifecycle (15–30 years)
  
  

• Static firmware is rarely updated
  
  

• Blind trust by operators
  
  

• Minimal runtime validation
  
  

• Legacy cryptography or none at all
  
  

A single compromised firmware update or engineering tool can poison thousands of plants globally.

Control vendors are not defending endpoints.
They are defending physical reality.

2. Tool Vendors: Observers, Not Process Owners

What Tool Vendors Provide

Tool vendors include:

• Firewalls & OT gateways
  
  

• IDS / NDR platforms
  
  

• Asset discovery tools
  
  

• SIEMs and SOC platforms
  
  

• AI anomaly detection
  
  

• Vulnerability scanners
  
  

They observe, analyze, or filter—but they do not execute control logic.

If compromised, the tool may:

• Lose visibility
  
  

• Generate false alerts
  
  

• Miss an attack
  
  

• Leak telemetry
  
  

Serious? Yes.
Catastrophic? Usually no.

The Tool Vendor Threat Model

Tool vendors assume:

• They may be bypassed
  
  

• They may be deceived
  
  

• Their failure should degrade visibility, not control
  
  

• Removal should not stop the process
  
  

• Updates can be rolled back easily
  
  

Their products are adjacent to operations, not embedded inside them.

3. The Critical Difference: Who Owns the “Last Action”

Dimension	Control Vendor	Tool Vendor
Executes logic	✅ Yes	❌ No
Controls physical actuators	✅ Yes	❌ No
Can cause unsafe states	✅ Directly	❌ Indirectly
Failure mode	Process disruption	Loss of visibility
Patch tolerance	Extremely low	Moderate
Attack dwell time	Years possible	Usually shorter

Control vendors own the last action before physics moves.
Tool vendors do not.

That single distinction changes everything.

4. Why Applying IT Threat Models Breaks OT Security

The Dangerous Assumption

“If we secure the tools, the system is secure.”

This is false in OT.

You can have:

• Perfect SIEM coverage
  
  

• AI-powered anomaly detection
  
  

• Zero Trust gateways
  
  

• 24/7 SOC monitoring
  
  

And still lose control if:

• Engineering software is compromised
  
  

• The firmware supply chain is poisoned
  
  

• Control logic integrity is violated
  
  

• Safety systems are misconfigured by trusted tools
  
  

Tools can only detect what they are allowed to see.
Controllers execute what they are told, silently.

5. Supply Chain Risk: A Tale of Two Vendors

Tool Vendor Compromise

• SOC detects anomalies
  
  

• The tool is isolated
  
  

• Logs restored
  
  

• Visibility resumes
  
  

• Process keeps running
  
  

Control Vendor Compromise

• Malicious logic executes normally
  
  

• Operators see “normal” values
  
  

• Safety logic behaves correctly, until it doesn’t
  
  

• Physical damage occurs
  
  

• Root cause analysis takes months
  
  

• Trust in the system collapses
  
  

One is an incident.
The other is an industrial disaster.

6. The Hidden Problem: Control Vendors Often Don’t Act Like High-Risk Vendors

Despite their risk profile, many control vendors:

• Lack secure boot
  
  

• Ship unsigned firmware
  
  

• Rely on obscurity
  
  

• Treat safety and security separately
  
  

• Resist external security scrutiny
  
  

• Move slowly on vulnerability disclosure
  
  

Meanwhile, tool vendors are subjected to:

• Pen tests
  
  

• Bug bounties
  
  

• Cloud security audits
  
  

• Continuous updates
  
  

The highest-risk layer often receives the least security pressure.

7. What OT Professionals Must Do Differently

Stop Lumping Vendors Together

Security assessments must ask:

• Does this vendor execute logic?
  
  

• Does this component move equipment?
  
  

• Does compromise change physics?
  
  

If yes → Control-layer threat model required

Demand More from Control Vendors

• Cryptographic signing of logic and firmware
  
  

• Runtime integrity validation
  
  

• Deterministic fail-safe states
  
  

• Secure engineering workflows
  
  

• Long-term vulnerability management
  
  

• Security baked into safety cases
  
  

Use Tools as Compensating Controls, Not Foundations

Tools should:

• Detect deviations
  
  

• Validate control behavior
  
  

• Correlate anomalies
  
  

• Support investigations
  
  

They should never be the only line of defense.

8. The Future: Agentic AI Makes This Divide Even Sharper

As AI moves closer to:

• Automated tuning
  
  

• Predictive control
  
  

• Self-optimizing logic
  
  

• Autonomous response
  
  

The question becomes brutal:

Is the AI advising the process or controlling it?

Once AI crosses into execution, it becomes a control vendor, not a tool vendor.

And its threat model must reflect that reality, or the industry will repeat the same mistakes at machine speed.

Conclusion: Different Vendors, Different Consequences

Tool vendors help you see.
Control vendors decide what happens.

Confusing the two leads to:

• Misplaced trust
  
  

• Weak safety cases
  
  

• Overconfidence in monitoring
  
  

• Underinvestment in control integrity
  
  

In OT security, who owns the last command matters more than who provides the best dashboard.

If you secure the tools but ignore the controllers, you are protecting the observer, not the system.

And physics does not care about dashboards.