PLC to cloud connectivity is now a routine requirement: maintenance wants remote condition data, management wants OEE across sites, and data teams want clean time series for analytics. This guide compares the three architectures that actually work in plants, native PLC MQTT, edge gateways and SCADA-based forwarding, and walks through the security and reliability decisions behind each. You will leave with a checklist to choose a design for your own site.
Why MQTT Is the Usual Bridge
PLCs speak field protocols designed for deterministic, local communication: PROFINET, EtherNet/IP, Modbus, S7 communication, ADS. None of these were designed to cross the internet. Cloud applications, on the other hand, want event streams over encrypted, authenticated connections that traverse firewalls.
MQTT fits in between because of three properties:
- Outbound connections only. The plant side opens a TLS connection to the broker. Nothing in the cloud needs to reach into the plant, so no inbound firewall ports are opened.
- Publish/subscribe decoupling. The PLC side publishes once; dashboards, historians, analytics and alerting subscribe independently. Adding a consumer does not touch the plant.
- Lightweight and tolerant of poor links. Small headers, keep alive, QoS levels, retained messages and persistent sessions handle cellular or congested WAN links well.
If the broker concept is new to you, start with what an MQTT broker does before choosing an architecture.
Architecture 1: Native MQTT in the PLC
The controller itself runs an MQTT client and connects to the broker. Siemens offers a library for S7-1200 and S7-1500, CODESYS has an MQTT client library, and Beckhoff TwinCAT has IoT functions; walkthroughs are in the Siemens S7 MQTT tutorial and its siblings.
Strengths: no extra hardware, minimal latency, payloads defined by the person who knows the process best.
Weaknesses: network and certificate code now lives in the control program, every change means a PLC download, store-and-forward is limited by controller memory, and the PLC must have a route to the internet or to a DMZ broker, which many security teams resist.
Fits when: a machine builder ships connected machines, or a handful of controllers need a few dozen signals and adding hardware is impractical.
Architecture 2: Edge Gateway
A gateway on the controls network reads PLCs using their native protocols and publishes MQTT upstream. It can be an industrial PC with a commercial connectivity server, a container on an edge platform, Node-RED, or a short Python service. The IIoT edge gateway guide covers hardware and software choices in depth.
Strengths: PLC programs stay untouched, one gateway serves many controllers and brands, disk-backed buffering survives WAN outages, and payload formatting, deadbands and Sparkplug B encoding happen in a place where software tools are good.
Weaknesses: one more device to patch, monitor and back up; the gateway becomes a critical node; and native protocol reads must be enabled on the PLCs, which sometimes weakens controller-side protections such as disabled PUT/GET.
Fits when: you are connecting a line, a plant or a mixed fleet. This is the default choice for most brownfield sites.
Architecture 3: SCADA-Based Forwarding
The existing SCADA or HMI server already polls every PLC. An MQTT module or script on that server forwards selected tags to the broker, often as Sparkplug B. Ignition is a common example; see Ignition with MQTT.
Strengths: reuses the existing tag database, alarm configuration and naming; no new PLC connections; one place to manage what leaves the plant.
Weaknesses: cloud data now depends on SCADA availability and licensing; SCADA tag names may not match the enterprise naming standard; and the SCADA server, typically a high-value OT asset, now has an outbound internet path.
Fits when: SCADA already covers the assets you care about and its team owns the integration.
PLC to Cloud Architectures Side by Side
| Criterion | Native PLC MQTT | Edge gateway | SCADA forwarding |
|---|---|---|---|
| Extra hardware | None | Gateway per site or line | None |
| PLC program changes | Yes | No | No |
| Multi-vendor PLCs | One implementation per vendor | Yes, via drivers | Yes, if SCADA supports them |
| Store-and-forward | Limited | Strong (disk buffer) | Depends on module |
| Payload flexibility | Limited by PLC string handling | High | Medium to high |
| Change management | PLC download | Gateway config deploy | SCADA project change |
| Dependency risk | Each PLC's network path | Gateway availability | SCADA availability |
| Typical owner | Controls engineer | OT or IT/OT team | SCADA team |
Many plants end up mixing them: machine builders deliver natively connected equipment, legacy lines go through gateways, and SCADA forwards its alarm and production summaries.
Security Patterns for PLC to Cloud
Security is where these projects succeed or stall. The patterns below apply regardless of architecture.
- Outbound only. Plant devices initiate TLS connections to the broker. No inbound port forwarding, no VPN into controller networks for data collection.
- Segment by level. Keep PLCs in the control zone. Place gateways at the boundary or in an industrial DMZ, and allow only the gateway to reach the broker. The MQTT DMZ pattern explains broker placement between OT and IT.
- TLS everywhere outside the cell. Use port 8883 with certificate validation; never disable verification to make a connection work.
- One identity per publisher. Each PLC or gateway gets its own username, password and client ID, so one compromised device can be revoked without touching others.
- Read-only by default. Treat cloud-to-PLC writes as a separate project with allow-lists, range checks, PLC-side interlocks and an audit trail.
- Keep secrets out of projects. Do not commit broker passwords into PLC projects or gateway repositories shared across teams.
- Watch for abuse. Use a broker that rate-limits floods and blocks repeated failed logins, and alert when an expected publisher disappears.
ConnectMQ, for example, applies per-plan quotas, flood protection and IP blocking after repeated failed logins on every broker, so these protections do not depend on each plant getting its own configuration right.
Reliability and Data Quality
A connection that works in a demo is not the same as one that delivers trustworthy data for years. Check these before go-live:
- Report by exception with heartbeats. Publish on meaningful change, plus a periodic refresh, so idle values are distinguishable from dead links.
- Last Will and retained status. A retained
onlineorofflinestate per publisher lets every consumer know what is current. - Timestamps at the source. Stamp values where they are read, not where they are received, and keep clocks synchronized with NTP.
- Buffering. Decide what happens during a WAN outage: drop, buffer in memory, or buffer on disk and replay in order.
- Naming. Agree on an ISA-95 based topic hierarchy before the second site connects. Renaming later is expensive.
Testing the Network Path
Before building anything, prove that the plant network can reach a broker over TLS. From a machine in the zone where your publisher will run:
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i plant-path-test-9x2c -t 'connectmq/demo/9x2c/path-test' -m 'hello from the plant'
If this fails with a timeout, the firewall blocks outbound 8883. If it fails during the handshake, a TLS-inspecting proxy may be replacing certificates, which is a conversation to have with the network team early. The public test broker is shared and readable by anyone, so send only test strings.
Where the Broker Should Live
Your options are an on-premises broker, a broker you run yourself in the cloud, or a hosted MQTT broker. On-premises brokers are useful for local consumers and DMZ designs; for enterprise-wide data, a cloud broker reachable from every site is simpler. ConnectMQ offers this as a managed service with MQTT 3.1.1 and 5.0, TLS on 8883, and options from shared Serverless plans to Dedicated clusters and BYOC deployments in your own cloud account. The portal's devices view understands ISA-95 topics and Sparkplug B, so data from native PLC clients, gateways and SCADA lands in one browsable hierarchy.
Decision Checklist
- How many PLCs, from how many vendors, are in scope this year?
- Can PLC programs be changed and downloaded, and who approves it?
- Does SCADA already poll the assets you need?
- What is the required data latency: seconds, minutes or hours?
- What happens to data during a WAN outage, and for how long?
- Which zone may initiate outbound connections, and on which ports?
- Who will own gateway patching, certificates and monitoring?
- Is any cloud-to-PLC write path required, and has it been risk-assessed?
If the answers point to many vendors, no PLC changes and long outages, start with an edge gateway. For the end-to-end architecture, continue with the industrial IoT with MQTT guide.
Start Your PLC to Cloud Project with ConnectMQ
Whichever architecture you choose, it needs a dependable cloud MQTT broker on the other end. Create a free Serverless broker at app.connectmq.com, no credit card required, and connect your first PLC or gateway over TLS today.
Frequently Asked Questions
What is the most secure way to connect a PLC to the cloud?
Keep the PLC in its control zone, let a gateway or DMZ broker make outbound TLS connections only, give each publisher its own credentials, and keep the data path read-only.
Do I need an edge gateway for PLC to cloud?
Not always. Some PLCs can publish MQTT natively, but gateways are usually preferable for multi-vendor fleets, buffering during outages and keeping PLC programs unchanged.
Is OPC UA or MQTT better for PLC to cloud?
OPC UA excels at local, structured access to PLC data, while MQTT is better for distributing events to many cloud consumers. Many architectures read via OPC UA at the edge and publish via MQTT.
Should PLC data go to the cloud in real time?
Most cloud use cases need seconds to minutes, not milliseconds. Keep closed-loop control local and send report-by-exception data upstream.
