A shorter version of this ran as a debate piece in Digi, in Norwegian and edited for length. This is the full text.
Every operator in process manufacturing knows they own the security risk for their OT systems. Most of them don’t govern like it.
Tom-Roger Stensberg’s piece in Digi makes the point directly, writing from oil and gas. Suppliers are blocking operators from securing their own systems. His core argument is right. The operator is the system owner. The supplier is not. My experience is from forest-industry manufacturing, not offshore, but the dynamic Stensberg describes is immediately recognisable. The sectors differ in regulatory regime and risk profile. The structural relationship between operator and system integrator is the same.
Where I’d push the analysis further is on how we got here, and why the situation persists even when regulatory frameworks clearly place accountability on the operator. The answer isn’t really about suppliers behaving badly. It’s about governance structures that never anticipated the problem.
The plant was engineered this way
The framing of this as a procurement failure misses how production plants actually get built. An engineering company designs the plant. System integrators deliver the control systems, instrumentation, and automation packages, often as subcontractors to the EPC contractor. The operator may not have direct contractual relationships with every integrator, because the engineering company managed those during construction.
By the time the operator takes over, the access terms are already set. Sometimes two or three contract layers deep. The restrictions on system access, diagnostic interfaces, and configuration visibility weren’t negotiated by the operator’s security team. They were inherited from an engineering project where cybersecurity was not on the requirements list.
This matters because the standard response, “negotiate better contracts,” assumes the operator had a seat at the table when the relevant decisions were made. In many cases they did not. The engineering company specified the systems. The system integrator delivered them. The operator received a plant that was designed to depend on the supplier for ongoing operation.
There is a second gap that compounds this. Enterprise security architecture is typically not included in engineering requirements for production systems. The engineering project specifies process control, instrumentation, safety systems, and communications infrastructure. Cybersecurity, if it appears at all, is treated as something to be addressed after handover. The result is that each plant arrives with its own control system architecture, its own supplier dependencies, and its own constraints on what the operator can actually do with the systems, none of which were designed with enterprise security standardisation in mind.
Add to this that most major enterprises in process manufacturing are not one organic company. They are a company of companies, assembled through decades of acquisitions, mergers, and joint ventures. Each acquired entity brought its own plants, its own supplier relationships, its own system integrators, and its own legacy contracts.
The outcome is variance. Every site different, every supplier relationship different, every security baseline different. And the system integrator’s relationship is at plant level, not enterprise level. They deal with local site engineers and local maintenance contracts. The enterprise security function has no seat in that relationship.
Trying to apply consistent cybersecurity protection across that portfolio is not a policy problem. It is an architectural one, and much of it was baked in before the current organisation even existed.
Aftermarket is the business model
Stensberg frames this as vendors protecting proprietary positions. That’s accurate but understates the scale. For many system integrators in process manufacturing, aftermarket support, including spares, service contracts, remote monitoring, and software maintenance, accounts for up to 80% of turnover. The initial system delivery is the entry point. The revenue is in the decades that follow.
When that is the business model, every design decision reflects it. Proprietary protocols. Restricted diagnostic tools. Configuration interfaces that only the supplier’s engineers can access. These aren’t incidental features of a product. They are the architecture of a service dependency that was engineered into the plant from day one.
This is not a side effect. It is the commercial logic of the industry.
IEC 62443 asks the right question but doesn’t solve the power dynamic
Stensberg correctly points to IEC 62443 and the regulatory expectation that operators maintain visibility into their OT environments. The standard is clear on who owns the risk.
The problem is that standards define obligations. They don’t redistribute power. An operator can be fully aware that IEC 62443 requires zone and conduit analysis, asset inventories, and risk assessment across their industrial control systems. If the supplier controls access to the network traffic data, restricts configuration visibility, and conditions support on using only their approved tools, the operator faces a choice between regulatory compliance and operational continuity.
That is not a security decision. It is a governance failure, and it happened upstream of the security team. The engineering project set the terms. Contract management accepted the restrictions. Executive steering never asked whether security requirements were addressed. The security team inherited constraints they did not create and often cannot change without executive backing they don’t have.
The proprietary security play makes the problem worse
Stensberg flags a trend worth watching. Suppliers are now offering their own security monitoring and management as a commercial add-on. This deserves direct language. When the entity that controls your system access also sells you the security visibility into that system, you have a conflict of interest, not a security solution.
Independent security monitoring requires independence. The operator needs to see what is happening on their systems without filtering through the supplier’s tooling, priorities, or commercial interests. A supplier-provided security dashboard that shows what the supplier wants the operator to see is not monitoring. It is reporting, and the difference matters.
For a system integrator whose revenue depends on aftermarket lock-in, offering security as yet another managed service is a rational commercial move. It extends the dependency into a new domain. Operators who accept this arrangement are outsourcing their risk visibility to the same entity that engineered the visibility gap.
What would functional governance look like?
The structural fix isn’t primarily a security initiative. It requires changes in how operators govern the engineering and delivery process, not just the supplier relationship after handover.
Security requirements need to be in the engineering specifications, not in post-handover negotiations. Before an EPC contract is signed, the operator should know exactly what network visibility they will have, what monitoring tools they can deploy independently, and what data the system integrators will provide on request and at what latency. If a system integrator won’t commit to those terms, the operator is making a deliberate decision to accept reduced security visibility. That trade-off should be documented, approved at the right level, and reviewed periodically.
For the installed base, operators need a structured programme to renegotiate access terms at every contract touchpoint, including service renewals, change orders, support extensions, and upgrades. Each of those moments is leverage. Most operators don’t use it because the security team isn’t in the room when those conversations happen.
The governance gap is organisational. Security requirements need a pathway into engineering specifications, EPC contract negotiations, and aftermarket service agreements. In most process manufacturing organisations, those pathways either don’t exist or run through so many layers that the security requirements arrive too late to influence the outcome.
The supplier is not the villain
It’s worth being precise about this. System integrators are acting rationally within their commercial incentive structure. Aftermarket revenue sustains the business. Proprietary access protects aftermarket revenue. Offering security as an add-on extends the aftermarket into a new domain. None of this requires malice. It requires only commercial incentives operating unchallenged by the buyer.
The operators who have solved this, and some have, didn’t do it by appealing to supplier goodwill. They did it by putting security requirements into the engineering specification, backing those requirements with executive commitment, and being willing to walk away from system integrators who wouldn’t comply. That takes governance maturity that many organisations in the sector haven’t built yet.
Stensberg is right that the operator is the system owner. The question is whether the operator governs like one.
Related reading
- Manufacturing’s vulnerability management problem isn’t a vulnerability management problem, on why patch capability is the wrong investment for legacy OT, and where the procurement argument above leads.
- OT-sikkerhet: Leverandøren er ikke skurken, the Digi version, in Norwegian.
I advise industry and energy companies on security governance and risk management. More about my work.