OPC Classic/DA - DCOM protocol in industrial automation. Security and segmentation

OPC Classic (Open Platform Communications, formerly OLE for Process Control) is a family of industrial communication protocols developed in the 1990s by the OPC Foundation. The most widely used specification is OPC DA (Data Access) - designed for real-time process data exchange between SCADA systems, HMIs, process historians, and PLCs. OPC Classic was built on Microsoft DCOM (Distributed Component Object Model) technology, which was a pragmatic choice at the time but turned out to be a decision with long-lasting security consequences.

Despite being officially superseded by OPC UA (Unified Architecture) in 2008, OPC Classic remains widely deployed in industrial installations around the world. Migration to OPC UA requires replacing software and often hardware - a process that will take many facilities years to complete.

Architecture and the DCOM mechanism

What is DCOM

DCOM is an extension of Microsoft’s COM (Component Object Model), enabling communication between objects on different computers in a Windows network. In the OPC Classic context:

OPC Server - a Windows application running on a computer connected to PLCs (via the manufacturer’s communication driver). It exposes process data as COM objects.
OPC Client - a SCADA, HMI, or historian application that connects to the remote OPC server via DCOM.

Connection mechanism

Establishing an OPC Classic/DCOM session proceeds as follows:

The client contacts the RPC Endpoint Mapper service on the server (TCP port 135)
The Endpoint Mapper returns a dynamically assigned TCP port where the requested OPC server is listening
The client establishes a connection on the dynamic port (default range: 1024-65535)
Subsequent DCOM calls (read/write values, subscriptions) occur through that port

The problem is obvious: each DCOM session can use a different port from a range of thousands. This makes firewall configuration a serious challenge.

Technical parameters

Parameter	Value
OSI model layer	4-7 (TCP/IP + DCOM/RPC)
Port - Endpoint Mapper	TCP 135
Ports - DCOM sessions	Dynamic (default 1024-65535, configurable range)
Transport protocol	Microsoft RPC over TCP
Authentication	NTLM / Kerberos (DCOM Security configuration)
Encryption	Optional (RPC Packet Privacy), rarely enabled
Operating system	Windows only
Standards organization	OPC Foundation
Status	Superseded by OPC UA (2008), but still widely deployed

Security assessment

OPC Classic/DCOM is widely considered one of the most difficult protocols to secure in OT environments. The problems stem from both the DCOM architecture and deployment practices.

Dynamic ports - a firewall nightmare

The default DCOM configuration uses ports in the 1024-65535 range. In practice, this means administrators either open the entire range on the firewall (defeating the purpose of segmentation) or configure a restricted port range in the Windows registry - which requires changes on every OPC server and every client.

TIP

If you must maintain OPC Classic, configure a static DCOM port range in the Windows registry (key HKLM\Software\Microsoft\Rpc\Internet). Recommended range: 100-200 ports (e.g. 49152-49352). Then open only TCP 135 + that range on the firewall. This does not solve the DCOM security problem but limits the attack surface.

DCOM authentication - theory vs. practice

DCOM supports NTLM and Kerberos authentication and various levels of packet protection (from no protection to encryption). In theory, OPC Classic can be configured to require strong authentication and encryption.

In practice, the situation is different:

Many OPC server manufacturers recommended lowering the DCOM security level to “resolve connection issues”
Configuring DCOM Security requires precisely setting permissions at the operating system, COM component, and application levels - which is complicated and error-prone
In multi-vendor environments (one manufacturer’s OPC client, another’s OPC server), DCOM authentication issues are so common that many integrators set minimal security
Older Windows systems (XP, Server 2003), still present in OT installations, have limited DCOM Security configuration options

DCOM as an attack vector

TCP port 135 (RPC Endpoint Mapper) is one of the most frequently attacked ports in Windows systems. Numerous historical exploits (MS03-026 “Blaster”, MS08-067 “Conficker”) targeted the RPC service. Even if modern Windows systems are immune to those specific exploits, an open port 135 remains a valuable reconnaissance target - allowing enumeration of RPC services, COM objects, and potential attack vectors.

TIP

