Maritime Cybersecurity Guide: Vessel OT, IMO and Ports

A modern ship is a floating network of operational technology, connected to shore by satellite, maintained remotely by equipment makers and navigated by systems that trust radio signals anyone can fake. Maritime cybersecurity (or maritime cyber security) now has binding rules behind it, for vessel cybersecurity and ports alike: IMO expects cyber risk in safety management systems, IACS UR E26 and IACS UR E27 apply to new ships, and the US Coast Guard's cybersecurity rule applies to US-flagged vessels and port facilities. This guide explains what those rules require, how to secure onboard OT systems such as ECDIS and propulsion control, how to defend against GNSS and AIS spoofing, and how to protect ports and terminal operating systems. It is written for ship operators' technical and security teams, port and terminal security managers, and the OT and identity specialists who support them.

Key takeaways

Cyber risk is part of safety management. IMO Resolution MSC.428(98) asks that cyber risks be addressed in the ISM Code safety management system, verified at the company's Document of Compliance audit since 2021, and MSC-FAL.1/Circ.3/Rev.3 (April 2025) adds Govern to the functional elements.
New ships are built to class cyber rules. IACS UR E26 (ship) and UR E27 (systems and equipment) apply to ships contracted for construction on or after 1 July 2024, with an asset inventory, network topology and supplier security capabilities checked at construction, commissioning and annual surveys.
US rules are now enforceable. The Coast Guard rule in 33 CFR part 101 subpart F took effect on 16 July 2025, with incident reporting to the National Response Center from that date and Cybersecurity Plans due by 16 July 2027.
Navigation inputs are untrusted by design. AIS is unencrypted VHF and GNSS can be jammed or spoofed; cross-check positions with radar and other sensors and never rely on AIS alone.
Remote access is the main door. Uncontrolled maker and shore access over VSAT, shared default accounts and removable media cause most onboard exposure; MFA, segmentation and brokered access close it.

The maritime cyber risk landscape

Maritime cyber risk spans two worlds that rarely share a security team: ships, which combine IT with OT that steers, propels and loads them, and ports and terminals, which run their own OT and IT. IMO defines OT as computer-based systems "focused on the use of data to control or monitor physical processes", and the distinction matters because OT failures can cause collisions, groundings, pollution or injury, not only data loss.

Domain	Key systems	Typical exposure	Worst-case consequence
Bridge and navigation	ECDIS, radar, GNSS receivers, AIS, autopilot, voyage data recorder	Chart and software updates on USB media, maker remote support, spoofed radio inputs	Wrong position or route, collision or grounding
Engine and power	Propulsion control, power management, machinery automation	Flat networks shared with monitoring PCs, vendor laptops, legacy operating systems	Loss of propulsion or blackout at sea
Cargo and stability	Cargo and loading management, ballast water systems, tank monitoring	Shore data exchange, shared accounts	Stability or pollution incidents, cargo loss
Communications	VSAT and other satellite terminals, crew Wi-Fi, ship-to-shore links	Internet-exposed management interfaces, default credentials	Path from internet into onboard networks
Port and terminal	Terminal operating system, ship-to-shore cranes, gate automation, port community systems	Remote maintenance links, third-party integrations, IT/OT convergence	Port closure, cargo diversion, supply chain disruption

The BIMCO cyber security guidelines, written with other industry bodies, list the ship cybersecurity weaknesses seen most often: "the use of default administrator accounts and passwords", "insufficient screening of removable media", shipboard networks "which lack boundary protection measures and segmentation", and unknown and uncoordinated remote access to an operating ship.

IMO rules: MSC.428(98) and MSC-FAL.1/Circ.3

IMO Resolution MSC.428(98): adopted by the Maritime Safety Committee in June 2017, titled "Maritime Cyber Risk Management in Safety Management Systems". It "encourages administrations to ensure that cyber risks are appropriately addressed in existing safety management systems" under the ISM Code, "no later than the first annual verification of the company's Document of Compliance after 1 January 2021".
ISM Code cyber: because cyber risk sits in the safety management system, it needs the same elements as other safety risks: risk assessment, procedures, responsibilities, training, drills, reporting of non-conformities and management review. A separate cyber policy that the ship's crew have never seen does not meet the intent.
MSC-FAL.1/Circ.3 (Guidelines on maritime cyber risk management): the current version, Rev.3, is dated 4 April 2025, approved by MSC 108 and FAL 49. It defines cyber risk management as "the process of identifying, analysing, assessing and communicating a cyber-related risk" and sets six functional elements: Govern, Identify, Protect, Detect, Respond and Recover, which "are not sequential" but "concurrent and continuous in practice". It is "primarily intended for ships", lists "Ship-to-shore integrated systems" among vulnerable systems, and points ports to the IAPH Cybersecurity Guidelines for Ports and Port Facilities.

