OT Cyber Basics for Engineers and ETOs

Operational Technology is where cyber risk becomes physical. A bad email rule can leak information. A bad OT change can silence an alarm, stop a pump, open the wrong path, break a monitoring screen, disable a fallback, or leave the yacht unsure which system is really in control.

IT systems move information. OT systems can monitor machinery, start equipment, stop equipment, open valves, shed loads, acknowledge alarms, control access, run HVAC plant, supervise power, display machinery status or support propulsion-related functions.

NIST SP 800-82 Rev.3 defines OT as programmable systems and devices that interact with the physical environment, or manage devices that do. For yacht engineers and ETOs, that definition is useful because it draws the line clearly: if the system can affect equipment or physical operation, it needs OT thinking.

OT cyber is not about turning engineers into office IT administrators. It is about protecting the control and monitoring systems that engineering teams already depend on.

If a vendor laptop brings malware onto an HMI network, if a remote support tunnel stays open after a yard period, if an automation project file is lost, or if a cloud-connected monitoring gateway is changed without backup, the engineering consequence can be real. The fault may appear as a nuisance alarm, missing data point, failed controller, incorrect dashboard, unavailable HMI or unexpected dependency on remote support.

A yacht may have several OT layers:

• Alarm monitoring system.
• Vessel management system.
• Power management system.
• Generator and propulsion monitoring.
• HVAC controls.
• Tank and bilge monitoring.
• Pump, fan and valve control.
• Access control and CCTV.
• Lighting and hotel automation.
• PLC/HMI workstations.
• Engineering laptops and vendor programming tools.
• Bridge or owner-dashboard data feeds.

Some of these systems only monitor. Some control. Some protect. The consequence changes the cyber treatment.

Classify by consequence first. A monitoring-only temperature dashboard is different from a PMS controller, fuel-transfer valve interface, bilge alarm input, fire-related shutdown, access-control system or propulsion-support workstation.

Office IT security often prioritises confidentiality. OT security must also protect availability, integrity and safety. A failed update, blocked network port, mistimed reboot or aggressive antivirus scan can create operational problems if applied blindly to control systems.

This does not mean OT should be left unprotected. It means changes need planning, testing and fallback. Engineers should know what each system does, what it controls, how it fails, what manual or local fallback exists, and who can approve changes.

Good OT security is controlled change, not random hardening. The safest control may be a documented backup, a locked engineering workstation, disabled-by-default remote access, a tested manual fallback or a clear rule that guest/AV networks never touch the engineering zone.

IEC 62443 uses the idea of zones and conduits. A zone is a group of systems with similar security needs. A conduit is the controlled communication path between zones.

On a yacht, useful zones might include:

• Guest Wi-Fi.
• Crew welfare network.
• Owner office network.
• AV/control network.
• CCTV/access-control network.
• Engineering monitoring network.
• PMS/AMS/VMS control zone.
• Bridge data zone.
• Vendor support zone.

The conduit is the firewall rule, gateway, jump host, data diode, read-only API or managed route that allows one zone to talk to another. The engineering question is not "are they on Ethernet?" It is "what is allowed to talk, why, and what happens if that path fails?"

Use this language during refit. When a supplier asks for a route between systems, ask which zone it crosses, what data flows, whether control is possible, how the route is logged, and what happens if the route is removed.

Vendor remote access is common for automation, PMS, HVAC, SatCom, AV and monitoring systems. Treat it as a controlled maintenance activity. Engineers and ETOs should know:

• Which vendor can connect.
• Which system they can reach.
• Whether access is enabled all the time.
• Whether MFA is used.
• Whether sessions are logged.
• Whether a backup is taken before changes.
• How access can be disabled quickly.

If a vendor laptop connects directly to an OT switch, it becomes part of the OT risk picture. It may carry malware, old tools, uncontrolled adapters or saved credentials.

Remote support should have an engineering closeout: backup taken, change recorded, alarms checked, system tested, remote access closed and follow-up risk noted.

OT backups include PLC code, HMI projects, alarm lists, cause-and-effect matrices, controller configurations, switch and firewall configs, server images, licensing records and vendor software versions. A NAS backup of documents will not restore a corrupted automation project.

Engineers should know where the latest known-good project files are stored and whether they have been tested. If only the vendor has the project, the yacht has a dependency risk.

The handover question should be direct: if this HMI server dies tonight, do we have the project, license information, version baseline and vendor contact needed to rebuild it?

OT patching should be deliberate. Some systems need vendor approval, class consideration, compatibility checks, backup before change and testing after update. The answer is not "never patch." The answer is "patch with a plan."

At minimum, record current version, known vulnerabilities, vendor recommendation, operational window, backup captured, rollback plan and post-change test.

Engineers and ETOs can add simple checks:

• Unexpected alarms or disabled alarms.
• Unknown laptops connected to OT switches.
• Remote-access devices left powered.
• HMI clock/time mismatch.
• Backup job failures.
• Unusual login names.
• Engineering workstation warnings.
• New network devices.
• Changed firewall/VPN status.
• Vendor work without change notes.

These are operational checks, not cyber theatre.

Escalate when you see unknown laptops connected to engineering switches, vendor modems left powered, unmanaged Wi-Fi bridges, disabled alarms without records, HMI warnings nobody owns, remote access outside approved windows, missing project backups, or AV/guest network routes into control environments.

None of these automatically means there is a cyber incident. They do mean the OT boundary is not controlled enough.

• Treating an HMI as a normal office PC.
• Leaving vendor modems or VPNs permanently active.
• Not holding a copy of PLC/HMI project files.
• Connecting guest or AV networks into engineering systems for convenience.
• Applying updates without backup or rollback.
• Assuming monitoring-only systems cannot create risk.