50 Security Questions to Ask Your Cloud SCADA Vendor
Merobix Engineering • • 12 min read
Every cloud SCADA vendor's website says "enterprise-grade security." The only way to find out what that actually means is to ask questions the marketing department did not prepare for. This is the question bank we would use to evaluate any platform - including our own: 50 questions across seven categories, each with a note on what a good answer sounds like and the red flags that should end the conversation. Use it in demos, RFPs, and security reviews; a well-run session with these questions separates architecture from adjectives in about an hour.
Two rules before you start. First, ask open questions - "how is tenant isolation enforced?" not "do you have tenant isolation?" - because yes/no questions always come back yes. Second, grade answers on specificity: engineers who built a control describe it in mechanisms (row-level security, Ed25519 signatures, idempotency keys); vendors who did not describe it in adjectives (robust, hardened, bank-level). The seven categories these vendor security questions cover: identity and access, tenant isolation and data protection, telemetry and edge devices, control actions, detection and incident response, network and API security, and supply chain and resilience. This question bank pairs with our 12-control cloud SCADA security checklist - the checklist tells you what to demand, these questions tell you how to find out whether it exists.
Identity & Access (Questions 1–8)
What MFA methods do you support, and on which plans? Good: TOTP everywhere, FIDO2/passkeys available. Red flag: MFA is an enterprise-tier upsell, or SMS-only - a channel the NIST SP 800-63B digital identity guidelines have restricted for years.
Do you support phishing-resistant authentication such as passkeys or hardware keys? Good: yes, with an enrollment story. Red flag: "TOTP is enough for everyone."
What roles exist, and can permissions be scoped per site? Good: distinct roles (viewer through admin) plus site-level authorization. Red flag: admin/user only, global scope.
Does RBAC gate control actions - setpoint writes and commands - or only screen visibility? Good: control actions require specific roles and, ideally, competency checks. Red flag: anyone who can see a tag can write it.
How do sessions expire, and can an admin revoke all sessions for a user instantly? Good: configurable expiry, revocation, logout-everywhere. Red flag: sessions live until the browser closes.
Are concurrent sessions limited and visible? Good: limits plus a session list. Red flag: no idea how many places an account is logged in.
What happens after repeated failed logins? Good: brute-force detection with persistent lockout requiring deliberate reinstatement. Red flag: a lockout that auto-resets in minutes, or none.
Do high-risk workflows require step-up authentication? Good: re-verification at the moment of a critical action, such as signing a permit. Red flag: one login unlocks everything for eight hours. (Our SCADA authentication guide covers this whole category in depth.)
Tenant Isolation & Data Protection (Questions 9–16)
How is tenant isolation enforced, at which layers? Good: application authorization plus database row-level security - two independent layers. Red flag: "logical separation" with no mechanism named.
How is the tenant context protected from tampering? Good: a signed request context the application cannot silently alter. Red flag: a tenant ID column filtered in application code and nothing else.
What happens when a cross-tenant access attempt occurs? Good: denied, logged, security-alerted. Red flag: "that can't happen."
Is cross-tenant access part of your ongoing security testing? Good: yes, with test cases in continuous validation. Red flag: tested once at launch. (Full detail in our tenant isolation verification guide.)
What exactly is encrypted at rest - disks, databases, or fields? Good: field-level encryption of sensitive data, with blind indexes for searching encrypted identifiers. Red flag: disk encryption presented as the whole answer.
How are passwords and reset tokens stored? Good: modern password hashing; reset and registration tokens hashed, never stored raw. Red flag: hesitation, or "encrypted."
Are audit records tamper-evident? Good: immutable, chained records for sensitive events with verification tooling. Red flag: logs in an editable table.
Can we export our data and audit history - and leave? Good: retention and customer-export workflows exist today. Red flag: export requires a services engagement.
Telemetry, Devices & the Edge (Questions 17–24)
Does each gateway or device have unique credentials? Good: unique registration and credentials per device. Red flag: a shared fleet secret.
Is telemetry cryptographically signed, and by what identity? Good: device-generated signing keys (Merobix uses Ed25519) with signed envelopes. Red flag: TLS alone presented as data integrity.
How do you detect replayed or forged telemetry? Good: sequence numbers, timestamps, payload digests, replay detection. Red flag: blank stare.
What happens to data during a connectivity outage? Good: store-and-forward buffering at the gateway, durable acceptance in the cloud. Red flag: gaps in the historian.
What direction do gateway connections flow? Good: outbound-only TLS, zero inbound rules. Red flag: inbound ports or a VPN into the OT network.
How are gateway software updates delivered and verified? Good: signed artifacts verified before install. Red flag: unsigned downloads or manual USB updates.
Which industrial protocols are supported, and how are those connections secured? Good: a real driver list (Merobix ships drivers across the major protocol families) with TLS where the protocol allows. Red flag: "we support everything."
Can the platform run on-premise or air-gapped if policy requires? Good: yes, with stated trade-offs. Red flag: cloud-only with no exit path - see our cloud vs on-premise comparison for how to weigh this.
Control Actions & Operational Safety (Questions 25–31)
How do you limit which tags can be written at all? Good: an explicit writable-tag allowlist; everything else read-only. Red flag: write access follows read access.
Are setpoint values validated against bounds before dispatch? Good: per-tag bounds checked server-side. Red flag: validation only in the browser.
How do you prevent duplicate or stale commands from executing twice? Good: idempotency handling and command expiry. Red flag: retries just resend.
Can you show the lifecycle of a command? Good: pending, applied, verified, failed, expired states visible to the operator. Red flag: fire-and-forget writes.
Is there read-back verification that the device actually took the value? Good: yes, where the protocol supports it. Red flag: assumed success.
Can management-of-change or pre-startup safety review gates be enforced in the platform? Good: configurable approval gates before sensitive changes. Red flag: process lives entirely in paper.
Is every command and acknowledgement audit-recorded against a named user? Good: yes, immutably. Red flag: shared operator accounts anywhere in the answer.
What does the platform detect at runtime? Good: cross-tenant denials, privilege probes, repeated auth failures, suspicious control activity. Red flag: "we review logs."
How are security alerts delivered, and what guarantees delivery? Good: a durable outbox with retry and dead-letter handling across email, SMS, webhook, SIEM. Red flag: best-effort email.
Can security events stream to our SIEM? Good: yes, in a documented format. Red flag: CSV export on request.
How would you detect and notify us of a breach affecting our tenant? Good: defined detection, notification commitments in the contract. Red flag: no articulated process.
Can we monitor platform health and telemetry freshness ourselves? Good: health surfaces for API dependencies and data freshness. Red flag: "check the status page."
Can administrators verify the audit chain independently? Good: verification tooling for chained records. Red flag: trust us.
Can we see exactly what version of the software is serving us? Good: build or Git-SHA visibility of deployed services. Red flag: versioning is internal only.
Network, API & Application Security (Questions 39–44)
What inbound firewall rules does your architecture require at our sites? The only right answer is none. Anything else weakens the OT network segmentation that NIST SP 800-82 Rev. 3, the guide to OT security, treats as foundational - the reasoning is laid out in our OT network security guide.
How are API keys scoped and managed? Good: scoped keys with lifecycle and instant revocation. Red flag: one master key per account.
What rate limits and request validation protect the API? Good: rate limits, size limits, strict validation, bounded outbound requests. Red flag: none articulated.
How do you prevent SSRF through connectors and webhooks? Good: SSRF defenses plus pinned-IP webhook delivery with proper TLS validation. Red flag: the acronym needs explaining.
What browser-side protections are enforced? Good: HTTPS with HSTS, restrictive CSP, clickjacking and MIME-sniffing protection, trusted-origin CORS. Red flag: "we use HTTPS."
Are production API docs, debug endpoints, and sensitive paths exposed? Good: disabled or blocked in production, coarse public health responses only. Red flag: a live Swagger console on the production domain.
How do you validate a release before it ships? Good: automated build, test, and security checks with a clear gate; the strongest vendors are moving to deploys only from a fully green, signed build. Red flag: manual pushes to production.
How are backups validated, and when did you last run a restore drill? Good: archive validation, controlled restore tooling, a recent drill date. Red flag: backups exist but have never been restored.
Are you certified under SOC 2, the AICPA's Trust Services attestation framework - and if not, what exactly is your program status? Good: either a current report, or an honest readiness program with evidence collection under way. Red flag: a certification logo with no report behind it. (Merobix, for the record: SOC 2 readiness program in progress, controls mapped to IEC 62443 - not certified, and we say so.)
When was your last independent penetration test, and what was in scope? Good: named scope including the multi-tenant boundary, findings remediated, or a candid statement that independent testing is part of an ongoing validation program. Red flag: "our developers test it."
Which requirements of the ISA/IEC 62443 series published by ISA have you mapped your platform against? Good: a specific mapping exercise with known gaps. Red flag: "we're compliant with 62443" as a blanket claim.
What security work is on your roadmap right now? Good: a concrete list - every honest vendor has one. Red flag: "there are no gaps." This is the single best trust probe in the entire bank.
Scoring the Answers
You will not get fifty perfect answers from anyone, including us. What you are measuring is the shape of the answers across the whole session:
Dimension
Strong Vendor Sounds Like
Red Flag Sounds Like
Specificity
Names mechanisms: row-level security, signed envelopes, idempotency, dead-letter queues
Blurry: "compliant with SOC 2 and ISO 27001" with nothing to show
Architecture posture
Zero inbound ports, unique device identity, signed updates
Open a port, share a credential, trust the LAN
Weight the categories by your deployment. Read-only remote monitoring can tolerate weaker answers on questions 25–31; the moment the platform writes setpoints to real equipment, that category becomes pass/fail. If you are formalizing this into a procurement, our enterprise SCADA buyer's guide shows where security scoring fits in the wider evaluation.
Key takeaway: The goal of vendor security questioning is not to find a vendor with fifty perfect answers - it is to find a vendor who answers in mechanisms instead of adjectives, shows evidence instead of logos, and tells you their gaps before you find them. Question 50 ("what security work is on your roadmap?") is the fastest trust test in the bank: every honest vendor has a real answer, and every dishonest one claims there is nothing left to do.
We publish our own answers to this question bank openly: the shipped architecture is on the Merobix security page, roadmap items are labeled as roadmap, and you can put any of the fifty questions to our engineers directly in a live demo - including the ones we answer with "in progress."
Frequently Asked Questions
What security questions should I ask a cloud SCADA vendor?
Organize your questions into seven categories: identity and access (MFA, roles, sessions, lockout), tenant isolation and data protection (row-level security, encryption, audit trails), telemetry and edge devices (signed data, replay protection, gateway architecture), control actions (writable-tag allowlists, setpoint bounds, command verification), detection and incident response (runtime monitoring, SIEM export, alert delivery), network and API security (inbound firewall rules, API keys, webhooks), and supply chain and resilience (build integrity, backups, restore drills, compliance program status). Ask open-ended questions rather than yes/no ones, and grade answers on specificity - real implementations get described in mechanisms, not adjectives.
What are red flags in SCADA vendor security answers?
The biggest red flags are absolute claims (unhackable, military-grade, 100 percent secure), vague abstractions where a mechanism should be (logical separation instead of a named isolation mechanism like row-level security), certifications claimed without a report or certificate to show, security features that exist only in the top pricing tier, a requirement to open inbound firewall ports into your OT network, shared or default device credentials, and any vendor who claims to have no security gaps or roadmap at all. Honest vendors describe shipped controls, in-progress work, and validation activities separately and can show evidence for each.
Should I ask SCADA vendors for a SOC 2 report or penetration test results?
Yes - but interpret the answers carefully. Ask whether the vendor holds a current SOC 2 report, and if not, whether they run a structured readiness program with evidence collection. Readiness is a legitimate stage for a younger platform as long as it is described honestly and not inflated into a certification claim. For penetration testing, ask who performed the most recent test, its scope (was the multi-tenant boundary in scope?), and how findings were remediated. Many vendors will share a summary letter under NDA rather than a full report. A vendor who runs continuous internal validation and is candid about the status of independent testing is more credible than one who waves at a certification logo but cannot produce documents.
How do I evaluate SCADA vendor answers about multi-tenancy?
Ask three questions in sequence. First, how is tenant isolation enforced - a strong answer names at least two independent layers, such as application-level authorization plus database row-level security, and explains how the tenant context is protected from tampering. Second, what happens when a cross-tenant access attempt occurs - the right answer is that it is denied, logged, and raised as a security alert, not silently ignored. Third, how is isolation tested - look for cross-tenant test cases in the vendor's ongoing validation program, not just a one-time review. Vendors who answer all three with specifics have engineered isolation; vendors who repeat the phrase secure by design have not.