When you buy cloud SCADA, you are almost always buying multi-tenancy: your compressor data, alarm rules, and user accounts live in the same application - often the same database - as dozens or hundreds of other companies. Done well, that shared platform is patched faster and monitored harder than anything you could run yourself. Done badly, a single missed authorization check exposes every customer at once. This guide explains how real tenant isolation is engineered - row-level security, signed request context, cross-tenant detection, performance isolation - and exactly how to verify that a vendor has done the work rather than just claimed it.
From the Merobix industrial security hub - every security, compliance & certification guide in one place.
To verify tenant isolation in multi-tenant cloud SCADA, demand evidence on four fronts: an architecture walk-through naming at least two enforcement layers (application authorization plus database row-level security), a signed request context that stops tenant-switching, a live demonstration of a logged and alerted cross-tenant denial, and cross-tenant test cases in the vendor's continuous validation program. Here is why that bar is justified.
Every other security control in a cloud SCADA platform protects you from outsiders. Tenant isolation protects you from the platform's other customers - and from the platform's own bugs. It is the one risk category that simply does not exist in an on-premise deployment, which is why it deserves more scrutiny than any other item on your cloud SCADA security checklist.
The stakes are asymmetric. In IT SaaS, a cross-tenant leak exposes documents. In SCADA, the tenant boundary guards operational telemetry (production volumes are commercially sensitive - your neighbor on the platform may literally be your competitor), alarm configurations, and in the worst case the control surface: the ability to write a setpoint to another company's equipment. A platform where tenant A can even enumerate tenant B's site names has failed; one where a crafted request could reach tenant B's writable tags is a disqualifying hazard.
The uncomfortable truth for buyers: broken object-level authorization - exactly the bug class behind cross-tenant leaks - has topped the OWASP API Security Top 10 for years, because it is easy to get subtly wrong at scale. Hundreds of endpoints, each needing a correct ownership check, maintained by a changing team under deadline pressure. That is why the architecture question is not "do you have isolation?" but "how many independent layers enforce it, and what catches the layer that fails?"
Vendors implement multi-tenancy - the pooled, shared-resource model that NIST SP 800-145, the NIST definition of cloud computing, treats as a defining characteristic of cloud services - on a spectrum. None of the models is automatically secure or insecure; each moves the risk somewhere different:
| Model | How It Works | Strengths | What to Watch |
|---|---|---|---|
| Silo (single-tenant instances) | Each customer gets a dedicated application and database | Hard physical separation; simple residency story | Patch lag across many instances; uneven hardening; highest cost |
| Schema-per-tenant | Shared application, separate database schema per customer | Clear data boundary inside one database | Migration complexity grows with tenants; connection routing is the weak point |
| Pooled with row-level security | Shared application and tables; every row tagged by tenant, database enforces policies | One codebase to harden; uniform patching; isolation enforced by the database engine | Everything depends on the RLS policies and how the tenant context is set |
Most modern SaaS SCADA platforms - Merobix included - use the pooled model with row-level security, because it concentrates security engineering in one place and lets every customer benefit from every fix within hours. The rest of this guide focuses on what makes that model trustworthy, because it is the one you will most often be evaluating. (If your policy requires physical separation instead, the right question is whether the vendor also offers dedicated on-premise deployment - see our cloud vs on-premise comparison.)
The first enforcement layer lives in the application: every request is bound to an authenticated user, the user to a tenant, and every data access checks ownership before proceeding - the per-request access decision model formalized in NIST SP 800-207, Zero Trust Architecture. Mature platforms go further than a generic "is logged in" check - they verify site ownership before operational and administrative actions, so even within a tenant, a user touching Site 12 must actually hold rights on Site 12. This is also where role-based access control does its work; our authentication and session security guide covers that half of the story.
Application-layer checks are necessary - they carry the business logic RLS cannot express - but they are not sufficient. They are code, code has bugs, and one endpoint that forgets the tenant filter is a leak. Which is why the second layer exists.
PostgreSQL row-level security attaches policies directly to tables: once enabled, every query against a protected table is automatically filtered to the rows the current tenant context may see, no matter what SQL the application sends. If a developer ships an endpoint that forgets its WHERE clause, the database still returns only the correct tenant's rows. Isolation stops being a per-endpoint coding discipline and becomes a database guarantee.
Merobix enforces PostgreSQL row-level security on customer-owned records as its second isolation layer, beneath the application checks. Two other design details matter and are worth asking any vendor about:
RLS has one soft spot: it trusts the tenant context the application sets on the connection. If an attacker - or a bug - can flip that context from tenant A to tenant B before the query runs, the database will faithfully enforce isolation for the wrong tenant. The strongest mitigation is a signed database request context: the tenant context is cryptographically bound when the request enters the system, and the database layer rejects any context that was not properly signed. Application code cannot silently switch tenants, because it does not hold the ability to forge the signature.
Merobix implements exactly this - a signed request context that prevents unauthorized tenant-context changes - and we consider it the difference between "RLS as a safety net" and "RLS as a boundary." When you evaluate any vendor, this is the sharpest single question in the category: "What prevents your application code from setting the wrong tenant context on a database connection?" Engineers who have solved it will light up; vendors who have not will change the subject.
Data isolation gets the attention, but tenants also share compute, database capacity, and message brokers - and in SCADA, performance interference is an operational risk, not an inconvenience. If another customer's alarm storm or runaway historian query delays your high-level alarm by four minutes, the tenant boundary failed you just as surely as a data leak. Ask vendors how one tenant's worst day affects yours:
A well-isolated platform still sees cross-tenant access attempts - probing scripts, misconfigured integrations, curious users editing URLs. What separates mature platforms is what happens next. The weak pattern returns a 404 and forgets it happened. The strong pattern logs every cross-tenant denial and raises a security alert - treating denials as auditable security events in the sense of the audit-and-accountability controls catalogued in NIST SP 800-53 Rev. 5 - because a spike in denials scoped to one account is exactly what an attacker probing the boundary looks like. Merobix logs cross-tenant denials and feeds them into runtime threat monitoring alongside privilege probes and repeated authentication failures, with delivery to email, SMS, webhook, or your SIEM. Ask any vendor to show you what a cross-tenant denial event looks like in their audit trail - in a live demo, this takes five minutes and speaks volumes.
You cannot pen-test a vendor's production platform yourself, but you can demand evidence across four fronts:
Key takeaway: Trustworthy multi-tenant SCADA is layered: application authorization that checks site ownership, PostgreSQL row-level security that filters every query at the database engine, a signed request context that stops tenant-switching, performance isolation against noisy neighbors, and cross-tenant denials treated as logged, alerted security events. A vendor should be able to name every one of those layers, show you the denial event, and point to cross-tenant tests in their ongoing validation program. "Logical separation" is not an architecture - it is the absence of one.
Tenant isolation is the set of technical controls that keeps each customer's data, users, devices, and control paths completely separated from every other customer sharing the same cloud SCADA platform. In a multi-tenant platform, many organizations share one application and often one database, so isolation must be enforced by software rather than by physically separate servers. Strong isolation is layered: application-level authorization that checks tenant ownership on every request, database-level enforcement such as PostgreSQL row-level security that filters every query to the current tenant, a protected tenant context that application code cannot silently change, and monitoring that logs and alerts on any cross-tenant access attempt.
Row-level security (RLS) is a database feature - mature in PostgreSQL - that attaches security policies directly to tables, so every query is automatically filtered to rows the current tenant context is allowed to see. It matters for SCADA because it moves tenant isolation from thousands of application code paths, any one of which can have a missed filter, into one policy enforced by the database engine itself. Even if an application bug forgets a tenant filter, RLS still returns only the correct tenant's rows. It converts isolation from a per-endpoint coding discipline into a database guarantee, which is why buyers should specifically ask whether a vendor enforces RLS on customer-owned records rather than relying on application-level filtering alone.
Ask for evidence across four areas. Architecture: have the vendor walk through how a request is bound to a tenant and which layers enforce isolation - expect at least application authorization plus database row-level security. Tamper resistance: ask how the tenant context is protected from being switched by compromised or buggy application code - a signed request context is the strong answer. Detection: ask what happens on a cross-tenant access attempt - it should be denied, logged, and alerted, and you can ask to see such an event in a demo. Testing: ask whether cross-tenant access attempts are part of the vendor's continuous security validation and independent testing program, not just a one-time launch review.
Not automatically. Single-tenant deployment removes the shared-database risk, but it multiplies operational surfaces - every customer instance must be patched, monitored, and hardened separately, and single-tenant instances in practice often lag behind on updates. A well-engineered multi-tenant platform concentrates security investment: one hardened codebase, database-enforced isolation, uniform patching within hours, and centralized threat detection across the fleet. The honest comparison is between a multi-tenant platform with layered, tested isolation and a single-tenant estate with real patch discipline. For operators whose policy requires physical separation, the practical answer is a platform that offers both models - Merobix runs multi-tenant cloud with RLS-enforced isolation and also offers dedicated on-premise or air-gapped deployment.
The noisy-neighbor problem is performance interference between tenants sharing infrastructure: one customer's massive historian query, alarm storm, or misbehaving integration consumes shared compute, database, or broker capacity and degrades service for everyone else. In SCADA this is an availability-of-monitoring issue, not just an annoyance - a delayed alarm is an operational risk. Mitigations to ask about include per-tenant rate limits and request-size limits, bounded and validated queries, durable telemetry ingestion that buffers bursts, and health surfaces that expose telemetry freshness so you can see degradation immediately. Ask vendors specifically how one tenant's worst day affects your alarm latency.
Row-level security, signed request context, cross-tenant denial alerts - ask us to walk the whole request path live and show you the denial event in the audit trail.