Every decision your operation makes - opening a valve, dispatching a crew, billing a customer, filing a compliance report - rests on one assumption: the numbers on the screen are the numbers the sensor produced. Stuxnet's most enduring lesson was that this assumption can be attacked directly, feeding operators normal-looking data while the process runs off a cliff. This guide covers the telemetry threat model, why TLS alone cannot guarantee integrity, how signed envelopes with Ed25519 device identities and replay detection close the gap, and what to demand from any cloud SCADA vendor before you trust their pipeline.
Part of our SCADA security guide library - 60+ articles on securing industrial operations.
Telemetry feels like the boring part of SCADA security - it is "just monitoring data," compared to the obvious stakes of control commands. That instinct is wrong for three reasons. First, operators act on telemetry: a falsified low-pressure reading triggers a real pump start; a suppressed high-level alarm lets a real tank overflow. Manipulated data produces physical consequences without the attacker ever touching a control function. Second, money rides on it: custody transfer, run tickets, and production allocation in oil and gas are computed from telemetry, and a few percent of drift - malicious or accidental - is a commercial dispute. Third, compliance rides on it: emissions reporting, discharge monitoring, and batch records are only as defensible as the integrity of the underlying data.
The historical proof is Stuxnet - the subject of CISA's Stuxnet malware mitigation advisory (ICSA-10-238-01B) - which replayed recorded "normal" sensor values to the monitoring layer while centrifuges tore themselves apart. The 2021 Oldsmar water incident showed the inverse concern: when operators cannot fully trust what the screen shows or who changed it, every reading becomes a question. Integrity is not a monitoring nicety - it is the foundation the rest of the security stack, including the audit trail, stands on.
Four distinct attacks target the telemetry path - all threat classes recognized in the NIST SP 800-82 Rev. 3 guide to operational technology security - and each needs a different defense:
Note what is missing from most SCADA deployments: all four defenses. The common posture - shared MQTT credentials, TLS to the broker, no message signing, no freshness alerting - addresses only casual eavesdropping. It leaves every attack above open to anyone who compromises one credential or one intermediate component.
"All data is encrypted with TLS" is the most common - and most incomplete - answer vendors give on data integrity. TLS - currently version 1.3, specified in RFC 8446 - is genuinely necessary: it prevents reading and altering traffic on the wire, and Merobix uses TLS across cloud, MQTT, and industrial connections. But TLS has two structural limits for telemetry.
First, TLS protects the pipe, not the data. A TLS session terminates at each hop - the broker, the load balancer, each internal service. After termination the payload is plaintext to that component. A compromised broker or mid-tier service can modify readings, and downstream consumers have no way to notice, because each hop's TLS session is individually valid. Second, TLS authenticates connections, not messages. Anything holding valid connection credentials can publish fabricated data, and TLS has no concept of "this exact message was already delivered an hour ago" - so replay passes straight through.
The fix is to make integrity a property of the message itself: sign the data at the device, verify at the platform, and treat everything in between - brokers, networks, buffers - as untrusted transport. Cryptographers call this end-to-end integrity; in practice it means a signed envelope.
In a signed-telemetry architecture, each device proves both who produced a reading and that it was not altered. Here is how the Merobix pipeline implements it:
This converts the trust question from "did this arrive over an authenticated connection?" to "was this specific message produced, unaltered, by this specific registered device?" - a question with a cryptographic answer. Merobix is also extending this guarantee to make signed telemetry mandatory across every ingestion path, including a signing migration for legacy gateway traffic, so no unsigned side door remains. The device-side half of this story - signed gateway artifacts, update verification, and outbound-only connectivity - is covered in our OT network security guide.
A signature proves origin and integrity, but a replayed message still carries a valid signature - it really was produced by the device, just not now. Replay defense works by making every message unique and time-bound, then rejecting anything that violates either property:
| Attack | TLS-Only Pipeline | Signed Envelope Pipeline |
|---|---|---|
| Impersonating a device with stolen broker credentials | Accepted - connection is valid | Rejected - no valid device signature |
| Altering a reading at a compromised broker or mid-tier hop | Undetected - each hop re-encrypts | Detected - digest and signature break |
| Replaying an hour of captured "normal" readings | Accepted - messages are individually valid | Rejected - stale sequence numbers and timestamps |
| Duplicating messages to skew totals | Double-counted | Deduplicated by sample ID |
| Proving data provenance to an auditor years later | Impossible - no per-message evidence | Signature and envelope metadata retained with the record |
Field connectivity fails - cellular dead zones, storm damage, carrier maintenance. What happens to integrity during the gap separates serious pipelines from fragile ones. The correct pattern is store-and-forward: the gateway buffers readings locally with their original timestamps, sequence numbers, and signatures, then transmits when the link returns. The historian ends up gapless, and - critically - late-arriving data is verifiable to exactly the same standard as live data, with the record honestly showing capture time versus delivery time. That distinction matters for custody transfer and compliance reporting, where "measured at 03:00, delivered at 06:40" and "measured at 06:40" are very different statements.
On the receiving side, demand durable acceptance: telemetry should be persisted the moment the platform accepts it, before any downstream processing, so a mid-pipeline crash cannot silently drop verified data. Merobix implements both halves - gateway store-and-forward buffering for outages, and durable telemetry acceptance ahead of historian processing. The failure mode to screen out when evaluating vendors: backfilled data stamped with arrival time, or buffered data that loses its signatures - both quietly corrupt the historical record in ways you may discover only during a dispute. Weigh this alongside the broader resilience questions in our cloud vs on-premise comparison.
Integrity extends beyond "not tampered with" to "honestly described." Every stored reading should carry its provenance - sample ID, timestamp, quality flag, source device, site, and tenant - so any number on any screen can be traced to a specific verified message from a specific device. Quality flags matter operationally: a value the driver marked questionable must render differently from a good one, because an operator who cannot distinguish them will eventually act on bad data.
Freshness is the last-value trap. Most HMIs display the most recent reading indefinitely, so a silenced device looks identical to a healthy, stable process. The platform should track telemetry freshness per device and surface staleness as a first-class alarm - Merobix exposes health surfaces for exactly this, and its runtime monitoring treats a quiet device as a signal, not a blank. Suppression is an attack (and a failure mode) that only freshness monitoring catches.
Seven questions, in the order that eliminates vendors fastest:
Any vendor with a real integrity architecture will answer these specifically and enjoy doing it. Vague appeals to "bank-grade encryption" mean the architecture is TLS and hope - pressure-test the answers in a live demo.
Key takeaway: TLS protects the pipe; signatures protect the data. A trustworthy telemetry pipeline signs every reading at the device with a unique key, verifies before storage, rejects replays by sequence and time, preserves signatures through outages, and alarms on silence. That is the difference between "the connection was encrypted" and "this exact number came from this exact sensor, unaltered - and we can prove it." The full Merobix integrity pipeline is documented on our security architecture page.
Data integrity matters most when someone acts on it - the same signing principles carry into safe setpoint writes and remote control security.
Signed telemetry means each reading - or batch of readings - leaves the field device wrapped in an envelope carrying a cryptographic signature produced by a private key that only that device holds. The receiving platform verifies the signature against the device's registered public key before accepting the data. If verification fails, the data is rejected and flagged. This proves two things TLS alone cannot: that the data originated from the specific registered device (not merely from something that reached the broker), and that the payload was not altered anywhere along the path. Merobix devices generate Ed25519 signing identities at registration and wrap MQTT telemetry in signed envelopes.
A replay attack is when an attacker captures legitimate telemetry messages and re-sends them later, unmodified. Because the messages were genuinely produced by a real device, signatures and encryption alone do not stop them - the classic example is replaying an hour of normal tank-level readings to hide an ongoing overfill, which is essentially what Stuxnet did to its operators' screens. Defenses work by making every message unique and time-bound: monotonically increasing sequence numbers, embedded timestamps checked against acceptance windows, and unique sample identifiers. The platform rejects anything out of sequence, outside the time window, or already seen.
TLS is necessary but not sufficient. It protects data in motion between two endpoints - nobody can read or alter traffic on the wire. But TLS terminates at each hop: at the broker, at load balancers, at every intermediate service. After termination, the data is plaintext to that component, so a compromised broker or middle-tier service can alter readings without detection. TLS also authenticates the connection, not the data - anything holding valid credentials can inject fabricated values, and TLS cannot stop the replay of captured messages. Message-level signing with sequence numbers and digests closes those gaps by making integrity a property of the data itself, verified end to end.
Store-and-forward means the gateway buffers readings locally during a connectivity outage and transmits them when the link returns, so the historian has no gaps. Done correctly, buffered records keep their original timestamps, sequence numbers, and signatures, so late-arriving data is verifiable to the same standard as live data, and the record shows it was captured on time but delivered late - which matters for custody transfer and compliance. Done poorly, backfilled data gets stamped with arrival time or loses its integrity metadata, quietly corrupting the historical record. Ask vendors specifically how buffered data is signed, sequenced, and timestamped.
Ed25519 is a modern elliptic-curve digital signature algorithm that fits embedded and gateway hardware well: small keys (256-bit) and signatures, fast signing and verification on modest CPUs, and a design that avoids many implementation pitfalls of older signature schemes. For device identity, each device generates its own keypair - the private key never leaves the device - and registers the public key with the platform. Every signed envelope then proves device origin without shared secrets that could be extracted from one device and reused to impersonate a fleet. It is a widely trusted primitive, used across SSH, modern PKI, and secure messaging.
Ed25519 device identities, signed envelopes, replay detection, and store-and-forward that preserves the truth - see the Merobix telemetry pipeline end to end.