What is ActiveX in Industrial Automation? COM, DCOM & OPC Classic Explained

What ActiveX is and where it came from

ActiveX is not a single technology. It is Microsoft's branding for a family of component-based software technologies built on COM (Component Object Model) that allow software objects to interact with each other. COM defines a binary interface standard: any software component that implements a COM interface can be called by any other COM-aware application, regardless of which programming language each was written in. A C++ hardware driver can expose its data through a COM interface, and a Visual Basic HMI application can read that data without either application knowing the other's implementation details.

The technology chain that produced OPC Classic begins with OLE (Object Linking and Embedding), a Microsoft technology from the early 1990s that allowed documents to embed objects from other applications. From OLE came COM, the underlying binary standard. From COM came ActiveX, the branding Microsoft used for COM components designed for interactive and internet use. From ActiveX came DCOM (Distributed COM), which extended the same component interaction model across a network: a COM client on one machine could call methods on a COM server running on a different machine as transparently as if both components were local.

The OPC Foundation, then a task force composed of Fisher-Rosemount, Rockwell Software, Opto 22, Intellution, and Intuitive Technology, recognized this stack as an ideal foundation for industrial automation interoperability. Before OPC, each automation hardware vendor required its own custom driver on every application that needed to read its devices. If a plant had five PLC brands and five software applications, it potentially needed 25 custom drivers maintained by 10 different vendors. OPC used COM/DCOM to define a single driver interface: hardware vendors wrote one OPC server, and application vendors wrote one OPC client. The first OPC specification was released in August 1996 and achieved wide adoption within a few years.

The OLE/COM/ActiveX/DCOM/OPC technology chain: These terms are often used interchangeably in OPC documentation, which creates confusion. They are related but distinct: OLE is the document embedding standard that originally required COM. COM is the binary component interface standard. ActiveX is Microsoft's name for the interactive/component use of COM. DCOM extends COM across network connections. OPC Classic uses all of these: COM for local component communication between an OPC server and a client on the same machine, DCOM for remote access across a network. The OPCDAauto.dll, which is the Automation Wrapper that simplified OPC client development, is an ActiveX component that abstracts the lower-level COM interfaces into a simpler interface accessible from Visual Basic and scripting languages.

The COM/DCOM/ActiveX technology stack that OPC Classic runs on

OLE

Object Linking and Embedding: the original Microsoft component standard

Microsoft's 1990-era technology for embedding objects from one application into another (embedding an Excel spreadsheet in a Word document, for example). OLE required COM as its underlying component infrastructure. In OPC context, "OLE for Process Control" is the full expansion of the OPC acronym, referencing OLE as the generic Microsoft component technology on which the original OPC standard was built.

COM

Component Object Model: the binary interface standard for Windows components

COM defines how software objects expose their interfaces: a binary standard that allows any COM-capable programming language to call any COM component's methods and properties without knowing the component's implementation language. COM components are registered in the Windows Registry with GUIDs (Globally Unique Identifiers) that identify their interfaces. An OPC server is a COM server: it registers itself in the Windows Registry and exposes COM interfaces that OPC client applications call to read process variable data. COM communication is strictly within a single machine.

ActiveX

ActiveX: Microsoft's branding for interactive COM components

ActiveX is COM applied to interactive components: controls that can be embedded in containers (Internet Explorer, Visual Basic forms, HMI development environments) and expose properties, methods, and events through COM interfaces. In OPC client development, the OPC Automation Wrapper (OPCDAauto.dll) is an ActiveX component that wraps the lower-level OPC DA custom interface in a simpler Automation-compatible interface accessible from Visual Basic, VBScript, and other scripting environments. Many early SCADA and HMI products exposed their OPC client capability through ActiveX controls embedded in their application development environments.

DCOM

Distributed COM: COM extended across a network

