Securing OPC Classic Systems with OPC UA: How the OPC UA Wrapper Eliminates DCOM Security Risks

The security problem no one wants to talk about

Most industrial facilities running OPC Classic know, on some level, that their legacy protocol stack is not ideal from a security perspective. What fewer people appreciate is just how specific and well-documented those risks are.

OPC Classic – covering OPC DA (Data Access), OPC HDA (Historical Data Access), and OPC AE (Alarms and Events) – was built on Microsoft’s COM/DCOM technology. DCOM was a reasonable architectural choice in 1996, when OPC Classic was introduced. Industrial networks were air-gapped by default, cybersecurity was not an OT priority, and Windows dominated the automation world.

None of those conditions reliably hold today.

As IT/OT convergence has progressed, as cloud connectivity has become standard, and as industrial cybersecurity has moved from a niche concern to a boardroom priority, the DCOM foundations of OPC Classic have become a genuine liability. Not a theoretical one – a documented, exploited, actively monitored liability.

What DCOM vulnerabilities actually mean for your plant

CVE-2021-26414: the patch that broke OPC Classic

In June 2021, Microsoft disclosed CVE-2021-26414, a critical vulnerability in the Windows DCOM Server Security Feature. The vulnerability allowed remote attackers to bypass DCOM authentication controls, potentially enabling unauthorised access to any DCOM-exposed service including OPC Classic servers.

Microsoft’s response was mandatory security hardening via the KB5004442 Windows update, which tightened DCOM authentication requirements. This was not optional: as of June 2023, the hardening is enforced by default on all supported Windows systems.

The practical consequence for OPC Classic users was significant. Many legacy OPC Classic client applications, particularly older SCADA systems, historians, and HMI platforms, relied on the looser DCOM authentication that KB5004442 eliminated. Applying the security patch caused connectivity failures in OPC Classic deployments across multiple industries. Organisations faced a difficult choice: apply the security patch and break their OPC infrastructure, or delay the patch and remain exposed to the vulnerability.

This is not an edge case. It is an illustration of the fundamental architectural problem with DCOM-based OPC Classic: security improvements at the OS level break the protocol, because the protocol was never designed with security as a requirement.

The structural DCOM security problems

Beyond CVE-2021-26414, DCOM introduces several persistent security problems that cannot be fixed without replacing the protocol:

• Dynamic port allocation. DCOM negotiates communication ports dynamically, typically using a range of 49152–65535. Properly configured industrial firewalls should restrict port access to exactly what is needed. With DCOM, this is impractical; either you open thousands of ports (expanding your attack surface) or you restrict them and break OPC Classic connectivity. Most OT environments have resolved this tension by leaving firewall rules too permissive, creating exactly the kind of lateral movement opportunity that attackers exploit after an initial compromise.
• No message-level encryption. OPC Classic has no native mechanism for encrypting the data it carries. Process values, setpoints, alarm states, and historical data all travel in plaintext over the network. On an assumed-isolated OT network, this was acceptable. On a network with any IT/OT connectivity (which now describes most industrial facilities) it means that any device with network access can read operational data in transit.
• No application-level authentication. OPC Classic relies on Windows user accounts and DCOM security settings for access control. There is no concept of an application presenting a cryptographic certificate to prove its identity before being granted access to process data. This means that any application running as a sufficiently privileged Windows user can connect to an OPC Classic server without the server being able to verify what that application actually is.
• Firewall-hostile by design. The combination of dynamic port allocation and DCOM’s reliance on the Windows RPC endpoint mapper (port 135) makes OPC Classic inherently difficult to isolate with firewall rules. IEC 62443 Zone and Conduit models require precise control of communication paths between security zones. DCOM makes this precision extremely difficult to achieve in practice.

Why replacing legacy systems is not always the answer

The obvious solution to OPC Classic security problems is to replace OPC Classic servers with native OPC UA servers. OPC UA was built from the ground up with security as a core requirement. It has mandatory encryption, X.509 certificate authentication, role-based access control, and a single configurable port that works cleanly with firewall rules.

But “replace everything” is not a realistic plan for most industrial facilities. The reasons are straightforward:

• Installed base depth. An established manufacturing plant may have dozens or hundreds of OPC Classic server integrations, PLCs, DCSs, historians, SCADA systems, some of which have been running reliably for fifteen years. Replacing all of them requires significant engineering time, extensive testing, and operational risk during the transition.
• Vendor support timelines. Not every OPC Classic server has a supported upgrade path to OPC UA. Some legacy device vendors have discontinued the product lines involved. Others offer OPC UA upgrades that require hardware replacement, not just a firmware update.
• Budget and prioritisation. Capital expenditure for full protocol replacement competes with other operational and maintenance priorities. A phased approach that reduces security risk immediately, before full replacement is budgeted and planned, is often more realistic.
• Operational continuity requirements. Critical processes cannot be taken offline for extended migration windows. The risk of a migration-induced outage in a high-availability environment can outweigh the risk of a delayed migration.

