Cloud SCADA has moved from experiment to default: remote operations, no server room, vendor-managed patching. But moving supervisory control to a multi-tenant platform changes the security questions completely. It is no longer "is our firewall configured correctly?" - it is "how does this vendor keep our data separate from a hundred other customers, prove our telemetry was not tampered with, and stop a stolen password from writing a setpoint?" This checklist gives you the 12 control families to demand from any cloud SCADA vendor in 2026, what a real implementation looks like for each, and the evidence to request before you sign.
How to read this page. This comparison is written and published by Merobix, which offers a competing product, so it is our own analysis and marketing - not independent, neutral, or third-party research. We aim to be accurate and to note where the products discussed may be the better fit, but you should weigh it accordingly and confirm anything that matters against the products discussed's own current documentation.
Explore the full security & certification article series - 60+ practitioner guides.
The short answer: a cloud SCADA security checklist must cover twelve control families - phishing-resistant MFA, least-privilege RBAC, hardened sessions, verifiable tenant isolation, encryption, tamper-evident audit trails, signed telemetry, safeguarded control writes, an outbound-only gateway, API hardening, runtime detection, and validated backup and supply-chain assurance. Here is why the old on-premise checklist cannot do the job.
Traditional OT security guidance assumes the SCADA server lives inside your fence: segment the network, harden the box, control physical access. Cloud SCADA breaks those assumptions. Your historian lives in a data center you will never visit, your operators log in from phones and home offices, and your data shares infrastructure with other companies - possibly your competitors. The old checklist still matters at the plant edge, but it says nothing about the questions that now decide your risk: tenant isolation, telemetry integrity across the internet, API exposure, and the vendor's own software supply chain.
The good news is that a well-built cloud platform can beat the real-world security of the average on-premise deployment - because the average on-premise deployment is an unpatched Windows server with a port forwarded to a PLC and a shared operator password taped to the monitor. The bad news is that "well-built" is doing enormous work in that sentence, and vendor marketing pages all look the same. The difference is verifiable architecture, and this checklist is how you verify it. It condenses the same territory covered by our OT network security buyer's guide into twelve concrete control families, each with the evidence you should demand.
One framing note before the list: these controls are vendor-neutral, and they track the same control territory as the NIST SP 800-82 Rev. 3 guide to operational technology (OT) security and CISA's Cross-Sector Cybersecurity Performance Goals, applied to the cloud delivery model. Whether you are evaluating Merobix, a tag-based SCADA platform Cloud Edition, traditional SCADA vendors Insight, or a niche telemetry SaaS, the same twelve families apply. Any vendor who cannot speak to all twelve has a gap - the only question is whether they will tell you about it honestly.
A password alone protecting process control is no longer defensible. Demand TOTP-based MFA as a floor and FIDO2/passkey support as the target - passkeys are phishing-resistant because the credential is cryptographically bound to the real site, so a fake login page gets nothing - the verifier-impersonation resistance described in the NIST SP 800-63B digital identity guidelines. Ask whether MFA is available on every plan or gated behind an enterprise tier, and whether high-risk workflows (like signing a work permit or changing a critical setpoint) require step-up authentication - a fresh verification at the moment of the action, not just at login. Our full SCADA authentication guide covers TOTP vs passkeys, session controls, and SSO in depth.
Every user gets a named account and a role that limits what they can see and do. The critical test: does RBAC govern control actions - setpoint writes, command dispatch - or only screen visibility? A contractor viewing compressor trends must not inherit the ability to change a shutdown setpoint. Look for granular roles (viewer, operator, manager, engineer, admin) plus site-level authorization, so a user with rights at one facility has none at another. Merobix ships six roles with site-level scoping and ownership checks before any operational or administrative action.
Sessions are where stolen credentials become persistent access. Demand configurable session expiry, the ability to revoke sessions and log a user out everywhere, concurrent-session limits, and brute-force detection with persistent account lockout - not a lockout that resets after five minutes and lets the password sprayer continue.
In a multi-tenant platform, isolation failures are catastrophic by definition - one flaw exposes every customer. Demand isolation enforced in at least two independent layers: tenant-aware authorization in the application and a database-level mechanism such as PostgreSQL row-level security, so a bug in one layer is caught by the other. The strongest implementations add a signed database request context, which prevents application code from silently switching tenants, and they log and alert on every cross-tenant denial. This topic deserves its own article, and it has one: how to verify tenant isolation in multi-tenant cloud SCADA.
TLS - ideally TLS 1.3 as specified in RFC 8446 - on every path - browser to platform, gateway to cloud, MQTT, and industrial connections - is table stakes. Beyond that, ask about field-level encryption of sensitive application data, modern password hashing, hashed reset and registration tokens, and blind indexes that let the platform search encrypted identifiers such as email addresses without storing them in plaintext. "We encrypt at rest" can mean anything from disk encryption (which protects against stolen hard drives and nothing else) to per-field application-layer encryption; make the vendor say which.
When a setpoint changes at 2 AM, the audit trail is what turns a mystery into a timeline. Demand that every login, failed login, configuration change, control action, and acknowledgement is recorded against a named user - and that sensitive-event records are immutable and chained, so an attacker (or insider) cannot quietly edit history. Ask how the chain is verified and whether you can export the records for your own retention.
If your platform accepts any well-formed packet that arrives on the broker, an attacker who obtains one device credential can forge readings for the whole site - or replay yesterday's healthy data while today's incident unfolds. The strong pattern: each device holds its own signing identity (Merobix uses device-generated Ed25519 keys), telemetry travels in signed envelopes carrying sequence numbers, timestamps, and payload digests, and the platform detects replays and rejects unsigned or tampered data. Ask also about durable acceptance - telemetry persisted before historian processing - and store-and-forward buffering at the gateway so outages do not create data gaps.
Remote control is where cloud SCADA risk becomes physical. Demand an explicit writable-tag allowlist (everything else is read-only, forever), setpoint bounds validated before dispatch, role and competency checks on the person commanding, idempotency against duplicate commands, and a full command lifecycle - pending, applied, verified, failed, expired - with read-back verification where the protocol supports it. Where your process requires it, management-of-change and pre-startup safety review gates should be enforceable in the platform, not just in a binder.
The gateway architecture decides your firewall posture. An outbound-only gateway initiates all connections from inside the OT network over TLS, so your firewall denies all inbound traffic permanently - no exposed ports, no VPN concentrator to patch. Each gateway should have unique registration and credentials (never a fleet-wide shared secret), and gateway software updates should be signed and verified before installation, closing off the edge as a malware delivery path.
Every cloud SCADA platform is also an API product, whether the vendor says so or not. Demand scoped API keys with lifecycle management and revocation, rate limits and request-size limits, strict input validation, and SSRF defenses on anything that makes outbound calls - connectors and webhooks are a classic pivot into cloud metadata services. Pinned-IP webhook delivery and trusted-origin CORS are marks of a team that has thought past the happy path.
Prevention fails eventually; detection decides how much it costs. Ask what the platform detects at runtime - cross-tenant denials, privilege probes, repeated authentication failures, suspicious control activity - and how those events reach you: email, SMS, webhook, and SIEM export, delivered through a durable outbox with retry and dead-letter handling so a notification provider outage does not silently eat your security alerts.
Ransomware resilience is a restore problem, not a backup problem: demand backup archive validation, controlled restore tooling, and data-retention and customer-export workflows so you can leave with your data. On the supply chain side, ask how the vendor builds and ships software - dependency scanning, build provenance, visibility into exactly which build is running. Mature vendors expose the Git SHA of deployed services; the strongest are moving toward deploys only from a fully green, signed build. Merobix publishes build SHAs today and is building out full release assurance - blocking security checks, immutable release bundles, and signed provenance - as part of its current roadmap.
| Control Family | What to Demand | Evidence to Request |
|---|---|---|
| 1. MFA | TOTP floor, FIDO2/passkeys, step-up auth for high-risk actions | Live demo of enrollment and step-up prompt |
| 2. RBAC | Named accounts, granular roles, site-level scope, control-action gating | Role matrix; show a viewer blocked from a setpoint write |
| 3. Sessions | Expiry, revocation, concurrent limits, persistent lockout | Session policy docs; lockout behavior demo |
| 4. Tenant isolation | App-layer checks plus database RLS; signed request context; denial alerts | Architecture doc; cross-tenant test methodology |
| 5. Encryption | TLS everywhere, field-level encryption, blind indexes, modern hashing | Written crypto summary, not just "AES-256" |
| 6. Audit trails | Every action attributed; immutable chained records for sensitive events | Sample export; chain-verification explanation |
| 7. Telemetry integrity | Per-device signing, replay detection, durable acceptance, store-and-forward | Envelope format description; outage behavior |
| 8. Control safety | Writable-tag allowlist, bounds, idempotency, command states, read-back | Demo of a rejected out-of-bounds write |
| 9. Edge security | Outbound-only TLS, unique device credentials, signed updates | Required firewall rules (answer: none inbound) |
| 10. API hardening | Scoped keys, rate limits, SSRF defenses, webhook pinning | API security docs; key revocation demo |
| 11. Detection | Runtime threat monitoring, SIEM export, durable alert delivery | Alert catalog; delivery guarantee description |
| 12. Resilience | Validated backups, restore tooling, export rights, supply chain program | Restore-drill cadence; build provenance status |
Do not send the list as a yes/no questionnaire - every vendor will return twelve yeses. Instead:
Key takeaway: Cloud SCADA security is not a deployment-model question - it is an architecture question, and architecture is verifiable. Twelve control families - identity, RBAC, sessions, tenant isolation, encryption, audit, telemetry integrity, control safety, edge security, API hardening, detection, and resilience - cover the attack surface that matters. Demand evidence for each, weight them by your risk, and disqualify any vendor who claims perfection instead of showing you their program.
We built this checklist because it is the standard we hold ourselves to, so here is our own honest scorecard. Shipped today: TOTP MFA and FIDO2/passkeys, six-role RBAC with site-level authorization and step-up authentication, session revocation and persistent lockout, tenant isolation via application checks plus PostgreSQL row-level security with a signed request context and cross-tenant denial alerting, TLS everywhere with field-level encryption and blind indexes, immutable chained audit records, Ed25519-signed telemetry envelopes with replay detection and store-and-forward, writable-tag allowlists with setpoint bounds and full command states, an outbound-only gateway with unique device credentials and signed updates, scoped API keys with SSRF and webhook hardening, runtime threat detection with SIEM delivery, and validated backups with customer-export workflows.
In progress, stated plainly: we run a readiness program for SOC 2, the AICPA's Trust Services attestation framework, and map our controls to the ISA/IEC 62443 series of industrial cybersecurity standards published by ISA - we do not claim certification. Independent penetration testing is part of our ongoing validation program alongside continuous cross-tenant and replay testing. And we are building mandatory signed telemetry across all legacy paths, immutable versioned gateway installs with atomic rollback, and full release assurance with signed build provenance. The complete architecture is documented on our security page, and every claim above can be pressure-tested live in a demo. For how this compares to keeping SCADA in-house, see our cloud vs on-premise comparison.
Demand twelve control families: phishing-resistant multi-factor authentication, role-based access control with least privilege, hardened session management, verifiable tenant isolation, encryption in transit and at rest, tamper-evident audit trails, cryptographically signed telemetry with replay protection, safeguarded control writes with setpoint bounds and command states, an outbound-only gateway with per-device identity and signed updates, API and webhook hardening, runtime threat detection with assured alert delivery, and validated backup, recovery, and software supply chain practices. Ask the vendor to show evidence for each - architecture documentation, test results, and audit records - rather than accepting a marketing summary.
It can be, but security depends on the specific platform architecture, not on the deployment model. A well-built cloud SCADA platform with an outbound-only gateway, enforced MFA, tenant isolation at the database layer, signed telemetry, and continuous vendor patching frequently exceeds the real-world security of an unpatched on-premise SCADA server with open inbound ports. A poorly built cloud platform with shared credentials and weak tenant boundaries is worse than either. Evaluate the twelve control families in this checklist against any candidate platform, and require an on-premise or air-gapped option if your policy or regulator demands one.
Tenant isolation is the set of controls that keeps one customer's data, users, and control paths completely separated from every other customer sharing the same cloud platform. It matters because a single isolation flaw can expose the telemetry - or worse, the control surface - of every organization on the platform. Strong implementations enforce isolation in at least two independent layers: application-level authorization checks plus database-level mechanisms such as PostgreSQL row-level security, with a signed request context so application code cannot silently switch tenants. Ask vendors how isolation is enforced, whether cross-tenant denials are logged and alerted, and whether cross-tenant access is part of their ongoing security testing.
Ask for architecture documentation showing network paths and trust boundaries, a description of authentication and session controls, an explanation of how tenant isolation is enforced at the database layer, sample audit records, the status of independent security validation such as penetration testing, and the status of compliance programs - including the honest distinction between being certified and running a readiness program. A trustworthy vendor will tell you plainly which controls are shipped, which are in progress, and how they validate them. Treat vague answers, refusal to discuss architecture, or claims like unhackable or 100 percent secure as disqualifying.
Yes. An outbound-only gateway sits inside the OT network, polls PLCs and RTUs locally, and initiates encrypted TLS connections outward to the platform. Because every connection originates from inside, the OT firewall can deny all inbound traffic permanently - there is no listening service for internet scanners to find and no VPN concentrator to patch. The Merobix gateway works this way, buffering data locally during outages with store-and-forward so no telemetry is lost. This removes the most common industrial attack vector: internet-exposed inbound ports.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
We compare current, generally available capabilities using publicly available information and Merobix's understanding, and we describe operating models and cost structure rather than quoting a competitor's confidential prices. Product capabilities, editions, licensing, and pricing change over time and vary by configuration.
This comparison draws on the vendor's publicly available product documentation and pricing pages together with Merobix's own product knowledge. Where a specific figure is not published by the vendor, we say so or omit it rather than estimate a competitor's private pricing.
Spotted something out of date or inaccurate? Please tell us through our corrections process and we will review it.
Disclosure & trademarks. Merobix authored this page and may compete with the companies discussed; it reflects our opinions and interpretation and may be incomplete or out of date. Verify current capabilities, editions, and pricing with the respective vendor before making a decision.
Third-party products and all other third-party product names, company names, logos, and brands are the property of their respective owners and may be trademarks or registered trademarks of those owners. They are used here only to identify and compare the products (nominative use); their use does not imply any affiliation with, sponsorship by, or endorsement by those owners, and Merobix is not affiliated with them.
Twelve control families, one platform built to answer for all of them - bring this checklist to a live demo and grade us against it.