The IMO maritime cyber risk guidance is deliberately high level. Operators turn it into practice with industry guidance such as the BIMCO-led Guidelines on Cyber Security Onboard Ships (version 5), produced with ICS, INTERTANKO, INTERCARGO, OCIMF, DCSA and others, and with class rules.

IACS UR E26 and UR E27 for new ships

IACS UR E26 "Cyber Resilience of Ships" and UR E27 "Cyber Resilience of On-Board Systems and Equipment" are class requirements, so compliance is checked by the classification society rather than by a regulator. IACS withdrew the first versions (planned for 1 January 2024) before they entered into force; the revised versions "will be applied to new ships contracted for construction on and after 1 July 2024". The BIMCO guidelines confirm they are "applicable to newbuilds only", although existing ships can use them as guidance.

Aspect	UR E26 (ship)	UR E27 (systems and equipment)
Who it addresses	Shipyard, owner and class society, for the vessel as a whole	Suppliers of computer-based systems installed on board
Scope	Passenger ships and high-speed craft on international voyages, cargo ships and high-speed craft of 500 GT and upwards on international voyages, mobile offshore drilling units of 500 GT and upwards, and self-propelled mobile offshore construction units; other vessels may apply it voluntarily	Systems and equipment within E26 scope
Core content	Goals under Identify, Protect, Detect, Respond and Recover; computer-based system (CBS) asset inventory; network topology; security zones and controlled connections; incident response and recovery plans	"Minimum-security capabilities for systems and equipment", supplier documentation and testing
When checked	Construction, commissioning and annual surveys	Supplier documentation and testing, then verification on board

For buyers of new ships: write E26 and E27 deliverables into the shipbuilding contract and supplier orders, including who maintains the asset inventory after delivery and how patches will be supplied.
For existing fleets: use E26 as a target architecture during dry-dock and refit, starting with the asset inventory and topology, which also serve the IMO and USCG requirements. See the IEC 62443 Guide for the zone and conduit model the class rules draw on.

US Coast Guard cybersecurity rule and the MTSA

The Maritime Transportation Security Act of 2002 (MTSA) gives the Coast Guard authority over vessel and facility security plans. On 17 January 2025 the Coast Guard published the final rule "Cybersecurity in the Marine Transportation System", adding subpart F to 33 CFR part 101. The USCG cybersecurity rule (often called the Coast Guard cybersecurity rule) applies to owners and operators of US-flagged vessels, MTSA-regulated facilities and Outer Continental Shelf facilities required to have security plans. Foreign-flagged vessels are not covered by the rule, but the Coast Guard has said it will increase Port State Control scrutiny of poor cybersecurity practice.

Requirement	Section	Date
Rule effective; report reportable cyber incidents to the National Response Center without delay	101.650(g)	16 July 2025
Designate a Cybersecurity Officer (CySO)	101.625	By 16 July 2027
Conduct a cybersecurity assessment and submit a Cybersecurity Plan, including a Cyber Incident Response Plan, for approval	101.630, 101.655	No later than 16 July 2027
Two cybersecurity drills every 12 months	101.635	Under the approved plan
Account security, including "multifactor authentication on password-protected IT and remotely accessible OT systems" and automatic lockout	101.650(a)	Under the approved plan
Device and data security; logs "securely captured, stored, and protected"	101.650(b), (c)	Under the approved plan
Penetration testing with each plan renewal; network segmentation; physical security; personnel training	101.650	Under the approved plan

The Coast Guard also uses MARSEC Directives for specific threats. MARSEC Directive 105-5 (notice of 19 November 2024) sets "Cyber Risk Management Actions for Ship-to-Shore Cranes Manufactured by People's Republic of China Companies", adding to Directive 105-4 of February 2024. Both are Sensitive Security Information, obtained by eligible owners and operators through their Captain of the Port.

Securing onboard OT systems and ECDIS

For ship cyber security, the hard part is onboard OT systems. They are often supplied as sealed packages by different makers, run older operating systems and cannot be patched without class or maker approval. The approach is the one used in other OT sectors: know what is there, separate it, control who and what connects, and plan for loss. See the OT Security Guide.

