Is your yacht's firewall blind? Is it intelligent enough to protect you?
We find the same device on superyacht after superyacht. It has a recognised name. It is genuinely fine for what it was intended for, a small business office, but not for a vessel with operational technology governing thrusters, stabilisers, and navigation systems. Nobody who specified it asked whether it could read the traffic it was supposed to be protecting.
The answer, in almost every case, is that it is not intelligent enough for what you need. And the consequences of that gap are not theoretical.
The firewall is the device that sits between the vessel's networks and the outside world, and between the different network zones inside the vessel itself. It decides what traffic is allowed through and what is not. When it works properly, it is one of the most important lines of defence on board. When it cannot understand the protocols it is governing, it is something worse than no firewall at all. It is a false boundary. It gives everyone, the captain, the owner, the management company, the confidence that something is being checked, while the traffic that matters passes through unexamined.
A superyacht is not a network of office computers. It runs two fundamentally different kinds of system. Information technology: crew internet, administrative systems, guest connectivity, communications. And operational technology: the systems that govern the physical behaviour of the vessel. Thrusters. Stabilisers. Dynamic positioning. Engine management. Navigation. These are not the same problem, and they are not solved by the same tools.
The firewall that protects an office network is designed to understand office protocols. Web traffic, email, file transfers, remote desktop sessions. It does this well. What it does not do, and was never designed to do, is understand the industrial protocols that operational technology systems use to communicate. Modbus. DNP3. EtherNet/IP. PROFINET. These are the languages that a thruster controller uses to receive instructions, that a navigation system uses to share position data, that an engine management system uses to report status and accept commands. A firewall that does not speak these languages cannot police the conversations happening in them.
What an OT-blind firewall actually cannot do
An office firewall performs what is called stateful packet inspection. It can see that a connection exists, verify that it is using the expected port, and block traffic that does not conform to basic rules. What it cannot do is look inside the payload of an industrial protocol communication and understand what instruction is being sent. It can confirm that a Modbus connection is open on the correct port between two known devices. It cannot distinguish a legitimate read command from a write command that should never be permitted, or identify an instruction to change a setpoint that has no business being sent from that source. The pipe looks clean. The conversation inside it is invisible.
The practical consequence is this: once a connection between two devices is permitted by the firewall, everything that travels across that connection is invisible to it. A vendor remote access session that is legitimately opened for a routine diagnostic check looks identical to the same session being used to issue commands that should never be authorised. A navigation system receiving data from a positioning sensor looks identical whether that data is accurate or has been manipulated upstream. The firewall has allowed the connection. What happens inside it is ungoverned.
Attacks against operational technology systems do not look like office network attacks. They do not typically involve malware payloads, phishing links, or brute-force credential attempts against web interfaces. They involve the manipulation of industrial protocol communications: falsified sensor readings, unauthorised command injections, changes to setpoints and thresholds that cause physical systems to behave incorrectly. An intrusion detection system trained on office network threat signatures will not recognise these patterns because they are not in its vocabulary. The threat passes through undetected not because the system is not looking, but because it does not know what it is looking for.
An attacker does not need to break down a locked door. They walk through the open one, issuing syntactically valid commands that any OT-blind firewall will happily pass because it only inspects the port, not the payload.
When we ask who is responsible for the security of the operational technology network on board, the answer is almost always unclear. The captain manages the vessel. The IT supplier manages the office network and the firewall that sits between it and the internet. The equipment manufacturers manage their own systems under service agreements. Nobody has been given explicit responsibility for the boundary between the IT network and the OT network, or for what crosses it. The firewall that was specified for the IT side has been extended to cover the OT side by default, not by design. That default is the gap.
A firewall that cannot read industrial protocols is not protecting your operational systems. It is providing the appearance of protection while the traffic that matters passes through unexamined.
Why this keeps happening
The device we encounter most frequently in this role was not chosen carelessly. It is a capable, well-regarded product that delivers genuine value in the environment it was designed for. It handles web filtering, email security, VPN access, and general network traffic management competently. In a small office, it is an entirely reasonable choice. On a superyacht with operational technology networks, it is the wrong tool specified by people who were not asked to think about the difference.
Refit specifications are typically written by people who understand vessel systems and by IT contractors who understand office networks. The intersection of those two worlds, where industrial control protocols and office networking meet, is a specialist discipline that neither group is typically trained in. The result is a firewall specification that addresses the threat model the IT contractor knows, not the threat model the vessel actually presents.
This is compounded by the fact that the inadequacy is invisible in normal operation. The vessel runs. The systems communicate. Nothing fails. The firewall logs show clean traffic. There is no signal that the OT network is ungoverned, because the signal that would indicate a problem requires the kind of deep protocol inspection the device cannot perform. The absence of alerts is mistaken for the presence of security.
What adequate protection actually requires
Protecting a vessel with operational technology networks requires a firewall that understands both worlds. Not a device that performs deep packet inspection on web traffic and treats Modbus as an unknown protocol to be permitted or blocked wholesale. A device that can read inside industrial protocol communications, enforce rules at the command level, and distinguish between traffic that is legitimate and traffic that should never be permitted regardless of its source.
A firewall with genuine OT protocol awareness looks inside the payload to distinguish a read command from a write command. It permits an engine management system or engineering workstation to request status data, while automatically dropping any unauthorised instruction to alter a thruster setpoint or vessel control parameter. It also flags subtle reconnaissance, such as sequential register polling, long before a command injection occurs.
Firewalls built for industrial and operational technology environments handle this natively. They understand the protocol stack that superyacht OT systems use. They can enforce granular rules at the command level rather than at the connection level. They can be configured to permit only the specific communications that should occur between specific devices, and to alert on anything that deviates from that baseline. This is a different class of device from a general-purpose network security appliance, and the distinction is not marginal.
The question is not whether a firewall exists. The question is whether it understands the language of the systems it is supposed to be protecting.
Three questions worth asking now
You do not need a full assessment to establish whether this gap exists on your vessel. Three questions will locate it.
- What firewall sits between your IT network and your operational technology systems, and was it specified by someone who understood both environments?
- Can your current firewall perform deep packet inspection of industrial control protocols, and if so, which ones?
- Who holds explicit accountability for the security boundary separating your guest and crew networks from the systems controlling the vessel's physical movement?
If any answer is uncertain, that uncertainty is the finding. A boundary that nobody owns is a boundary that nobody is defending.
At CyberPlus, we work with owners, captains, and close protection teams who want to understand where cyber and physical risk actually intersects on their vessel, and remove it without disruption or noise.
When we assess a vessel's network architecture, we look at what the firewall can actually see, not just whether one exists. The difference between those two questions is where most of the risk lives.
If you'd like to talk, you know where we are.
A firewall that cannot read the conversation is not a firewall. It is a locked door with the window open.