Cloud vs On-Premise SCADA

Cloud vs On-Premise SCADA

SCADA architecture is no longer a simple choice between “local server” and “remote access.” For modern industrial plants, utilities, and infrastructure operators, the decision between cloud and on-premise SCADA affects latency, availability, cybersecurity, lifecycle cost, regulatory compliance, and maintainability. The wrong architecture can create serious operational risk: too much dependence on connectivity, weak segregation between IT and OT, or insufficient resilience for alarms and control. The right architecture depends on the process criticality, the required response time, the site topology, the compliance regime, and the organization’s ability to operate and secure the platform over its full lifecycle.

What SCADA must do before you choose an architecture

Before comparing cloud and on-premise deployments, define the control model. SCADA is typically used for supervisory control, telemetry, alarming, historian functions, reporting, and operator visibility. It is usually not the primary real-time control loop for safety-critical functions. That distinction matters because cloud architectures may be suitable for monitoring, analytics, and fleet-wide visibility, while hard real-time and safety-related actions often remain local.

In practice, the first engineering question is not “cloud or on-premise?” but “which functions must remain local to preserve safe and deterministic operation?” For example, a pump station may need local PLC control and local alarming even if the enterprise wants cloud dashboards and centralized reporting. This aligns with the layered automation concept in IEC 62264 and the segmentation principles commonly used in IEC 62443 industrial security architectures.

On-premise SCADA: strengths and limitations

On-premise SCADA places the HMI, historian, alarm server, engineering workstation, and often the application server on-site or in a plant-owned data room. It remains the dominant choice for high-criticality operations because it offers local autonomy and predictable latency.

Advantages of on-premise SCADA

• Low latency and deterministic local response for alarms, trends, and operator actions.
• Operational continuity during WAN or internet outages.
• Greater control over physical access, change windows, and maintenance timing.
• Often simpler to align with strict site-specific cybersecurity zoning and air-gapping strategies.
• Useful where legacy PLCs, serial devices, and proprietary protocols must remain local.

Limitations of on-premise SCADA

• Higher local infrastructure burden: servers, backups, patching, virtualization, UPS, HVAC, and spares.
• Harder to scale across multiple sites without duplicated infrastructure.
• Remote access can become insecure if not engineered properly.
• Disaster recovery may be weaker if the plant lacks a secondary site or replicated environment.

From a compliance perspective, on-premise does not automatically mean secure. IEC 62443-3-3 requires security capabilities such as identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. The architecture still needs segmentation, access control, logging, and recovery planning.

Cloud SCADA: strengths and limitations

Cloud SCADA typically means that some or all SCADA functions are hosted in a public cloud or private cloud platform, with edge gateways or site controllers collecting data and forwarding it to the cloud. In many projects, the cloud is used for historian replication, fleet dashboards, alarm notification, analytics, and multi-site reporting rather than direct control.

Advantages of cloud SCADA

• Rapid scaling for multi-site operations and temporary projects.
• Centralized visibility across distributed assets.
• Lower local IT burden if the provider handles infrastructure, backups, and platform updates.
• Better support for analytics, machine learning, and enterprise integration.
• Potentially faster deployment for greenfield or remote assets.

Limitations of cloud SCADA

• Dependence on WAN and internet connectivity.
• Potential latency and jitter, especially for alarms or operator actions that require immediate feedback.
• Complex cybersecurity and identity management across OT and IT domains.
• Data residency and sovereignty concerns, especially in Europe.
• Vendor lock-in risk if data models, alarms, and workflows are proprietary.

For European projects, cloud adoption must be evaluated against GDPR where personal data is involved, but more importantly against operational resilience and cybersecurity obligations. NIS2 raises the bar for essential and important entities, making incident handling, supply-chain security, access control, and continuity planning central design requirements. Cloud does not remove these obligations; it redistributes them between asset owner, integrator, and cloud provider.

Latency, determinism, and control-loop boundaries

SCADA is supervisory, but timing still matters. Alarming, operator acknowledgement, command execution, and trend refresh all have latency expectations. A local on-premise system commonly delivers alarm-to-screen response in well under one second on a LAN. Cloud systems may add network round-trip delay plus provider processing overhead.

For example, if an operator command must traverse a 40 ms one-way WAN path, the round-trip network time alone is approximately:

$$T_{RTT} = 2 \times 40 \text{ ms} = 80 \text{ ms}$$

If the cloud application adds 120 ms of processing and queueing, total command feedback latency becomes:

$$T_{total} = 80 \text{ ms} + 120 \text{ ms} = 200 \text{ ms}$$

This may be acceptable for supervisory commands like setpoint changes or valve opens, but it is not a substitute for local PLC logic in fast interlocks or safety functions. IEC 61511 and IEC 61508 principles remain relevant: safety functions should not depend on non-deterministic external networks. Cloud should not be placed in the protective layer for critical shutdown logic.

Cybersecurity and compliance considerations

Cloud and on-premise both require a formal security architecture. The difference is where trust boundaries sit and who owns which controls. IEC 62443-3-2 requires a risk-based approach to security zones and conduits. In practice, that means segmenting the OT network, limiting trust relationships, and defining what data can cross between plant and enterprise or cloud layers.

Relevant guidance includes:

• IEC 62443-3-2: security risk assessment and system design.
• IEC 62443-3-3: system security requirements and security levels.
• IEC 62443-2-1: security program requirements for asset owners.
• ISA/IEC 62443 terminology and zone/conduit concepts for industrial networks.
• NFPA 70 Article 110 for electrical equipment installation and suitability, where SCADA panels and network equipment are part of the installed system.

