OPC Classic and DCOM Hardening Guide: Securing Legacy OPC DA After the DCOM Change

OPC Classic still carries process data between SCADA, historians and control systems in most plants, and it rides on DCOM, one of the hardest Windows protocols to secure and firewall. When Microsoft hardened DCOM authentication to fix CVE-2021-26414, many OPC DA, HDA and Alarms and Events links that had quietly run with weak or no authentication stopped working, and the common fix was to weaken security again. This guide explains how OPC Classic uses DCOM, what the Microsoft hardening change requires, how to configure accounts, permissions, authentication levels and firewalls so OPC keeps working securely, and when to wrap or migrate to OPC UA instead. It is for OT engineers, control system integrators and OT security teams responsible for Windows-based SCADA and historian estates.

Key takeaways

• The DCOM hardening is permanent: Microsoft's KB5004442 rollout ends with servers enforcing an authentication level of packet integrity or higher with no option to disable it. Fixing OPC clients, not reverting the change, is the only durable path.
• Most OPC breakage is an authentication level mismatch: older OPC clients request a level below RPC_C_AUTHN_LEVEL_PKT_INTEGRITY (value 5), which the hardened server now rejects.
• Accounts are the real control: OPC Classic security depends on Windows identities, launch and access permissions on each OPC server's AppID, and the identity the server runs as. Shared local accounts with matching passwords on every node are the usual weak point.
• DCOM needs TCP 135 plus dynamic ports: restrict the dynamic range in the registry and allow it only between named OPC client and server hosts, never across the IT and OT boundary.
• Tunnel or wrap across zones, migrate when you can: crossing a zone boundary with raw DCOM is the wrong design. Use an OPC UA wrapper or tunneller at the edge, and plan OPC UA migration as systems are upgraded.

How OPC Classic uses COM and DCOM

The OPC Foundation describes OPC Classic as the earlier family of specifications built on Microsoft COM/DCOM, with three main areas: Data Access (DA) for live values with timestamps and quality, Alarms and Events (AE), and Historical Data Access (HDA). Each OPC server is a COM server registered with a ProgID, CLSID and AppID on its host. A client on another machine activates the server through DCOM: it contacts the RPC Endpoint Mapper on TCP 135, which returns a dynamic port where the server listens, and from then on calls (and, for DA subscriptions, callbacks from server to client) flow over that port.

Microsoft defines seven authentication levels, from RPC_C_AUTHN_LEVEL_DEFAULT (0) and NONE (1) through CONNECT (2), CALL (3), PKT (4), PKT_INTEGRITY (5), which authenticates the data and verifies it was not modified in transit, to PKT_PRIVACY (6), which also encrypts call arguments. Many OPC integrations were configured years ago at None or Connect, often with Everyone or Anonymous Logon granted launch and access rights, because that was the quickest way to make cross-machine OPC work.

What the Microsoft DCOM hardening changed

Microsoft's KB5004442 addresses a Windows DCOM Server security feature bypass, CVE-2021-26414. The hardening makes DCOM servers enforce an authentication level of RPC_C_AUTHN_LEVEL_PKT_INTEGRITY or higher for activation. Microsoft delivered it in phases:

• Registry value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat, DWORD RequireIntegrityActivationAuthenticationLevel, 0 or absent for disabled and 1 for enabled during the transition phases, with a restart required. In the final phase this value no longer turns the hardening off.
• Exact dates: Microsoft revised the dates for the later phases during the rollout. Check the current KB5004442 text for the dates that apply to your servicing level; do not rely on blog posts.
• Event logging: Windows logs DistributedCOM events in the System log when activation is rejected for an insufficient authentication level (commonly cited as event ID 10036 on the server and 10037 and 10038 on the client). Use these to find every affected OPC client before enforcement reaches your patch level.
• Who must fix what: Microsoft recommends testing both client and server applications that use DCOM. In practice the fix is in the OPC client: it must request PKT_INTEGRITY or higher, either through a vendor update or through updated OPC Core Components.

The risk in many plants is the reverse fix: holding back Windows updates on OPC hosts indefinitely, or setting the value to 0 and forgetting it. Both leave the original weakness in place and stall patching for unrelated vulnerabilities.

Hardening OPC Classic hosts step by step

1. Inventory every OPC link: list each OPC server (vendor, ProgID, host), each client (SCADA, historian, MES, engineering tools, OPC tunnellers) and the direction of data and callbacks. Include OPCEnum, the OPC Foundation server browser that remote clients use to list servers.
2. Collect evidence before changing anything: enable the hardening in audit-like fashion on a test pair first, and review DistributedCOM System log events on servers and clients.
3. Update OPC clients and Core Components: ask each vendor for the version that supports packet integrity, and install the current OPC Core Components redistributable on both sides.
4. Create dedicated accounts: one domain service account (or, in workgroup OT networks, one local account per role with a unique strong password on each host) for each OPC client application, plus a separate RunAs identity for the OPC server. Do not use local Administrator or Interactive User.
5. Set per-AppID permissions: in dcomcnfg, under the OPC server's AppID, grant launch, activation and access only to the client service account and an OT engineering group. Remove Everyone and Anonymous Logon. Grant the server identity access on the client host for callbacks.
6. Tighten machine-wide limits: review MachineLaunchRestriction and MachineAccessRestriction so they allow the OPC accounts but do not grant remote launch to Everyone.
7. Raise authentication levels: set the machine default authentication level to Packet Integrity (or Packet Privacy where all components support it) and confirm each OPC server process requests at least that level.
8. Restrict DCOM ports: configure HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet with a Ports range (REG_MULTI_SZ), PortsInternetAvailable = Y and UseInternetPorts = Y, then restart. Microsoft advises a range above 5000 and at least 100 ports, because other services use RPC too.
9. Firewall by host pair: on Windows Defender Firewall and the zone firewall, allow TCP 135 and the restricted dynamic range only between the named OPC client and server hosts, in both directions where callbacks are used.
10. Enable the hardening and test: run every data flow, including reconnection after a server restart, historian backfill and alarm acknowledgement.
11. Rollback plan: keep exported dcomcnfg and registry settings and the previous client versions. During the transition phases, setting RequireIntegrityActivationAuthenticationLevel to 0 is the emergency rollback, but record it as a time-limited exception with an owner.

