What Deception Solutions Are – and Aren't

A deception solution deploys decoy versions of real OT assets across your network. These decoys don't just open ports and wait; in a well-implemented solution, they behave credibly at the protocol level. A convincing substation decoy, for example, responds plausibly to IEC 61850 MMS queries, handles Modbus requests, or mimics DNP3 behavior. An attacker probing the network should find it indistinguishable from a real device. When an intruder interacts with one of these decoys, defenders receive an alert - often far earlier than any traditional monitoring tool would trigger.

This is frequently confused with honeypots, but they serve different purposes:

  • Honeypots
    Research instruments: they study attacker behavior in controlled environments and capture techniques for analysis. 

  • Deception Solutions
    Operational detection tools: They catch attackers already inside your network before they reach critical systems - not to observe them, but to expose them.

Why Deception Requires Security Maturity

Deception solutions generate a specific kind of alert: low-volume, high-confidence. A decoy should never receive legitimate traffic. Any interaction with it is, by definition, suspicious. That's the strength of the approach - but it also exposes a hidden dependency.

Acting on a precise, high-confidence alert requires capability that many OT security programs are still building. Without a complete asset inventory, you can't place decoys convincingly - a decoy that doesn't match the topology of your real network won't fool a sophisticated attacker who has already done reconnaissance. Without network visibility, you can't reliably distinguish an attacker interacting with a decoy from a misconfigured real device doing the same thing. And without established incident response processes, the alert, however accurate, simply joins the queue of things that couldn't be followed up on.

This is why deception belongs at a later stage of the OT security maturity journey, not the first. 

The prerequisites are needed to make the deception alert actionable:

  • Network segmentation and a maintained asset inventory
    • Firewall architecture with defined zone and conduit structures
    • Endpoint protection
    • Network intrusion detection (NIDS) with active monitoring
    • Network access control (NAC)
    • Logging, alerting, and established response procedures
    • Skilled staff capable of investigating and escalating incidents

In terms of widely-used frameworks, this roughly corresponds with the mid-to-upper tiers of security maturity models. If your organization is still working through the lower levels, deception adds complexity before adding value.

How Deception Reduces Dwell Time

For organizations that have built the foundation, the value is substantial - and it maps directly to the most persistent problem in OT security: dwell time.

Industry data on OT and ICS incidents regularly shows that attackers spend months inside a network before being detected. That window is where damage accumulates: reconnaissance, lateral movement, positioning for maximum impact. Shortening it meaningfully changes the risk profile of an incident.

Deception solutions intervene specifically at the lateral movement phase, when an attacker is probing the network to map assets and find targets. This is exactly when a decoy becomes attractive - and exactly when triggering an alert has the most defensive value. Catching an attacker here, rather than at the point of impact, gives defenders time to respond before operational technology is affected.

There's also an asymmetric cost argument worth considering. Maintaining a decoy is inexpensive compared to hardening every real asset. For energy operators with large, heterogeneous OT environments - aging field devices, mixed vendor equipment, long replacement cycles - that asymmetry matters. You can't harden everything equally, but you can place decoys strategically.

Regulatory context reinforces this. NIS2 and German KRITIS obligations increasingly require energy operators to demonstrate not just protection, but detection and response capability. Deception contributes meaningfully to that posture, but only as part of a broader detection architecture that already includes monitoring, logging, and defined response processes.

Where Deception Fits into Your OT Security Program

Deception is not the place to start your OT security program. It's where a mature program can take the next step.

The highest-value investments for organizations still building capability remain: 

  • Establishing proper network segmentation
  • Gaining visibility across OT assets
  • Putting logging and monitoring in place
  • Ensuring that alerts - from any source - can be investigated effectively

Once that foundation is in place, deception becomes something genuinely useful: an early-warning layer that catches sophisticated attackers at the moment they're most exposed, reduces dwell time before they reach critical systems, and does so at a cost that makes it one of the more efficient tools available to critical infrastructure operators.

The cherry on top, so to say – but only once there's a cake underneath it.

Resources

Simon Rommer

OT Cybersecurity Expert, OMICRON

Simon combines hands-on experience in SOC analysis, forensics, and IT/OT interfaces with a knack for tackling complex challenges. From securing Austria's largest energy provider to optimizing security at the IT/OT edge, he's dedicated to making the protection of critical systems smarter and safer.