Every SCADA vendor has a stake in this argument, including us - Merobix sells both deployment models, which is exactly why we can afford to be straight about it. Neither cloud nor on-premise is "more secure" as a category. They distribute the same security work differently: who patches, who monitors, whose certifications cover the running system, what is exposed to the internet, and whose staff carries the pager. This guide compares the two models layer by layer, shows where the certification burden actually lands, and gives you an honest read on when each one wins.
Part of our SCADA security guide library - 60+ articles on securing industrial operations.
"Is cloud SCADA secure?" is really three questions wearing one coat: What is exposed? Who does the security work? Whose evidence proves it? The deployment model changes the answer to all three - but it never changes the total amount of work. Security is conserved; it just moves between your payroll and the vendor's.
That framing dissolves most of the ideology in this debate. The on-premise purist is right that a cloud platform is an internet-facing service and a third-party dependency. The cloud advocate is right that the median self-managed SCADA server - unpatched OS, shared logins, backups nobody has restored - is far softer than a professionally operated platform. Both are describing execution failures, not model properties. This post covers the security dimension specifically; for architecture, cost, and operational trade-offs, see our companion cloud vs on-premise SCADA comparison, and for the money side, the .
Here is the comparison that should be in every RFP, and rarely is. Read the on-premise column as a staffing plan, because that is what it is:
| Security Layer | Cloud SCADA | On-Premise SCADA |
|---|---|---|
| Physical infrastructure | Vendor / data-center provider | You - server room, power, physical access control |
| OS and platform patching | Vendor, continuously | You - on a calendar you must defend against "don't touch it" |
| Application security and updates | Vendor ships fixes to everyone at once | Vendor writes fixes; you must apply them, offline if air-gapped |
| Tenant/data isolation | Vendor - demand row-level security and isolation testing evidence | Not applicable (single tenant), but internal segmentation is yours |
| Identity and access (MFA, roles, offboarding) | Platform provides the controls; you run the accounts | Platform provides the controls; you run the accounts and the identity infrastructure |
| OT network and gateway | You - segmentation, gateway placement, PLC network | You - same, plus the server network |
| Monitoring and threat detection | Vendor watches the platform 24/7; you watch your operations | You - logs, review, alerting, staffing |
| Backups and disaster recovery | Vendor for platform data; verify restore testing | You - backups, offline copies, rehearsed restores |
Two rows never move regardless of model: your OT network and your user account discipline. No vendor can segment your plant LAN from your office LAN or revoke the access of a technician you forgot to offboard. Get the full split into the contract as a responsibility matrix - ambiguity here is where incidents fall between chairs.
In the cloud model, the vendor's certifications and attestations - SOC 2 reports under the AICPA's framework, ISO 27001 certificates, ISA/IEC 62443 assessments - cover most of the running system, because the vendor operates most of it. Your job is verification: read the report scope, check the exceptions, and confirm the audited service is the one you are buying. (On honest framing: Merobix runs a SOC 2 readiness program and maps its controls to IEC 62443 - that is different from holding the certificates, and any vendor should state which side of that line they are on as plainly.)
In the on-premise model, those vendor documents shrink to covering the software and its development process. The operational program - the thing SOC 2 actually attests - becomes yours to build: an IEC 62443-2-1 asset-owner program, ISO 27001 if your customers demand a certificate, hardening, and evidence collection. That shifted burden is large enough that we wrote a full guide to it: on-premise SCADA certifications and what you need to run it yourself. Sector rules - NERC CIP, AWIA, TSA directives, FDA 21 CFR Part 11 - bind the operator identically in both models; deployment choice never makes a regulator go away.
If one factor separates the models in observed real-world outcomes, it is this. Attackers routinely exploit known, aged vulnerabilities on systems nobody dared to update - CISA's joint advisories on the top routinely exploited vulnerabilities keep finding years-old CVEs among the most abused. Cloud platforms are patched continuously by the vendor, for every customer at once, with no local change window required. On-premise systems are patched exactly as often as your organization schedules the downtime, wins the "if it ain't broke" argument, and (if air-gapped) walks verified media across the boundary.
This is not an unwinnable fight for on-premise - operators with real patch calendars and tested rollback plans run tight ships. But be honest about your organization's track record before assuming you will be one of them. When was your current SCADA server's OS last updated? If the answer is measured in years, that answer is your security posture, whatever the architecture diagram says.
Ask the same question of the vendor, in both directions. For cloud: how often do releases ship, how are they tested before deployment, and how quickly did the last critical vulnerability go from disclosure to fixed-in-production? For on-premise: how are updates packaged and signed, is there a documented offline update path for isolated sites, and what fraction of on-premise customers are actually running a current release? A vendor who cannot answer that last question is telling you something important about how its on-premise fleet ages in the field.
The classic objection to cloud SCADA - "you're connecting my plant to the internet" - deserves a precise answer, because the naive version of cloud connectivity really is dangerous. The precise answer is outbound-only gateway architecture: the gateway sits inside the OT network, polls PLCs locally, and initiates outbound TLS connections to the platform. Your OT firewall denies all inbound traffic, permanently. Nothing listens; internet scanners find nothing. Merobix works exactly this way - no inbound ports, no VPN, with Ed25519 device-signed telemetry, replay detection, and store-and-forward buffering when the connection drops. The full design is on our security page.
What remains exposed in the cloud model is the platform itself - the web application your operators log into. That surface is real, and it is the vendor's full-time job: demand MFA and passkey support, brute-force lockout, tenant isolation evidence, and continuous validation. What remains exposed in the on-premise model is subtler: every remote-access accommodation your own team bolts on over the years - the VPN for the integrator, the RDP for the on-call engineer, the port forward "just for commissioning." Internet scans find those constantly. On-premise systems are not exposed by design; they become exposed by accretion, without a security team watching for it.
Rerun the responsibility table above as a hiring plan and the models separate sharply. The on-premise column assumes somebody - with a name, hours, and a backup for their vacation - hardens servers, applies patches, reviews logs, rotates backups, and rehearses restores. In a large utility with an OT security team, that somebody exists. In a 15-person operator where "IT" is the office manager and a consultant, that somebody is nobody, and the security architecture quietly becomes fiction. The cloud model converts most of that staffing into the vendor's problem, purchased as subscription. For small operators this is usually the decisive security argument, independent of every other consideration - a point our enterprise SCADA buyer's guide weighs from the opposite end of the size spectrum, where dedicated teams change the calculus.
And the models compose. A common fleet pattern: the one facility with an isolation mandate runs the platform on-premise inside its boundary, while the other twenty sites run cloud with outbound-only gateways. Merobix ships the same platform, the same roles and MFA, and the same immutable audit records in both modes, so the split costs you an architecture decision - not a second product.
Key takeaway: Cloud vs on-premise does not change how much security work exists - only who performs it and whose audit proves it. Choose cloud when you want the vendor's full-time program, continuous patching, and outbound-only exposure; choose on-premise when regulation demands isolation or you genuinely staff the program yourself; and put the responsibility matrix in the contract either way. Then judge vendors on execution: ask to see the controls live in a demo, in whichever deployment model you are actually going to run.
Neither model is more secure by definition - security is a property of execution, and the two models distribute the execution differently. Cloud SCADA gives you the vendor's full-time security operation: continuous patching, monitored infrastructure, and audited controls, at the cost of trusting a third party and accepting an internet-facing service. On-premise SCADA gives you complete control and can be isolated entirely, at the cost of owning every layer yourself - and self-managed systems that miss patches for years are a far more common real-world failure than cloud platform breaches. The honest question is which set of responsibilities your organization will actually execute well, with the staff it really has.
Responsibility is shared, and the split should be written down. In a typical cloud SCADA deployment the vendor secures the platform: infrastructure, application code, patching, tenant isolation, encryption, monitoring, and backups of the hosted service. The operator remains responsible for its own side: user account hygiene and role assignments, enforcing MFA, the OT network where the gateway and PLCs live, physical security of devices, and deciding who may write setpoints. Field wiring, local network segmentation, and joiner-mover-leaver discipline never transfer to any vendor. Before signing, get the responsibility matrix in the contract - vague splits are where incidents fall through.
Mostly no. A SOC 2 report or ISO 27001 certificate attests to the systems inside its audit scope - for a SCADA vendor, that is normally the hosted service and the vendor organization, including its software development practices. When you deploy the same software on your own servers, the vendor's development-practice evidence still speaks to the quality of the code you install, but the operational controls the report describes - patching, monitoring, backups, access management for the running system - are now performed by you and are not covered by anyone's audit unless you build your own program. That shifted burden is the central certification difference between the two models.
It depends on which framework binds you and how much program you can staff. Sector rules such as NERC CIP, AWIA, TSA pipeline directives, and FDA 21 CFR Part 11 attach to the operator in both models - no deployment choice makes them disappear. Cloud helps because the vendor brings audited controls, evidence, and continuous patching you can reference, and most frameworks accommodate well-governed cloud connectivity. On-premise helps when a policy or accreditation genuinely requires isolation or strict data residency, and it is the only path to a true air gap. Many operators split the difference: isolated deployment for the few facilities that require it, cloud for the rest of the fleet.
Yes - this is exactly what outbound-only gateway architecture is for. The gateway sits inside the OT network, polls PLCs and RTUs locally, and initiates outbound TLS connections to the platform; the OT firewall denies all inbound traffic permanently, so there is no listening service for internet scanners to find. Merobix works this way: no inbound ports, no VPN concentrator, with device-signed telemetry and store-and-forward buffering for connection outages. The remaining internet-facing surface is the vendor's platform itself, which is the vendor's full-time job to defend - and the thing you should interrogate before buying.
Merobix runs cloud-hosted with an outbound-only gateway or fully on-premise and air-gapped - same MFA, same roles, same immutable audit trail. Compare both against your requirements before you choose.