What is DCOM and Why Does It Matter for OPC? Firewall, Hardening & Fixes

What DCOM is

COM (Component Object Model) lets two programs on the same Windows machine share data and call each other's functions through a well-defined binary interface. DCOM extends that capability across a network: a program on Machine A can call methods on a COM object running on Machine B as if the remote object were local. The network transport, authentication, and marshaling of function calls are handled transparently by the Windows operating system on both machines.

DCOM was introduced with Windows NT 4.0 in 1996, the same year the OPC Foundation released the first OPC DA specification. The timing was not coincidental. The OPC task force deliberately built OPC Classic on COM and DCOM because they were the established Microsoft standards for application interoperability, and because they made it possible for any Windows application to access any OPC-compliant device driver without a custom software interface on each side. This was the specific problem OPC was designed to solve: ending the proliferation of one-to-one driver relationships between SCADA software and hardware PLCs.

For local OPC connections, where the OPC server and the OPC client run on the same Windows machine, COM handles the communication and DCOM is not involved. Local COM is fast, stable, and largely immune to the configuration complexity that DCOM introduces. The vast majority of DCOM-related OPC problems occur in remote OPC configurations, where the OPC server runs on one computer (often the SCADA server or a dedicated OPC server machine) and the OPC client runs on a different computer (a historian, a data logger, a remote HMI, or a different SCADA application).

COM vs DCOM in one sentence: COM is a local inter-process communication standard. DCOM is COM extended across a TCP/IP network. An OPC server is a COM server whether accessed locally or remotely. When accessed from another machine, DCOM becomes the transport. The OPC application code does not change between local and remote configurations; Windows decides whether to route the COM call locally or via DCOM based on whether the server is registered on the local machine or on a remote host.

How DCOM establishes a remote OPC connection

When an OPC client tries to connect to an OPC server on a remote machine, DCOM performs a sequence of steps that involve multiple network connections, Windows authentication, and registry lookups on both machines. Understanding this sequence explains why DCOM configuration involves so many moving parts and why a single misconfiguration in any step breaks the connection silently.

1

Client contacts the RPC Endpoint Mapper on the server machine

The OPC client sends a connection request to TCP port 135 on the OPC server machine. Port 135 is the RPC (Remote Procedure Call) Endpoint Mapper, the directory service that tells DCOM clients which dynamic port a specific COM server is listening on. This port must be open in the Windows firewall on the server machine and reachable from the client machine's network.

Firewall requirement: TCP 135 open inbound on the OPC server machine.

2

Endpoint Mapper returns a dynamic port number for the OPC server

The Endpoint Mapper looks up the CLSID (Class ID) of the requested OPC server in its registry and returns the specific dynamic high port (in the range 1024-65535 by default) that this OPC server instance is currently listening on. This dynamic port assignment changes each time the OPC server starts, which is what makes DCOM firewall configuration difficult: you cannot statically open one port for OPC traffic because the port number is different each session.

Problem: Dynamic ports require either opening the full 1024-65535 range or configuring a fixed DCOM port range in the Windows Registry.

3

Client authenticates with the server using Windows authentication

DCOM uses Windows authentication to verify that the OPC client machine and user have permission to access the OPC server. In a Windows domain environment, Kerberos authentication handles this automatically if both machines are domain members. In a workgroup environment (no domain controller), both machines must have a local Windows account with the same username and password. Mismatched accounts or passwords are the most common cause of DCOM authentication failures.

Requirement: Matching Windows accounts, or domain membership on both machines. The client user identity must have DCOM Launch and Access permissions on the server.

4

Server checks DCOM Launch and Access permissions

The OPC server machine checks whether the authenticated client identity has been granted Launch permission (to start the OPC server process if it is not already running) and Access permission (to make calls on the running OPC server). These permissions are configured in the Windows Component Services administrative tool (dcomcnfg.exe), under the specific OPC server application's properties. Missing permissions produce "access denied" errors at connection time even when authentication succeeds.

Configuration: dcomcnfg.exe on the OPC server machine. Component Services > Computers > My Computer > DCOM Config > [OPC Server application] > Security tab.

5

Data flows on the dynamic port for the session duration

Once authentication and permission checks pass, OPC data flows between client and server on the negotiated dynamic port for the duration of the session. DCOM handles retry logic and timeout management. If the network connection drops, DCOM attempts reconnection. If the OPC server restarts, DCOM must reestablish the session, potentially assigning a new dynamic port, which may require a new firewall rule if the firewall inspects port-level connections.

