Why Your OT Vendor Should Not Be the One Securing Your OT Network

When a plant asks who should look after the security of its control network, the easy answer is the company that already knows it best: the OEM or integrator that installed the controllers, the switches and the HMIs. They have the drawings, the support contract and an engineer who has been on site. The problem is not competence. It is that the vendor has a product roadmap to protect, and the party governing security has to be free to recommend against that roadmap.

That is the whole argument, and it is worth stating plainly before the details. Security governance decides which devices stay, which get replaced, who may connect remotely and under what rules. A vendor cannot make those calls about its own equipment, or about a competitor's equipment on the same network, without a conflict that surfaces exactly when the advice matters most. Auditors do not keep the books for the same reason. An OT Service Owner who sells nothing on the network removes the conflict rather than managing it.

What the vendor does well

None of this is a judgment of the vendor. The OEM knows its own platform better than anyone, carries the firmware, holds the spare parts and answers the phone when a drive faults at two in the morning. The integrator knows how the line was commissioned and why that one PLC still runs an old protocol. Both are necessary, and a plant that pushes them away loses real knowledge.

The vendor is also the right party for a lot of security work on its own equipment: hardening guides, firmware updates, secure configuration of its own remote access tool. What it should not hold is the governance above that work, the role that decides whether the update happens this outage or next, whether the remote tool is allowed at all, and whether the equipment should be replaced by another make.

Where the conflict shows up

The conflict is quiet most of the year. It becomes visible at four moments.

The modernization roadmap. Every plant carrying end-of-life controllers will fund a replacement program at some point. If the party writing the security roadmap is also bidding the replacement, the roadmap tends to recommend replacement. An independent owner can say that an obsolete controller, properly isolated, is a lower risk this year than a rushed migration during a kiln campaign.

Vendor remote access. Each OEM arrives with its own remote support tool and a reasonable request to use it. Someone has to decide where those sessions terminate, who approves them, how they are logged and when they are cut off. A vendor governing its own access will approve its own access. A vendor governing a competitor's access has no standing to refuse it.

The mixed fleet. Operators that grew by acquisition inherit a different OEM stack at each plant. A security program that works has to apply the same rules across all of them. A vendor's cyber arm is built around its own platform and cannot write rules that bind its competitors.

The support renewal. Renewal is a negotiation. If the security advisor sits on the vendor's side of that table, the operator has given away its leverage over its own spend. Procurement teams see this one first.

What structural independence means

Structural independence is the principle that the party assessing and governing an OT network has no equipment to sell on it and no vendor quota to meet. It is structural because it cannot be fixed by a clause in a contract. A vendor that promises objectivity is still a vendor at renewal time.

In practice the test is short. Does the governing party sell OEM equipment? Does it resell OEM support contracts? Does it take referral revenue from any vendor whose access it governs? If the answer to all three is no, the operator's interest is the only interest at the table. Your procurement team can verify each answer on its own.

What the owner role actually does

An OT Service Owner extends the operator's team rather than replacing it. The work is service management applied to the control network: defined roles, change approval with a named approver, a written remote access policy for every vendor with a path into the plant, and a fleet-wide view of risk that reads the same at every site. It operates on a maintained drawing of the network, which is why the role comes after documentation exists and not before.

The vendor's job does not shrink in this model. It gets clearer. The OEM still does the firmware, still answers the fault call and still proposes the upgrade. The difference is that someone without a stake in the answer decides when and whether.

How to decide for your plant

If a single plant with a single OEM has a trusted integrator and a small team, the vendor may be the only practical option for a while. The question to ask is what happens at plant two with a different make, or at the first renewal where the security advice and the sales proposal arrive in the same email.

Start by writing down who currently decides each of the four moments above. If the answer to most of them is the vendor, the governance role is vacant and the vendor has filled it by default. Documenting the network is the first move; our post on the assessment before the penetration test explains why that order holds for governance too.