"Is the data encrypted?" is the first security question most SCADA buyers ask - and "yes" is the least informative answer a vendor can give. Encryption is not one thing: data moving between a gateway and the cloud, data sitting in a database, an email address you need to search, and a password you must verify all demand different cryptographic tools, and a platform that nails one layer while skipping another leaves exactly the gap an attacker will find. This guide breaks SCADA encryption into its real layers - transit, rest, search, and credentials - explains what each protects and what it cannot, and arms you with the specific questions that expose a shallow encryption story.
Part of the SCADA Security Hub - 60+ guides on SCADA security, compliance & certifications.
Think of your operational data as living in four states, each with its own threat model. In transit, it crosses networks you do not control - cellular carriers, the public internet, corporate LANs - where interception and modification are the risks. At rest, it sits in databases and backups, where the threats are stolen storage, leaked backups, database compromise, and over-curious insiders. In search, some encrypted fields still need to be found again - you cannot log a user in if you cannot look up their email - which naively forces a choice between security and function. And credentials - passwords, reset tokens, API secrets - are the special case where the right answer is not encryption at all.
A serious platform answers all four with the right tool per layer. A shallow one answers "TLS" and stops. Keep that frame as we go through each layer - it is also the structure of the encryption row in any good SCADA RFP evaluation.
Transport encryption is the mature layer, and the standard is simple to state: TLS on every connection, no exceptions, enforced rather than optional. In a cloud SCADA architecture that means four distinct paths, and you should ask about each: the browser or mobile session to the platform (HTTPS, with HSTS so a downgrade to plain HTTP is refused by the browser itself), the gateway's uplink from the site to the cloud, the MQTT or message-broker links that carry telemetry internally, and connections to industrial equipment where the protocol supports it. Merobix runs TLS across its cloud, MQTT, and industrial connections, with HTTPS and HSTS at the application edge - and because its gateway makes only outbound connections, there is no inbound listener to misconfigure; the transport story and the network story reinforce each other, as covered in our OT network security guide.
Two qualifiers separate real answers from checkbox answers. First, modern versions: TLS 1.2 minimum with 1.3, specified in RFC 8446, preferred; a vendor still accepting old protocol versions for "compatibility" has an unencrypted problem wearing an encrypted costume. Second, certificate validation: encryption without verifying who you are talking to stops eavesdroppers but not impersonators. This matters especially for webhooks and integrations - Merobix, for example, delivers webhooks to pinned IPs while still validating TLS against the original hostname, closing a subtle gap where DNS manipulation could redirect "encrypted" traffic to an attacker.
Now the uncomfortable part: most industrial protocols cannot do any of this. Classic Modbus - RTU over serial and standard Modbus TCP - has no encryption and no authentication; anyone who can reach the PLC on the network can read and write its registers. Much fielded BACnet and EtherNet/IP traffic runs similarly open - a class of legacy-protocol weakness documented at length in the NIST SP 800-82 Rev. 3 guide to OT security. Newer options exist - OPC UA has strong built-in signing and encryption modes, DNP3 has a secure authentication variant, and TLS-wrapped Modbus exists on paper - but the installed base of devices in the field will speak unencrypted protocols for decades.
Since you cannot upgrade the protocol, you contain it. The pattern that works is the gateway boundary: unencrypted industrial traffic lives only on an isolated OT segment, traveling short, controlled distances between devices and a local gateway; the gateway terminates the legacy protocol and carries the data onward inside TLS. The plaintext never crosses a network you do not fully control. This is exactly how the Merobix gateway operates across its drivers for major industrial protocols spanning 7 families - Modbus RTU and TCP, OPC-UA, MQTT, DNP3, BACnet/IP, EtherNet/IP, and HTTP - polling locally, then pushing everything outbound over TLS. Transport encryption alone still does not prove the data was not altered before or after the pipe; message-level signing addresses that, and it is the subject of our companion guide on telemetry integrity and signed data.
"Encrypted at rest" usually means full-disk or storage-volume encryption - and buyers should understand precisely how little that covers. Disk encryption protects against one scenario: physical theft of the storage medium. To every running process, the data is transparently decrypted; a SQL injection, a leaked database credential, a compromised service, or an insider with query access all see plaintext. In a cloud data center, where physical disk theft is the least likely attack in the catalog, disk-level encryption is the floor, not the achievement.
The layer that changes outcomes is field-level (application-layer) encryption: sensitive values are encrypted by the application before being written, so even legitimate database access yields ciphertext. If a backup leaks or an attacker dumps tables, the sensitive fields are opaque without keys the database never held. Merobix encrypts sensitive application data at this layer, on top of transport and storage protections. The honest engineering trade-off: field-level encryption is applied selectively - encrypting every telemetry point would cripple historian queries for little benefit, so the discipline is classifying data and encrypting what is genuinely sensitive: personal identifiers, credentials-adjacent material, and commercially sensitive configuration. Ask vendors which fields get application-layer encryption; "all of it" and "none of it" are both wrong answers.
Field-level encryption creates a functional problem worth understanding, because how a vendor solved it reveals engineering depth. Properly randomized encryption means the same email address encrypts to different ciphertext every time - so the database can no longer answer "find the account with this email" without decrypting every row. Historically, vendors resolved this by quietly leaving searchable identifiers unencrypted. There is a better answer.
A blind index stores a separate keyed hash - an HMAC computed with a dedicated key - alongside the encrypted value. To find a record, the platform computes the same keyed hash of the search term and matches it against the index: exact-match lookup succeeds, the plaintext is never exposed, and an attacker who steals the database cannot reverse the index or even run a dictionary attack without the index key. Merobix uses blind indexes to search encrypted identifiers such as email addresses - login lookup works, and the underlying address stays encrypted. It is a niche-sounding detail that makes an excellent interview question: a vendor who can explain their blind-index design has thought about data protection beyond the checkbox; one who has never heard the term probably left the "encrypted" fields searchable by not encrypting them.
Passwords are the case where encryption is the wrong tool entirely. Anything encrypted can be decrypted by whoever holds the key - and you do not want a key to your users' passwords to exist at all. The correct approach is one-way hashing with a modern, deliberately slow algorithm from the bcrypt, scrypt, or Argon2 (RFC 9106) family, salted uniquely per password - the salted, one-way storage approach NIST SP 800-63B requires for stored passwords. Slow is the feature: if the credential table ever leaks, each password guess costs the attacker real compute, turning an instant breach into a slog that buys you time to force resets. Fast hashes like MD5 or SHA-1, or reversible encryption, remain disturbingly common in legacy SCADA products - it is worth asking directly.
The same one-way logic extends to tokens: password reset links and registration invitations are bearer credentials, and a database that stores them in plaintext hands out live account takeovers when it leaks. Store only the token's hash; verify by hashing what the user presents. Merobix applies modern password hashing and stores reset and registration tokens hashed. Related credential hygiene worth probing: brute-force lockout, MFA, and API key scoping - the identity half of this story lives in our SCADA authentication guide.
| Layer | Protects Against | Does Not Protect Against | Question to Ask the Vendor |
|---|---|---|---|
| TLS in transit | Eavesdropping and tampering on the wire between endpoints | Compromised endpoints or brokers; replayed messages; anything after the pipe ends | Which TLS versions, on which connections - including MQTT and gateway links? |
| Disk / volume encryption | Physical theft of storage media | Any access through a running system: SQL injection, leaked credentials, insiders | Is that your only at-rest layer? |
| Field-level encryption | Database dumps, leaked backups, insider queries reading sensitive values | Compromise of the application itself while keys are in use | Which specific fields are application-layer encrypted? |
| Blind indexes | Exposing identifiers to make them searchable | Range or fuzzy queries - exact match only, by design | How do you search encrypted identifiers like email? |
| Password / token hashing | Credential theft even in a full database leak | Phishing and credential reuse - pair with MFA | Which hashing algorithm, and are reset tokens hashed too? |
Encryption gets outsized attention in procurement because it is easy to ask about - but it is one control family among several, and it does nothing about an authorized user doing the wrong thing, a stolen credential used through the front door, or a fabricated reading signed into an unauthenticated pipeline. Encrypted transport happily delivers a malicious setpoint; an encrypted database faithfully stores falsified telemetry. The controls that catch those live elsewhere: authentication and MFA, write-path safeguards on control actions, message-level signing, and tamper-evident audit trails.
Key management is the other honest caveat: encryption is only as strong as the discipline around key storage, separation, and rotation. And on algorithm claims - treat "military-grade encryption" as a marketing tell, not a specification. The mark of a trustworthy vendor is naming standard primitives and describing layers plainly, the way this guide has, and framing their assurance program honestly: Merobix documents its control architecture publicly, maps controls to IEC 62443, the industrial cybersecurity series published by ISA and IEC, and runs a readiness program against the AICPA's SOC 2 Trust Services Criteria with independent validation as an ongoing effort rather than claiming finished certifications it does not hold.
Seven questions that surface the whole picture in one meeting:
Key takeaway: demand encryption in layers - enforced TLS on every connection, legacy protocols contained behind a gateway boundary, field-level encryption on genuinely sensitive data, blind indexes so encrypted identifiers stay searchable, and slow-hashed passwords and tokens. A vendor who can walk that stack specifically has an encryption architecture; a vendor who says "bank-grade encryption" has a slogan. The full Merobix data-protection design is documented on the security architecture page, and you can walk through it live in a demo.
Look for layered encryption, not a single claim. In transit: TLS on every connection - browser to platform, gateway to cloud, MQTT broker links, and industrial connections where the equipment supports it - with HSTS enforcing HTTPS. At rest: field-level encryption of sensitive application data on top of any disk or database encryption, so a leaked backup or a curious insider with database access still sees ciphertext. For credentials: passwords stored with a modern slow hashing algorithm, and reset or registration tokens stored hashed. For searchability: blind indexes that allow exact-match lookups on encrypted identifiers. The red-flag answer is a vague 'we use bank-grade encryption' with no specifics about layers.
A blind index solves the conflict between encrypting a field and searching it. If email addresses are encrypted with a randomized scheme, the database cannot answer 'find the account with this email' without decrypting every row. A blind index stores a separate keyed hash (such as an HMAC) of the value: at login or lookup time, the platform computes the same keyed hash of the query and matches it against the index - an exact-match search that never exposes the plaintext, and useless to an attacker who steals the database without the index key. Merobix uses blind indexes to search encrypted identifiers such as email addresses. It matters because it removes the usual excuse for leaving personal identifiers unencrypted.
No. Full-disk or storage-volume encryption protects against exactly one scenario: someone physically stealing the disk or accessing the raw storage medium. To every running process, every database session, every application bug, and every insider with query access, the data is transparently decrypted - a SQL injection or a leaked database credential yields plaintext. Field-level encryption at the application layer closes that gap: sensitive values are encrypted before they are written, so database-level access reveals ciphertext. The practical standard for cloud SCADA is both layers - storage encryption as the baseline and application-layer encryption for sensitive fields.
Never encrypted, never plaintext - hashed, with a modern, deliberately slow password hashing algorithm from the bcrypt, scrypt, or Argon2 family, with a unique salt per password. Slow hashing means that even if the credential database leaks, brute-forcing each password costs the attacker enormous compute, buying time to force resets. Encryption is the wrong tool because anything encrypted can be decrypted by whoever holds the key; a hash cannot be reversed at all. The same logic extends to password reset and registration tokens: store only their hashes, so a database leak does not hand out live account-takeover links. Merobix uses modern password hashing and stores reset and registration tokens hashed.
Classic Modbus - both RTU over serial and standard Modbus TCP - has no encryption and no authentication; anyone with network access to the PLC can read and write registers. A TLS-wrapped variant of Modbus TCP exists but has seen limited adoption in fielded equipment. The practical mitigation is architectural: keep unencrypted industrial protocols confined to an isolated OT network segment that carries them only between the devices and a local gateway, and let the gateway terminate the legacy protocol and carry the data onward over TLS. That way the unencrypted traffic never leaves a controlled network zone. This gateway pattern is how Merobix handles legacy protocol security across its drivers for major industrial protocols.
TLS on every path, field-level encryption, blind indexes, and hashed credentials - walk the full data-protection stack with an engineer, layer by layer.