DCOM extends COM's component interaction model across TCP/IP networks. An OPC client on one Windows machine can call methods on an OPC server running on a different Windows machine using the same programming model as local COM. DCOM handles the network transport, retry logic, and timeout management transparently to the application. Remote OPC connections, where the OPC server runs on one computer and the OPC client runs on another, use DCOM as the transport layer. This is the source of most OPC Classic network configuration complexity: DCOM requires Windows firewall rules (TCP port 135 for endpoint mapping, plus dynamic ports for the actual data channels), DCOM permissions configured in the Windows Component Services administrative tool, and Windows user account permissions aligned between client and server machines.

OPC Classic

OPC DA, HDA, A&E: the industrial data exchange specifications built on this stack

OPC Classic specifications (DA for real-time data, HDA for historical data, A&E for alarms and events) define the COM interfaces that OPC servers expose and OPC clients call. Every OPC DA server, regardless of the hardware it connects to (Allen-Bradley, Siemens, Modbus, DNP3, or any other protocol), exposes the same set of COM interfaces defined in the OPC DA specification. Every OPC DA client, regardless of its application type (SCADA, historian, MES, or data logger), uses those same interfaces. This standardization created the interoperability that freed automation engineers from custom driver proliferation. TOP Server is one of the most comprehensive OPC DA/HDA/A&E servers in the industry, supporting this full OPC Classic interface alongside its modern OPC UA server.

Known limitations of the COM/DCOM/ActiveX architecture

OPC Classic delivered enormous value: it standardized industrial connectivity for three decades and remains in active use across a huge percentage of the world's installed SCADA and historian infrastructure. But the COM/DCOM foundation imposed constraints that become increasingly difficult to manage as industrial networks modernize and cybersecurity requirements tighten.

🖥️

Windows-only architecture

COM and DCOM are Microsoft Windows technologies. OPC Classic servers and clients must run on Windows. Modern industrial architectures increasingly include Linux-based edge devices, cloud platforms, and embedded controllers that cannot host COM components. OPC UA is platform-independent by design, running on Linux, embedded RTOS, macOS, and cloud environments without Windows dependency.

🔒

DCOM firewall and permissions complexity

Remote OPC via DCOM requires TCP port 135 open for the RPC endpoint mapper, plus a range of dynamic high ports for the actual data connections. Configuring Windows firewall rules, DCOM launch and access permissions in Component Services, and Windows user account permissions between client and server machines is the most common source of OPC Classic connectivity problems. Each Windows security patch cycle can also silently change DCOM behavior.

🛡️

No built-in security at the protocol layer

OPC Classic has no application-level security: no message encryption, no certificate-based authentication, and no built-in authorization beyond Windows user account permissions. Data transmitted via DCOM between an OPC server and a remote OPC client travels unencrypted over the network. In OT cybersecurity terms, OPC Classic communications are fully visible to any device with access to the network segment between the server and client machines.

💻

Tight Windows version coupling

OPC Classic behavior is tied to the specific Windows version, service pack level, and installed security patches on both the server and client machines. Changes to DCOM behavior introduced by Windows security updates have repeatedly broken working OPC configurations without any application-level change. The OPC Foundation's forum confirms this directly: "The trouble with DCOM support is MS is always adding security fixes to Windows that can break OPC DCOM applications."

📡

Point-to-point scalability ceiling

Each OPC client connects directly to each OPC server. For a historian that needs data from 50 OPC servers, it must maintain 50 individual DCOM connections. For 10 applications each needing data from 50 servers, the network carries 500 DCOM connections. This does not scale well for large IIoT deployments where many applications need access to many devices, compared to the pub/sub broker model used by OPC UA PubSub and MQTT.

🚫

Firewall-incompatible by default

DCOM's dynamic port allocation makes it inherently difficult to secure with a stateful firewall. Restricting DCOM to a defined port range requires Windows registry configuration that is not enabled by default, and even then the configuration is fragile across Windows updates. Sending OPC Classic data across a firewall or DMZ boundary without specialized tunneling software (like DataHub) is either a significant security risk or an ongoing configuration maintenance burden.

Microsoft DCOM hardening and its impact on OPC Classic

Starting in 2021, Microsoft began issuing Windows security updates that progressively hardened DCOM authentication requirements in response to a class of DCOM security vulnerabilities. This hardening changed the required authentication level for DCOM connections from "Connect" to "Packet Integrity," which silently broke many existing OPC Classic remote connections that were configured with the older, less strict authentication level.

