OPC UA rarely fails because of its cryptography. It fails because someone left a trust list open, kept an anonymous login on "just for commissioning", or shipped a server built on a library nobody patched. If you are looking for OPC UA security best practices that hold up in a real plant, start there: the protocol is sound, the deployments are the weak point. 

That is not our opinion alone. Germany's BSI reviewed the specification in 2016 and again in 2022 (the update covered version 1.04 and the open62541 implementation) and found no systematic design flaws. Yet Bitsight's TRACE team counted 14,220 OPC UA servers exposed to the internet over the twelve months to June 2025, and 51.74% of them accepted anonymous connections. Of the devices that reported their security modes, roughly 80% still offered the unencrypted None mode. Same protocol, very different outcomes. 

This Blog is written for CISOs, OT security leads and plant architects who already know what OPC UA is. It covers how certificates and trust lists actually work in the field, which security policies to enable and which to retire, the misconfigurations we see most often, and the advisories published in 2026 that change what you should check this quarter. 

Key Points 

• Treat application authentication (certificates and trust lists) as the control that matters most. Anonymous users are tolerable behind it and dangerous without it. 

• Disable the None policy and the deprecated Basic128Rsa15 and Basic256 policies unless a documented legacy device forces you to keep them. 

• Use SignAndEncrypt on every endpoint, and make sure username tokens are also encrypted with a modern policy. 

• Inventory the OPC UA libraries inside your products. October's Eclipse Milo advisory is a reminder that the stack version matters as much as the server configuration. 

• Never expose an OPC UA endpoint directly to the internet, and audit the ones that can reach each other inside the plant. 

OPC UA security in 2026: what changed and why it matters 

OPC UA advisories have piled up since the summer, and they point in one direction: the weak spots are in stacks, trust anchors and legacy cryptography rather than in the protocol itself. Here is the timeline, newest first. None of the items below is a confirmed incident; the advisories describe what is possible, and vendors report no known exploitation for most of them. 

Three patterns worth your attention 

1. Authorization logic fails even when the configuration is right. Several of the Milo flaws sit in access control rather than cryptography. One CVE concerns a server configuration copy that silently drops the configured role mapper, which can leave role-protected methods and nodes exposed, particularly where the server also allows anonymous sessions. Another lets a call to a protected method ride along inside a batch with an allowed one. A third makes the diagnostics nodes readable without authorization, which discloses session security details, including the policies in use and public client certificates. You can configure everything correctly and still lose, which is why library inventory belongs in your OPC UA programme. 

2. Legacy cryptography still carries real risk. The most severe Milo issue, CVE-2026-60007 (CVSS v4.0 9.1), is a padding oracle in username-token handling. An on-path attacker who captures a username token encrypted with Basic128Rsa15 can send repeated unauthenticated ActivateSession requests and recover the password. Sessions that avoid that policy are not exposed to this specific technique, so retiring deprecated policies is a concrete mitigation, not housekeeping. Note that scores differ between sources: the advisory itself lists CVSS v3 8.2 overall, while individual CVEs use v4.0 vectors. 

3. Trust anchors and clients are the quiet attack surface. The Prosys advisory and the open62541 client bug come from opposite directions but share a lesson: what your OPC UA client or broker connection trusts matters as much as what your server accepts. Prosys reports that its OPC UA client and server connections were unaffected, because they use the application certificate store rather than the Java CA list. That is OPC UA's own PKI model doing its job; the exposure sat in the surrounding MQTT, HTTPS and LDAP connections. 

Specification and stack updates 

On the standards side, the 1.05.07 release of the OPC UA specification brought significant changes to ECC security policies. The open62541 1.5.5 maintenance release implemented them, including ECC-based session authentication, and its server now refuses to use ECC policies for authentication over an unsecured (None) channel. An OPC Foundation issue targeted at 1.05.07 also moves the ECC nistP256 policy from AES-128-CBC to AES-128-GCM. We cover what this means for your policy choices below. 

How OPC UA security is layered (and where it goes wrong) 

OPC UA security is three separate controls that people routinely treat as one. The OPC Foundation's own guidance describes them as user, application and transport security, and each can be configured, or misconfigured, independently. 

