The communication network is not yours to design
The manufacturer's network engineer arrives at the early-design meeting with a topology drawing. It shows the turbine controllers, the SCADA workstation, the historian, the engineering workstation, and the firewall to the outside world. The IP addresses are pre-assigned. The VLANs are labelled. The redundant uplink connects to a switch marked "owner network", and at that switch the drawing politely stops.
The drawing is, by its own conventions, complete. It shows everything from the sensor in the blade to the boundary of the operator's network. The conversation that follows assumes the drawing is the basis for the network design — that the manufacturer specifies, the operator implements what the manufacturer specifies, and the boundary is where the two diagrams meet.
That assumption is the source of more friction in early project meetings than any other single architectural question.
The plant communication network is not the manufacturer's to design. The local area networks inside the plant, the segmentation between zones, the firewalls between layers, the industrial demilitarised zone that mediates upstream connectivity, the routing to the substation and to corporate, the IP address space, the VLAN allocation, the default gateways, the spanning-tree topology, the time synchronisation hierarchy — all of it is the operator's responsibility. The manufacturer specifies what their equipment needs. The operator specifies how that need is met.
This is not a courtesy. It is a structural consequence of the regulatory and security framework the project sits inside.
Why this separation exists
Three reasons make the role separation non-negotiable.
The first is governance. Under the NIS2 Directive , the operator is the essential entity. The operator is the party with statutory obligations on risk management, incident handling, supply chain security and reporting. The operator's regulator does not accept "the manufacturer designed and operates the network" as an answer when something fails. A network that the operator cannot describe, cannot monitor, cannot audit and cannot change without manufacturer approval is a governance failure on the operator's side, regardless of how technically well-designed it might be.
The second is the security architecture itself. IEC 62443 organises an industrial control system into zones — groupings of assets that share a common security level — separated by conduits, the controlled communication paths between them. The asset owner is responsible for the zone and conduit design (62443-3-2) and the system-level security requirements (62443-3-3) . The manufacturer, as supplier and L0/L1 integrator, is responsible for the components within their zone (62443-4-1 for the development process, 62443-4-2 for the components themselves) . The architecture is explicit about where each party's design authority begins and ends, and the plant communication network — particularly the network above the manufacturer's process zone — sits firmly on the operator's side of that line.
The third is the multi-vendor reality of modern renewable energy plants. A typical utility-scale project includes a turbine or solar inverter manufacturer, a battery energy storage supplier with its own controls, a SCADA platform vendor whose software may come from a third party, a substation automation vendor, a protection relay vendor, sometimes a separate condition-monitoring vendor, and a meteorological mast supplier. Each cannot bring their own network. Each connects to a shared infrastructure designed and operated by the asset owner. A manufacturer who arrives expecting to design the network they will sit on has not yet accommodated the fact that they are one tenant among several.
What good vendor specification looks like
What a manufacturer should specify is precise and brief. The equipment, by model and quantity. The communication protocols, by standard. The transport requirements — TCP or UDP, port numbers, expected message rates, latency tolerance, packet loss tolerance, jitter sensitivity. The physical layer — copper or fibre, single-mode or multi-mode, port count per device, connector type, distance constraints. The redundancy posture — single-homed, dual-homed with application-level failover, parallel redundancy protocol, high-availability seamless redundancy, rapid spanning tree with stated convergence targets. The time synchronisation requirement, in terms of accuracy and protocol (NTP, PTP, IRIG-B).
That is the entirety of what the manufacturer needs to say. The operator's network team takes that specification and delivers a network that meets it.
What a manufacturer should not specify is the implementation. They should not state that their controller requires the 192.168.10.0/24 subnet. They should not state that the redundant LAN must use VLAN 200. They should not state that the gateway IP must be 192.168.10.1. They should not state that the time source must be a specific NTP server address embedded in firmware. They should not assume that their device will be on the same broadcast domain as any other device they communicate with. They should not assume the firewall rule between their device and the historian will be open in both directions for a port range; it will not. It will be open from the device to the historian, for the specific port, with the specific source and destination addresses, and any deviation from the specified behaviour will be dropped.
A device that comes off the production line with hard-coded subnets, embedded gateway assumptions or fixed IP addresses that cannot be configured at deployment is a device with a delivery defect. It will be returned. The manufacturer will be asked to provide firmware that accepts IP configuration parameters from the operator's deployment process. If that firmware does not exist, the manufacturer's bid does not survive the technical evaluation.
Redundancy and the assumed topology
The redundancy question deserves its own treatment because it is where the assumed topology most quietly collides with the operator's design.
A manufacturer's redundancy requirement, stated correctly, looks like this: "Controller A requires two independent network interfaces with failover between them, recovery time below 200 milliseconds, no loss of in-flight transactions during a single link failure." That is a clean specification. The operator can deliver it through Parallel Redundancy Protocol or High-availability Seamless Redundancy under IEC 62439-3, through Rapid Spanning Tree with appropriate timer tuning, through link aggregation with LACP, through Multiple Spanning Tree with engineered convergence, or through application-managed failover where the controller maintains parallel connections on both interfaces. There are many implementations; the manufacturer cares that the requirement is met, not how.
A manufacturer's redundancy requirement, stated incorrectly, looks like this: "Controller A requires LAN 1 on subnet 192.168.10.0/24 and LAN 2 on subnet 192.168.20.0/24, both with the same default gateway, failover triggered by loss of ICMP response from the gateway, return to primary after 30 seconds of stable response."
That is not a requirement. It is an implementation, and it is an implementation that assumes the operator's network can accommodate the manufacturer's mental model of redundancy. Most plant networks cannot, because they run protocol-level redundancy at the switch fabric rather than at the device, or they run application-level redundancy where the device opens connections on both interfaces and uses whichever responds, or they use addressing schemes — overlapping management VLANs, non-routable maintenance networks, unique-local IPv6 — that the manufacturer's static-IP assumption simply breaks.
The architectural principle is straightforward. The manufacturer assumes that their device will receive an IP address. From which CIDR block, with which subnet mask, with which default gateway, on which VLAN — none of these are the manufacturer's to specify. Each interface configurable at deployment, each tolerant of the addressing scheme the operator chooses, each functioning correctly regardless of whether the two interfaces sit on the same subnet, on different subnets, on different VLANs or on different physical networks entirely. The device's redundancy logic must work in all of those conditions, because in different plants in different jurisdictions designed by different network teams, all of those conditions will occur.
The visibility question
The visibility question is the hardest part of this conversation for manufacturers to accept, because it feels like an information vacuum. The manufacturer is told that their equipment will be deployed in a network whose topology, addressing scheme, segmentation and firewall rule base they will not see in any meaningful detail.
This is not gatekeeping. It is the security framework operating as intended.
The plant network topology is a sensitive asset. It maps the attack surface. It identifies which assets are reachable from which other assets, which traffic flows the firewalls permit, which segments are isolated for safety reasons, which paths a sophisticated attacker would have to traverse to reach the critical zones. Each additional party that holds the topology is a party whose own information security posture becomes a path to the plant. The principle of least privilege, applied to design information rather than to access credentials, says that the manufacturer should see only what the manufacturer needs to see.
What the manufacturer needs to see is what they actually receive. The IP addresses their devices will use. The gateways their devices will route through. The destination addresses and port numbers their devices will reach. The protocols they will speak on each interface. The credentials for their service accounts. The diagnostic interface they may query for the health of their own equipment. They are not given the diagram of how those endpoints are reached internally. They are not given the list of other devices on the same VLAN. They are not given the firewall rule base above the conduit between their zone and the next. That information is not theirs.
What the manufacturer is given in addition, at the conduit boundary, is a specification of what their equipment must support: which protocols are allowed across the conduit, in which directions, with which authentication and which logging. The conduit specification is the contract. Everything beyond the conduit is the operator's domain.
What this means at proposal stage
At proposal stage, this discipline pays off rapidly. A bid that specifies the equipment, the protocols, the port numbers, the bandwidth envelope, the latency budget, the redundancy posture and the time synchronisation requirement — and stops there — is a bid the operator's network architects can work with. A bid that specifies the equipment plus a full assumed topology with hard-coded addresses, embedded VLAN identifiers and required subnet masks is a bid that will be returned with comments asking the manufacturer to remove the topology and restate the requirements.
The principle is not new. It is how interfaces have always worked between independent engineering disciplines. The manufacturer who treats the network specification as an interface contract — what I need from you, what you need from me, no more — finds the architectural conversation much shorter than the manufacturer who arrives with a topology drawing.
The deeper habit to break is the one imported from markets where the manufacturer was also the integrator, the operator, and the network designer. In an EU-financed project, those roles are separated by design. The plant network is the operator's, and the operator's alone. The manufacturer's job is to specify what they need from it and to deliver equipment that works inside whatever the operator builds.
The next article moves one step outward, to the boundary where the plant ends and the substation begins — and to the engineering discipline on the other side of that fence, which is not the operator's either.
This article reflects the regulatory and standards landscape at publication. References to IEC 62443 and IEC 62439 may be superseded by revisions of those standards; NIS2 transposition continues to evolve across member states. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.