Sign vs SignAndEncrypt
In OPC UA, Sign authenticates both applications by certificate and detects tampering, but leaves message contents readable on the wire. SignAndEncrypt adds confidentiality. Both use the same certificates and the same handshake; the difference is only whether the payload is also encrypted, and the cost difference is small.
The security difference in practice
Sign already gives you the two properties most people actually want: neither side can be impersonated without the private key, and no one can alter a Write or a Method call in flight. What Sign does not give you is secrecy. Anyone with a port mirror can read every value, every BrowseName, and any UserName token, since the token is protected by the channel rather than separately. That is the whole decision.
When Sign is the right answer
Sign is genuinely useful when you need packet-level visibility: commissioning, protocol debugging with the Wireshark OPC UA dissector, or an IDS that must inspect industrial traffic on a segmented cell network. It is also the pragmatic choice on constrained controllers where the encryption cost measurably affects cycle time. Choosing Sign should be a written decision with a reason, not a default that survived from a bench test.
When SignAndEncrypt is not optional
Require SignAndEncrypt whenever a UserName or password token is used, whenever traffic crosses a zone boundary or shared plant network, whenever recipes, part programs or anything commercially sensitive is readable in the address space, and generally wherever a 62443 security level of 2 or above is the target. Encryption on a modern CPU is cheap relative to the OPC UA stack's own overhead; the honest cost is usually a few percent, not a redesign.
Neither mode does authorisation
This is the misunderstanding that matters. SignAndEncrypt tells you which application is talking and keeps the conversation private. It says nothing about which user is behind it or what they are allowed to do. A fully encrypted channel with anonymous access and no Part 18 roles is an encrypted tunnel to an open door. Channel security and user authorisation are separate layers and you need both.
Example
What is protected under each mode
None Sign SignAndEncrypt
application authentication no yes yes
tamper detection no yes yes
payload confidentiality no no yes
UserName token protected no yes yes
readable in a packet capture yes yes no
both trust lists must be set no yes yesDefined in: Part 2 - Security Model; Part 4 - Services for MessageSecurityMode.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.