Session port: dynamic, assigned by Endpoint Mapper. Changes on OPC server restart. Restrict to a defined range via HKLM\SOFTWARE\Microsoft\Rpc\Internet registry key.

DCOM firewall ports: what needs to be open

Port	Protocol	Direction	Purpose	Notes
135	TCP	Inbound to OPC server	RPC Endpoint Mapper: the directory service that tells clients which dynamic port the OPC server is on	Must always be open. Without this, DCOM cannot locate the OPC server at all. This is the first port OPC connectivity troubleshooting checks.
1024-65535	TCP	Inbound to OPC server	Dynamic data ports: the actual port the OPC server uses for data transfer, assigned by the Endpoint Mapper	Default range is the full dynamic port range. Opening this range is a significant security exposure. Best practice is to restrict DCOM to a defined smaller range (e.g., 5000-5100) via Windows Registry and open only that range in the firewall.
Custom range	TCP	Inbound to OPC server	Restricted DCOM port range configured via Registry	Set via HKLM\SOFTWARE\Microsoft\Rpc\Internet, MinPort/MaxPort/UseInternetPorts. Allows the firewall to be opened for only the defined range rather than all dynamic ports. Requires OPC server restart after configuration.
N/A	N/A	N/A	OPC tunneling (DataHub) replaces all of the above	DataHub OPC tunneling uses a single configurable TCP port (default 4502), initiated as an outbound connection from inside the OT network. No inbound firewall ports needed on the OPC server side. This is the recommended alternative to DCOM for remote OPC.

Windows DCOM hardening: what changed and when

Starting in 2021, Microsoft issued a series of Windows security updates that progressively hardened DCOM authentication requirements to address a class of DCOM vulnerabilities. These changes have had significant impact on existing OPC Classic installations that use remote DCOM connections.

June 2021

KB5004442 introduces DCOM hardening. Microsoft raises the required DCOM authentication level from "Connect" (level 2) to "Packet Integrity" (level 5). Initially, a registry key allows the change to be disabled. OPC clients built before this change typically use "Connect" authentication. Remote OPC connections from unupdated clients to updated server machines begin failing silently on sites that apply this patch.

June 2022

Hardening enabled by default. The authentication level change becomes active by default on all updated Windows machines. An OPC Classic client using "Connect" authentication can no longer connect to an OPC server where this hardening is active, regardless of other DCOM permissions. The Prosys OPC analysis confirms: "The hardening will make the operating system raise the used Authentication Level in non-anonymous connections to Packet Integrity, even if the application would use Connect." Vendor-supplied patches that update the OPC client to use Packet Integrity authentication are required for continued remote OPC connectivity.

March 2023

Hardening becomes permanent, no workaround. The registry key that previously allowed disabling the hardening is removed entirely. Organizations that have not updated both their OPC Classic client and server applications to use Packet Integrity authentication lose remote DCOM-based OPC connectivity with no further Windows-level workaround available. The OPC Foundation's explicit guidance: "Your best option and the most future-proof alternative in any case is to move from OPC Classic to OPC UA. In this case, you can disable DCOM and be sure that DCOM issues will not affect you anymore."

2024+

Ongoing brownfield impact. Many legacy SCADA, HMI, and historian applications whose vendors have not issued Packet Integrity authentication updates continue to lose remote OPC connectivity after Windows updates. Sites that defer Windows updates to avoid breaking OPC accumulate security debt. The most practical immediate solution for affected sites is OPC tunneling (DataHub), which eliminates DCOM from the remote OPC connection entirely without requiring changes to the OPC server or client applications.

Alternatives to DCOM for remote OPC connectivity

Best for legacy OPC Classic

OPC tunneling via DataHub

DataHub replaces DCOM as the network transport for remote OPC Classic connections. The OPC server connects locally (COM, not DCOM) to the OT-side DataHub instance. The IT-side DataHub instance presents a local OPC DA interface to the OPC client. DataHub handles the network transport over a single configurable TCP port via an encrypted proprietary connection, initiated outbound from the OT side. No DCOM. No firewall complexity. No authentication level mismatches. Works without any changes to existing OPC server or client applications.

SWTB: Cogent DataHub OPC tunneling.

Best for new connectivity

Migrate to OPC UA

OPC UA has no dependency on COM or DCOM. It uses TCP/IP directly with a simple, well-defined firewall profile (single configurable port, typically 4840). OPC UA's security model uses X.509 certificates and TLS encryption at the protocol layer, independent of Windows authentication. Adding new client applications that need data from an existing TOP Server installation costs one open TCP port, not a DCOM permission tree. The OPC Foundation's recommended path for any new OPC connectivity work.

