OPC UA is the rare industrial protocol that was designed with security built in: certificates, signing, encryption, and user authentication are part of the specification, not bolted on later. Yet real-world OPC UA deployments are routinely found running with security mode None, anonymous access enabled, and clients configured to trust every certificate they see. This guide explains how OPC UA security actually works - message security modes, security policies, certificate trust, and user tokens - and walks through the deployment mistakes that quietly turn a secure-by-design protocol into an open door. It is written for the OT engineer or operations manager who has to configure, audit, or buy systems that speak OPC UA.
Explore the full security & certification article series - 60+ practitioner guides.
Most industrial protocols - Modbus, EtherNet/IP, classic DNP3 - were designed in an era when the plant network was assumed to be trusted, so they carry no authentication and no encryption. OPC UA, standardized as IEC 62541 (published by the IEC) and developed by the OPC Foundation, was designed in the 2000s with the opposite assumption: that industrial data would cross network boundaries and needed protection at the protocol layer. Security is not an add-on module; the handshake itself is built around X.509 certificates, and every session negotiates a security mode and policy before any process data moves.
That design gives OPC UA three layers of protection that most OT protocols lack entirely. First, application authentication: client and server each present a certificate, and each side decides whether to trust the other. Second, message protection: messages can be signed (tamper-evident) and encrypted (unreadable to eavesdroppers). Third, user authentication: once the applications trust each other, the session identifies a human or service account through a user token, so permissions can differ between an operator, a historian, and a third-party analytics client.
The catch - and the reason this article exists - is that every one of those layers can be switched off. The specification permits insecure configurations for commissioning and legacy interoperability, and vendors often ship them enabled by default. OPC UA is only more secure than Modbus when someone actually turns the security on. If you are weighing OPC UA against MQTT for a cloud monitoring architecture, our MQTT vs OPC UA comparison covers that decision in depth; this guide stays focused on securing OPC UA itself.
Every OPC UA endpoint advertises one or more message security modes, defined in Part 2 (Security Model) of the OPC UA specification. This is the single most important setting in the entire protocol, because it determines what protection the session traffic actually gets:
| Security Mode | What It Provides | What an Attacker on the Network Can Do | Appropriate Use |
|---|---|---|---|
| None | Nothing - plaintext messages, no integrity protection | Read all process data, modify messages in transit, impersonate either side | Bench commissioning only; disable before production |
| Sign | Digital signature on every message - tampering and spoofing are detectable | Read all process data (traffic is plaintext), but cannot alter it undetected | Rare edge cases where data confidentiality genuinely does not matter |
| SignAndEncrypt | Signature plus encryption of the full message payload | See that a connection exists; nothing else | The correct default for production deployments |
The practical guidance is short: production endpoints should offer SignAndEncrypt and nothing else. Leaving a None endpoint enabled "for troubleshooting" is the OPC UA equivalent of leaving a spare key under the mat - automated tools enumerate OPC UA endpoints and their security modes, and a None endpoint is an invitation. Most server stacks let you disable endpoints individually; do it, and verify with a discovery client that only the secure endpoint is advertised.
The security mode says whether messages are signed and encrypted; the security policy says how - which algorithms and key lengths are used. Policies have evolved as cryptographic recommendations have moved on, and older ones are now formally deprecated:
The operational problem is fleet asymmetry: a ten-year-old PLC gateway may only speak deprecated policies, while your new historian refuses them. Resist the temptation to solve this by dropping the whole system to the lowest common denominator. Keep strong policies on every endpoint that supports them, isolate the legacy device on its own network segment, and put its upgrade on the capital plan. A security policy is only a checkbox in a config screen, but it decides whether the encryption on your control network would withstand serious analysis or merely casual curiosity.
OPC UA's application-level trust is built on X.509 certificates, and this is where the protocol's security most often breaks down in practice - not because the cryptography is weak, but because managing certificates across an industrial site is genuinely tedious, and every shortcut weakens the model.
How it is supposed to work: every OPC UA application (each client and each server) has its own application instance certificate. When a client connects, the server checks the client's certificate against its trust list, and the client does the same for the server. A certificate not on the trust list lands in a rejected folder, where an administrator can review it and deliberately promote it to trusted. Larger deployments can centralize this with a certificate authority or a Global Discovery Server (GDS), which handles certificate distribution, renewal, and revocation across the fleet.
How it often works instead:
Minimum viable certificate hygiene for a small or mid-size operation: unique certificate per application, auto-accept disabled after commissioning, an expiry-date register with renewal reminders, and a documented procedure for trusting a new client. Sites with dozens of OPC UA applications should evaluate GDS-based or CA-based management, because manual trust lists stop scaling around that point.
Certificate trust authenticates applications; it says nothing about who is using the connection. That is the job of user identity tokens, which OPC UA supports in several forms: anonymous, username and password, certificate-based user identity, and issued tokens for federated identity schemes.
The rules that matter:
Security assessments of OPC UA installations keep finding the same handful of issues. If you audit only five things on your own system, audit these:
None of these are exotic. All of them are configuration, which means all of them are fixable in a maintenance window rather than a capital project.
Work through this list per server, then per client. It fits in an afternoon for a typical site:
Even a perfectly hardened OPC UA server should not be exposed beyond the OT network. The pattern that preserves segmentation is a local gateway: software inside the OT zone connects to the OPC UA server as a hardened, read-scoped client, then pushes data outbound over TLS to the platform. No inbound firewall rules, no OPC UA endpoint visible from outside the plant.
This is how the Merobix gateway consumes OPC UA. The gateway runs inside the customer network as one of the platform's drivers for the major industrial protocols (Modbus, DNP3, OPC UA, EtherNet/IP, Siemens S7, and MQTT) - OPC UA alongside Modbus RTU/TCP, MQTT, DNP3, BACnet/IP, EtherNet/IP, and HTTP - and makes only outbound TLS connections to the cloud, so the OT firewall can deny all inbound traffic. Above the protocol layer, Merobix adds its own integrity controls that OPC UA alone does not provide end to end: each gateway registers with unique device credentials, telemetry is carried in signed envelopes with sequence numbers and replay detection, and any control action is checked against explicitly configured writable tags and setpoint bounds before dispatch. The full architecture is documented on the Merobix security page, and the broader evaluation framework - segmentation, gateways, RBAC, audit - is covered in our secure SCADA for OT networks guide. If your estate is Modbus-heavy rather than OPC UA-native, the companion post on Modbus security risks and mitigations deals with the much harder problem of protocols that have no security to configure. You can also see how a hardened OPC UA source flows into a monitored platform in a live demo.
Key takeaway: OPC UA gives you real, standards-based security - but only as configured, not as shipped. The whole posture comes down to four decisions: SignAndEncrypt only, modern security policies only, deliberate certificate trust with tracked expiry, and named least-privilege user accounts with anonymous access off. Make those four decisions, keep the server inside a segmented OT zone behind an outbound-only path, and OPC UA becomes one of the strongest links in your architecture instead of a false comfort.
Certificate discipline at the server matters little if the controllers behind it are wide open - our PLC security hardening checklist covers that layer.
The most secure practical OPC UA configuration is message security mode SignAndEncrypt with a modern security policy such as Aes256_Sha256_RsaPss (or Basic256Sha256 where newer policies are unavailable), the None endpoint disabled entirely, anonymous user tokens disabled, per-client application certificates that are individually reviewed and trusted rather than auto-accepted, and username or certificate-based user authentication on top of the application-level trust. Certificates should have tracked expiry dates and a documented renewal process. Finally, the server should never be reachable from outside the OT network - protocol security complements network segmentation, it does not replace it.
SignAndEncrypt is the strongest of the three OPC UA message security modes. Every message between client and server is digitally signed, which proves it came from the holder of the certificate and was not modified in transit, and encrypted, which prevents anyone capturing network traffic from reading the process data. The other modes are Sign, which protects integrity but transmits data in the clear, and None, which provides no message protection at all. For any deployment carrying production data or control commands, SignAndEncrypt should be the default choice.
OPC UA uses X.509 application certificates for mutual trust: every client and server has its own certificate, and each side must explicitly trust the other. In practice most industrial deployments use self-signed certificates managed through per-device trust lists rather than a central certificate authority, so every new client-server pairing needs a manual trust step on both ends. Certificates also expire - a certificate that silently lapses can stop data flow months after commissioning - and rotating them across dozens of servers without a Global Discovery Server (GDS) or other central management is tedious. The difficulty is operational, not cryptographic, and the common shortcut of enabling auto-accept for all certificates quietly removes the protection the certificates exist to provide.
No, not in production. Anonymous user tokens mean any client that completes the application-level handshake can browse the address space and read tags, and on servers where write permissions are not restricted per user, potentially write to them. Many OPC UA servers ship with anonymous access enabled by default to make commissioning easy, and it frequently stays enabled after go-live. Disable anonymous tokens, create named user accounts with the minimum permissions each integration actually needs, and prefer certificate-based or username user tokens carried inside an encrypted session.
Yes, by design. Modbus has no authentication, no encryption, and no message integrity - any device that can reach a Modbus port can read and write to it. OPC UA builds authentication, signing, and encryption into the protocol itself through certificates, security modes, and user tokens. The important caveat is that OPC UA is only more secure when those features are actually enabled: an OPC UA server running with security mode None and anonymous access offers roughly the same protection as Modbus. Both protocols still belong inside a segmented OT network behind a firewall, never exposed to the internet.
OPC UA, Modbus, DNP3 and more - consumed by an outbound-only gateway with signed telemetry, TLS everywhere, and zero inbound firewall rules.