The network conversation for a monitoring rollout is usually shorter than people expect, once the actual shape of the traffic is on the table. A gateway needs two distinct network relationships, one to the machines it reads, one out to the internet, and keeping those separate is most of what a security-minded IT department is going to ask about. This guide covers the pattern that answers those questions cleanly: a segmented machine network, and a gateway that only ever calls out.
Two networks, not one
A gateway’s network interfaces each carry a role. One is the uplink, whichever path reaches the internet, wired, WiFi, or cellular, covered in its own detail in choosing a gateway’s uplink. The other is the plant side, the network the actual machines, PLCs, and controls sit on. On a dual-NIC gateway those two roles are enforced by the device itself: the plant-side port can never become the internet route, no matter what the machine network’s own DHCP server hands out. That’s a real protection, not a formality. A rogue or misconfigured device on the machine network handing out its own gateway address is a known way a flat network gets hijacked, and it can’t happen here, because the plant port is locked out of that role entirely.
VLANs: separate the machines from everything else, the office network included
Putting the machine network on its own VLAN, isolated from the office network and from general plant WiFi, is worth doing independent of Spall entirely. It limits what a compromised laptop or a rogue device anywhere else on the plant’s network could reach. A PLC or an older CNC control was rarely built with today’s network threats in mind. Many have no authentication on their own protocols at all, and the strongest protection available for one isn’t a patch. It’s not being reachable from anything that doesn’t need to reach it. The gateway’s plant-side port joins that VLAN the same way any other device would, reading the machines that live there without needing them exposed to anything else.
A managed switch with 802.1Q VLAN tagging is the clean way to do this: one physical switch, machine ports and office ports assigned to separate VLANs. No traffic crosses between them without going through a router configured to allow it, and by default it isn’t. Where a managed switch isn’t already in place, a separate physical switch dedicated to the machine network is a lower-tech version of the same idea, no tagging to configure, just no shared cabling between the two networks at all. Either approach reaches the same result: a machine on the plant network has no path to anything outside it except through the gateway’s own outbound connection.
Where a second gateway NIC fits when there’s no managed switch yet
A site with no managed switch and no spare budget for one can still get the same isolation using the gateway’s own second network port as the boundary. The gateway’s plant-side interface connects to a small, dedicated switch serving only the machines, and that switch has no other uplink anywhere, not to the office network, not to a second internet connection someone wired in for convenience. The gateway is the only device bridging the two networks, and its own enforced role separation is what keeps that bridge from becoming a route. This is a smaller, cheaper version of a managed-VLAN setup, and it’s a legitimate one, particularly for a single-machine pilot or a small standalone cell where running full VLAN infrastructure isn’t worth the cost yet.
The outbound-only pattern
Every connection the gateway makes to Spall’s cloud is outbound, initiated by the gateway itself, over TLS-encrypted MQTT. Nothing needs to reach in. There’s no inbound port to open on a firewall, no VPN to stand up, no public IP for the gateway to expose. A command from the cloud, a configuration push, a diagnostics request, rides the same already-open outbound connection back down. The cloud never opens a new connection into the plant network. That’s the property that makes the whole pattern acceptable to a security-conscious IT team: the plant network’s own firewall rules don’t have to change shape at all. One outbound allowance is the entire ask.
What IT asks, and the answer
“What ports need to be open inbound?” None. The gateway never listens for an inbound connection from the internet.
“What does it need outbound?” One rule: TLS-encrypted MQTT to Spall’s cloud endpoint, standard port 8883. Nothing else has to leave the plant network for monitoring to work.
“Can it see our office network or anything beyond the machines?” No, by design. The plant-side interface only ever talks to whatever’s on the machine VLAN it’s assigned to, and it can’t become a route to anywhere else. That’s enforced on the device, not left to trust.
“What happens if the internet connection drops?” The gateway buffers locally and catches up once the connection returns, covered in detail in what happens when the internet goes down. Nothing about the machine-side reads changes during an outage.
“Does anything get written to our PLCs?” No. Every protocol driver in this series issues read requests only. A compromised or malfunctioning gateway has nothing to write back with, because the capability isn’t built in to begin with.
What goes on the machine network
Only what the gateway needs to reach: the PLCs, CNCs, meters, and other devices being read, and the gateway’s own plant-side interface. Nothing on that segment needs its own path to the internet, and general-purpose devices, laptops, phones, anything not directly part of the monitored equipment, belong on a different network entirely. A machine network that stays narrowly scoped to exactly the equipment it needs to reach is both the simplest one to secure and the simplest one to reason about six months later, when someone’s trying to remember what’s plugged into it.
An engineering laptop used occasionally to reprogram a PLC is the one case worth a specific answer, since it’s a common reason someone asks whether the machine network needs to be reachable from somewhere else after all. It doesn’t. Bring the laptop to the machine network when programming work is happening, on a spare port or a temporary WiFi bridge scoped to that VLAN alone. Don’t build the whole segment around occasional access nobody needs most days. The same rule that keeps a PLC unreachable from a compromised office machine keeps it unreachable from a laptop that isn’t currently plugged in for a reason.
Quick recap
- A gateway’s plant-side interface can never become the internet route, enforced on the device, regardless of what the machine network’s DHCP hands out
- Put the machine network on its own VLAN, isolated from the office network. It’s the right call on its own security merits, independent of monitoring
- Every connection to Spall’s cloud is outbound, TLS-encrypted MQTT, one rule, no inbound ports, no VPN
- IT’s questions have short, direct answers: nothing inbound, one outbound rule, no path to anything beyond the machine VLAN, no writes to any PLC
- Keep the machine network scoped to exactly the equipment being monitored, nothing general-purpose belongs on it