The OPC Expert scanner (formerly OPC Analyzer) and tools like Wireshark with the OPC DA dissector allow auditing OPC Classic traffic on the network. It is worth conducting such an audit to identify all active DCOM sessions and verify whether authentication is actually enforced.

No support outside Windows

OPC Classic works exclusively on the Windows platform because DCOM is a Microsoft technology. This means every OPC Classic server and client is a Windows machine with all the consequences - OS updates, account management, exposure to Windows-targeting malware.

Network segmentation with OPC Classic

Network segmentation involving OPC Classic requires special attention due to dynamic ports and Windows infrastructure dependencies.

Practical recommendations

Restrict DCOM port range - configure a static port range in the Windows registry on every OPC server and client. Document these ranges centrally.
Firewall rules: TCP 135 + dynamic range - allow TCP 135 and the configured port range only between specific IP address pairs (client-server). Block OPC traffic from/to any other source.
OPC tunneling as an alternative - products such as Matrikon OPC Tunneller, Kepware LinkMaster, or Softing dataFEED encapsulate OPC Classic traffic in a single TCP tunnel on a fixed port. This eliminates the dynamic port problem and simplifies firewall configuration. This is the recommended transitional approach.
DMZ zone for OPC servers - an OPC server exposing data from the OT network to IT systems (historian, MES) should be placed in a DMZ zone. The IT OPC client connects to the server in the DMZ, not directly to the server in the OT zone.
Windows hardening - minimize services, block unnecessary ports, use GPOs to restrict remote DCOM access, disable anonymous access to the RPC Endpoint Mapper.
Migration plan to OPC UA - OPC UA solves the fundamental problems of OPC Classic: it operates on a single configurable port (default TCP 4840), supports TLS, X.509 certificate authentication, and is cross-platform. A migration timeline should be prepared for every existing OPC Classic deployment.
DCOM session monitoring - logging DCOM connections at the Windows system level (Event Log, DCOM audit) combined with a SIEM system allows detecting unauthorized connection attempts.

More on designing zones and conduits in OT environments in the article OT network segmentation - how to protect industrial systems.

OPC UA - the successor solving security problems

OPC UA (Unified Architecture) was designed from the ground up with security in mind:

Feature	OPC Classic	OPC UA
Transport	DCOM (port 135 + dynamic)	TCP (default 4840, configurable)
Authentication	NTLM/Kerberos (DCOM configuration)	X.509 certificates, username/password, Kerberos
Encryption	Optional (RPC Packet Privacy)	TLS, AES-256, RSA-2048+
Operating system	Windows only	Cross-platform (Windows, Linux, embedded)
Firewall	Difficult configuration (many ports)	Single port
Status	Legacy, no development	Active development, new specifications

Migration to OPC UA is not always immediate - it requires updating OPC server software, clients, and often controllers. But for every new project, OPC UA should be the only option considered.

Summary

OPC Classic is a protocol that enabled industrial system interoperability for two decades, but its DCOM-based architecture now poses a serious security burden. Dynamic ports hinder segmentation, DCOM authentication configuration is complex and often skipped, and Windows dependency limits hardening options. Where OPC Classic must remain, restricting ports, tunneling, and DMZ placement are essential. Where possible - migrate to OPC UA.

Open source tools

Tool	Language	Description	Link
OPC Expert	GUI (Windows)	Free Softing tool for browsing and diagnosing OPC Classic servers	softing.com
Matrikon OPC Explorer	GUI (Windows)	Free OPC Classic client for browsing, reading, and writing data from OPC DA servers	matrikonopc.com
Wireshark	C	DCOM/OPC dissector - analysis of RPC sessions, identification of OPC servers and DCOM operations	wireshark.org

TIP

OPC Classic servers expose DCOM interfaces - the OpcEnum service on port 135 allows listing all registered OPC servers on a given Windows machine.

Sources

OPC Foundation - OPC Classic Specifications - official OPC Classic documentation
OPC Foundation - OPC UA - OPC UA specification
Microsoft - Configuring DCOM for OPC - DCOM configuration documentation
CISA - Recommended Practices for OPC Security - CISA recommendations
Matrikon OPC Tunneller - OPC Classic tunneling solution
Langner, Ralph - “OPC Security: Old Problems and New” - OPC security analysis in the Stuxnet context