"The cloud vendor handles security" and "we can't use cloud because we'd lose control of security" are both wrong - and both dangerous, because each one leaves real controls with no owner. Cloud SCADA security is a division of labor: the vendor secures what it builds and operates, you secure what only you can see and control, and the incidents happen in the seam between. This guide lays out the shared responsibility model layer by layer - who owns what, where the gray zones are, what belongs in the contract, and the questions that reveal whether a vendor actually understands its half of the deal.
Part of the SCADA Security Hub - 60+ guides on SCADA security, compliance & certifications.
The shared responsibility model was popularized by the big cloud infrastructure providers to answer a recurring confusion: customers assumed "it's in the cloud" meant "it's secured," while providers meant only "the parts we run are secured." The canonical phrasing became security OF the cloud (provider) versus security IN the cloud (customer) - a split federal guidance formalizes in CISA's Cloud Security Technical Reference Architecture and, a decade earlier, in NIST SP 800-144 on public cloud security. Cloud breach post-mortems show a recurring pattern: incidents commonly trace not to provider failures but to customer-side misconfiguration - open storage buckets, over-privileged accounts, leaked keys. The infrastructure was secure; the usage wasn't.
Cloud SCADA needs its own version of the model because the stack is longer than SaaS. A CRM vendor's model ends at the browser. A SCADA platform's stack extends past the browser, through a gateway on your plant network, down to PLCs, instruments, and physical valves - layers no cloud vendor can reach, patch, or watch for you. That means the operator's half of the model is bigger in OT than in IT, not smaller, and pretending otherwise is how the seam-gaps form. If you're still weighing deployment models, our cloud vs on-premise comparison is the companion read; this article assumes cloud is on the table and asks who does what.
Here is the model we recommend buyers adapt, whatever vendor they choose. Print it, put names in the last column, and attach it to the contract:
| Layer | Vendor Owns | Operator Owns |
|---|---|---|
| 1. Cloud infrastructure | Hosting security, physical data centers, network edge protection, DDoS mitigation | Nothing directly - but verifying the vendor's choices before signing |
| 2. Application platform | Secure code, vulnerability management, patching, tenant isolation, encryption in transit and at rest, platform monitoring | Nothing directly - but demanding documented evidence of each |
| 3. Identity & access | Providing MFA, roles, session controls, lockout, audit logging as platform capabilities | Using them: creating accounts, assigning least-privilege roles, enforcing MFA, same-day offboarding, access reviews |
| 4. Gateway & edge | Gateway software security, signed updates, device credential system, encrypted transport | Physical hosting of the gateway, local network placement, applying updates where operator-managed, not bypassing it with port forwards |
| 5. OT network & field devices | Nothing - the vendor cannot see behind your firewall | Segmentation, PLC hardening, physical site security, removing legacy exposure |
| 6. Data governance | Backup execution, restore capability, retention machinery, export tooling | Deciding retention policy, periodically exporting and archiving your own copy, verifying restores are available |
| 7. Detection & response | Detecting platform-level attacks, delivering security alerts and alarms reliably, notifying customers of incidents | Rostering humans to receive and act on alerts, incident response procedures, manual-operation fallback, tabletop practice |
Two readings of this table repay attention. First, rows 1–2 are delegation, not abdication: you don't operate those controls, but you choose the vendor, so due diligence is your control. Second, rows 3 and 7 are traps for optimists: the vendor supplies the mechanism, but the mechanism does nothing until you operate it. MFA that exists but isn't enforced, and alerts that fire into an unwatched inbox, are the two most common ways "shared" responsibility becomes "nobody's."
On its side of the line, the vendor's obligations are absolute: you cannot patch their application or configure their database isolation, so the standard must be documentation, not trust. Concretely, a serious cloud SCADA vendor should be able to show:
No platform, however good, can reach these; budget real recurring hours for them:
Post-incident reviews in cloud-connected operations keep finding the same five seams - each one a control both parties plausibly believed the other owned:
Key takeaway: Shared responsibility fails as a slogan and works as a table. Write the matrix, put a named owner in every row, attach it to the contract, and review it annually. The vendor's half is verified by documentation and evidence; your half is verified by whether the hours are actually rostered. Any row with two owners has zero.
The matrix earns its keep when it's contractual. Minimum set of terms to demand - reasonable vendors accept these without drama:
Five questions that reveal in one meeting whether a vendor understands its half: Where exactly does your responsibility end and mine begin - show me the document? How would you detect and tell me about a cross-tenant incident? What happens to my data and configuration if we part ways? Who patches the gateway and how do I verify it? What evidence of your security program do I get without asking? Merobix publishes its answers on the security page, and a demo is a fine place to ask all five out loud - of us or anyone else.
It is the explicit division of security duties between the platform vendor and the operator. The vendor secures what it builds and runs: cloud infrastructure, the application, tenant isolation, encryption, platform patching, and platform-level monitoring. The operator secures what only the operator can control: who gets accounts and roles, MFA enforcement, offboarding, the OT network and field devices behind the gateway, physical site security, and operational procedures. The model matters because every security control needs exactly one accountable owner - controls that both parties assume the other one owns are where incidents happen.
In a managed cloud SCADA service, the vendor owns the security of the hosting infrastructure, the application code and its vulnerability management, isolation between customer tenants, encryption of data in transit and at rest, platform patching and release testing, availability and redundancy of the service, backup execution and restore capability for platform data, and monitoring of the platform for attacks. A serious vendor can document each of these - including how tenant isolation is enforced (for example, database row-level security), how telemetry is authenticated, and how customers are notified of security events.
Everything the vendor cannot see or control from the cloud: creating and removing user accounts, assigning least-privilege roles, enforcing MFA use, offboarding departed staff the same day, securing the OT network and PLCs behind the gateway, physical security of sites and panels, deciding which tags are writable and what setpoint limits apply, responding to the alarms and security alerts the platform delivers, and maintaining incident response and manual-operation procedures. No cloud platform can disable your ex-employee's account for you or notice that a contractor was given admin rights.
In the gray zones where each party assumes the other is acting: gateway hardware that the vendor ships but the operator hosts (who updates it, and on what schedule); alert response (the vendor delivers the alarm, but is anyone on the operator side rostered to act on it); user lifecycle (the platform supports instant revocation, but HR never tells anyone the technician left); configuration backups (the vendor backs up the platform, but who exports and archives the operator's own configuration); and incident communication (each side waits for the other to declare). The fix is a written responsibility matrix with a named owner for every row.
At minimum: a responsibility matrix as a contract exhibit; an uptime SLA with defined measurement and remedies; a security-incident notification clause with a concrete timeframe and named contact path; data ownership language confirming the telemetry is yours; data export rights in standard formats during the term and at offboarding, with a defined retention and deletion timeline; breach-of-tenant-isolation as an explicit reportable event; a description of the vendor's validation program (testing, independent assessment) and how customers receive evidence; and change notification for material reductions in security posture. Honest vendors accept these terms; evasive answers here are a strong pre-contract signal.
Tenant isolation, signed telemetry, audit trails, and documented controls on our side - clear tooling for roles, MFA, and exports on yours. Ask us the hard questions live.