Your OPC Classic server didn't break.
Microsoft hardened DCOM, and you have been living with the workaround ever since.
If an OPC DA link between two machines started failing after a patch window, nothing about the OPC server changed. The rules underneath it did. Here is what actually changed, why it lands on OPC Classic specifically, and what the honest options are — including the ones that have nothing to do with us.
A CVE, a KB, and a floor that moved
CVE-2021-26414is a security-feature-bypass weakness in DCOM. Microsoft's answer was KB5004442, a change to the authentication level DCOM will accept. In plain terms: the server side of a DCOM activation now insists on packet integrity on the call, and a client that negotiates something weaker is refused rather than accommodated. The floor moved up, and it moved up for everything that uses DCOM.
The rollout was staged on purpose. The hardening first shipped available but off in June 2021, then on by default with a registry switch to turn it back off in June 2022, then on with the switch gone. Since 14 March 2023 it is enforced on every supported version of Windows. That last step is the one people remember, because it is the step where the thing that used to buy time stopped working.
None of this was aimed at OPC. DCOM is a general-purpose Windows remoting mechanism and the weakness was in DCOM. OPC Classic is simply one of the loudest things sitting directly on top of it, in an environment where the machines at either end are the hardest ones in the building to change.
OPC Classic is COM, and cross-machine COM is DCOM
OPC DA, HDA and AE are COM interfaces. On one machine that is a local call and none of this applies. Across two machines it is DCOM, and the mechanics are specific enough to be worth naming.
Reaching a DA server on another host means the endpoint mapper on TCP 135 plus a dynamic high port range. Subscriptions make it worse rather than better: DA pushes value changes back through a COM callback, so the client has to stand up its own object exporter and accept a call in the other direction too. Two machines, both listening, both activating objects on the other. On top of that sits identity — NTLM or Kerberos lined up across both hosts, service accounts holding launch and access rights, DCOM ACLs configured at both ends — all of it designed when the plant network was assumed friendly.
The hardening raises the required authentication level on every one of those calls. Wherever the two ends cannot negotiate packet integrity — an old server, an old client, an OS past its support date, a mismatched identity path — the call is refused. From the control room that looks exactly like the OPC server breaking. It isn't. The server is doing what it always did; the platform stopped accepting it.
Both sides of this argument are right
The option space collapses to two uncomfortable choices. Run the machine unhardened or unpatched and keep the integration working. Or harden and upgrade, and watch the OPC DA integration fail.
The first is a real security and compliance position, not a theoretical one: a weakness with a CVE number and a published patch, deliberately left in place, on a machine sitting in the path of live process data. Where IEC 62443 or NERC CIP applies, that is a finding, and the honest response is a documented exception with a review date — which is a way of tracking the problem, not solving it.
The second is a real operations position. The integration works. It has worked for years. Breaking it to satisfy a patch policy means a data outage on a system somebody is accountable for, and the replacement plan usually does not exist yet.
What makes it a squeeze rather than a debate is that the clock is not yours. Windows end-of-support dates arrive on a schedule set somewhere else entirely. Eventually the machine has to move, and the DA integration gets re-litigated on someone else's calendar rather than on a turnaround plan. Ops is right that the integration works. Security is right that the exception is real. Neither of them created the deadline.
Maintenance mode is not deprecation, but it is a direction
The OPC Foundation's development effort goes to OPC UA; Classic is maintained rather than extended. It is not formally deprecated, and it is not recommended for new installations.
Read that plainly and it says three things. The interface will keep working. The specification is not going to grow to meet a hardened Windows halfway. And the platform underneath it will keep getting stricter, because that is the direction every general-purpose OS has been moving for a decade. The trend line only points one way, and it is not toward DCOM getting easier to run across a segmented network.
That is not an argument for ripping anything out. Most of these servers are doing their job accurately and have been for years. It is an argument for knowing which of the four answers below you have actually chosen, rather than arriving at one by default.
Four answers, and what each one costs you
There is no version of this where nothing is given up. The useful question is which trade you are making deliberately.
Keep the machine off the patch train, write the exception down, attach compensating controls and a review date. This is a scheduling decision rather than a fix, and it gets harder to defend every year the machine stays in service. It is still a legitimate answer for a defined window — if the unit that server feeds is already booked for a turnaround that replaces the whole chain, standing up a separate project first is hard to justify.
You are carrying a documented, dated exception through every assessment until the window closes.
Retire the OPC Classic server and move everything to a native OPC UA source. It is the cleanest end state and the hardest one to schedule: every client bound to that server moves at once, which means a coordinated outage and a re-validation across systems owned by different people. That is not a technical problem, it is a calendar problem, and it is why 'next year' has been the answer for a decade in a lot of plants.
One coordinated outage across every consumer of that server, plus re-validation.
The standard industry answer, and often the right one. Configure the existing OPC server to expose the same tag database over both OPC Classic and OPC UA. Point new clients at the UA endpoint, and retire DA clients at natural refresh instead of all at once. Where the server supports it and the vendor is still around to support you, this is a sound plan with no new component to operate.
You keep owning, licensing and running the legacy server, on the machine it lives on, with the same end-of-support clock. The northbound interface changed; the dependency did not.
Leave the DA server exactly where it is and put a wrapper on the same machine. The wrapper speaks COM to the server locally — the same in-box call any client on that machine could always make — and serves the result northbound as OPC UA. No DCOM crosses the network, so there is no cross-machine authentication level left to negotiate. What the network carries instead is one OPC UA session on one TCP port, with UA's own certificate and policy handling. The DA server is not replaced, reconfigured or restarted.
The wrapper is itself a component you acquire, deploy and operate. It does not patch the Windows box, does not make an unsupported OS supported, and does not stop the end-of-support clock. The machine and its lifecycle are still yours to plan.
What a local wrapper changes, and what it doesn't
The fourth option is the one we build, so it is worth being precise about the mechanism rather than the promise. A connector process runs on the machine that already hosts the OPC Classic server and talks COM to it in-box. Northbound, a single runtime serves the result as OPC UA on one TCP port. The DCOM question disappears from the network path because there is no cross-machine DCOM left — not because anything about DCOM was fixed.
What survives the trip matters as much as the transport. DA item IDs cross verbatim and arrive as UA nodes carrying their real data type, access rights and browse structure. Quality is mapped rather than invented. The source timestamp is the device's own, and a source that supplies no timestamp is reported as having none rather than stamped with the bridge's clock. Writes come back with the device's own per-item status rather than a blanket success. A wrapper that quietly improves the data it is wrapping is worse than useless in a plant.
And the limits, stated plainly: this does not patch the Windows machine, does not make an unsupported operating system supported, and does not remove the end-of-support date from anybody's calendar. It changes what has to cross the network and what a modern client has to speak. It decouples the client migration from the machine migration, so the two no longer have to happen on the same day. Whether the resulting architecture satisfies a given assessment is a question for your assessor, against your zone and conduit model — not something a product gets to declare.
Five things worth establishing about your own site first
None of this needs a vendor to answer. An integrator with access to the estate can close these out in an afternoon, and the answers usually pick the option for you.
- 01Which machines still serve OPC Classic to a client on a different host — and which of those links are subscriptions rather than plain reads.
- 02Whether any of those machines is carrying a documented DCOM or patching exception, and when that exception was last reviewed.
- 03The Windows version on each of them, and its end-of-support date, written next to the exception review date.
- 04Whether the OPC server product on each machine can serve OPC UA from the same tag database, and whether that capability is licensed and supported on the version installed.
- 05Which DA clients would have to move if the server did — by owner, not by count. That list is the schedule.