The fear is legitimate — and addressable
Operational technology was historically "secure" by being isolated — air-gapped, proprietary, disconnected. Connecting it for visibility understandably raises the worry that you're creating a path for an attacker to reach the equipment that runs your plant. That worry is healthy. But the answer isn't to stay blind; it's to connect in a way that exposes data without exposing control. The security risk comes from doing it carelessly — putting a PLC on the public internet, or wiring an IoT box straight into the control network with write access — not from monitoring itself.
The core principle: get the data out, never let control in. A monitoring connection should be read-only and outbound-only — the edge device reads the machine and pushes data to the platform; nothing reaches back to the PLC.
How to connect securely
- Read-only at the edge. The edge device reads data from PLCs and sensors without write access, so even if it were compromised it couldn't change a setpoint or stop a pump.
- Never expose PLC ports. Controllers stay on a protected OT network. The edge device initiates an outbound connection to the platform; nothing untrusted initiates a connection in to the PLC.
- Segment the network. Put IoT/edge devices in their own segment with a firewall between OT and IT — defence in depth, so a problem in one zone doesn't reach the control layer.
- Encrypt and authenticate. Encrypted transport and authenticated, outbound-only connections from edge to platform; no plaintext, no anonymous access.
- Role-based access & audit log. Named users with least-privilege roles, and a full audit trail of who viewed or changed what.
- Own your data and your patch path. Keep data ownership (in-region cloud or on-prem) and a clear process for updating and patching edge devices over their life.
The security protocols that do the work
"Encrypt and authenticate" isn't hand-waving — it rests on specific, well-proven security protocols. The ones that matter on an industrial IoT deployment:
- TLS (Transport Layer Security) — the standard that encrypts and authenticates data in transit from the edge gateway to the platform, and secures the dashboard in your browser (HTTPS). MQTT and REST both run over TLS.
- OPC-UA security — the OPC-UA protocol carries its own signing and encryption with certificate-based authentication, so machine-to-machine data is protected end to end.
- AES-128 on the radio — LoRaWAN and similar low-power networks encrypt payloads with AES-128 using separate network and application session keys, so readings can't be intercepted or spoofed over the air.
- VPN / mutual TLS for remote access — any remote support tunnels over an authenticated VPN or mutual-TLS channel, never an open inbound port.
The point isn't the acronyms; it's that a credible IoT solution uses modern, audited security protocols at every layer — radio, transport and application — rather than shipping data in the clear. Ask a vendor which protocols secure each hop; a vague answer is a red flag.
Why connected can be more secure
Done right, monitoring improves your security posture rather than degrading it. Continuous visibility means you notice anomalies — unexpected access, abnormal device behaviour — that an isolated, unmonitored plant would miss entirely. Centralised, role-based access with an audit log is more controllable than a dozen engineers sharing a SCADA password. And edge buffering means a network problem degrades gracefully (data queues locally) rather than failing open. "Air-gapped" often really means "unmonitored and unpatched" — which isn't as secure as it sounds.