RIoTPot is an open-source hybrid-interaction honeypot designed primarily for Internet of Things (IoT) and operational technology (OT) protocols. It is not a consumer security appliance that you install to automatically protect every smart device on your network.
An expert take by Ethan Cross, HakTechs.com Lead Analyst
Its job is deception and observation. RIoTPot can expose services that look like real networked systems, accept connections to those services, and route the traffic toward lightweight emulators or more complete service implementations. The original RIoTPot research describes this ability to mix interaction levels as a central part of the design.
So the useful question is not simply, “Does RIoTPot support IoT?” A better starting point is: which service do you need to emulate, how realistic does its behavior need to be, and how will you safely isolate the infrastructure behind it?
This guide explains RIoTPot’s architecture, interaction model, currently documented services, deployment options, and the limitations worth understanding before using it in a cybersecurity lab.
What Is RIoTPot?
RIoTPot is a honeypot project built around resilient IoT and operational-technology deception. It is maintained under The Honeynet Project’s GitHub organization and was introduced in academic research as a modular hybrid-interaction IoT/OT honeypot.
The current repository describes RIoTPot as a proxy-oriented system. Instead of forcing every simulated service to run inside one large application, RIoTPot can sit in front of internal, nearby, or external services and forward traffic to them according to its configuration.
That makes RIoTPot easier to understand as a honeypot framework and traffic-routing layer rather than as one simulated industrial device.
A deployment can combine:
- low-interaction service plugins,
- separate service implementations,
- containerized services,
- other honeypots,
- routing rules and proxies, and
- a web interface and REST API for management.
The current repository also says the main RIoTPot application is written primarily in Go, while the web interface uses React and TypeScript.
What Problem Does an IoT/OT Honeypot Solve?
Many IoT and OT systems expose recognizable network services. During an initial scan, an attacker may not know whether a responding endpoint is a real PLC, broker, embedded device, web service, or a deliberately constructed decoy. The first thing they see is the service itself and how it responds.
A honeypot creates a controlled place for that interaction to happen.
Instead of allowing suspicious traffic to reach production industrial equipment, a researcher can expose a service designed specifically to collect information about connection attempts, probes, and attack behavior.
RIoTPot’s original research focused on this problem in IoT and industrial-control-system environments. The authors also discussed a familiar honeypot tradeoff: lightweight emulation needs fewer resources, but shallow or predictable responses may make the honeypot easier to fingerprint.
That tradeoff helps explain why RIoTPot’s interaction model is more important than simply counting supported protocols.
A honeypot can help you observe hostile activity. It does not replace a firewall, endpoint-protection platform, intrusion-prevention system, network segmentation, or a broader OT security architecture.
How RIoTPot Works
RIoTPot Core
The RIoTPot core coordinates the exposed proxies and the services sitting behind them.
In the current project architecture, a RIoTPot instance exposes configured proxy ports and connects those proxies to selected services. When a client reaches one of those ports, RIoTPot relays traffic between the client and the service assigned to that proxy.
This separation is useful because the system visible to the connecting client does not have to be the same system that actually implements the protocol behavior.
Protocol and Service Plugins
RIoTPot includes low-interaction services implemented as plugins. These let you emulate certain services without running a full implementation for every exposed port.
The current repository README lists these default low-interaction services:
| Service | Typical Exposed Port | Role in RIoTPot |
|---|---|---|
| Echo | 7 | Low-interaction service |
| SSH | 22 | Low-interaction service |
| Telnet | 23 | Low-interaction service |
| HTTP | 80 | Low-interaction service |
| Modbus | 502 | OT/industrial protocol emulation |
| MQTT | 1883 | IoT messaging service emulation |
| CoAP | 5683 | IoT-oriented protocol emulation |
Do not treat this table as a permanent protocol guarantee. RIoTPot can change as the repository evolves. Check the current plugin and service documentation before building a deployment around a specific protocol.
Containerized and Adjacent Services
The architecture becomes more flexible when traffic is sent beyond RIoTPot’s lightweight local emulators.
Its proxies can connect to surrounding services such as fuller protocol implementations, containers, other honeypots, or reachable hosts. This gives RIoTPot a way to support higher-interaction behavior without putting every protocol implementation inside the core application.
The repository’s Docker example currently includes MQTT, HTTP, Modbus, and OCPP services, along with packet capture through tcpdump.
A fuller service can respond with richer behavior than a minimal emulator, which may be useful when simple responses are not enough for the research goal. The tradeoff is more infrastructure to secure, isolate, monitor, and maintain.
Routing, API and Web Interface
The proxy layer connects these pieces.
RIoTPot can register proxies, associate them with services, and relay incoming traffic toward the selected destination. The repository also documents a REST API and web interface for managing RIoTPot instances, proxies, and profiles.
Profiles provide a useful way to think about a deployment. Instead of configuring every port as an unrelated service, several services can be grouped so the instance more closely represents a particular kind of networked system.
One security warning in the project documentation is easy to overlook: the management API should not be exposed directly to the Internet.
Low, High and Hybrid Interaction Explained
The easiest way to understand RIoTPot is to separate interaction depth from protocol support.
Low Interaction
A low-interaction honeypot reproduces only enough of a service to accept and respond to certain traffic. It does not try to recreate the complete target system.
This approach generally requires fewer resources and can be easier to isolate because less functionality is exposed.
The tradeoff is realism. Limited protocol behavior can reveal that a service is being emulated, especially when someone performs deeper fingerprinting instead of a simple port scan.
High Interaction
A high-interaction approach gives the connecting system more functionality to explore.
In the original RIoTPot research, containerized services were used to provide fuller protocol implementations. Traffic could be forwarded to these services rather than being handled only by a lightweight local emulator.
That can produce richer observations, but it also increases the amount of functionality exposed to hostile traffic. Isolation, outbound restrictions, monitoring, and recovery become more important as interaction depth increases.
Hybrid Interaction
Hybrid interaction is what separates RIoTPot from a simple collection of protocol emulators.
You do not have to use the same interaction level for every exposed service. One service can use lightweight emulation, while another can send traffic to a fuller implementation when deeper behavior is useful.
That lets the deployment follow the research question. You can spend more resources on the services where realism matters and keep other parts of the environment simpler.
IoT and OT Protocol Emulation
The phrase “IoT/OT honeypot” covers a very broad area, so the actual protocol support matters.
IoT and operational technology include many different device types and protocols. Support for one industrial protocol does not mean a honeypot can accurately reproduce every PLC, gateway, building-control system, charging station, or embedded device.
RIoTPot’s currently documented built-in service list includes common Internet services along with MQTT and CoAP for IoT-oriented use and Modbus for industrial environments. Its Docker documentation also shows OCPP as an example of a surrounding service.
Before building a deployment, answer a few practical questions:
- Is the protocol you need currently supported?
- Is it handled by a low-interaction plugin or by a separate service?
- Does the implementation reproduce the behavior that matters for your research?
- Does the device profile you are simulating need several services at once?
- Can you isolate the resulting environment safely?
A protocol name by itself does not prove that a honeypot will convincingly resemble a specific device.
Where RIoTPot Fits in a Security Lab
RIoTPot fits best in environments where the goal is controlled observation rather than automatic protection.
Possible lab uses include:
- studying unsolicited Internet traffic aimed at IoT or OT services,
- comparing low- and higher-interaction deployments,
- experimenting with honeypot fingerprinting resistance,
- observing scanning and probing behavior,
- building repeatable cybersecurity research environments,
- testing combinations of lightweight emulation and fuller service implementations, and
- collecting network traffic for later analysis.
The original researchers exposed RIoTPot to Internet traffic and later extended the evaluation into a longer study comparing different interaction models across cloud and self-hosted infrastructure.
That background gives a good sense of the intended audience. RIoTPot is much closer to a research and lab platform for security practitioners, students, and technically experienced users than to a one-click smart-home security product.
What You Need Before Deploying RIoTPot
The setup depends on how you plan to run it.
If you are building RIoTPot from source, the current README lists Go as required for building the main application and Node for building the UI. Git and Make are listed as useful optional tools.
For the project’s containerized deployment approach, the documentation calls for Docker and Docker Compose.
The operating-system requirements need a closer look. The current documentation describes the base application as interoperable, but the internal plugin mechanism has platform restrictions. The README’s main introduction describes the bundled low-interaction plugins as Linux-oriented, while a technical footnote also refers to plugin compatibility with Linux, FreeBSD, and macOS.
Those statements are not identical, so Linux is the safer platform to plan around if the built-in low-interaction plugins are important to your setup. Check the current repository before installation rather than relying on an older guide.
The same caution applies to Docker instructions. Tutorials from earlier stages of RIoTPot’s development may refer to different branches, configuration formats, or orchestration steps than the current project.
Important Limitations and Security Considerations
A honeypot is intentionally placed where it can receive traffic you would normally try to keep away from important systems. That makes isolation part of the deployment, not an optional extra.
Do not expose the environment casually. Keep management interfaces separate, restrict outbound connectivity, isolate adjacent services, protect collected logs, and assume that any sufficiently interactive component may eventually receive hostile input.
RIoTPot’s documentation says unsolicited outbound requests, including reverse-shell behavior, are restricted for security and ethical reasons. Its Docker guidance also describes isolated virtual and overlay networks for separating services.
Other limitations are worth keeping in view:
- A honeypot is not a prevention system. It does not replace segmentation, authentication, patching, monitoring, or other defensive controls.
- Emulation is not physical hardware. Timing, responses, and implementation behavior can differ from genuine equipment.
- Virtualized environments can leave fingerprints. RIoTPot’s documentation notes that timing differences may theoretically help identify a honeypot.
- Protocol coverage is limited. “IoT/OT” does not mean every industrial or embedded protocol is supported.
- Older documentation may no longer match the current project. Check the repository before following historical installation instructions.
Who RIoTPot Is Best Suited For
RIoTPot is most useful for people who already understand what it means to deliberately expose a research or deception system to suspicious traffic.
That includes:
- cybersecurity researchers,
- OT and ICS security students,
- honeypot developers,
- security teams building controlled deception labs,
- researchers comparing interaction models, and
- advanced homelab users studying IoT/OT network behavior.
It is a poor match for someone whose goal is simply to “secure my smart-home devices.” That calls for conventional defensive controls, not a research honeypot.
RIoTPot vs a Conventional Security Product
| Area | RIoTPot | Conventional Security Control |
|---|---|---|
| Primary purpose | Deception, observation and research | Protection, detection, prevention or policy enforcement |
| Typical behavior | Exposes deliberately emulated services | Monitors or protects legitimate systems |
| Success depends on | Realistic services, routing and safe isolation | Coverage, detection logic, configuration and enforcement |
| Expected users | Researchers and technically experienced operators | Consumers, administrators or enterprise security teams depending on product |
The difference is straightforward: RIoTPot gives suspicious traffic a controlled target to interact with. Conventional security products are generally trying to detect, block, monitor, or contain that traffic around real systems.
The two approaches can be used together, but one does not replace the other.
Frequently Asked Questions
What is RIoTPot?
RIoTPot is an open-source hybrid-interaction honeypot focused primarily on IoT and operational-technology protocols. It can expose proxy endpoints and route incoming traffic to low-interaction plugins or other surrounding services.
What is an IoT/OT honeypot?
An IoT/OT honeypot is a deliberately constructed system that imitates network services associated with IoT or operational-technology environments. Its purpose is to give suspicious traffic a controlled system to interact with instead of using real production equipment as the target.
How does RIoTPot’s hybrid-interaction model work?
Different services can use different interaction depths. One proxy might use a lightweight local emulator, while another forwards traffic to a fuller service implementation.
Which IoT and OT protocols can RIoTPot emulate?
The current GitHub README lists default low-interaction services for Echo, SSH, Telnet, HTTP, Modbus, MQTT, and CoAP. Its documented Docker example also includes OCPP as a surrounding containerized service. Check the current repository before assuming a protocol is still available or implemented in the same way.
What is the difference between low- and high-interaction honeypots?
Low-interaction honeypots reproduce a limited amount of service behavior and are usually lighter to operate. High-interaction environments expose more complete functionality, which can produce richer observations but also requires tighter isolation and more operational control.
Does RIoTPot require Linux or Docker?
Docker is not the only documented way to run RIoTPot, but the project uses it for its containerized deployment approach. The built-in plugin system has operating-system restrictions, so Linux is the most sensible platform to investigate first if those low-interaction plugins are required. Check the current repository before deployment.
Is RIoTPot intended for production OT environments?
RIoTPot should not automatically be treated as a production OT security control. Whether it belongs in a particular environment depends on isolation, protocol requirements, architecture, organizational risk tolerance, and the purpose of the honeypot. A controlled lab is the more natural place to start.
How is RIoTPot different from a normal network-security product?
RIoTPot deliberately exposes services for observation and deception. Firewalls, IDS/IPS platforms, endpoint controls, and other network-security products are designed primarily to protect legitimate systems or enforce security policy around them.
Final Verdict
The main reason to look at RIoTPot is its architecture, not simply the fact that it targets IoT and OT protocols.
Its proxy-based design gives researchers room to mix lightweight emulated services with fuller surrounding implementations. You can keep some services simple while giving others more realistic behavior when the research calls for it.
That flexibility is useful for security researchers, OT-security students, honeypot developers, and experienced lab users who want control over interaction depth. Someone looking for a plug-and-play tool that automatically protects smart-home devices is looking at the wrong kind of software.
Start with the protocol and the research objective. Work out what needs to be emulated, how much interaction is necessary, whether the current repository supports the required services, and how the environment will be isolated before you expose it.
For installation and configuration, use the current RIoTPot repository as the authority rather than assuming older GSoC posts or historical tutorials still reflect the present project.
