Every SCADA vendor tells you their platform is secure. The interesting question is what evidence sits behind the sentence - and most buyers never ask for it, because they are not sure what good evidence looks like. This guide fixes that. It walks through the full validation stack from automated scanning to red teams, shows you how to read a penetration test report and spot the scope games vendors play, explains why cross-tenant testing is the question that matters most in cloud SCADA, and closes with the signals that separate an honest security program from a confident-sounding one.
Part of the Merobix OT security guide collection - vendor vetting to industry compliance.
Verifying SCADA vendor security means demanding evidence across four layers: recent independent penetration tests with real scope and retest results, continuous automated validation on every release, cloud-specific cross-tenant and replay testing, and a standing vulnerability disclosure channel. Here is why anything less is marketing.
Security claims are cheap to make and expensive to verify - which is exactly why marketing pages are full of them. "Bank-grade encryption," "military-grade security," "unhackable architecture": these phrases have no technical content, and a vendor who leads with them is telling you something about how they think buyers evaluate security. Meanwhile, the systems your operation will depend on - the authentication stack, the tenant boundary, the control-command path - either have been adversarially tested or they have not, and the difference does not show up in a brochure.
For cloud SCADA the stakes compound, because you are not just buying software - you are buying the vendor's ongoing operational security. Their engineers hold administrative reach over infrastructure that touches your process data and, in many deployments, your control path. The right posture is the one auditors take: claims are hypotheses; evidence is test results. Your job in procurement is to figure out which validation activities the vendor actually performs, how recently, at what depth, and what happened to the findings. This post is a field guide to doing exactly that; it pairs with our broader 50 vendor security questions bank.
No single activity "proves" security. Mature vendors run a stack, where each layer catches what the previous one cannot:
| Validation Layer | What It Proves | Healthy Cadence | What It Misses |
|---|---|---|---|
| Static analysis (SAST) + secret scanning | Known-bad code patterns and leaked credentials never ship | Every build, blocking the merge | Logic flaws, runtime behavior |
| Dependency / SBOM scanning | Known-vulnerable third-party components are caught and patched | Continuous, with alerting | Zero-days, custom code |
| Automated security regression tests | AuthN/AuthZ, tenant isolation, and replay defenses still hold after every change | Every release | Novel attack paths not yet encoded as tests |
| Independent penetration test | A skilled human adversary probed the real system | At least annually + after major changes | Everything that changed since the test week |
| Red team / adversarial exercise | Detection and response work against a realistic campaign | Periodic, for mature programs | Coverage breadth (goal-driven, not exhaustive) |
| Vulnerability disclosure / bug bounty | Outside researchers have a sanctioned path and incentive to report | Standing, always on | Depth depends on researcher interest |
Two readings of this table matter for buyers. First, the bottom rows get the attention, but the top rows do most of the work - a vendor with blocking static analysis, dependency scanning, and security regression tests on every release is structurally safer than one with a beautiful annual pen test and nothing in between. Second, the layers verify different claims: a pen test cannot tell you the next release is safe, and a scanner cannot tell you an attacker was creative. Ask about the whole stack. This connects directly to software supply chain security - release assurance and signed builds are the layer below all of this.
When a vendor shares pen-test results - typically under NDA, which is reasonable - read them the way an auditor would:
If the vendor will only provide a one-page "attestation letter" summarizing that a test occurred, treat it as weak evidence - letters attest to the existence of an engagement, not its depth or outcome.
Most misleading security evidence is technically true. The mechanisms to watch for:
In multi-tenant cloud SCADA, one security property towers over the rest: customer A must never be able to see or affect customer B - not their telemetry, not their alarms, and above all not their control path. A single isolation flaw is a breach of every tenant simultaneously. Yet generic pen tests frequently under-test it, because meaningful cross-tenant testing requires multiple provisioned tenants and deliberate attempts to break the boundary: requesting foreign object IDs through every API, manipulating tenant context in tokens and requests, and probing shared infrastructure like queues and caches.
So ask three pointed questions. How is isolation enforced? The strong answer is defense in depth ending in the database - application-layer authorization backed by PostgreSQL row-level security, so a missed filter in code still cannot cross tenants; Merobix additionally signs the database request context so tenant identity cannot be silently swapped mid-request. Is the boundary monitored? Cross-tenant denial attempts should be logged and raise security alerts - probing should be visible, not silent. Is it tested on a schedule? Here honesty matters more than gloss: Merobix runs cross-tenant denial monitoring in production today and is building recurring cross-tenant and replay/forgery testing - alongside independent penetration testing - into its continuous validation program, with SOC 2 readiness evidence collection running in parallel. That is the truthful shape of a young-but-serious program, and it is the framing you should expect: shipped enforcement, shipped monitoring, and a validation cadence stated as a commitment, not a past-tense trophy. The full topic gets its own treatment in our multi-tenant isolation guide.
A vulnerability disclosure policy (VDP) is table stakes: a published, sanctioned way for researchers to report issues - the coordinated-disclosure model CISA's Coordinated Vulnerability Disclosure Program applies to industrial control systems at national scale - with a commitment not to prosecute good-faith research and a track record of acknowledging and fixing reports. A paid bug bounty adds incentive and continuous outside attention, but interpret it with nuance - big bounty programs correlate with mature teams, yet a small vendor with a VDP, fast fixes, and honest advisories can be healthier than a large one with a bounty and a backlog. The real signal is what happens after a report: response time, fix time, and whether customers are notified when it matters. A vendor with no disclosure channel at all is choosing not to hear bad news, which tells you how internal bad news is handled too.
The deeper problem with pen-test-as-proof is arithmetic. A cloud platform shipping weekly makes roughly fifty releases a year; an annual test examines one of them. Everything else reaches your operations checked only by whatever automated and procedural validation runs on every release. That is why the modern standard is continuous - the posture NIST formalizes as continuous monitoring in SP 800-53's security assessment controls: static analysis, dependency and secret scanning, and security regression suites as blocking release gates; isolation, replay, and restore/failover exercises on a calendar; independent testing layered on top as the periodic deep probe. When a vendor describes their program, listen for per-release guarantees first and annual events second - and expect roadmap honesty here, since almost every vendor (Merobix included, per its published program) is still hardening parts of this pipeline. The follow-up question that cuts deepest: "What security checks would have to fail for a release to be blocked from shipping?" Vendors with real release gates answer instantly.
After enough evaluations, you learn that how a vendor talks about security predicts what you will find inside. Green flags:
Red flags: absolute claims ("unhackable," "100% secure"), zero-finding reports presented proudly, refusal to discuss scope, certification logos that dissolve when you ask for the report, and security answers that only the salesperson - never an engineer - is allowed to give.
Key takeaway: Verification beats assurance. Demand the full stack - per-release automated gates, recent independent pen tests with real scope and retest evidence, cross-tenant testing for anything multi-tenant, and a standing disclosure channel - and grade vendors on the honesty of their answers as much as the content. A vendor who says "here is what testing found, here is the fix, and here is what we are still building" is showing you a working security program; a vendor who says "nothing to see" is showing you a brochure. See how Merobix documents its own program, current and roadmap, on the security architecture page.
Ask for evidence, not adjectives, across four layers: independent penetration test results (scope, methodology, findings, and retest confirmation - under NDA if needed), continuous automated validation (static analysis, dependency scanning, and security tests running on every release), cloud-specific testing such as cross-tenant isolation and replay or forgery testing, and a vulnerability disclosure policy with a track record of published fixes. Then verify architecture claims live in a demo: watch MFA, role enforcement, and audit logging actually work. A vendor who explains what testing found and fixed is more credible than one who claims testing never finds anything.
A credible report names the testing firm and dates, defines the scope precisely (which applications, APIs, networks, and environments were tested and which were excluded), describes the methodology and whether testing was black-box, gray-box, or authenticated, lists findings with severity ratings and reproduction detail, and - critically - documents remediation and retest results showing the issues were actually fixed. Be wary of one-page summary letters, tests older than about twelve months, scopes that exclude the components you will depend on, and reports with zero findings, which usually indicate a shallow test rather than a flawless product.
Cross-tenant testing deliberately attempts to read or modify one customer's data from another customer's account - probing APIs with foreign identifiers, manipulating tenant context, and abusing shared infrastructure. It matters because tenant isolation is the defining security property of multi-tenant cloud SCADA: a single flaw can expose every customer at once, and generic penetration tests often skip it. Ask vendors how isolation is enforced (database-level controls such as row-level security, not just application filters), whether cross-tenant attempts are logged and alerted, and whether isolation is exercised by dedicated recurring tests rather than one historical assessment.
No. An annual penetration test is a snapshot of one build on one week, while a cloud platform may ship changes weekly or daily - so most of the code your operations depend on was never seen by last year's test. Annual independent testing remains valuable as a deep adversarial exercise, but it needs to sit on top of continuous validation: static analysis and dependency scanning on every build, automated security regression tests for authentication and authorization, isolation and replay testing, and a disclosure channel that keeps finding issues between engagements. Ask vendors what security checks run on every release, not just what happened at the last annual engagement.
Honest vendors are specific and comfortable with imperfection. Good signs: they share real test reports under NDA rather than summary letters, they discuss findings and how they were fixed, they distinguish shipped controls from roadmap items without being pushed, they describe certifications accurately (for example, a SOC 2 readiness program in progress rather than a vague certified claim), they publish a vulnerability disclosure channel, and their team can explain threat models unprompted. Red flags: claims of unhackable or military-grade security, zero-finding reports, refusal to discuss scope, and certification logos that do not survive a request for the actual report or certificate scope.
Bring every question in this guide to a live session - tenant isolation, release gates, detection, and the validation program we are building - and grade the answers yourself.