In an industrial environment the assets worth defending are the ones you are least able to instrument: a controller will not run an endpoint agent, its firmware is patched on a schedule measured in years, and the protocol it answers on was designed to trust any correctly formatted command. Deception fits this constraint instead of fighting it, because a decoy controller sitting in the same segment needs nothing installed on anything real, and no legitimate HMI or engineering workstation has a reason to poll a device that is not part of the process.
The hard part of OT detection is not deciding whether a command was malicious. It is having any record of the command at all.
Why OT is the hard case
Every assumption that IT detection rests on is weaker in a plant, and the weaknesses stack.
The endpoint cannot be instrumented. A PLC, a safety controller, an RTU, a drive, a protection relay: none of these take an agent. Whatever detection you get for the devices that move the physical process has to come from somewhere other than the devices.
The protocol does not authenticate. The widely deployed industrial protocols were specified for a serial link on a trusted wire. A read request and a write request from an attacker are byte-for-byte indistinguishable from one issued by the real HMI. There is no credential to steal because there is often no credential, which is why MITRE's ICS mitigation set has to call out authorization enforcement and message authentication as things to add rather than things to configure.
Patching is a negotiation. Fixing a known vulnerability on a controller means a change request, a validation cycle, a window, and in regulated plants a requalification. "Known-vulnerable and running" is the normal, accepted steady state, not a backlog failure.
Nobody wants more traffic on the control network. Deep inspection of production traffic is a hard sell when the network it is inspecting has a bandwidth budget set in the 1990s and an engineer who remembers what happened the last time something unexpected talked to Level 1.
Safety beats security, correctly. Any control that could stall a loop or delay an operator action loses the argument, and should.
What survives all five constraints is narrow: things that are passive, things that live outside the control path, and things that generate no traffic toward real devices. A decoy is all three. It also has the property that nothing in the plant has a baseline for it, because it has no process function. There is no normal volume of Modbus reads against a device that is not part of the process. The number is zero.
What the intrusions actually look like
The useful thing about recent public cases is how unexotic the entry is.
In July 2026 CISA reported malicious activity against internet-exposed systems at more than 100 Water and Wastewater Systems Sector entities in a single month, commonly reaching programmable logic controllers connected directly to a cellular modem. The actors changed device passwords to lock operators out and changed PLC IP addresses to disconnect the controllers, and the consequences were boil-water notices and plants running on sustained manual operation.
CISA's guidance was to find and remove publicly exposed PLCs and other OT from the internet, change default credentials, secure required remote access, and monitor continuously for anomalous activity. The agency has made the same point about operator interfaces in a joint fact sheet with the EPA on internet-exposed HMIs, and in a separate advisory on state-affiliated actors exploiting PLCs across US critical infrastructure. Public reporting on the summer intrusions describes the same pattern repeatedly: a reachable interface, credentials that were never changed, and then a foothold on the operator's own screen.
None of that requires a vulnerability. It is exposure plus a default password plus a remote-access path somebody set up for a vendor in 2019.
Manufacturing adds a second route that does not touch a controller at all. The plant can stop because the systems that tell it what to build stopped: scheduling, MES, the historian, the label printers, the quality records a regulated line cannot ship without. That intrusion begins and ends in IT, which means the detection opportunity is also in IT, upstream of the moment production notices. That path is covered in ransomware early detection; this page is about the industrial side of the boundary.
Where deception fits in the OT attack path
The ICS technique IDs are here so you can line this against the coverage map you already maintain.
Getting in. External remote services (T0822) is the front door in most public cases: a vendor VPN, a remote-support appliance, a cellular modem, a jump host someone exempted from MFA. Default credentials (T0812) is what makes the door cheap to walk through. Deception does not prevent either, but the credential a decoy breadcrumb supplies is one the attacker will try, and trying it is the alert.
Finding the process. This is where an industrial attacker is slowest and most exposed, because the information they need does not exist on the internet. They have to learn your plant: remote system discovery (T0846) to find what answers, network sniffing (T0842) to see which devices talk to which, and point and tag identification (T0861) to work out what the registers and tags actually control. That last step is the real gate. Flipping a coil is trivial; knowing which coil matters takes reading an HMI, a historian, or an engineering project file. Every one of those is something you can plant a convincing fake of.
Moving toward Level 1. Valid accounts (T0859), remote services (T0886) into HMI and engineering sessions, and lateral tool transfer (T0867) to get an engineering client or a protocol tool somewhere useful.
Acting on the process. Unauthorized command message (T0855), modify parameter (T0836), program download (T0843), and change operating mode (T0858) to reach the engineering functions that make a download possible. Or no process effect at all: theft of operational information (T0882), where the recipe, the tolerances, and the line layout are the objective.
Deception is strongest in the middle two phases and weakest at the edges. It will not stop the initial access and it will not undo a logic download. It is aimed at the reconnaissance-to-targeting gap, which in OT is unusually long, because the attacker has to understand a physical process before they can do anything useful to it.
Placement table
Placement is by Purdue level, because that is how the network is already drawn and how the change approvals are already scoped.
| Level | Deceptive asset to place | Why an attacker goes for it | What a touch tells you |
|---|---|---|---|
| IT (4/5) | Breadcrumb VPN and engineering credentials, decoy entries in saved-session and connection history | The shortest route to OT is a credential on an engineer's laptop | Someone is hunting for plant access from the enterprise side, and you know which host |
| DMZ (3.5) | Decoy remote-access portal and decoy vendor jump host | Vendor paths are trusted, under-logged, and documented in the wiki | A credential is being tried against a plant entry point with no real users |
| Level 3 | Decoy historian, decoy engineering file share holding project and configuration files | This is where the process is described in plain language | Someone is reading the plant's documentation, which only matters to an attacker or an auditor |
| Level 2 | Decoy HMI with a plausible operator screen, decoy SCADA server | Point and tag identification: the fastest way to learn what controls what | Reconnaissance aimed at process effect, not generic scanning |
| Level 1 | Decoy controller answering the plant's industrial protocols, with a realistic model and firmware banner | The target itself, and the thing a protocol scan finds first | An unexplained read in a segment where the legitimate baseline is zero |
| Level 1 | Decoy register and tag ranges on that controller, named to look production-critical | Attackers prioritize what sounds consequential | A write attempt, which is intent rather than curiosity |
If you can only build two, build the Level 2 decoy HMI and the breadcrumb credential on the IT side. They bracket the boundary crossing: one fires when someone starts looking for plant access, the other when they start learning your process, and both land before anything has been written to a real device.
Decoy realism at Level 1 is the part that needs an engineer’s eye rather than a security team’s. A controller profile that answers on the right protocol but reports a model your plant has never bought is a tell. So is a device with a firmware string three major versions off anything in your inventory. LokiMesh’s OT decoys answer on Modbus/TCP, S7comm, EtherNet/IP with CIP, DNP3, IEC 61850 MMS, OPC UA, IEC 60870-5-104 and BACnet. Each protocol comes with a specific vendor persona: a Siemens S7 CPU, a WinCC HMI or SCADA station, an Allen-Bradley ControlLogix 5580, an SEL RTAC substation gateway, or a Tridium Niagara building controller.
Each instance gets its own model, order number, firmware release and serial numbers, and every surface reports the same values. The Modbus device identification, the controller’s protocol-level identity and the web diagnostics page all agree. What operators can’t do today is type in the exact model and firmware of their installed base. The values come from a curated catalog of real part numbers and firmware releases, so they’re plausible but not necessarily yours. Before deployment, compare what each decoy reports against your asset inventory, and pick the template whose vendor and generation match the cell it sits in.
Deployment constraints, honestly
Nothing is installed on production systems. Breadcrumbs are inert artifacts: a file, a credential string, a configuration entry. They do not execute, they have no agent, and they do not alter the behavior of the host they sit on. They matter only if someone steals them. No controller is touched.
No decoy traffic toward real devices. A decoy's job is to be found, not to look around. It does not poll production controllers, which is what makes it different from an active discovery scan and why it does not consume a device's limited connection table.
Address conflicts are the real risk, and they are a change-control problem. In an environment where a duplicate IP can drop a loop, "we added a device to the network" is not a small sentence. Decoys run in isolated fabrics with strict IP-pool validation and conflict detection so they cannot collide with real assets. Treat the allocation as a managed change anyway, approved by whoever owns the segment.
You will still need a window for the network, not for the plant. Deploying decoys does not require touching the control system, but it does require a port, an address, and a VLAN, and in a plant that means a management-of-change record. Plan it as a network change rather than a security deployment and it fits an ordinary window.
Keep decoys out of safety paths entirely. A deceptive asset must never sit in the path of a safety instrumented function, share a safety network, or be reachable in a way that could influence a protective action. If a proposed placement needs that argued, the answer is no.
Tell the inventory owner. Decoys will appear in asset-discovery and OT monitoring tools as unknown devices. Decide before deployment who knows, who does not, and where the authoritative list lives, or the first thing the program produces is an engineer chasing a ghost.
A worked detection
An attacker with an enterprise foothold is looking for the plant. On an engineer's workstation they find saved credentials for what is labeled a vendor support portal. The credentials are a breadcrumb; the portal is a decoy in the DMZ. They authenticate.
That is the first alert, and it is already enough to act on. Say it is missed, or triaged slowly. From the decoy portal the attacker enumerates and finds a Level 2 host that presents an operator interface. It is a decoy HMI. They browse the screens, which is point and tag identification, and the screens name a set of registers in a way that implies one of them governs a pump. They pivot to the device those screens appear to control, a decoy controller at Level 1, and read the coil those screens point at. Then they write to it.
severity : critical
decoy : PLC-WTP-03 (decoy controller, Level 1, process cell 2)
event : write single coil to decoy address (coil 00021, "PMP2_RUN_CMD")
protocol : Modbus/TCP, port 502, function code 05
source : 10.14.6.31 (decoy HMI, Level 2) <- itself a decoy
chain : breadcrumb credential (WS-ENG-0117) -> decoy vendor portal (DMZ) -> decoy HMI (L2) -> this
note : no production device has ever addressed this controllerThe line that matters is the chain. Each hop was a deceptive asset, so there is no ambiguity to resolve and no correlation search to write: an intruder crossed from IT into the plant, learned enough to pick a target, and attempted a process change. And the attempt landed on a device that controls nothing, which means you are reading this with the line still running.
The read would have been enough. The write tells you what they came for.
Compliance hooks
Three are worth naming precisely, because in OT the audit conversation often decides the budget.
IEC 62443 zones and conduits. The standard's risk assessment work partitions the environment into zones with defined conduits between them. A deceptive asset inside a zone is a test of that partition that runs continuously: if something in Zone B touches a decoy in Zone C, a conduit is not enforcing what the drawing says it enforces. It also answers the question an auditor actually asks, which is not "is the segmentation designed correctly" but "how would you know if it failed." The segmentation itself remains the control; the decoy is how you find out it has been bypassed.
NIS2 Article 23. For in-scope entities the reporting clock is three-staged: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. Read that as a detection-latency requirement, because that is what it is. An organization that learns about an intrusion in week six has already missed two deadlines, and no amount of reporting process recovers them. The technical controls in the 62443 series map onto the NIS2 risk-management measures reasonably well; the timing obligations have no equivalent in the standards and have to be met by detecting sooner.
CISA's own exposure-reduction guidance. The published advice for the water sector ends with continuous monitoring for anomalous activity, which is straightforward to agree with and hard to implement on devices that cannot be monitored. A decoy is one of the few ways to satisfy it without instrumenting the controllers.
Next to the OT tooling you already have
Deception is an additional source. The boundaries are what make it worth buying.
Passive OT network monitoring is better than deception at the things deception does not attempt. It inventories every device rather than the handful you planted, it baselines real protocol behavior, and it sees the production traffic a decoy never will. If you have to choose one and you do not know what is on your network, build the inventory first. Deception's complement to it is specificity: passive monitoring tells you a flow is unusual, and unusual in a plant is often a maintenance crew.
Firewalls, diodes, and segmentation are preventive, and nothing here substitutes for them. Removing the internet-exposed PLC is still the highest-value action available to most plants, and it is the one CISA leads with. Deception is for the intrusion that gets past the design.
EDR applies where it can be installed, which in practice means Level 3 and some Level 2 Windows hosts. It is better than deception on any of those machines and blind everywhere below them.
SIEM is where this lands. Deception adds a low-volume, high-confidence source, which makes it one of the few OT inputs where automated escalation is defensible.
The honest limits. A decoy nobody touches detects nothing, so placement is the whole product and a bad placement is worse than none because it builds false confidence. Your own tooling will reach decoys: active discovery scanners, inventory tools, and third-party assessments all probe segments broadly, so write down the expected benign triggers and who owns them before an analyst meets one at 3 AM. An attacker with physical access who plugs into a cell and touches exactly one real controller may trip nothing. A decoy that is never updated becomes fingerprintable as the installed base around it moves on. And deception detects; it does not stop a program download already in flight, which is why the preventive controls above stay where they are.
Where to start
The cheapest honest test does not involve a controller. Put one decoy host in the OT DMZ, plant a credential for it on a single engineering workstation, and leave both alone for a month. You will learn three things: whether anything in your environment touches them, whether the alert reaches a person, and who that person turns out to be. If the answer to the last one is nobody, that is the finding, and it is worth more than a product evaluation.
Decoy Management provisions, blends, and retires those assets from one control plane across IT, OT, IoT, and cloud, with coverage planned against MITRE ATT&CK so placement follows the techniques your plant is actually exposed to. For the movement between the hosts that bracket the boundary, see lateral movement detection; for the identity side of that crossing, Active Directory and identity attacks; and for the IT-origin case that stops a line without touching a controller, ransomware early detection. For why federal guidance now lists decoys as baseline rather than advanced, see what the CISA decoy guidance says.