Asset inventory: list every computer-based system, its maker, software version, network connections, remote access paths and who supports it. This is an E26 deliverable and the base for every other control. See the OT Asset Visibility Guide.
Segmentation: separate bridge, engine, cargo, crew and business networks into zones with firewalls between them; crew Wi-Fi must never route to OT. Data flowing to shore (performance monitoring, engine data) should leave through a controlled conduit, ideally one way.
ECDIS security: chart and software updates usually arrive on removable media or through a shore link. Scan media on a dedicated, isolated station before use, restrict USB ports on ECDIS and other bridge consoles, keep the operating system and anti-malware at the levels the maker supports, and keep the backup ECDIS genuinely independent so one infection cannot disable both.
Vessel OT accounts: replace default administrator accounts, give each engineer and maker technician a named account where the system allows, and keep shared accounts for emergency use with passwords changed after each use. See the OT and ICS Identity and Access Guide.
Patching and change: agree a patch process with each maker and record every software change in the planned maintenance system.
Recovery: keep offline backups and installation media on board, with procedures crew can follow without shore support.

GNSS, GPS spoofing at sea and AIS spoofing

Navigation depends on radio signals that were never designed to be authenticated. The US Maritime Administration advised that "Instances of significant GPS interference have been reported worldwide in the maritime domain" and that "AIS signals can be spoofed, resulting in incorrect or missing AIS data", because AIS uses unencrypted VHF radio. MARAD added that AIS "should never be solely relied upon for collision avoidance or navigational decision-making".

Threat	What it looks like	Defensive measures
GNSS jamming	Loss of position fix, alarms on GNSS receivers and ECDIS, timing errors on systems that use GNSS time	Radar and visual position fixing, dead reckoning, inertial or other backup sources, procedures for prolonged outage, separate time source for critical systems
GPS spoofing at sea	Plausible but wrong position, sudden position jumps, several ships appearing at the same location, speed and heading not matching the log and compass	Cross-check against radar overlay, depth, gyro and log; alarms on position discontinuity; multi-constellation receivers; bridge team training to distrust GNSS when inconsistent
AIS spoofing	Ghost targets, vessels shown in impossible locations, real vessels disappearing or showing false identity	Correlate AIS with radar targets; treat AIS as advisory; report anomalies (in US waters to NAVCEN); shore operators flag identity and track inconsistencies
Satellite link attacks	Compromise of VSAT terminal management interfaces, interception of unencrypted traffic	See VSAT security below

The BIMCO guidelines note that manipulation of external sensor data, including GNSS, "should not be discounted" as a risk.

VSAT security and ship to shore connectivity

Satellite connectivity turned ships into always-on endpoints. The BIMCO guidelines warn that "VSAT signals are vulnerable to exploitation using low-cost, off-the-shelf products". For the wider satellite context, see the Space and Satellite Cybersecurity Guide.

Terminal hardening: change default credentials on satellite terminals and modems, keep firmware current, and make sure management interfaces are not reachable from the internet or the crew network.
Encrypt everything: treat the satellite link as an untrusted network; use VPNs or TLS for all ship-to-shore traffic, including telemetry.
Brokered remote access: makers and shore teams should connect through a controlled remote access gateway with named accounts, MFA, approval by the master or chief engineer, session recording and time limits, rather than standing VPNs or remote desktop tools installed on OT PCs. This is the same pattern the USCG rule requires for remotely accessible OT. See the Remote Access Identity Guide and the Third-Party Access Guide.
Ship to shore connectivity map: document every link (satellite, 4G or 5G near shore, port Wi-Fi) with what it carries and who owns it.
Machine credentials: gateways forwarding engine and performance data to shore use certificates, API keys or service accounts; give each an owner and rotate them.

Port cybersecurity and terminal operating systems

Ports concentrate risk: a terminal operating system (TOS) plans every container move, yard position and crane instruction, and its loss can stop a terminal within hours. Port facility cybersecurity in the US falls under the MTSA facility security plan and the Coast Guard rule; elsewhere, ports usually fall under national critical infrastructure law, and IMO points them to the IAPH guidelines.

Terminal operating system: treat the TOS as a crown jewel. Restrict administrative access to named, MFA-protected accounts, log every change to vessel plans and container release, and test restoration from offline backups against a recovery time the terminal can survive.
Container release fraud: release PINs that let a truck collect a container are credentials; make them single use, short lived and tied to the collecting party.
Cranes and automation: ship-to-shore and yard cranes are remotely programmable OT. Inventory every remote connection, remove maker connections that are not needed, segment crane networks from the TOS and corporate IT, and apply MARSEC Directive requirements where they apply.
Integrations: shipping lines, customs and hauliers connect through APIs and EDI; scope each integration identity and remove it when the relationship ends.
Incident response: run joint drills with terminal operators, the port authority and shipping lines, covering manual operations. See the OT Incident Response Guide.

Implementation roadmap