SWTB: TOP Server exposes OPC UA alongside OPC DA from the same installation. No separate server required.

Reduce DCOM exposure

Keep OPC local on each machine

Local COM (OPC server and client on the same Windows machine) does not use DCOM and is not affected by DCOM hardening or firewall configuration. For sites where remote OPC is causing persistent DCOM problems, consolidating OPC server and client applications onto the same machine eliminates DCOM from the equation entirely. The OPC Foundation guidance confirms: "We encourage vendors to limit OPC COM to local machine communication only and rely on OPC UA for communication between nodes."

Applies to all TOP Server installations: local OPC DA client connections use COM, not DCOM, and are unaffected by hardening changes.

Diagnose and repair

OPC Tools for DCOM diagnostics

Before migrating to OPC UA or tunneling, some sites can resolve DCOM problems by correcting specific configuration issues: updating the OPC client to use Packet Integrity authentication, fixing DCOM Launch and Access permissions in Component Services, restricting the DCOM port range and opening only that range in the firewall, or ensuring matching Windows accounts in workgroup environments. OPC Tools provides diagnostic utilities for identifying which step in the DCOM connection sequence is failing.

SWTB: OPC Tools includes OPC connectivity diagnostics, server browser, and component registration verification utilities.

Frequently asked questions

What is dcomcnfg.exe and when do I need to use it?+−

dcomcnfg.exe is the Windows Component Services administrative tool, the primary interface for configuring DCOM settings. When you run it (Start > Run > dcomcnfg), it opens the Component Services snap-in where you can configure DCOM permissions for individual COM applications.

For OPC Classic remote connectivity, you typically need to use dcomcnfg on the OPC server machine to: set the OPC server application's Launch and Access permissions to allow the OPC client machine's user account; set the default DCOM authentication level; and optionally configure a fixed DCOM port range. The correct navigation path is Component Services > Computers > My Computer > DCOM Config, then find your OPC server application in the list, right-click it, select Properties, and configure the Security tab. The Identity tab controls what Windows account the OPC server runs under, which affects what resources it can access on the local machine.

Why does DCOM work on some Windows updates but break on others?+−

Microsoft periodically issues security updates that change DCOM behavior, typically by raising authentication requirements or restricting how COM server endpoints are registered. These changes are made in response to security vulnerabilities in the DCOM infrastructure. Because OPC Classic applications were built to work with the DCOM behavior that existed at the time they were developed, a Windows security update that changes DCOM behavior can silently break OPC connections that worked before the update.

The OPC Foundation has explicitly acknowledged this: "The trouble with DCOM support is MS is always adding security fixes to Windows that can break OPC DCOM applications." This is fundamentally why OPC UA was designed without any COM or DCOM dependency, and why the OPC Foundation's recommendation for any new inter-machine OPC connectivity is OPC UA rather than OPC Classic over DCOM.

Can I restrict which ports DCOM uses to simplify firewall configuration?+−

Yes. By default, DCOM assigns data ports dynamically from the full Windows dynamic port range (1024-65535 or 49152-65535 depending on Windows version), which makes static firewall rules impractical. You can restrict DCOM to a defined port range by adding registry values under HKLM\SOFTWARE\Microsoft\Rpc\Internet: set Ports to your desired range (e.g., 5000-5100), set PortsInternetAvailable to Y, and set UseInternetPorts to Y. After restarting the OPC server, DCOM will only use ports within that defined range, and you can open only that range in the firewall.

This reduces but does not eliminate the DCOM firewall complexity. TCP 135 must still be open for the Endpoint Mapper. Windows authentication must still be configured. The DCOM permissions tree in Component Services must still be correct. For most sites, OPC tunneling via DataHub is significantly simpler to configure and maintain than a correctly restricted DCOM firewall setup, and eliminates all of the above requirements.

Does the March 2023 DCOM hardening affect local OPC connections?+−

No. The DCOM hardening changes affect remote DCOM connections only, where the OPC client and OPC server are on different machines. Local COM connections, where the OPC client and OPC server run on the same Windows machine, are not affected by DCOM authentication level hardening because they do not use DCOM at all. Local COM uses in-process or out-of-process COM calls through shared memory and Windows messaging, with no network transport and no authentication level negotiation.

If your OPC server and historian or SCADA application run on the same machine, you can apply all Windows updates without affecting OPC connectivity. The hardening impact is limited to remote OPC configurations where DCOM carries data across a network between two different computers.

What is DCOM and why does it matter for OPC?