OT/IoT Cybersecurity on the Factory Floor: The Blind Spots That Get Missed

Once a plant starts connecting machines and sensors to a cloud monitoring platform, one question rarely asked at the start of the project always surfaces sooner or later: does this make our production network more vulnerable? The honest answer is — it can, if the architecture isn't designed properly. But that risk is manageable, and deliberately managing it is far safer than an OT network that has only ever been "secure" by coincidental isolation.

OT networks were never built assuming internet connectivity

Most PLCs, HMIs, and power meters on a factory floor were designed decades ago assuming the OT (Operational Technology) network was fully isolated from the outside world. Their protocols — Modbus RTU, and plenty of older Modbus TCP variants — were designed for communication reliability, not authentication or encryption. When these devices suddenly get a path to the internet for remote monitoring, three classic risks appear:

• OT and IT networks mixed without segmentation. The same switch serving office PCs and production PLCs means an IT-side incident — malware, ransomware — has a direct path to production devices.
• Legacy devices exposed as-is. Modbus and similar protocols have no built-in authentication; anyone who reaches the network can read or write registers unimpeded.
• Unmonitored new entry points. A gateway or IoT device installed hastily without a clear security policy becomes a gap that never gets audited.

This isn't a reason to avoid connectivity — the benefit of remote monitoring is too large to give up. It's a reason to design the path correctly from the start.

Core principle: the gateway as the only way out

The correct approach isn't connecting every OT device straight to the internet, but making the gateway the single controlled exit point from the OT network outward:

• OT devices stay on a closed network. PLCs, power meters, and sensors keep communicating over Modbus RTU/TCP only within the plant's local network — never connected directly to the internet.
• The gateway bridges, it doesn't forward raw traffic. IncludeGateways reads data from the OT side and sends it to the platform over an encrypted outbound connection — communication direction stays from gateway to cloud, not the cloud opening a path into the plant network.
• One point to monitor and audit. With one gateway per network segment acting as the gate, the IT team only has to secure and watch that one point, not dozens of legacy devices that can't be patched.

Network segmentation: the cheapest and most important separation

Before talking about encryption or advanced firewalls, the most fundamental and cheapest step is segmentation — separating the OT network from the office IT network, physically or logically (VLAN):

• Separate the production VLAN from the office VLAN. A security incident on an employee laptop should never have a direct network path to a production line's PLC.
• Limit communication to what's necessary. A gateway only needs access to the OT devices relevant to it — explicit firewall rules are safer than a flat network with no boundaries.
• Treat every gateway as a trust boundary. Each gateway's credentials and access should ideally be unique per site, so a compromise at one point doesn't automatically open every other site.

This kind of segmentation sounds simple, but in practice it's the single control that prevents the most incidents from spreading from one device to an entire plant.

What's different on the platform side

Security doesn't stop at the local network — data that has already reached the platform also needs equivalent protection:

• Encryption in transit. Data from the gateway to the INCLUDE Smart Industry platform travels over an encrypted connection, not a plaintext protocol that can be intercepted on a public or cellular network.
• Role-based access control. Operators, supervisors, and admins see and change data according to their role — not full access for every account, which magnifies the impact if a single account is compromised.
• A recorded audit trail. Configuration or alarm-threshold changes are logged with who made them and when, so an incident — intentional or not — can be traced.

The most common findings when IoT projects get audited

When a security team reviews an IoT monitoring project that has run for a few years, the most common findings aren't sophisticated attacks — they're basic oversights:

• Default credentials never changed on a gateway or network device installed years ago.
• Device management ports left open to the internet for the sake of easy remote access, with no VPN or IP restriction.
• No clear device inventory — the team doesn't actually know how many OT access points are connected outward.
• Gateway firmware never updated since initial install, even when security patches are available.

None of these four are exotic technology problems — they're all basic governance issues that can be fixed without replacing a single device.

Starting a security review without stopping production

You don't need to overhaul the network all at once to start improving your security posture. The most practical step: first map every point connecting the OT network outward — including older gateways that may have been installed without full documentation — then prioritize segmentation on the highest-risk segments. For plants that need a full review or an OT/IT network re-integration, the INCLUDE services team — including its System Integrator practice — can help design a secure architecture from the entry point onward.

The principle is simple: connectivity and security are not a trade-off. What's actually risky is connectivity installed without a deliberate network architecture.