Securing an OPC UA channel involves two related but separate choices. The security policy decides which cryptographic algorithms are used; the message security mode decides how they are applied. There are three modes - None, Sign, and SignAndEncrypt - and understanding the difference between the last two is central to designing an OPC UA connection that is protected the way you actually intend. This guide explains what each mode gives you, the trade-off between integrity and confidentiality, why Sign-only can be reasonable inside a trusted network, and how mode works together with certificate trust and the security policy.
Sign vs SignAndEncrypt in one line: The OPC UA message security mode determines how a channel's cryptographic algorithms are applied: None means no protection, Sign means messages are signed for integrity and authenticity but sent in the clear, and SignAndEncrypt means messages are both signed and encrypted for integrity plus confidentiality. It is a separate choice from the security policy, which specifies which algorithms are used. Sign proves messages are genuine and untampered; SignAndEncrypt additionally hides their contents from anyone watching the wire.
It is easy to conflate the security policy and the security mode, but they answer different questions. The security policy - a name like Basic256Sha256 - specifies which cryptographic algorithms the channel uses: the hash for signing, the cipher for encryption, the scheme for key exchange. The message security mode specifies whether and how those algorithms are actually put to work. You can think of the policy as the toolbox and the mode as the decision about which tools to pick up. The same policy can back a channel that only signs or a channel that both signs and encrypts.
This separation is why a secure OPC UA endpoint is really described by a pair: a policy and a mode together. An endpoint offering Basic256Sha256 with mode Sign is a very different security proposition from the same policy with mode SignAndEncrypt, even though the algorithm names are identical. When you evaluate or configure an OPC UA connection, you have to look at both halves, because a strong-sounding policy tells you nothing on its own about whether your data is encrypted or merely signed.
The three modes form a ladder of increasing protection. None sits at the bottom with no cryptographic guarantees at all. Sign adds integrity and authenticity. SignAndEncrypt adds confidentiality on top of that. Each step up costs more computation and, in the case of encryption, hides more from anyone observing the traffic. Choosing among them is a deliberate decision about what threats the link actually faces, not a box to tick blindly.
In Sign mode, every message carries a cryptographic signature computed over its contents. That signature does two things: it proves the message came from the party holding the expected certificate (authenticity) and it proves the message was not altered in transit (integrity). If an attacker modifies a signed message, the signature no longer verifies and the receiver rejects it. What Sign mode does not do is hide anything. The message body travels in readable form, so anyone who can capture the traffic can see the tag values, node identifiers, and commands - they simply cannot tamper with them undetected or impersonate a legitimate endpoint.
SignAndEncrypt adds the missing piece: confidentiality. Messages are still signed for integrity and authenticity exactly as in Sign mode, but the contents are also encrypted, so an eavesdropper capturing the traffic sees only ciphertext. This is the mode to use whenever the data itself is sensitive or the network path is not trusted, because it protects not just against tampering and impersonation but also against passive observation. The cost is additional processing to encrypt and decrypt every message, which on high-throughput links or constrained devices is a real, if usually manageable, overhead.
The trade-off between the two is therefore about confidentiality versus performance and simplicity. If the only thing you need is assurance that data is genuine and unaltered - and you do not care whether an observer can read it - Sign delivers that at lower cost than full encryption. If the content must be kept private, only SignAndEncrypt will do, and the extra processing is the price. Crucially, both modes depend on the same underlying certificate trust: the signature in either mode is meaningless unless the receiver actually trusts the certificate that produced it, which ties message security mode directly to how the two endpoints authenticate each other.
The right mode depends on where the link runs and what it carries. On any connection that traverses an untrusted network - across sites, over a shared corporate network, or anywhere the traffic could be captured - SignAndEncrypt is the sensible default, because both tampering and eavesdropping are realistic threats and there is no reason to leave the content readable. For a cloud SCADA platform such as Merobix connecting to an OPC UA server across a wide-area link, encrypting the channel end to end keeps field data confidential as it travels, and the signing that comes with it ensures an operator's commands cannot be forged or altered on the way to the server.
Sign-only mode has a narrower but legitimate place. Inside a tightly controlled, trusted network segment - a dedicated automation VLAN with no untrusted hosts, for example - some operators accept Sign without Encrypt on the reasoning that they primarily need to prevent tampering and impersonation, the eavesdropping risk is low because the segment is isolated, and they would rather not spend the encryption overhead on high-rate traffic. This can be a defensible engineering choice, but it rests entirely on the assumption that the segment really is trusted and stays that way. The moment that assumption weakens, Sign-only leaves the data readable to anyone who gains a foothold on the network.
None mode should be reserved for controlled testing and discovery, never for production data, exactly because it provides neither integrity nor confidentiality nor authentication. The overall guidance for a monitoring deployment is to default to SignAndEncrypt, consider Sign-only only for genuinely isolated segments where the confidentiality risk is truly low and the overhead matters, and refuse None outside a lab. Because the signature in any mode is only as trustworthy as the certificate behind it, getting mode right goes hand in hand with getting certificate trust right - the two together, not either alone, are what make an OPC UA link secure.
Sign mode signs every message so the receiver can verify it is genuine and untampered, but the message contents travel in readable form. SignAndEncrypt does everything Sign does and also encrypts the contents, so an eavesdropper sees only ciphertext. Sign gives integrity and authenticity; SignAndEncrypt adds confidentiality on top, at the cost of extra processing to encrypt and decrypt each message.
No, they are separate and complementary. The security policy specifies which cryptographic algorithms are used - the hash, cipher, and key-exchange scheme. The message security mode specifies how they are applied: not at all (None), for signing only (Sign), or for signing and encryption (SignAndEncrypt). A secure endpoint is described by both together, so you have to check the mode as well as the policy.
It can be a reasonable choice inside a genuinely isolated, trusted network segment where the main concern is preventing tampering and impersonation, the eavesdropping risk is low, and the encryption overhead on high-rate traffic is worth avoiding. It relies entirely on that segment staying trusted, though. On any untrusted or cross-site link, SignAndEncrypt is the safer default because it also keeps the data confidential.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.