Most industrial intrusions are not discovered by the victim - they are discovered by a third party, weeks or months in. The signals were almost always there: failed logins piling up, an account probing permissions it never used before, telemetry going quiet at odd hours. Nobody was looking, and the alerts that did fire went to an inbox nobody read. This guide covers what security monitoring should look like in a cloud SCADA platform: which OT-specific events deserve detection, why alert delivery is an engineering problem as hard as detection itself, how durable outboxes and dead-letter queues keep alerts from silently vanishing, and how to pull it all into the SIEM your security team already runs.
Part of the Merobix OT security guide collection - vendor vetting to industry compliance.
SCADA threat detection done right is a three-link chain: the platform detects the OT-specific events only it can see (brute force, privilege probes, cross-tenant denials, suspicious control activity), delivers them through a durable outbox with retries and dead-letter handling, and streams them into the SIEM your security team already watches. Most enterprises are missing the first link entirely.
Your IT security team can probably tell you within minutes if a workstation runs unsigned code or a mailbox rule starts forwarding to an external address. Ask them who changed a setpoint at the gas plant last night and you will usually get silence. Enterprise security tooling - EDR, identity monitoring, network detection - stops at the edge of the process world. The SCADA platform is where OT-specific security signals live, and if the platform does not detect and export them, nobody sees them at all.
This blind spot is well documented. Industrial incident reports - including the ICS-CERT alert on the 2015 cyber-attack against Ukrainian critical infrastructure - consistently show long dwell times between initial compromise and discovery, and post-incident forensics almost always finds precursor signals in application logs that no alerting pipeline ever touched. The corrective is not heroics - it is plumbing: the platform detects what only it can see, delivers those events reliably, and hands them to the team whose job is watching. Each of those three steps fails in its own characteristic way, so we will take them in order.
Detection starts with knowing what to watch - continuous security monitoring of OT environments is a core recommendation of NIST SP 800-82 Rev. 3, the federal guide to OT security. Four families cover most of what matters in a cloud SCADA platform, and they map directly to what Merobix's runtime threat monitoring watches today:
Ask vendors for their actual detection list. "We log everything" is not detection - logging is storage (a discipline with its own federal guide, NIST SP 800-92 on security log management), detection is someone or something deciding an event warrants attention within minutes.
Here is the part most evaluations miss entirely: raising an alert and delivering an alert are different engineering problems, and the second one is harder. An alert fired as a fire-and-forget email from application memory has many ways to die silently: the process restarts mid-send, the email provider has an outage, the webhook endpoint times out, a queue overflows under load. These failure modes cluster precisely when alerts matter most - during infrastructure trouble and active attacks.
The engineering answer is the durable outbox pattern. Every security notification is written to persistent storage together with the event that caused it; a separate delivery process works through the outbox, marks confirmed deliveries, and retries failures with backoff. Notifications that exhaust their retries land in a dead-letter queue - parked, visible, and re-sendable once the cause is fixed - rather than evaporating. Merobix implements exactly this: a durable security-notification outbox feeding email, SMS, webhook, and SIEM channels, with retry and dead-letter handling built in.
When you evaluate any platform, ask the morbid question: show me where a failed alert goes. If the answer is a shrug, assume alerts are being lost today.
A SIEM - Splunk, Microsoft Sentinel, QRadar, Elastic, or a managed SOC service - is where detection becomes response - the detection-to-response handoff at the heart of NIST SP 800-61's incident response recommendations - because it is where trained eyes and correlation rules live. SCADA security events belong there, alongside identity and endpoint telemetry, so a SOC analyst can see that the user failing logins on the SCADA platform is the same user whose laptop flagged malware an hour ago. Export approaches differ sharply in reliability:
| Export Approach | How It Works | Failure Behavior | Verdict |
|---|---|---|---|
| Best-effort syslog / log spray | Events streamed as unstructured log lines, often over UDP | Silent loss on any network or collector hiccup; no delivery record | Better than nothing, unverifiable |
| Manual export / CSV pulls | Admin downloads event reports periodically | Days-to-weeks latency; useless for response, marginal for audit | Not monitoring |
| Polling API | SIEM pulls events on a schedule from a platform API | Decent if paginated with cursors; gaps if the poller breaks unnoticed | Acceptable with monitoring on the poller |
| Durable outbox + push delivery | Structured events pushed via webhook/SIEM integration, from persistent queue with retries and dead-letter | Failures are visible, retried, and recoverable; delivery is accounted for | What to demand |
Beyond transport, look at event quality: structured payloads with named user, tenant, site, device, timestamp, and event type - attribution your SOC can pivot on, not prose. That attribution depends on the platform's identity model being real in the first place: named accounts, MFA, and per-role permissions, as covered in our authentication guide.
Alerts are for the next five minutes; audit records are for the next five months. When an incident becomes an investigation - or a regulatory inquiry, or litigation - the audit trail is the evidence, and evidence is only as good as its integrity. Ordinary database rows can be edited by anyone with sufficient access, including the attacker you are investigating. The stronger pattern is immutable, chained audit records for sensitive events: each record cryptographically linked to its predecessor, so deleting or altering any entry breaks the chain visibly.
Merobix writes chained audit records for sensitive events and provides admin audit-chain verification, so an administrator can prove - not assert - that the record is intact before handing it to an auditor or investigator. Every control command and acknowledgement is audited as well, which means the control-path signals discussed above always have a paper trail behind them. The full topic, including what auditors specifically ask for, is covered in our guide to SCADA audit trails and immutable logs.
Security monitoring usually watches for events that happen. In OT you must also watch for events that stop happening. Telemetry that goes stale can mean a dead modem - or a compromised gateway, or an attacker suppressing data to hide a process manipulation, which is precisely what Stuxnet did with fabricated readings. A platform should therefore expose health surfaces: per-site telemetry freshness, API dependency status, and delivery-channel health, so both operators and monitoring systems can distinguish "quiet because nothing is wrong" from "quiet because something is very wrong." Merobix exposes health surfaces for API dependencies and telemetry freshness as part of the platform, and publicly reveals only coarse health responses - detailed status stays behind authentication, where it belongs.
The honest frontier in this space is proving the alert pipeline works before you need it. Merobix is building alert-delivery assurance into the platform roadmap: provider canaries that continuously exercise email and SMS delivery paths end to end, sticky degraded status so a channel that failed stays visibly degraded until verified healthy rather than flapping back to green, and duplicate reconciliation so retry-driven duplicates are reconciled rather than double-alarming an on-call operator at 3 AM. These are roadmap items, framed as exactly that - and the fact that a vendor treats alert delivery as an engineering discipline with its own roadmap is itself a signal worth weighting in your evaluation. The same delivery machinery carries operational alarms, where the stakes are identical: an alarm that does not arrive did not happen.
Key takeaway: SCADA threat detection is a chain with three links - detect the OT-specific events only the platform can see, deliver them through a durable pipeline where failure is visible and recoverable, and land them in the SIEM where your security team actually looks. Most platforms break at link two: alerts that fire but never arrive. Demand the outbox, the retries, and the dead-letter queue by name. Merobix builds all three into the platform - see the security architecture or watch a cross-tenant denial raise an alert live in a demo.
Detection and alerting is one of the twelve control families every cloud SCADA evaluation should cover - the full framework is in our cloud SCADA security checklist, and the API-layer signals that feed this pipeline are covered in the SCADA API security guide.
Yes, and they should. A modern cloud SCADA platform emits structured security events - failed logins, lockouts, privilege probes, cross-tenant denials, suspicious control activity - and delivers them to your SIEM through webhook or SIEM export integrations. That puts OT security in the same console your SOC already watches, with correlation against IT signals. Merobix delivers security notifications over email, SMS, webhook, and SIEM channels from a durable outbox with retry and dead-letter handling, so events survive delivery failures instead of vanishing.
Watch four families. Authentication signals: repeated failed logins, brute-force patterns, account lockouts, and logins from unusual contexts. Authorization signals: privilege probes and, in multi-tenant platforms, cross-tenant denial events. Control-path signals: setpoint writes outside normal patterns, commands from unexpected accounts, and failed or unverified command states. Integrity and health signals: telemetry that stops arriving, replay or signature failures on device data, and audit-chain verification errors. Each of these means something different, but all of them mean look now rather than during the next quarterly review.
A durable outbox means every security notification is written to persistent storage in the same transaction as the event that caused it, and a separate delivery process then works through the queue. If the email provider is down, the webhook endpoint times out, or the platform restarts mid-send, the notification still exists and will be retried. Without this pattern, alerts fired directly from application memory can vanish in exactly the chaotic conditions - outages, failovers, attacks - when you most need them to arrive.
A dead-letter queue is where notifications land after all delivery retries fail - because an endpoint is misconfigured, a provider rejects the message, or a receiver is permanently down. Instead of being silently dropped, the failed notification is parked, visible, and actionable: administrators can see what failed to deliver, fix the cause, and re-send. In security alerting this is the difference between knowing your SIEM feed broke on Tuesday and discovering during an incident that three weeks of events never arrived.
Yes. An IT SOC sees your endpoints, network, and identity providers - it cannot see inside the SCADA platform, where OT-specific signals live: who attempted a setpoint change, which device's telemetry failed signature checks, which account probed permissions it does not have. The platform must detect those itself and export them. The right division of labor is platform-native runtime detection for OT-specific events, streaming into the SOC's SIEM for correlation, triage, and response alongside everything else the SOC watches.
Runtime threat monitoring, durable alert delivery over email, SMS, webhook, and SIEM, and tamper-evident audit chains - see the whole pipeline against your own scenarios.