You segment an OT network so that the control side and the business or DMZ side cannot reach each other directly, and then someone installs a server with a foot in both. That server, with one network card on each network, is a dual-homed device, and it is one of the most useful and most dangerous things on the network at the same time. Used deliberately it lets a historian safely move data between zones; used carelessly it can silently join the two networks and quietly undo the firewall you spent effort building. This page explains what a dual-homed device is, its legitimate role, the bridging danger, and how to lock it down.
Dual-homed device in one line: A dual-homed device is a host with two network interfaces, each connected to a different network, so that the single device sits on both networks at once. In OT this is often intentional, for example a historian with one NIC on the DMZ and one on the control network so it can collect data from controllers and serve it up to business users without either side connecting directly to the other. The danger is that if that device is configured or compromised to forward traffic between its two interfaces, it becomes a bridge that joins the networks and defeats the firewall meant to separate them.
A device is dual-homed when it has two network interfaces, each with its own address, connected to two separate networks. The device itself is a member of both networks and can send and receive traffic on either interface, but that is not the same as connecting the two networks to each other. In its safe form, the device simply has two doors: it can be reached from network A through its A interface and from network B through its B interface, and it decides for itself what it does with what arrives at each door. The two networks remain separate; only the device straddles them.
The distinction that matters is between a host that merely has two interfaces and a host that forwards traffic between them. An ordinary dual-homed server receives on one interface, does something with the data inside its own applications, and independently sends on the other interface if and only if its software chooses to. Traffic does not pass through the machine from one network to the other; it terminates at the machine on one side and, separately, originates from the machine on the other. That is a controlled, application-level handoff, and it is the whole point of a properly built dual-homed device.
The trouble begins if the machine is instead configured to route or bridge, meaning it will take a packet that arrives on interface A destined for a device on network B and forward it straight out interface B. Now the device is no longer just a member of two networks; it is a conduit joining them, and anything on network A can reach network B through it. Whether a dual-homed device is a safe endpoint or a dangerous bridge comes down entirely to this: does it forward between its interfaces or not.
The textbook legitimate use of a dual-homed device is a data broker sitting between zones, most commonly a historian in a demilitarized zone between the control network and the business network. It puts one interface on the control side to poll or receive data from PLCs and RTUs, and another interface on the DMZ or business side to serve that collected data to dashboards and reporting tools. Because the historian is the only thing touching both sides, and because it terminates the control-side conversation in its own software and separately originates the business-side conversation, business users get their data without any device on the business network ever opening a connection to a controller. The historian is the airlock.
The danger is that this same physical arrangement, two interfaces on two networks, is exactly what an attacker or a misconfiguration needs to defeat the segmentation. If IP forwarding is enabled on the host, whether left on by default, switched on by an administrator for convenience, or turned on by malware that has compromised the machine, the historian stops being an airlock and becomes an open passage between the control network and the business network. Traffic that your firewall was carefully preventing from reaching controllers can now flow straight through the dual-homed host, and it does so invisibly, because from the firewall's point of view nothing has changed; the bypass is entirely inside the server.
This is why a dual-homed device is often described as a way to accidentally build a bridge around your own firewall. All the effort of placing a firewall between two zones is wasted if a single server quietly connects the two zones behind the firewall's back. The risk is amplified by the fact that dual-homed hosts are frequently general-purpose servers running an ordinary operating system, which are far more exposed to malware and misconfiguration than a purpose-built firewall is, so the very devices most likely to end up dual-homed are also the ones most likely to be compromised into forwarding. A compromised dual-homed historian is a direct path from the business network to the control system.
The single most important control is to make absolutely sure the host does not forward between its interfaces. That means disabling IP forwarding and routing at the operating-system level so the machine can never pass a packet from one interface to the other, verifying it is off rather than assuming, and re-checking it after patches or rebuilds because defaults and updates can quietly turn it back on. With forwarding firmly off, the device reverts to being a pair of separate endpoints that happen to live in one box, which is the safe state, and each side's conversation is forced to terminate in the host's own software rather than passing through it.
Beyond that, the dual-homed host should be hardened and constrained as heavily as any device that touches the control network, because it does touch it. Host firewalls on each interface should permit only the specific applications and ports that each side legitimately needs, so even if forwarding were somehow enabled, the traffic that could cross would be tightly limited. The machine should be patched, its unnecessary services removed, its accounts locked down, and, ideally, it should run a minimal purpose-built function rather than serving as a general-purpose server that people log into for other tasks, since every extra piece of software is another way in. Many designs prefer a data-diode or a firewall-mediated handoff over a dual-homed host precisely to avoid trusting a general-purpose machine with this job at all.
The last piece is visibility, and this is where monitoring earns its place. A dual-homed host quietly beginning to forward traffic is exactly the kind of change that produces no obvious symptom until it is exploited, so it helps to watch for the signs: forwarding-enabled states on the host, unexpected traffic appearing on the control side that originated on the business side, or new connections through the historian that do not match its normal pattern. A network-monitoring or cloud SCADA platform that has a picture of what should be talking to what can flag traffic crossing a boundary it was never supposed to cross, turning a silent bridge into a detectable event. In a well-run OT network the dual-homed historian is a known, watched, and locked-down component rather than a forgotten server nobody realised was sitting on both networks.
No. A dual-homed device is safe as long as it does not forward traffic between its two interfaces, and in that state it is a legitimate and common design, such as a historian collecting data on the control side and serving it on the business side. It becomes a problem only when IP forwarding or routing is enabled, whether by misconfiguration or by malware, because then it bridges the two networks and defeats the firewall meant to separate them. The security work is therefore about guaranteeing forwarding stays off and hardening the host, not about avoiding dual-homing entirely.
A firewall is a purpose-built device whose entire job is to inspect and control traffic passing between networks according to explicit rules, and it is hardened for exactly that role. A dual-homed host is a general-purpose server that happens to sit on two networks, and when it is working correctly it does not pass traffic between them at all; it terminates each side's conversation in its own applications. The risk is that a general-purpose server is far easier to compromise or misconfigure into forwarding than a firewall is, which is why a dual-homed host is never a substitute for a firewall and should sit behind one.
IP forwarding is an operating-system setting that tells a host to pass packets that arrive on one interface out through another interface toward their destination, effectively acting as a router. On a dual-homed device this is the exact switch that turns a safe two-interface endpoint into a bridge joining the two networks, so ensuring IP forwarding is disabled is the single most important control for such a host. Because patches, rebuilds, or malware can turn it back on, it should be verified as off rather than assumed, and re-checked after any change to the machine.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.