A shorter version of this ran as a debate piece in Digi, in Norwegian and edited for length. This is the full text.
Every system owner in process manufacturing knows they own the security risk for their OT systems. Most of them don’t govern like it.
Two roles need separating here, because conflating them is how the accountability goes missing. The operator runs the plant: the control room, the maintenance crews, the people who keep the line moving. The system owner sits above that, at mill management and function executive level, and holds the budget, signs the contracts and carries the risk. Everything below is about the second. The first inherits whatever the second agreed to, usually years earlier and usually without being asked.
Tom-Roger Stensberg’s piece in Digi makes the point directly, writing from oil and gas. Suppliers are blocking their customers from securing their own systems. His core argument is right. The risk sits with the system owner, not with the supplier. 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 system owner 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 system owner. 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 system owner may not have direct contractual relationships with every integrator, because the engineering company managed those during construction.
By the time the system owner 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 anyone’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 system owner 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 mill 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 can actually be done 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 suppliers 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 system owners 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. A system owner 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 choice becomes regulatory compliance or operational continuity.
Note where that choice lands. The constraint shows up in the control room and in the maintenance crew’s day, but the decision that created it was taken several levels above them and years earlier. Operators absorb a trade-off they had no part in making, which is why treating this as an operational discipline problem never fixes anything.
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 system owner 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 shown 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. System owners 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 the engineering and delivery process is governed, not just how the supplier relationship is managed after handover. That work sits with mill management and the function executives, not with the people running the plant.
Security requirements need to be in the engineering specifications, not in post-handover negotiations. Before an EPC contract is signed, the system owner should know exactly what network visibility they will have, what monitoring tools can be deployed 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 system owner 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, system owners 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 organisations don’t use it, because the security team isn’t in the room when those conversations happen and the system owner isn’t in the room either.
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 organisations that 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 at management level that many organisations in the sector haven’t built yet.
Stensberg is right that the system owner owns the risk. The question is whether the company actually governs like it.
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.