Connecting PLCs to the Cloud Without Opening Your Plant Network

Machine data is valuable: it feeds OEE, predictive maintenance and digital twins. But the networks that run machines were rarely designed for connectivity. Many plants have flat networks where an office laptop can reach a PLC, and remote-desktop tools installed by machine builders years ago.

Connecting those machines to the cloud carelessly can turn a productivity project into a safety and security risk. This article lays out a pattern that is both practical and safe.

Why OT security is different from IT security

In IT, the priority is usually confidentiality. In operational technology, it is availability and safety: a machine must keep running, and must not do anything unexpected. Patching a PLC is not like patching a laptop; it may require a shutdown and re-validation. That changes how you design connectivity.

The zones you need

This zoning follows the familiar layered approach used in industrial security standards such as IEC 62443. The essential idea is simple: traffic crosses between IT and OT only through a controlled middle zone.

The edge gateway pattern

• The gateway sits in the DMZ and reads tags from PLCs or SCADA using industrial protocols.
• It initiates an encrypted, outbound connection to the cloud. No inbound ports are opened.
• It buffers data during outages and forwards it in order when the link returns.
• It only reads an approved list of tags.
• Its software updates are signed and scheduled with the plant.

Read-only first

Most value — OEE, downtime analysis, condition monitoring — comes from reading data. Writing to machines (changing recipes or set points remotely) introduces safety risk and should be handled as a separate project with its own risk assessment, approvals per signal and clear fallback to local control.

Remote access for machine builders

OEMs often need remote access to support their machines. Replace always-on remote-desktop tools with a jump host or privileged access gateway in the DMZ: access is requested, approved for a time window, and recorded.

Change control on the plant network

• Survey and observe passively before changing anything.
• Plan changes in maintenance windows, with plant engineering present.
• Keep configuration backups and a tested rollback.
• Maintain an inventory of connected devices and tags.
• Review firewall rules on a schedule.

What to ask before you buy a gateway

• Which protocols does it support natively, and which need add-ons?
• How long can it buffer data during an outage, and what happens when the buffer is full?
• How are its software updates delivered, signed and scheduled?
• Can it be managed centrally without opening inbound ports?
• What happens to the plant if the gateway fails? (The answer should be: nothing.)

Tag mapping: the unglamorous work that decides success

Every PLC exposes many more values than you need, often with names that only the original programmer understood. Tag mapping — deciding which values to read, what they mean, their units and how often to read them — usually takes longer than installing the hardware.

Do it with the plant’s controls engineer, line by line. Record each tag’s meaning, unit, normal range and source. Then validate by comparing the values in the cloud with what the HMI shows on the floor. A twin or dashboard built on mis-mapped tags will lose the operators’ trust in a day.

Monitoring the connection itself

Once machine data feeds dashboards and alerts, a silent gateway becomes a problem: everything looks calm because no data is arriving. Monitor the gateway like any other critical system — heartbeat, data freshness per line, buffer usage — and alert someone when data stops flowing, not only when values cross limits.

A sensible rollout sequence

Start with one line or the plant bottleneck. Map the tags you need, install the gateway, run it read-only for a few weeks and validate the data against what operators see on the HMI. Then expand line by line. Segmentation of the wider network can run in parallel as its own project.