One of the most important differences of OPC UA is that security is not a bolt-on layer but part of the protocol. Those capabilities only protect when configured correctly, though: on many sites a “no security” mode or a setting that accepts every certificate is still common.
Three layers of security
- Application authentication: Client and server authenticate each other with application instance certificates.
- Channel security: Messages can be signed, or signed and encrypted.
- User authentication and authorization: Who opened the session and what they can read and write.
Message security modes
| Mode | Meaning | Recommendation |
|---|---|---|
| None | No signing or encryption | Disable in production |
| Sign | Messages signed (integrity) | Acceptable if confidentiality is not needed |
| SignAndEncrypt | Signed and encrypted | Generally preferred |
Security policies
A security policy defines the algorithms used. Older policies (for example Basic128Rsa15 and Basic256) are considered deprecated in current specifications. In modern deployments Basic256Sha256 is widely supported; newer versions add policies such as Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss. Which policies you can use depends on what both server and client support; check the documentation for your device firmware version.
Certificate management
Every OPC UA application identifies itself with a certificate. Client and server decide whether to trust the other side’s certificate from a trust list.
- Self-signed certificates are practical for small deployments, but trust must be managed by hand for each application.
- Certificates signed by an enterprise CA centralize trust management in larger deployments (trusting the root is enough).
- Monitor certificate expiry; an expired certificate cuts the connection in production at once.
- The certificate must match the application URI and hostname/IP; after a server is renamed, the old certificate may be rejected.
- Store and back up private keys securely.
User authentication
OPC UA supports several user token types: anonymous, username/password, X.509 certificate and issued token. In production, disable anonymous access, avoid shared accounts and apply least privilege with role-based authorization: a dashboard needs read access only.
Common field mistakes
- Leaving the “None” endpoint opened during testing available in production.
- Making “automatically accept all certificates” a permanent client setting.
- Not noticing expired certificates; if time synchronization (NTP) is broken, valid certificates can be rejected as well.
- Leaving security to the OPC UA layer alone and neglecting network segmentation.
Treat security as part of the whole
OPC UA security is not an OT security program on its own. Together with network segmentation, asset visibility and frameworks such as IEC 62443 it forms a layered defense. When data platforms such as HighByte Intelligence Hub act as OPC UA client and server, applying these settings consistently also matters; credentials and certificates should be managed centrally. To plan your security program together, see our OT/ICS cybersecurity page.
