OPC UA security & certificates
Security is built into OPC UA, not bolted on. A connection negotiates a security policy and mode, then client and server authenticate each other with X.509 certificates. Understanding these two ideas (modes and trust) resolves most security questions and connection failures.
The four pillars
| Pillar | What it protects |
|---|---|
| Encryption | Confidentiality: nobody can read the traffic |
| Signing | Integrity: messages can't be tampered with |
| Authentication | Identity, of the application (certificate) and user |
| Authorisation | Permissions: what an authenticated user may do |
Security modes
- None, no signing/encryption. Only for isolated testing.
- Sign: messages are signed (integrity + auth) but not encrypted.
- Sign & Encrypt: signed and encrypted. Use this in production.
Each mode pairs with a security policy (the cipher suite, e.g. Basic256Sha256 or the newer Aes256 policies). Prefer modern policies and disable deprecated ones.
How certificate trust works
Every OPC UA application has its own instance certificate. On connect, client and server exchange certificates; each keeps a small PKI store:
pki/
├─ own/ # this application's own cert + private key
├─ trusted/certs # certificates we trust
├─ trusted/crl # certificate revocation lists
├─ issuer/ # CA certs (if using a CA)
└─ rejected/ # certs seen but not yet trustedrejected/. Move it to trusted/certs on both ends, then reconnect. This single step fixes most "BadSecurityChecksFailed" errors.Self-signed vs CA-signed
Self-signed certificates are fine for small, static deployments: you manually trust each one. For fleets, a Certificate Authority (or the OPC UA GDS: Global Discovery Server) scales trust: trust the CA once and every certificate it issues is trusted automatically.
User authentication
Application (certificate) identity is separate from user identity. A server can accept anonymous, username/password, or user certificate tokens. Match what the server expects, and prefer named users over anonymous in production so actions are attributable.
Hardening checklist
- Use Sign & Encrypt with a modern policy; disable None and deprecated policies.
- Replace default/self-signed certs with managed ones; set sensible expiry and rotate.
- Require named users; disable anonymous where possible.
- Apply least-privilege authorisation: read-only unless write is truly needed.
- Keep CRLs current; remove stale certs from
trusted/. - Put OPC UA on a segmented network; restrict the port to known clients.
- Patch your OPC UA stack: treat it like any other networked service.
Last updated 4 September 2026 · Educational resource.