The practical consequence is that a server can advertise "certificate-based security" and still be open. Application authentication is the layer attackers probe first, because when it is not enforced, a rogue client can open a secure channel, ask for the endpoint list, and pick the weakest option the server offers. A client picks the endpoint; the server decides whether to allow it. If your configuration leaves a None endpoint alongside a secure one, an attacker simply chooses None. 

One boundary to keep in mind: the OPC Foundation is explicit that OPC UA does not replace an information security management system such as ISO 27001. It gives you mechanisms. Policy, training, physical security and network design stay your job. 

OPC UA certificates: trust lists, GDS and lifecycle management 

Certificate handling is where most OPC UA security programmes quietly stall. The cryptography works; the operational burden of distributing, approving and renewing certificates across hundreds of devices is what makes teams switch the checks off. 

How trust actually works 

Every OPC UA application holds an instance certificate. Servers and clients each keep a trust list containing the certificates (self-signed or CA-issued) they are willing to talk to. Anything not on the list should land in a rejected store until an administrator moves it across. That manual step is the control. It is also why it gets bypassed. 

summarising academic research on 48 industrial products that claim OPC UA support, grouped the certificate problems into three buckets: no trust list support at all (11 products, or 22.9%), trust lists disabled by default, and insecure trust list configuration. In their analysis, 14.6% of the products advertised secure design but did not properly verify certificate trust. The features exist; defaults and documentation too often steer people around them. 

Three questions will expose most of the risk in your own estate: 

1. Does each server reject unknown client certificates by default, or does it auto-accept? 

2. Who is allowed to move a certificate into the trusted store, and is that action logged? 

3. When a certificate expires or a device is retired, what removes it from every trust list that references it? 

Use a GDS or an OT certificate authority at scale 

Per-device trust works for ten servers. It does not work for a thousand. OPC UA's Global Discovery Server (GDS) model lets a central certificate manager sign application certificates and push trust lists to servers, so each server only has to trust the GDS rather than every peer. When a new CA certificate is added to the GDS, the update propagates to every managed server. 

A few operational points from vendor documentation and field practice: 

• The server must trust the GDS agent first. The usual push error is that the GDS is not yet trusted, and the fix is vendor-specific provisioning or moving the GDS certificate to the trusted store. 

• The account used for push needs certificate administration rights on the server (for example, membership of a SecurityAdmin role). Treat that account like a domain admin. 

• Some servers restart after a certificate push. Schedule rotations in a maintenance window and verify clients reconnect. 

• Keep this CA private. The Prosys advisory above shows what happens when a TLS client quietly inherits trust from a public root store. An OT-owned CA, or a tightly scoped subordinate CA, limits who can vouch for an application identity. 

Certificate hygiene checklist 

One more implementation risk deserves a mention. Claroty's Team82 found that some servers, which implemented certificate chain checks themselves, did not guard against a chain that loops back on itself (certificate A signed by B, B signed by A), allowing denial of service. If you build or integrate your own OPC UA components, test chain validation as deliberately as you test encryption. 

OPC UA security policies and modes: what to enable and what to retire 

A security policy is a named bundle of algorithms (signing, asymmetric encryption, symmetric encryption, key derivation) defined in Part 7 of the standard. The mode (None, Sign or SignAndEncrypt) decides whether those algorithms are applied at all. You need both to be right. A strong policy on a None endpoint protects nothing. 

A note on ECC. Elliptic curve policies give equivalent or stronger security with shorter keys, which suits constrained devices, and open62541 already supports six curves. But the family is still settling. The 1.05.07 revision changed how ECC secure channels and session authentication work, one issue moves nistP256 from AES-CBC to AES-GCM, and at least one major .NET SDK now flags its original Curve25519 and Curve448 policy URIs as deprecated in favour of ChaCha20-Poly1305 variants. Each ECC curve also needs its own certificate and key pair, although RSA and ECC policies can coexist on one server. Our advice: pilot ECC where you control both ends, and do not make it a hard requirement across a mixed-vendor plant yet. 

Modes and user tokens 

• Use SignAndEncrypt as the default. The OPC Foundation's guidance allows Sign where encryption overhead is genuinely a problem, but for control traffic and anything carrying credentials, there is little reason not to encrypt. 