Crossing zones: tunnelling, wrapping and migration

DCOM was designed for a single Windows domain and does not suit firewalled ICS zone designs. Opening TCP 135 and a port range from a business network or DMZ into a control zone should be treated as a design defect. The common alternatives:

The OPC Foundation presents OPC UA, released in 2008, as the platform-independent successor that brings together the Classic functionality with secure access through firewalls. See the OPC UA Security Guide for its security modes, certificates and user tokens, and the OT Security Guide for zone and conduit design.

Choosing between the options: if the link stays inside one control zone and the OPC vendor supports packet integrity, harden DCOM in place. If the link crosses a zone boundary, or a client vendor cannot support the hardening, put a tunneller or OPC UA gateway on the server side so DCOM never leaves the host or zone. If the control system is due for a major upgrade within two years, spend the effort on OPC UA rather than on a long-lived tunnel. Small sites with a handful of OPC links can usually harden in place in one outage; large multi-vendor sites need a phased plan by area and a test bench for each vendor combination. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Where identity fits

OPC Classic has no security of its own: every decision is made on the Windows identity of the caller. That makes the OPC service accounts some of the most important non-human identities in a plant.

• Workgroup "pass-through" accounts: OT networks without a domain often use the same local username and password on every host so that DCOM authentication succeeds. One compromised host then reveals a credential that works everywhere. Prefer an OT domain, or at least unique credentials per host pair managed in a vault.
• Interactive User identity: a server set to run as the interactive user runs with whatever rights the logged-on operator has, and stops when no one is logged on. Use a dedicated low-privilege service identity.
• Over-broad groups: granting DCOM rights to Everyone, Authenticated Users or local Administrators makes any account on the network an OPC client. Grant named accounts or a small group.
• Password rotation: OPC service accounts are often excluded from rotation because a change breaks links. Rotate them on a planned schedule with every dependent host updated in the same window.

DCOM is also a lateral movement channel: MITRE ATT&CK lists T1021.003 Remote Services: Distributed Component Object Model, and the ICS matrix lists T0886 Remote Services and T0859 Valid Accounts. Restricting who can launch and access DCOM objects reduces that path as well as protecting OPC. Where OPC hosts are domain joined, a group managed service account removes the password handling problem entirely for the server identity. See the Group Managed Service Accounts (gMSA) Guide.

Detection and monitoring

• DistributedCOM events: collect System log DCOM events from every OPC host; a spike after patching means a client is still using a low level, and events after stabilisation can mean an unknown client.
• Logon events: monitor Security log logons (event 4624, logon type 3) by OPC service accounts from hosts that are not in the inventory, and failed logons (4625).
• Network: passive OT monitoring should alert on new DCOM or RPC flows (TCP 135 and the dynamic range) between hosts that have no documented OPC link, and on any DCOM crossing zone boundaries.
• Configuration drift: baseline the dcomcnfg settings, the AppCompat value and the Rpc\Internet ports; alert on change.

Metrics

• Percentage of OPC links running at packet integrity or higher.
• Number of OPC hosts with the hardening disabled by registry exception, and the age of each exception.
• Number of OPC servers granting launch or access to Everyone or Anonymous Logon (target zero).
• Number of DCOM flows crossing a zone boundary (target zero).
• Percentage of OPC service accounts with unique, vaulted, rotated credentials.

Framework mapping

Common failure patterns

• Reverting instead of fixing: setting the AppCompat value to 0 to restore links and never updating the clients, then hitting the final enforcement phase unprepared.
• Freezing Windows updates on OPC hosts to avoid the change, leaving them exposed to other vulnerabilities.
• Everyone and Anonymous Logon granted remote launch and access, copied from an old integration manual.
• Whole dynamic range open (TCP 49152 to 65535, or "any") between IT and OT to make DCOM work through a firewall.
• Shared local accounts with the same password on every SCADA and historian node.
• Undocumented callbacks: firewall rules allow client to server but not the server's callbacks, so engineers widen rules until things work.

Practitioner checklist

• Inventory every OPC Classic server, client, tunneller and data flow, including callbacks.
• Review DistributedCOM System log events on all OPC hosts.
• Update OPC clients and OPC Core Components to versions that support packet integrity.
• Replace shared and interactive identities with dedicated, least-privilege service accounts.
• Remove Everyone and Anonymous Logon from launch, activation and access permissions.
• Set the machine default authentication level to Packet Integrity or higher.
• Restrict the RPC dynamic port range and allow it only between named host pairs.
• Remove any DCOM traffic crossing zone boundaries; use a tunneller, OPC UA gateway or DMZ historian.
• Track every hardening exception with an owner and an expiry date.
• Plan OPC UA migration into each control system upgrade.

Standards and references

• Microsoft Support: KB5004442 Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)
• Microsoft Learn: Authentication-Level Constants
• Microsoft Learn: Security in COM
• Microsoft Learn: Configure RPC dynamic port allocation to work with firewalls
• OPC Foundation: OPC Classic
• MITRE ATT&CK: Remote Services: Distributed Component Object Model
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: OT Security Guide · OPC UA Security Guide · NIST SP 800-82 OT Security Guide · Industrial IoT (IIoT) Security Guide