A SCADA server often needs to live in two worlds at once: it must talk to the field devices on an isolated control network, and it must also feed data to the business network or a DMZ where reports and cloud connections live. A dual-NIC, or multihomed, server does this with two network interfaces - one plugged into each network - so the machine can reach both without merging them into one. Done right, it keeps the control and business planes separate while still bridging the data an operation needs. Done wrong, it becomes the accidental route an attacker uses to reach the control network. This guide explains the design, the routing and gateway rules that keep the two planes apart, NIC teaming for a redundant control path, and the bridging pitfalls to avoid.
Dual-NIC SCADA server in one line: A dual-NIC SCADA server is a multihomed machine with two network interface cards, one connected to the isolated control or device network and the other to the business network or DMZ. The design lets one server participate in both networks without joining them, but it depends on careful routing and default-gateway configuration so that traffic cannot flow through the server from the business side into the control network.
A network interface card, or NIC, is the port through which a server connects to a network. A single-NIC server sits on one network and can only reach what that network reaches. A dual-NIC server has two of these ports, each cabled to a different network, and the term for a machine with feet in more than one network is multihomed. For SCADA, the two networks are usually the control or device network, where the PLCs, RTUs, and field devices live behind an isolation boundary, and the business or DMZ network, where operators' reporting tools, historians for the enterprise, and cloud connectivity sit.
The reason to multihome a SCADA server rather than route between the networks is to keep the field-facing side isolated while still letting the server pull data from devices and push it toward the business layer. The control-side NIC speaks the industrial protocols directly to the devices on a network that is deliberately walled off from the corporate LAN and the internet. The business-side NIC carries the results outward - to reporting, to an enterprise historian, or to a cloud platform - without exposing the device network to whatever reaches the business side.
The value of this arrangement is that no direct network path exists between the two sides except through the server's own application logic. The devices never appear on the business network, and business hosts never get a route to the control devices, because there is no router joining the two subnets - only a server that happens to be reachable on both. That separation only holds, however, if the server is configured so that it does not itself become a bridge, which is where the routing rules matter.
The single most important rule for a multihomed SCADA server is that it must have only one default gateway, and it should be on the business side, not the control side. The default gateway is where a machine sends traffic destined for networks it does not have a specific route to. If a dual-NIC server were given two default gateways, its behavior for off-subnet traffic becomes ambiguous and it can start routing between the two networks in ways nobody intended. A single default gateway removes that ambiguity and defines exactly one direction for general outbound traffic.
The control-side NIC should have no default gateway at all - only a direct connection to the device subnet it serves. Because the field devices are all on the same local subnet as the control NIC, the server reaches them directly without needing a gateway, and denying that NIC a gateway ensures the server never tries to route arbitrary traffic out through the control network. Where the server must reach devices on other control subnets, explicit static routes are added for just those specific networks, so the reachability is surgical rather than a blanket route that could be abused.
Just as important is that the operating system must not forward packets between its two NICs. A server can, if configured to, act as a router and pass traffic arriving on one interface out the other, which is precisely what you do not want here - it would turn the isolation boundary into a doorway. IP forwarding between the interfaces must be disabled so the server participates in both networks but never relays traffic from one to the other. With one default gateway, no gateway on the control NIC, targeted static routes, and forwarding off, the two planes stay genuinely separate while the server does its job on both.
Dual-NIC design serves separation, but a related technique, NIC teaming, serves redundancy, and the two should not be confused. Teaming bonds two physical NICs that connect to the same network into a single logical interface, so if one cable, port, or switch fails, the other carries the traffic without the server losing connectivity. For a control path that must not go dark, teaming two NICs into a redundant link to the device network protects against a single cable or switch-port failure. The key distinction is that teaming joins two ports to one network for resilience, whereas multihoming puts one port each on two different networks for separation.
The dangerous pitfall in any dual-NIC setup is accidental bridging - inadvertently creating a network path between the control and business networks through the server. This can happen if IP forwarding is left on, if someone bridges the two interfaces at the operating-system level, if a second default gateway sneaks into the configuration, or if a broad static route is added that unintentionally exposes the control network. Any of these turns the carefully isolated device network into something reachable from the business side, undoing the entire reason for the design and handing an attacker on the corporate LAN a route toward the field devices.
Guarding against bridging is mostly discipline: one default gateway, no gateway on the control NIC, forwarding disabled, and only the narrowest static routes needed, all reviewed whenever the server's networking is touched. Many mature architectures avoid putting the control server directly on the business network at all, instead using a hardened intermediary and pushing data outward through it. Cloud SCADA fits that pattern cleanly - a platform such as Merobix receives field data through a controlled outbound path rather than requiring the control network to be reachable from outside, so the operator's browser dashboard is fed without any inbound route into the device network that a misconfigured second NIC might otherwise create.
Because two default gateways make the server's routing for off-subnet traffic ambiguous and can cause it to inadvertently route between the control and business networks. A single default gateway, placed on the business side, defines exactly one path for general outbound traffic. The control-side NIC gets no gateway, only its local subnet plus any narrow static routes needed for specific device networks, which keeps the two planes from merging.
No. A dual-NIC, multihomed server puts one interface on each of two different networks for separation. NIC teaming bonds two interfaces that connect to the same network into one logical link for redundancy, so a failed cable or switch port does not drop the connection. They solve different problems, and a server can even do both - team a pair for the control path while remaining multihomed across the control and business networks.
Accidental bridging creates an unintended network path between the isolated control network and the business network through the server, which defeats the isolation the design exists to provide. It commonly happens when IP forwarding is left enabled, the two interfaces are bridged at the OS level, or a second default gateway or overly broad route is added. The result can hand an attacker on the business network a route toward the field devices, so forwarding must stay off and routing kept minimal.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.