• Look for a minimum security policy setting. Some products let you set a floor so that the server refuses weaker policies outright. Rockwell's FactoryTalk Optix is one example. If your products have this setting, use it, because it turns a recommendation into an enforced rule. 

• Protect the user token separately. The username and password travel inside the session activation, encrypted according to the user token policy. If that policy is Basic128Rsa15 or otherwise weak, a strong channel policy does not save you. Prefer X.509 user tokens for machine-to-machine sessions and keep passwords for humans, with MFA at the access layer. 

• Do not forget PubSub. OPC UA PubSub over MQTT or UDP uses its own message security policies (AES-CTR based) and, for MQTT, TLS to the broker. Apply the same private-CA discipline there. 

Ten common OPC UA misconfigurations and how to fix them 

Most OPC UA findings come down to a short list of repeat offenders. Use this table as an audit checklist. The first four account for the bulk of the real-world exposure. 

A fifteen-minute check you can run this week 

Point a free OPC UA client such as UaExpert at one server per site and read its endpoint list. Every line should show SignAndEncrypt with Basic256Sha256 or better. Then try to connect with a freshly generated certificate that is not in the trust list. The server should reject it. If either test fails, you have found items 1 to 4 on your own network before an attacker did. 

The pattern here matches what Trout Software noted in its own writing on the subject: most field vulnerabilities are configuration errors rather than protocol flaws. That is good news, because configuration is fixable without waiting for anyone's patch. 

Supply chain and client-side risk in OPC UA 

Your OPC UA exposure is partly decided by code you did not write and cannot see. Claroty's Team82 reported roughly 50 vulnerabilities across about 15 OPC UA protocol stacks, affecting hundreds of products, and concluded that stacks are the weakest link in the supply chain because many vendors reuse them with little modification. A flaw in one library can appear in a PLC, a gateway and a historian at the same time. 

Two habits make this manageable. 

Know what is inside. Viakoo's analysis of the Milo advisory makes a point worth repeating: Milo can be embedded in servers and other products, so the library version alone does not tell you whether a particular system is exposed. Ask vendors for the OPC UA stack and version in every product, and record it next to the asset. When an advisory lands, you want to answer "are we affected?" in an afternoon, not a month. 

Treat servers as untrusted from the client's point of view. OPC UA security discussions focus on protecting servers, but clients get attacked too. Team82 chained flaws in two popular clients, Inductive Automation Ignition and Softing edgeAggregator, by feeding them malicious content from an OPC UA server, and reached remote code execution. The 2026 open62541 client bug follows the same logic: a hostile server supplies data type definitions and the client mishandles them. An attacker who can stand up a rogue server and convince one client to connect has a way into your network. 

Practical controls: 

• Give clients an explicit allow-list of servers they may connect to, using trust lists rather than auto-accept. 

• Segment aggregators, gateways and integration servers. They bridge systems, which makes them excellent pivot points. 

• Treat any text, node name or structure delivered by a server as untrusted input in your own applications and dashboards. 

• Put these five questions into vendor security questionnaires: 

1. Which OPC UA stack and version does this product use? 

2. Do you publish an SBOM, and how quickly do you ship fixes for stack CVEs? 

3. Does the server reject unknown client certificates by default? 

4. Can we set a minimum security policy and disable None? 

5. Which role-based access controls does the OPC UA server enforce, and how are they tested? 

OPC UA hardening checklist for industrial networks 

Certificates and policies are necessary but not sufficient. These are the surrounding controls we would expect to see in any mature OPC UA deployment. 

Network and architecture 

• Segment OPC UA servers into defined zones and put conduits between them, in line with IEC 62443 thinking. Cross-zone OPC UA traffic should pass through a controlled point, not a flat route. 

• Allow-list client addresses at the firewall. The default port, 4840, is well known (96.81% of the exposed servers Bitsight found were using it), so do not count on obscurity. 

• Where products support reverse connect, let the server dial out to the client side so you avoid opening inbound holes into the control zone. 

• Route remote access through a VPN or brokered access path with MFA. Never publish an OPC UA endpoint to the internet. 

Identity and access 

• Give each human and each service its own account. Shared logins make auditing meaningless. 

• Use X.509 user tokens for machine-to-machine sessions and keep passwords for people. 

