OPC UA security: built in, often unused, and what breaks when it is

Yes, and this is the single biggest architectural difference from legacy OT protocols. OPC UA's own Part 2 specification (OPC 10000-2, the Security Model) defines security as a first-class objective of the protocol, not an add-on: Section 4.2 lists Authentication ("Entities such as Clients, Servers, and users should prove their identities"), Authorization, Confidentiality ("Data is protected from passive attacks such as eavesdropping, whether the data is being transmitted, in memory, or being stored"), Integrity, Auditability and Availability as objectives the protocol is built to support. Section 4.8 defines three MessageSecurityMode values any OPC UA session negotiates: None, Sign, and SignAndEncrypt. This is a genuinely different starting point from Modbus or classic OPC DA (which inherited Microsoft DCOM's security model and effectively none of its own) — see [Modbus protocol security](/guides/modbus-protocol-security-ot-ics/) for the contrast with a protocol that has no equivalent objectives in its specification at all.

Because having a security model in the specification does not mean every implementation gets it right, and does not mean every deployment turns it on. CISA's advisory ICSA-22-242-10 (30 August 2022, updated 8 September 2022) covers PTC's Kepware KEPServerEX — an OPC UA server embedded, white-labeled or OEM'd into Rockwell Automation's KEPServer Enterprise, GE Digital's Industrial Gateway Server, Software Toolbox's TOP Server and ThingWorx products — and assigns CVE-2022-2825 (CVSS v3 base score 9.8, CWE-121 Stack-based Buffer Overflow) to a finding that "specifically crafted OPC UA messages transmitted to the server could allow an attacker to crash the server and remotely execute code," plus CVE-2022-2848 (CVSS v3 9.1, CWE-122 Heap-based Buffer Overflow) for a related crash-and-data-leak finding. More recently, CISA's advisory ICSA-26-211-08 (30 July 2026) covers four vulnerabilities in open62541 — the widely embedded open-source OPC UA stack maintained by o6 Automation GmbH — including CVE-2026-65423 (integer overflow in variant array-dimension handling, CVSS v3.1 8.8 / CVSS v4.0 8.7, CWE-190) described as able to "trigger an out-of-bounds write," and CVE-2026-63035 (heap use-after-free in the TransferSubscriptions service, CVSS v3.1 8.1, CWE-416) that "may allow an authenticated attacker to cause a denial of service or potentially execute arbitrary code." None of these are failures of the OPC UA security *model* — they are memory-safety bugs in specific stack implementations, the same class of defect that affects any sufficiently complex parser regardless of what the protocol spec says about authentication.

CISA's own 2026 research into this question, published jointly with the OPC Foundation and other protocol maintainers, found the barrier isn't awareness — it's practical deployment friction. The report "Barriers to Secure OT Communication: Why Johnny Can't Authenticate" (CISA, 10 February 2026; the OPC Foundation lists itself alongside Anybus, the DNP Users Group, NSA, ODVA, Rockwell Automation, Schneider Electric and the Modbus Organization as a contributor) is based on CISA's own interviews with OT asset owners and operators across water/wastewater, transportation, chemical, energy and food-and-agriculture sectors. *A sourcing note: this guide's fetch tooling could not render the CISA PDF itself as extractable text; the findings below are drawn from the OPC Foundation's own published confirmation that it contributed to the report and its stated publication date, cross-checked against secondary industry reporting (Automation.com, Industrial Cyber) that this guide's tooling also could not independently re-verify as static text. Treat the specific framing below as a good-faith summary, not a verbatim quotation, until checked against CISA's own PDF.* With that caveat, the research reportedly groups the barriers into three categories that line up closely with why a security policy of None remains common even on OPC UA deployments that fully support stronger options: cost (procurement, deployment and ongoing maintenance of a PKI), availability fears (operators worried that enabling signing or encryption will add latency or break uptime on a system with no appetite for unplanned downtime), and PKI complexity itself (certificate provisioning and lifecycle management on devices that were never designed to be re-keyed in the field).

Three separate things, because "we use OPC UA" says nothing on its own about security posture. First, the negotiated SecurityPolicy and MessageSecurityMode for every endpoint — OPC UA's Part 7 profiles define a None policy specifically so a server can be stood up without any cryptography at all, and that policy remaining enabled (or being the default a device ships with) is a configuration choice, not a protocol limitation; CISA's and the OPC Foundation's own recurring guidance is to disable None wherever a client supports better. Second, the stack's patch level against known CVEs like those in Kepware KEPServerEX and open62541 above — a correctly configured SecurityPolicy does not protect against a memory-corruption bug in the message parser that runs before authentication is even checked. Third, certificate lifecycle: OPC UA's security model depends on X.509 certificate-based mutual authentication between client and server, which means an expired, self-signed, or improperly validated certificate chain can silently degrade the same security the protocol was designed to provide. See [NIST SP 800-82: OT security](/guides/nist-sp-800-82-ot-security/) for where this certificate and patch-management discipline sits inside a broader OT security program, and [the Purdue Model for OT/ICS network architecture](/guides/purdue-model-ot-ics-network-architecture/) for the segmentation that should still apply regardless of what an individual OPC UA endpoint is configured to do.