There is no cloud SCADA. Only hybrid — done well or done badly.

Every vendor pitch in 2026 wants you to believe SCADA is moving to the cloud.

They're not entirely lying. They're also not telling you the part that matters.

There is no cloud SCADA in any honest sense — only hybrid SCADA, done well or done badly. Here's how to tell which one you're being sold.

The reframe

When a vendor says "cloud SCADA," they mean one of three different things — and they're counting on you not noticing the difference.

1. The control loop runs in the cloud. False — physically impossible at any latency or availability bar a real plant requires.
2. The HMI runtime runs in the cloud. Rarely true — technically possible, operationally fragile the day the WAN drops.
3. The supervisory data layer, analytics, and dashboards run in the cloud. Commonly true — this is what most "cloud SCADA" actually is. And it's good, when scoped honestly.

The pitch deliberately blurs all three, so the buyer's mental image is "modern cloud SCADA" while the contract delivers #3 — and the buyer thinks they're getting #1 and #2 for free. That's where post-deployment disappointment lives.

The honest framing: SCADA is a stack, not a layer. Different parts of the stack have different cloud-readiness. The architecture that survives is the one that puts each part where it actually belongs.

What runs where — the 5-layer stack

L4

Cloud analytics · ML · reporting · mobile

Data lake · Snowflake / Databricks · Grafana Cloud · BI

CLOUD

L3

Cloud bridge — UNS broker · forwarder

MQTT · Sparkplug B · HiveMQ / EMQX · Kafka

HYBRID

L2

Local SCADA · HMI · historian · alarms

Ignition · FactoryTalk View · AVEVA · Power Historian / TimescaleDB

HYBRID

L1

Edge gateway — protocol translation · buffering

Ignition Edge · Kepware · Node-RED · store-and-forward

LOCAL

L0

Physical I/O · control loop · safety

PLC · DCS · SIL-rated safety systems · drives · sensors

LOCAL

Layer 0 — Physical I/O and safety. Never cloud. PLCs, DCS controllers, SIL-rated safety-instrumented systems, I/O modules, drives, sensors. The control loop closes here. Latency budget: milliseconds. Availability: 99.999%+. A chiller plant cannot stop because a cloud region had a bad afternoon. The Purdue model puts these at Level 0–1 for a reason that hasn't aged out.

If a vendor's pitch implies anything in this layer is cloud-managed, walk out.

Layer 1 — Edge gateway. Almost never cloud. Protocol translation (Modbus, OPC UA, proprietary fieldbus → MQTT, REST), local buffering, store-and-forward when the WAN drops. Think Ignition Edge, Kepware, FactoryTalk Linx, Node-RED with industrial palettes, or a custom Sparkplug B publisher. This layer can be remotely managed — config pushed from a cloud control plane is fine — but it has to run on physical hardware on the plant floor. Store-and-forward is what keeps the plant's data intact when the cloud is unreachable.

Layer 2 — Local SCADA, HMI, historian, alarms. Hybrid or local, depending on your tolerance. The screens the operator stares at. The alarm horn that wakes the on-call engineer. The historian queried while troubleshooting at 2 a.m. In principle these can be cloud-hosted; in practice they should not be — unless the site has dual independent WAN links and you have rehearsed the WAN-down failure mode. Tools: Ignition, FactoryTalk View SE, AVEVA System Platform, WinCC, with a local historian like Ignition 8.3's QuestDB-backed Power Historian, TimescaleDB, or InfluxDB. Ignition 8.3's file-based, git-controllable turn makes this layer increasingly portable across environments — but portable is not cloud.

Layer 3 — Cloud bridge: telemetry forwarder and UNS broker. Hybrid, leaning cloud. The pipe that carries operational data from the plant upward. An MQTT broker (HiveMQ, EMQX, Mosquitto), Sparkplug B for industrial semantics, Kafka in the heavier installations. This is the load-bearing layer for everything above it — and the layer most teams underspend on. Two failure modes that bite: the broker goes down and the analytics quietly run on stale data, or telemetry sized for analytics ends up carrying alarms too and the egress bill triples.

Layer 4 — Cloud analytics, ML, multi-site reporting, mobile. Absolutely cloud. Data lake, analytics warehouse, ML platforms, dashboards, mobile apps for stakeholders, regulatory reporting. On-prem analytics in 2026 is an own-goal — elasticity, ecosystem, and cost-per-query economics all favour cloud here. Even sovereign-cloud regions are good enough for most regulated workloads now.

The cleanest way to see why the stack sorts itself this way: plot each layer's tolerable latency. The spread isn't a design choice — it's physics and patience, and it spans five orders of magnitude.

LOCALHYBRIDCLOUD

Where teams get this wrong

Five failure modes that show up at month six of a poorly-scoped hybrid:

• The historian moved to the cloud and operator queries got slow. Ninety-day trends that took 800 ms now take 8 seconds. Operators stop querying. The modern stack silently becomes a write-only data lake. Fix: a local historian for hot data, cloud archive for cold, and a query router that knows which to hit.

• Alarms moved to the cloud and the WAN dropped. Either the operator gets no alarm — silent failure, the worst kind — or an alarm storm when the WAN returns. Alarm processing must run locally; alarm notification (push, escalation, on-call) can be cloud.
• Analytics stayed on-prem and the ML team can't iterate. Retraining takes three days on a box sized for 2018. The team gives up, and the AI thesis dies quietly. Fix: feature pipeline on-prem where residency demands it, training in cloud, serving wherever inference latency requires.
• The cloud bridge is a single point of failure. One broker, one VPN tunnel, one uplink. The bridge needs redundancy the same way the plant does — primary and DR broker, dual WAN, store-and-forward at every edge gateway.
• Egress cost surprised everybody. Second-by-second tags multiplied by thousands of points, shipped verbatim, generate remarkable bills. Aggregate at the edge, filter to changed values, tier the storage.

The bigger picture

The next decade of plant operations is being built on four things:

• AI copilots grounded in plant data — cloud-trained, with inference close to the plant when latency or sovereignty demands it.
• Multi-site templated deploys — one architecture, fifty plants, only possible with a cloud control plane.
• Cross-site carbon and regulatory reporting — data unification that has to live in Layer 4.
• Predictive maintenance that actually works — ML platforms scaled to the data, not the other way around.

None of these are possible on a pure on-prem stack. Most of them break a pure cloud stack. All of them work on a properly-layered hybrid.

A vendor who ships you a "cloud SCADA" pitch and doesn't show you a layered architecture diagram is selling you a product, not a system. Ask for the diagram. If they can't draw it, you have your answer.

Try it on your own stack

If you're scoping an OT modernisation programme right now and your architecture diagram is one box labelled "cloud SCADA" — pause. Hand-draw the five layers above on the back of an envelope and place each component of your current stack in the right one. Where the boxes don't fit cleanly is where the project will bleed in year two.

If you want a second pair of eyes on a hybrid architecture before you commit, tell me about it.