June 2021

Microsoft begins DCOM hardening patches. KB5004442 introduces DCOM authentication hardening. Initially the change is disabled by default but can be enabled via registry key. Some organizations begin experiencing OPC connectivity issues after applying Windows updates.

June 2022

Hardening enabled by default. The DCOM authentication level change becomes enabled by default for new Windows installations and updated machines. OPC Classic clients using the "Connect" authentication level cannot connect to servers where the hardening is active. Vendor patches that update the client to use "Packet Integrity" authentication are required.

March 2023

Hardening becomes permanent. The registry key that previously allowed disabling the hardening is removed. Organizations that have not updated their OPC Classic clients and servers to use Packet Integrity authentication lose remote OPC connectivity with no further workaround available at the Windows level. The only solutions are: update client and server applications to use the new authentication level, switch to OPC UA, or use OPC tunneling software to route OPC data without DCOM across the network.

2024+

Ongoing impact in brownfield installations. Many industrial facilities with older HMI, SCADA, and historian systems that cannot be updated to use Packet Integrity authentication continue to experience DCOM-related OPC connectivity problems after Windows updates. The OPC Foundation's recommendation remains: for any remote OPC communication, migrate to OPC UA or use a gateway product. Local DCOM (OPC server and client on the same machine) has fewer security issues and continues to work.

Migration options: from ActiveX/OPC Classic to OPC UA

The good news for organizations with large OPC Classic installations is that migration does not require ripping out field devices or replacing OPC servers all at once. Several migration paths accommodate the installed base while progressively moving toward OPC UA architecture.

1

Keep OPC Classic local, tunnel across network boundaries

For installations where the OPC server and OPC client run on the same machine, COM (local) communication continues to work well and avoids DCOM entirely. For remote OPC access across a network or DMZ, replace the DCOM transport with an OPC tunneling solution that eliminates the DCOM firewall and permissions complexity without requiring changes to the OPC server or client applications.

SWTB: Cogent DataHub OPC tunneling replaces DCOM for remote OPC DA connections. The OPC server and client both connect locally to their respective DataHub instances; DataHub handles the network transport via an encrypted proprietary connection, with no DCOM required across the network.

2

Add OPC UA alongside OPC Classic on the server side

Most modern OPC servers, including TOP Server, simultaneously expose both OPC Classic (DA/HDA/A&E) and OPC UA interfaces from the same server instance and the same device connections. New OPC UA-capable client applications (historians, SCADA platforms, MES systems) can connect via OPC UA while legacy applications that cannot yet be updated continue to connect via OPC Classic. This coexistence phase allows gradual migration of client applications without a hard cutover.

SWTB: TOP Server exposes all connected device data via both OPC DA/HDA/A&E (for legacy clients) and OPC UA (for modern clients) from the same installation. No separate OPC UA server is required alongside an existing TOP Server installation.

3

Wrap legacy OPC DA clients with an OPC DA-to-UA bridge

For applications that can only speak OPC DA but need to connect to an OPC UA server (or vice versa), an OPC DA/UA bridge translates between the two protocols without requiring application changes. This allows a legacy OPC DA-only HMI to continue operating while the OPC server is migrated to OPC UA, or allows a modern OPC UA historian to read from a legacy OPC DA-only device driver that has not yet been updated.

SWTB: OPC Tools includes OPC DA-to-UA bridging utilities for translating between OPC Classic and OPC UA client/server interfaces. For legacy ActiveX-based custom applications that embed OPC DA client controls, OPC Tools provides the wrapper layer that preserves the ActiveX interface while connecting to a modern OPC UA data source.

4

Full OPC UA migration: replace OPC Classic entirely

The long-term architecture replaces all OPC Classic components with OPC UA throughout: OPC UA servers at the device layer, OPC UA clients in all applications, and OPC UA PubSub or MQTT for plant-to-enterprise data distribution. OPC UA eliminates the Windows dependency, provides built-in security (X.509 certificates, message encryption, message signing), and scales from embedded devices to cloud platforms without the DCOM constraints that limited OPC Classic to Windows-only, same-domain network environments.

