Yes. DCOM is still supported in Windows 11 in 2026, including for applications that use remote COM activation and communication. Support does not guarantee that an existing OPC Classic connection will work unchanged: DCOM authentication hardening, Windows permissions, firewall rules, and application compatibility still determine whether it connects.
TL;DR
A Windows upgrade and an industrial connectivity migration are different projects. Windows 11 retaining DCOM does not establish that your OPC server, client, installer, or service account configuration supports the new host. Treat operating-system support and application support as separate acceptance criteria.
Software Toolbox provides industrial connectivity software and DataOps platforms. For an industrial deployment, start with the required data path and security boundary, then determine whether retaining DCOM meets those requirements. Do not replace a working architecture solely because someone says Windows 11 removed DCOM.
Windows 11 includes DCOM; it has not replaced every COM-based application interface with OPC UA or another protocol. DCOM remains relevant to OPC Classic applications, including OPC DA implementations that communicate between Windows computers.
The important distinction is between the presence of a Windows component and the support status of software using it. A DCOM-based application can depend on installer behavior, COM registration, service identities, and interfaces that require separate validation.
Does Windows 11 include DCOM?
Does that certify an OPC Classic application?
Can remote activation ignore DCOM hardening?
Does an open endpoint mapper port prove connectivity?
Does local operation prove remote operation?
For your 2026 deployment review, use Microsoft's DCOM authentication hardening guidance, KB5004442, for the remote activation requirement. Use Microsoft's Windows lifecycle information for the specific Windows edition and release. Neither reference substitutes for the application vendor's compatibility statement.
A Windows compatibility statement must identify the application release, not just the product family. An older installer or executable does not become supported because another release of the same product supports Windows 11.
Record the client and server versions, installed components, operating-system editions, and whether each executable runs interactively or as a service. Include dependencies that participate in browsing or connection establishment. That inventory gives the application vendor a reproducible configuration rather than a general question about Windows.
A client and server on the same computer do not exercise the same network path as applications on separate hosts. Local success establishes that some application functions work; it does not validate remote authentication, RPC firewall handling, or return traffic.
Test the deployed topology. If production uses separate computers, a same-machine demonstration is not an acceptance test. Likewise, successful browsing is not proof that a subscription will continue delivering updates.
Microsoft's DCOM hardening requires at least packet integrity for remote activation. In Windows authentication terminology, that requirement is RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Packet integrity protects message integrity; it is not the same as packet privacy, which adds encryption.
Older application behavior becomes a problem when the activation request does not meet the required authentication level. A connection failure after an update therefore does not establish that DCOM was removed. Investigate the authentication failure and the requesting process before changing unrelated permissions.
Do not use disabling DCOM hardening as a 2026 remediation plan. Microsoft's hardening enforcement is not a supported configuration choice that you can permanently turn off to accommodate an incompatible client.
The practical remedy is to use application versions and Windows configurations that meet the requirement. Review relevant DistributedCOM events on both hosts and follow the software vendor's guidance for the exact release. Distinguish a relevant event from unrelated background events by matching its time, application, and account to a controlled connection attempt.
Use a staged test that identifies the failing boundary. Changing firewall policy, service credentials, and DCOM permissions simultaneously destroys the evidence you need to diagnose the problem.
Confirm that the application vendor supports your Windows 11 edition and release for the installed software version. Check both ends of the connection. A supported server does not resolve an unsupported client, and the reverse is also true.
Record process architecture as well. A 32-bit process and a 64-bit process can encounter different COM registration and component-loading conditions. Mixed process architecture is not, by itself, proof of incompatibility, but it belongs in the test record.
Identify the account used by each process during the actual test. A successful interactive session under an administrator account does not validate a service running under a different identity.
Check authentication across the intended domain or workgroup arrangement. Document the server identity and relevant launch, activation, and access permissions. Grant the required rights to defined accounts or groups rather than broadening permissions until the error disappears.
Remote DCOM commonly begins with the RPC endpoint mapper on TCP port 135. The client then needs access to the endpoint assigned to the RPC service. Opening the endpoint mapper alone does not establish the complete communication path.
Review the active Windows firewall profile, host rules, and intervening network controls. Account for callback traffic where the application uses it. Coordinate any RPC port restrictions with the application vendor and security team; do not apply a generic port configuration without checking its effect on other RPC services.
Attempt the connection from the intended client host and account. Capture the error code, timestamp, requesting process, and related Windows events on both computers.
Separate failure to activate the server from failure to access an already running server. Those are different diagnostic branches. Confirm that the application registration points to the expected executable or service, especially after an upgrade or a side-by-side installation.
Validate the operations production actually requires: browsing, reads, subscriptions, and authorized writes. Test subscriptions beyond their initial connection so that callback and update delivery problems become visible.
Restart the client and server services under controlled conditions and confirm recovery. Include account changes, host restarts, and network interruptions in your acceptance plan where those conditions are relevant. A green connection indicator is not sufficient evidence that the complete data path works.
Validate each boundary separately before changing the next part of the configuration.
Keep the results as a configuration record, not just a troubleshooting transcript. The record should identify the approved accounts, application versions, permitted network paths, and successful operations. That gives cybersecurity and operations teams the same definition of a working deployment.
The presence of DCOM is consistent with Windows 11 support, but application behavior depends on the surrounding configuration. Investigate these factors before attributing a failure to the operating system:
For a 2026 change review, turn each factor into an explicit acceptance check. Record the expected result before testing. This prevents an incidental configuration change from becoming an undocumented dependency that nobody can explain during the next maintenance window.
Retain DCOM when your supported application and approved network design meet the operational requirement. Consider a different interface when the existing communication path conflicts with segmentation, authentication policy, or application lifecycle plans.
These are architecture choices, not direct product comparisons. An alternative protocol does not remove the need for certificate management, authorization, monitoring, or recovery testing.
Retain remote DCOM
Keep COM local and expose another interface
Use OPC UA between compatible endpoints
An OPC UA connection does not certify equivalent behavior to the OPC Classic connection it replaces. Validate the required data types, timestamps, quality information, writes, and recovery behavior. Include alarms or historical access when those functions are part of the project scope.
Software Toolbox's industrial connectivity and DataOps offering is relevant when evaluating that broader data path. TOP Server is one of its named OPC connectivity products. Confirm the required interface, supported operating systems, and deployment requirements for the specific release before selecting software; the product category alone does not establish compatibility.
Windows 11 supports DCOM, but an OPC Classic deployment still requires compatible client and server software. OPC DA relies on COM/DCOM technology; Windows retaining that technology does not certify every OPC DA implementation.
For your 2026 validation, require evidence from the installed application versions and the production topology. Check browsing, data quality, timestamps, subscriptions, and permitted writes rather than treating successful activation as the end of testing.
Windows 11 support does not, by itself, require an immediate DCOM-to-OPC-UA migration. Base that decision on application support, security boundaries, required interfaces, and the operational cost of maintaining the existing connection.
OPC UA is a different communication architecture, not a switch that makes a DCOM application compatible. Verify that the relevant endpoints or integration components support the functions you need. Then validate the replacement path before removing the working one.
Is DCOM still supported in Windows 11 in 2026?
Yes, DCOM is still supported in Windows 11 in 2026. Your specific OPC Classic client and server still need compatible application versions, correct permissions, and a working RPC network path.
Did Windows 11 remove DCOM for security reasons?
No, Windows 11 did not remove DCOM. DCOM authentication hardening changes the security requirements for remote activation; it does not eliminate the component.
Can I disable DCOM hardening to fix an older OPC client?
Do not plan on disabling DCOM hardening as a supported fix. Use application versions and configurations that meet Microsoft's remote activation authentication requirement.
Is opening TCP port 135 enough for remote DCOM?
No, opening TCP port 135 alone does not establish the complete remote DCOM path. Communication also needs access to the assigned RPC endpoint and any callback path used by the application.
Why does my OPC connection work locally but fail remotely?
Local success does not validate remote authentication, firewall access, or callbacks. Test the actual client account and remote topology, then correlate the failure with application errors and Windows events.
Does OPC UA use DCOM?
No, OPC UA does not use DCOM for its client-server communication. An integration application can still use COM/DCOM on a separate connection, so inspect the complete data path.
Does DCOM support mean every Windows 11 release is supported?
No, DCOM support does not establish the lifecycle status of every Windows 11 release. Check Microsoft's lifecycle information and the application vendor's requirements for the exact edition, release, and software version.
Test with the production service identity before approving the connection. An administrator's successful desktop test proves less than a repeatable subscription running under the account that will operate the application.
When discussing a deployment with Software Toolbox, bring the client and server versions, Windows releases, service identities, topology, error codes, and relevant event timestamps. That information turns a general compatibility question into a specific architecture and configuration discussion.