• Grant read access broadly and write or method-call access narrowly, then re-test role enforcement after every upgrade or configuration copy. The Milo role-mapper bug is exactly the sort of silent regression that a post-change test catches. 

Monitoring and detection 

• Turn on server auditing and forward events to your OT monitoring or SIEM. 

• Alert on sessions opened over None, new client certificates appearing in rejected or trusted stores, bursts of failed ActivateSession calls (the signature of an oracle-style attack), and Write or Call services from hosts that have never used them before. 

• Watch for endpoint discovery requests from unexpected sources. Reconnaissance usually starts there. 

Patching and resilience 

• Keep the OPC UA component inventory current, and patch through vendor-supported channels. Do not swap a library inside a vendor appliance on your own. 

• While waiting for a fix, restrict OPC UA routes to required clients using existing firewalls and approved remote access, which is the interim step recommended in coverage of the Milo advisory. 

• Set connection, session and message-size limits where the product allows. Several published OPC UA flaws, including the B&R PPT30 issue, are resource-exhaustion problems that an unauthenticated peer can trigger. 

• Test critical servers in a lab with a protocol fuzzer before go-live, and again after major upgrades. 

A 90-day OPC UA security plan for CISOs 

If you own the risk but not the plant floor, this sequence gets you from "we think we are fine" to evidence in one quarter. 

Two practical tips. First, expect legacy devices that cannot meet the baseline. Document each exception with an owner, a compensating control (isolation, allow-listing, monitoring) and a review date. Second, brief plant engineering before you change anything. Tightening a trust list on a live line without warning is how security programmes lose goodwill. 

How Shieldworkz helps secure OPC UA in critical infrastructure 

Shieldworkz is an end-to-end industrial OT cybersecurity company. We secure SCADA, OT and IoT environments across critical infrastructure, and we bring products, services and solutions together as one stack, so the findings in a review turn into fixes without a hand-off between vendors. 

For OPC UA specifically, that typically means: 

• Visibility: discovering OPC UA servers, clients and gateways across plants, and mapping which systems can reach them. 

• Assessment: reviewing endpoints, policies, certificates, user tokens and trust list behaviour against the baseline in this article, and ranking what to fix first. 

• Remediation support: helping design certificate and GDS processes, network segmentation and compensating controls for legacy devices that cannot meet the baseline. 

• Patch and vulnerability management: tracking advisories such as the Eclipse Milo and open62541 issues against your actual asset inventory, and planning updates that respect OT maintenance windows. 

If you want a second pair of eyes on your OPC UA estate, talk to the Shieldworkz team about an OPC UA security review. 

OPC UA security: frequently asked questions 

What are the most important OPC UA security best practices? 

Enforce certificate trust lists, use SignAndEncrypt with Basic256Sha256 or stronger, disable None and deprecated policies, turn off anonymous access, keep servers off the internet, enable auditing, and patch the OPC UA stack inside every product. 

Is OPC UA secure by default? 

The specification is, according to BSI's reviews. Individual products often are not, because trust lists, anonymous access and legacy policies are configurable and some ship in permissive states. Verify each product rather than assuming. 

Which OPC UA security policy should I use? 

Aes256_Sha256_RsaPss or Aes128_Sha256_RsaOaep where all components support them, and Basic256Sha256 as the floor. Retire Basic128Rsa15 and Basic256. Pilot ECC policies in controlled environments while the 1.05.07 changes are absorbed by vendors. 

Is anonymous access ever acceptable? 

Only where application authentication is enforced through certificate trust, access is limited to non-sensitive read-only data, and auditing is on. Anonymous access on an exposed server with no trust enforcement is an open door. 

Do I need a Global Discovery Server? 

If you manage more than a handful of OPC UA applications, yes, or an equivalent certificate management process. It lets each server trust one certificate manager instead of every peer, and makes rotation repeatable. 

Should the October 2026 Eclipse Milo vulnerabilities make me drop OPC UA? 

No. Identify which of your products embed Milo, ask vendors for supported upgrades, restrict network access in the meantime, and retire Basic128Rsa15 to remove the most severe attack path. 

Can OPC UA servers be exposed to the internet safely? 

Direct exposure is not recommended by the major OT vendors. If remote access is needed, use a VPN or a brokered remote-access service with MFA, and keep the endpoint itself inside a protected zone.