SWTB: TOP Server's OPC UA server interface, N3uron's OPC UA client-to-MQTT bridge, OPC Router's workflow-based OPC UA data routing, and DataHub's secure OPC UA proxy together provide a complete OPC UA data pipeline from field device to enterprise application without any OPC Classic dependency.

Frequently asked questions

Is OPC Classic still supported in 2026?+−

Yes. OPC Classic (OPC DA, HDA, A&E) is still in active use across a very large percentage of the world's installed industrial automation infrastructure. TOP Server continues to support OPC DA, HDA, and A&E alongside OPC UA. Microsoft has not removed COM or DCOM from Windows and has indicated it has no current plans to do so. The OPC Foundation continues to maintain OPC Classic specifications alongside OPC UA.

That said, OPC Classic is in maintenance mode: no new features are being added to the specifications, and the OPC Foundation directs new development to OPC UA. The DCOM hardening changes from 2021 to 2023 have created ongoing challenges for remote OPC Classic connectivity, reinforcing the OPC Foundation's guidance to use OPC UA for any new inter-machine OPC connectivity. For local OPC (server and client on the same machine), OPC Classic continues to work reliably without DCOM complexity.

Why did the OPC Foundation choose ActiveX/COM instead of a network-native protocol in 1996?+−

In 1996, COM and ActiveX were the dominant Microsoft application integration frameworks, and the OPC Foundation's founding members were primarily Windows software vendors. COM provided a proven, well-documented binary standard that allowed hardware vendors to write device drivers and expose them to any COM-capable application, solving the immediate problem of driver proliferation without requiring a new network protocol standard from scratch.

The Inst Tools history of OPC explains the reasoning directly: COM provided a binary standard where C++ hardware developers could write components accessible from Visual Basic application developers, which was an ideal match for the automation industry's structure of hardware-focused driver developers and application-focused SCADA developers. DCOM extended this to networked environments. In retrospect, the Windows and DCOM dependency created long-term constraints, which is precisely why the OPC Foundation spent several years designing OPC UA as a platform-independent, network-native replacement.

What is the OPCDAauto.dll and why does it appear in OPC documentation?+−

OPCDAauto.dll is the OPC DA Automation Wrapper, a standard ActiveX component defined by the OPC Foundation that wraps the lower-level OPC DA custom interface (which requires C++ to implement directly) in a higher-level COM Automation interface accessible from Visual Basic, VBScript, Python, and other scripting languages. It translates the complex OPC DA interface into a simpler object model that non-C++ developers can use to build OPC DA clients.

Many legacy OPC client applications built in Visual Basic or as scripted integrations use OPCDAauto.dll as their OPC client library. The file must be registered in the Windows Registry on the client machine (using regsvr32 OPCDAauto.dll) for these applications to function. When OPC Classic connectivity troubleshooting involves ActiveX registration errors or "class not registered" errors, the OPCDAauto.dll registration is often the issue. OPC Tools from SWTB includes utilities for verifying and repairing OPC component registration, including OPCDAauto.dll.

Can OPC Classic data cross a firewall or DMZ without DCOM?+−

Not natively. Standard OPC Classic remote communication requires DCOM across the network, which in turn requires open firewall ports (TCP 135 plus dynamic high ports) and Windows domain trust or matching local account credentials. This makes OPC Classic inherently firewall-unfriendly and unsuitable for crossing IT/OT DMZ boundaries in a security-conscious architecture.

The solution is OPC tunneling: a pair of software components (one on each side of the firewall) that communicate over a single, configurable TCP port using a proprietary protocol, while presenting a local OPC DA interface to both the OPC server and OPC client. Neither the OPC server nor the OPC client knows DCOM is not being used for the network transport. DataHub's OPC tunneling capability implements this pattern, allowing OPC Classic data to cross firewall and DMZ boundaries without opening DCOM ports, and without requiring any changes to the OPC server or client applications. The tunneled connection can be encrypted and initiated from inside the secured OT network (outbound-only), making it compatible with zero-trust OT security principles.

What is ActiveX in industrial automation?