Govern: assign accountability (in US-regulated entities, the Cybersecurity Officer), link cyber risk to the ISM safety management system or facility security plan, and agree who on board and ashore owns each control.
Inventory one representative vessel or terminal: systems, connections, accounts, remote access paths and makers. Use passive discovery only on OT networks.
Close the biggest doors first: remove default passwords, cut unknown remote access, separate crew networks from OT, and block unscanned USB use on bridge and engine consoles.
Pilot controls on one ship or terminal: deploy brokered remote access with MFA, segmentation firewalls in monitor mode first, then enforce after a voyage or operating cycle without false blocks. Keep the previous configuration so the chief engineer or terminal engineer can roll back if an OT function stops.
Roll out across the fleet or port: standardise configurations by ship class, train crews, and fold checks into ISM internal audits and planned maintenance.
Exercise and improve: run cyber drills (two per year under the USCG rule), including GNSS loss and ECDIS failure scenarios, and feed lessons into procedures.

Small vs large operators: a small owner will rely on makers, class guidance and a managed security provider, focusing on remote access, segmentation and media control. A large fleet or port operator should run shore-based security monitoring that receives ship logs during connectivity windows, with standard builds per ship class.

Detection, monitoring and metrics

What to log: remote access sessions and approvals, firewall decisions between zones, authentication on OT and IT systems, USB insertion on bridge and engine consoles, VSAT terminal logins and configuration changes, GNSS and AIS anomaly alarms, and TOS administrative changes.
Bandwidth-aware collection: forward high-value events in near real time and bulk logs during port calls; keep logs on board for a long passage.

Metrics that show progress:

Percentage of vessels and terminals with a current CBS asset inventory and network topology.
Percentage of remote access sessions brokered with MFA and approval, against all remote access observed.
Number of default or shared administrator accounts remaining on OT systems.
Percentage of ships where crew, business and OT networks are segmented and tested.
GNSS or AIS interference events logged and reported per quarter, and drills completed against plan.
Terminal operating system recovery time achieved in the last restore test.

Common failure patterns

Policy ashore, practice on board unchanged: a cyber chapter is added to the safety management system, but crews still share one password for the ECDIS and engine PCs.
Maker access nobody tracks: each equipment maker installed its own remote support tool during the warranty period, and the links remain years later with default credentials.
Flat ship networks: crew Wi-Fi, business PCs and OT share one network behind the satellite router, so a phishing email on a crew laptop reaches engine monitoring.
USB as the update channel: charts, software and documents move on unscanned media between the shore office, agents and bridge systems.
Trusting a single position source: bridge teams follow a spoofed GNSS position without cross-checking radar and depth.

Framework mapping

IMO functional element (Rev.3)	NIST CSF 2.0 function	IACS UR E26	USCG 33 CFR 101 subpart F
Govern	Govern	Ship and supplier documentation	101.620 owner or operator duties, 101.625 Cybersecurity Officer
Identify	Identify	CBS asset inventory, topology	Cybersecurity assessment, 101.630 plan
Protect	Protect	Security zones, access control, remote access	101.650 account, device and data security, segmentation, training
Detect	Detect	Network monitoring, anomaly detection	101.650 logging and monitoring
Respond	Respond	Incident response plan	Cyber Incident Response Plan, NRC reporting, 101.635 drills
Recover	Recover	Recovery plans, backups	Recovery and resilience measures in the plan

For OT control detail behind these elements, NIST SP 800-82 Rev. 3 and IEC 62443 are the usual references; see the IEC 62443 Guide.

Practitioner checklist

Confirm cyber risk is assessed and controlled within the ISM safety management system and verified at Document of Compliance audits.
Write UR E26 and E27 deliverables into newbuild contracts and keep the asset inventory and topology current after delivery.
For US-regulated vessels and facilities, report cyber incidents to the National Response Center and have the Cybersecurity Plan approved by 16 July 2027.
Replace default accounts on OT systems and give makers named, MFA-protected, brokered and recorded remote access.
Segment crew, business and OT networks and control removable media on bridge and engine consoles.
Train bridge teams to cross-check GNSS and AIS against radar and other sensors, and log and report interference.
Harden VSAT terminals and encrypt all ship to shore traffic.
Treat the terminal operating system and crane networks as crown jewels with tested offline recovery.
Run at least two cyber drills a year, including navigation and port system outage scenarios.

Standards and references

Related NHI Mgmt Group resources: OT Security Guide · OT and ICS Identity and Access Guide · IEC 62443 Guide · Space and Satellite Cybersecurity Guide · Third-Party Access Guide. This guide summarises IMO, IACS and US Coast Guard maritime cybersecurity requirements as of October 2026 and is not legal advice.

Maritime Cybersecurity Guide: Vessel OT, IMO Rules and Port Systems