An OT honeypot is a decoy that pretends to be an industrial device, such as a PLC or a Modbus-speaking controller, in order to attract attackers and record what they do. It runs no real process and controls nothing, so it has no legitimate reason to be touched, which means any interaction with it is inherently suspicious and worth studying. Tools like Conpot are purpose-built to present a convincing fake industrial surface, speaking real control protocols so that a probe or an attacker engages with it as though it were genuine. This page explains how an OT honeypot emulates a device, what intelligence its interactions yield, and where a honeypot sits so that it is safely separate from the real control network.
OT Honeypot (Conpot) in one line: An OT honeypot is a decoy system that emulates an industrial device, such as a PLC or Modbus controller, to lure attackers and log their activity. Because it runs no real process and no legitimate system has any reason to talk to it, any interaction is inherently suspicious and becomes high-value evidence of scanning or attack. Tools like Conpot are low-interaction honeypots that present a fake industrial surface speaking real control protocols, and they sit off the actual control network so they attract attention without ever exposing a real device.
An OT honeypot works by imitating the network presence of a real control device convincingly enough that an attacker or an automated scanner engages with it. It listens on the ports a genuine device would use and speaks the industrial protocols a genuine device would speak, so that when something probes it, it responds the way a real PLC or RTU would. Conpot, a well-known open-source example, is designed to emulate industrial control systems and can present the protocols and service banners of common control devices, giving a scanner every reason to believe it has found a genuine piece of OT equipment.
Most such honeypots are described as low-interaction, meaning they emulate the surface of a device, the protocols and responses an attacker first encounters, without implementing the full depth of a real control system. This is a deliberate design choice. A low-interaction honeypot is far simpler and safer to run because it is not a real controllable system that could be turned against you, and for the purpose of detecting and studying scanning and early-stage attacks, the surface is usually enough. The attacker reveals their intent in how they probe and what they try, long before they would need the device to actually do anything.
The realism can be tuned to the goal. A honeypot meant simply to detect scanning needs only enough fidelity to be identified as an industrial device and logged when touched, while one meant to study attacker techniques in depth benefits from a more convincing emulation that keeps an intruder engaged longer and elicits more of their toolkit. Conpot and similar tools let operators shape the fake device presented, so the decoy can be made to resemble the kind of equipment an organization actually runs, making it a plausible target rather than an obvious trap.
The value of a honeypot comes entirely from its logging, because everything that touches it is worth recording. Since no legitimate system has any reason to communicate with a device that runs no process, every connection, every probe, and every command sent to the honeypot is by definition unexpected and therefore interesting. The honeypot captures the source of the interaction, what protocol and what commands were attempted, and the sequence of what the intruder did, turning each contact into a clean, unambiguous record of hostile or at least unauthorized behavior.
That record yields several kinds of intelligence. At the simplest level it is an early-warning tripwire: a hit on the honeypot means someone or something is scanning for or attacking industrial devices in reach of it, which is a signal you may get nowhere else. More deeply, the captured interactions reveal what attackers are looking for and how they behave against control systems, which protocols they probe, which commands they try, and what techniques they use, providing insight into the threats actually facing that kind of environment rather than threats in the abstract.
This intelligence is uniquely high-fidelity because the honeypot generates almost no false positives. In a normal monitoring system a suspicious event might be benign, and much effort goes into telling real threats from noise. A honeypot inverts that: because it should never be touched at all, a touch is essentially never benign, so its alerts carry a confidence that behavioral or signature detection on production traffic can rarely match. Every interaction is a genuine signal, which makes the honeypot a source of clean evidence rather than another stream of ambiguous alerts.
The cardinal rule of an OT honeypot is that it must never be able to affect the real process, which shapes where it is placed. The honeypot is a decoy with no connection to actual control functions, deployed on a network segment isolated from the genuine control system, so that even if an attacker fully compromises it, they gain nothing but a fake device and a network position that leads nowhere useful. It attracts attention deliberately, so it must be positioned where that attention cannot spill onto anything that matters.
Placement also determines what the honeypot can catch. Positioned where an attacker who has breached a boundary would naturally look, it can catch reconnaissance and lateral movement inside a compromised environment, acting as a tripwire in the space an intruder would explore. The idea is to put the decoy in the intruder's path without putting it in the process's path, so it sees the attacker's early moves while remaining walled off from the equipment that runs the plant. Careful segmentation is what makes it possible to be alluring to an attacker and harmless to operations at the same time.
As a source of clean alerts, an OT honeypot complements a broader monitoring strategy rather than replacing it. Its high-confidence hits feed naturally into centralized security monitoring, and a cloud SCADA or security platform such as Merobix that gathers events across many sites can treat a honeypot interaction at any site as a strong, low-noise indicator that warrants immediate attention, correlating it with other signals to understand the wider picture. The honeypot's job is narrow but valuable: to sit safely apart from the real control network, draw out behavior that would otherwise stay hidden, and hand the monitoring layer a piece of evidence it can trust almost without question.
Because nothing legitimate should ever touch it. A honeypot runs no real process and no production system has any reason to communicate with it, so every connection, probe, or command it receives is by definition unexpected and unauthorized. That inverts the usual monitoring problem of separating real threats from benign noise, since a honeypot touch is essentially never benign, giving its alerts a confidence that detection on live production traffic rarely matches.
It means the honeypot emulates the surface of an industrial device, the protocols, banners, and responses an attacker first encounters, without implementing the full depth of a real control system. This is deliberate: a low-interaction honeypot is simpler and safer to run because it is not a genuinely controllable system that could be turned against you, and for detecting scanning and studying early-stage attacks the surface is usually enough, since attackers reveal their intent in how they probe long before they would need the device to actually do anything.
On a network segment isolated from the real control system, with no connection to any actual control function, so that even a fully compromised honeypot gives an attacker nothing but a fake device and a dead-end position. It should sit where an intruder who has breached a boundary would naturally look, so it acts as a tripwire in the space they explore, while careful segmentation keeps it out of the path of the equipment that runs the plant. The goal is to be alluring to an attacker and harmless to operations at once.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.