For European procurement teams, CE marking is not a label for “the whole SCADA system” in the abstract; it applies to relevant products and assemblies placed on the market, with conformity obligations depending on the applicable directives and standards. If the SCADA solution includes control panels, radio equipment, gateways, or machinery-related control functions, the integrator must consider the Machinery Directive or Machinery Regulation transition, EMC, low-voltage requirements, and any applicable radio or cybersecurity obligations. Documentation, technical file integrity, and risk assessment are essential.

Worked example: multi-site water utility

Consider a utility operating 12 remote booster stations and one central operations center. Each station has a PLC, local HMI, and telemetry gateway. The utility wants historian data, alarm forwarding, and remote operator visibility.

Option A is on-premise central SCADA in the operations center. Option B is cloud SCADA with edge gateways at each station.

Assume the following annual costs:

• On-premise server hardware, virtualization, backups, UPS maintenance: €18,000/year amortized.
• Software licensing and support: €24,000/year.
• Local IT/OT maintenance labor: €22,000/year.
• Total on-premise annual cost: €64,000/year.

• Cloud platform subscription: €3,200/month = €38,400/year.
• Edge gateway support and SIM/connectivity: €900/month = €10,800/year.
• Reduced local maintenance labor: €10,000/year.
• Total cloud annual cost: €59,200/year.

At first glance, cloud is only slightly cheaper. But the real comparison must include resilience and downtime cost. Suppose an on-premise server failure causes 6 hours of reduced visibility once every 2 years, and the utility estimates the operational cost of degraded monitoring at €2,500 per hour. The expected annual downtime cost is:

$$C_{downtime,onprem} = \frac{6 \times 2500}{2} = €7,500/year$$

Suppose the cloud service has a WAN outage risk causing 2 hours of lost remote visibility every year, but local PLC control remains intact. If the same visibility loss costs €2,500 per hour, then:

$$C_{downtime,cloud} = 2 \times 2500 = €5,000/year$$

Now the effective annualized cost becomes:

• On-premise effective cost: €64,000 + €7,500 = €71,500/year.
• Cloud effective cost: €59,200 + €5,000 = €64,200/year.

In this example, cloud has a modest cost advantage. However, if the utility required sub-second local operator response for critical pump sequencing, the cloud would still not replace local SCADA or PLC logic. The correct answer would likely be a hybrid architecture: local on-premise control and alarming at each site, with cloud replication for fleet-wide monitoring and reporting.

Decision matrix: when each architecture fits best

Criterion	On-Premise SCADA	Cloud SCADA	Typical Engineering Preference
Latency sensitivity	Excellent	Variable	On-premise for critical supervisory actions
WAN dependence	Low	High	On-premise for isolated or harsh sites
Multi-site scalability	Moderate	Strong	Cloud for fleet visibility and analytics
Cybersecurity complexity	Moderate to high	High, shared responsibility	Depends on team maturity
Data sovereignty	Strong control	Must be contractually managed	On-premise if sovereignty is strict
Disaster recovery	Requires local design	Often easier to replicate	Cloud for DR-heavy use cases
Lifecycle maintenance	Owned by site team	Shared with provider	Cloud if internal IT/OT resources are limited

Hybrid architecture is often the engineering optimum

For most industrial systems, the best answer is neither pure cloud nor pure on-premise. A hybrid design places deterministic control, alarming, and essential HMI functions on-site while using the cloud for historian replication, dashboards, asset performance management, and remote reporting. This reduces risk while preserving the benefits of scale.

Typical hybrid patterns include:

• Local PLC and local SCADA/HMI for operation during communications loss.
• Edge gateway publishing data to cloud using secure outbound-only connections.
• Cloud historian receiving replicated data for dashboards and analytics.
• Centralized identity and logging with strict role-based access control.

This pattern supports IEC 62443 zone/conduit design and helps meet NIS2 expectations for resilience, incident handling, and supply-chain management. It also reduces the blast radius of a cloud outage, because the plant continues to run locally.

Engineering selection criteria

When selecting architecture, ask the following questions:

1. Which functions must survive total internet loss?
2. What is the maximum acceptable latency for alarms, commands, and acknowledgements?
3. Are there data residency or customer confidentiality constraints?
4. Who will patch, back up, monitor, and test the platform?
5. Can the organization maintain IEC 62443 security controls in the chosen model?
6. Is the system part of machinery control, utility telemetry, or enterprise reporting?
7. What is the cost of one hour of lost visibility or control?

If the answer to the first two questions is “the process must continue safely and locally,” then cloud should be limited to non-critical functions. If the answer is “the system is geographically distributed and mainly informational,” cloud becomes much more attractive.

Conclusion: common mistakes to avoid

The most common engineering mistake is treating cloud SCADA as a direct replacement for local control. It is not. Another frequent error is underestimating cybersecurity obligations, especially segmentation, identity management, logging, and recovery testing under IEC 62443 and NIS2-aligned governance. Teams also misjudge latency by focusing only on average bandwidth instead of worst-case delay and outage behavior. Finally, procurement teams sometimes compare license prices without including resilience, maintenance labor, backup infrastructure, and the cost of downtime.

To avoid these mistakes, define the control boundary early, keep deterministic control local, use cloud selectively for monitoring and analytics, and document the security and compliance model in the functional specification. In most industrial projects, the best architecture is not “cloud versus on-premise” but a disciplined hybrid design that preserves safe operation, meets European compliance expectations, and scales economically over the asset lifecycle.