This is the context in which the OPC UA Wrapper addresses a real operational need.

How the OPC UA Wrapper eliminates DCOM security risks

The OPC UA Wrapper is a software bridge that sits between your existing OPC Classic infrastructure and the rest of your operational and enterprise architecture. It operates in two directions:

OPC Classic server → OPC UA clients (the Wrapper component). Existing OPC Classic servers, DA, HDA, and AE, continue to run exactly as they do today, communicating via DCOM on the local machine or within a tightly controlled network segment. The Wrapper connects to those servers using the legacy protocol internally, then re-exposes their data as a fully compliant OPC UA server to any external client. Those external clients, cloud platforms, analytics tools, MES systems, modern SCADA, connect using OPC UA with full encryption, certificate authentication, and RBAC. They never touch DCOM.

OPC UA servers → OPC Classic clients (the Proxy component). The reverse is equally supported. Where legacy OPC Classic client applications need to access modern OPC UA servers, the Proxy presents the OPC UA server as if it were an OPC Classic server. The legacy client connects via its familiar OPC Classic interface; the Proxy handles the OPC UA connection on the other side.

The security effect of this architecture is significant:

DCOM is contained. The Wrapper/Proxy localises DCOM communication to a controlled, minimal network zone – ideally the same physical or virtual host as the OPC Classic server. DCOM traffic no longer traverses the broader OT or IT network. The attack surface of DCOM vulnerabilities like CVE-2021-26414 is reduced to a managed, isolated perimeter rather than spanning the full network.

All external traffic uses OPC UA security. Every client connecting from outside that contained perimeter uses OPC UA with AES-256 encryption and X.509 certificate authentication. This satisfies the encrypted communications requirements of IEC 62443, NIS2 (for EU operators of essential services), and NERC CIP (for North American energy sector facilities).

Audit logging improves. The Wrapper provides advanced session logging and diagnostics recording which clients connected, when, what data they accessed, and what operations they performed. This audit trail supports the incident detection and regulatory reporting requirements of NIS2, NERC CIP, and FDA 21 CFR Part 11.

No changes to existing OPC Classic servers or clients. The Wrapper is transparent to the legacy infrastructure. Existing OPC Classic servers do not need to be modified, updated, or retested. The security improvement is achieved at the boundary, not inside the legacy systems. 

Ready for a secure upgrade?  
step-by-step OPC UA migration guide (PDF)

What organisations in your sector are dealing with right now

• Manufacturing (EU): The NIS2 Directive, effective October 2024, requires medium and large manufacturers classified as essential or important entities to implement appropriate technical cybersecurity measures. For OT environments, the most immediate gaps are typically unencrypted communications and inadequate access controls — precisely what DCOM-based OPC Classic fails to address. OPC UA Wrapper deployments can demonstrate measurable progress toward NIS2 compliance without requiring full infrastructure replacement.
• Energy and utilities (North America): NERC CIP standards require bulk electric system operators to maintain Electronic Security Perimeters with precise access controls. DCOM’s dynamic port requirements make this technically challenging. Replacing DCOM-exposed OPC Classic connections with OPC UA Wrapper-mediated connections simplifies firewall rule management and makes Electronic Security Perimeter compliance more achievable.
• Oil and gas (global): Wellsite and refinery environments frequently combine decades-old process control systems with modern data integration requirements. OPC Classic servers are common in these environments; so are requirements to push process data to cloud historians, AI analytics platforms, and corporate data warehouses. The OPC UA Wrapper enables this integration over secure OPC UA connections without touching the underlying control system.
• Pharmaceuticals (US and EU): FDA 21 CFR Part 11 and EU Annex 11 require electronic records to be trustworthy and traceable. Unencrypted, unauthenticated OPC Classic communications are difficult to defend in a regulatory audit context. OPC UA Wrapper deployments add the authentication and audit trail that compliance requires.

What customers say

Getting started

The OPC UA Wrapper is a plug-and-play deployment — no changes to existing OPC Classic servers, no PLC modifications, no process downtime required. Integration Objects provides full documentation and video tutorials to guide the configuration process.

• Watch the OPC UA Wrapper configuration video
• Download the OPC UA Wrapper User Guide (PDF)
• Explore the OPC UA Wrapper product page
• Contact Integration Objects to discuss your environment

Frequently asked questions