Windows DCOM Server Security Feature Bypass

UPDATE 21.07.2022: Prosys Sentrol OPC UA & Classic SDK has now been fixed.

UPDATE 21.06.2022: Prosys OPC Classic Client has now been fixed.

Microsoft has found a vulnerability (KB5004442, CVE-2021-26414) in DCOM and have decided to enforce hardening changes that will be applied over the next Windows updates.

The change affects OPC classic applications that use remote connections and the OPC Foundation has also released a notification about the issue.

The timeline for the updates is as follows:

June 8, 2021Hardening changes available, but disabled by default.
June 14, 2022Hardening changes will be enabled by default in Windows updates. You can still disable the changes. See below how.
March 14, 2023Hardening changes will be enforced in Windows updates.

The changes will affect usage of OPC classic client applications that connect to OPC classic servers running in another computer (using Distributed COM). Connections within the same computer are not affected (they are using COM).

The hardening will become effective, when Windows is updated in the server computer. As a result, client applications running in other computers will need to be updated.

Prosys OPC Products Affected

The hardening changes affect directly

Fixed Products

Overcoming the Problems in Your Sentrol Applications

Prosys Sentrol 7.5.0 and later will initialize COM with the required alPacketIntegrity security level by default, so you only need to recompile your applications with the new Sentrol libraries.

If you are still using Prosys Sentrol 7.4.0 or earlier, you must add the following to the Project Source code of your OPC Classic client applications:

					program Xxx;


  PsInitComSecurity(alPacketIntegrity, ilIdentify);

ComSecurity is initialized by default with alConnect level in these versions. That used to be enough to make remote connections, but after the Windows hardening, the servers will not accept connections with that level any more.

Note that as long as your applications connect over OPC Classic only within the same computer, the connections should work despite this setting.

Move to OPC UA

An alternative way to overcome the issue is to avoid remote DCOM connections between the OPC applications. Instead, you should consider moving the connections to use OPC UA, by applying OPC UA Gateway as a tunneler, for example.

Or, you should consider supporting OPC UA in your own applications, which is also possible with Prosys Sentrol.

Enabling and Disabling The Hardening

The changes can be enabled and disabled (until March 14, 2023) using the following Windows Registry key:

RequireIntegrityActivationAuthenticationLevel (DWORD value)

The value of 1 means that the hardening is enabled and 0 means that it’s disabled.

Note that you have to restart the computer for the changes in the registry key to take effect.

Registry Editor Window

The feature has already been made available in June 8, 2021, so if you have the latest updates in your Windows operating systems, you can try it out.


You should be able to see the effect, for example, by connecting remotely with Prosys OPC Client version 2.0 to Prosys OPC Simulation Server. (NOTE that the latest version 2.1 is already initializing COM properly, so it will be able to connect to a hardened server as well.) If the hardening is disabled in the server and you have configured DCOM and firewall to enable connections, you should be able to see the list of servers and connect to the Simulation Server.

RequireIntegrityActivationAuthenticationLevel=0 (DWORD value)

(Reboot after change)

Prosys OPC Classic Client - Access Denied window

Alternatively, you can try to just connect to the server. If it is also installed in the client computer, you can use the ProgID, e.g. ‘Prosys.OPC.Simulation’; otherwise you will need to use the CLSID, e.g. ‘{EB3A5F8E-7938-464C-AEFA-898335B1E6B5}’ in the Server field.

Prosys OPC Classic Client - Connect with CLSID

This should also fail with ‘Access denied’, if the hardening is enabled.

You can also enable logging of DCOM errors in the server computer to validate this. To do this, add the following registry key:

CallFailureLoggingLevel=1 (DWORD Value)

After this, you should see the following error in the Event ViewerWindows Logs-System (You can start it by typing ‘Event Viewer’ in the Start Menu):

Event Viewer window

And finally, when you have an application that initializes COM Security properly, you should be able to connect again.

Author Info

Headshot of Jouni Aro

Jouni Aro

Chief Technology Officer


Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top