Maritime Cyber Security and Resilience

A container ship at sea runs two networks that used to have nothing to do with each other. One carries email, the planned-maintenance database, and the crew’s connectivity; the other steers the ship, runs the main engine, and draws the electronic chart the officer of the watch navigates on. The first is information technology, IT; the second is operational technology, OT. The moment those two networks began sharing switches, satellite links, and the same USB sticks, a problem that used to cost a shipping company some data started being able to cost it steering, position, or propulsion. This article is the hub for the maritime cyber security and resilience cluster: it sets out the threat, the regulation that now puts cyber risk inside the safety management system, the class rules that build resilience into new ships, the risk method the industry has settled on, and the shipboard systems that actually need protecting. The two screening tools in the cluster, the IACS UR E26 cyber resilience screen and the IACS UR E27 OT/IT integration screen, turn the two class requirements into a check an owner or yard can run against a design.

The reason this matters in money rather than abstraction is a single documented case. In June 2017 the NotPetya malware, a destructive wiper dressed as ransomware, spread out of a compromised Ukrainian tax-accounting package and crossed into the corporate network of A.P. Moller-Maersk, the largest container line in the world. Maersk later put the cost at 250 to 300 million US dollars in lost revenue and rebuilt roughly 4,000 servers, 45,000 PCs, and 2,500 applications in about ten days, running terminals on pen and paper while it did. No ship’s steering was touched; the attack landed in IT. It still stopped container operations across terminals worldwide, & that is the point the regulation took from it: the maritime exposure is the whole operation, not the bridge in isolation.

The threat picture: what actually goes wrong

Maritime cyber threats are not one thing, and lumping them together is the first analytical error. They split into attacks on the business, which cost money and time, and attacks or failures on the control systems, which cost safety. The first category is dominated by ransomware and its destructive cousins, and the NotPetya impact on Maersk is the documented anchor: a corporate-network infection that never touched a ship’s automation still halted the cargo machine. Ransomware against ship managers, ports, and classification societies has continued since, because the sector runs old Windows estates, flat networks, and remote-access links that an attacker reaches the same way they reach any other enterprise.

The control-system threats are the ones unique to ships, and the most operationally present is interference with satellite navigation. GNSS jamming denies the position by drowning the weak satellite signal in radio noise, so the receiver simply loses its fix; the watch sees the position go away and knows something is wrong. Spoofing is the harder problem: the receiver is fed a false but internally consistent signal, computes a wrong position, and displays it as if it were true, so the officer of the watch can be looking at a confident latitude and longitude that is off by miles. Both have been reported in concentrated zones including the eastern Mediterranean, the Black Sea, and the Arabian Gulf, the same contested waters the war risk and high-risk areas pillar covers, because GNSS interference clusters where state and non-state actors are active. The danger is downstream: a spoofed GNSS feed corrupts the ECDIS position, the transmitted AIS position, and the dynamic-positioning solution all at once, because every one of those systems trusts the receiver. The defense is a navigator’s defense, a cross-check of the GNSS position against radar ranges, visual bearings, and an independent position source, not a software patch.

AIS, the Automatic Identification System every SOLAS ship transmits, has its own weakness: it carries no authentication. A station can broadcast a position, identity, and course that the receiving system displays without any way to verify the sender, so spoofed or fabricated AIS targets, ghost ships, false identities, and impossible tracks have been observed and are trivial to generate. AIS was designed in the 1990s as a collision-avoidance aid, not a security feed, and treating its tracks as ground truth is a known mistake. ECDIS, the Electronic Chart Display and Information System that has replaced the paper chart on most ships, is a Windows or Linux computer under the hood, and it has been infected by malware arriving on the update USB stick or chart-loading media, with documented cases of ECDIS units knocked out of service by ordinary commodity malware rather than any targeted maritime attack. A blanked or frozen ECDIS on a ship that has discarded its paper charts is a navigation-safety event, not a nuisance.

The thread tying these together is OT and IT convergence. The integrated automation system, the ECDIS network, the GNSS feed, and the business IT network increasingly share physical infrastructure, remote-maintenance connections, and removable-media workflows. A flat network with no segmentation lets malware that lands in a crew laptop reach the machinery-control VLAN, and a remote-maintenance link left open for a vendor becomes the path an attacker uses to reach a propulsion controller. The wider context for this commercial and operational risk sits in the maritime security and risk hub, which covers the physical and regulatory security picture alongside the cyber dimension.

How attackers actually get in

The entry routes onto a ship and into a shipping company are mundane, which is why the controls that close them are mundane too. There are five, and a real assessment walks each one:

• Email. Phishing and business-email-compromise land an attacker on the corporate network through a crew member or a shore clerk who clicked a link or opened an invoice, and from there a flat network does the rest. NotPetya did not phish Maersk directly; it rode in through trusted software, but the everyday route into shipping companies is the same inbox that every office faces.
• Removable media. A USB stick used to load a chart update onto ECDIS, to move a file between a vendor’s laptop and a controller, or to charge a phone in a control-room port carries whatever was on the last machine it touched, and on a ship that USB stick crosses the IT-OT boundary that the network is supposed to enforce.
• Remote access. Vendors maintain ECDIS, automation, and engine systems remotely to save the cost of flying an engineer to a ship, and the link they use, a satellite connection into a maintenance port, is a door into OT that is open whenever the link is up. An attacker who finds that door, or who compromises the vendor, reaches the controller directly.
• Supply chain. Equipment delivered with default passwords, unpatched firmware, or a hidden maintenance account is a vulnerability the ship inherits at delivery, which is exactly the gap IACS UR E27 makes the supplier close.
• Physical access. A contractor, a surveyor, or a visitor with access to a bridge or engine-room console can connect a device or plug in media, which ties the cyber threat to the physical-access controls the ISPS regime governs in port.

None of these is exotic, and that is the point: the maritime attack surface is the ordinary enterprise attack surface plus a control network that was never designed to be on a network at all.

A short documented history

The threat is not hypothetical, and a few documented points anchor it. In 2013 researchers at the University of Texas demonstrated that a civilian GNSS receiver could be spoofed into steering a yacht off course using a fabricated signal, the first widely cited proof that civilian navigation could be deceived rather than merely denied. ECDIS malware infections were documented by class societies and security researchers through the mid-2010s, with cases of units running outdated Windows being knocked offline by commodity malware that was not even aiming at ships. The June 2017 NotPetya event is the watershed because of its scale and its cost, the 250 to 300 million US dollar Maersk figure, and because it landed in the same year the IMO adopted MSC.428(98). GNSS interference reports concentrated in the eastern Mediterranean, the Black Sea, and the Arabian Gulf have continued since, reported through navigational warnings and industry advisories, which is why position cross-checking is now standard bridge practice rather than a precaution. The pattern across the decade is consistent: the demonstrations came first, the real incidents followed, and the regulation arrived behind both.

The regulatory drivers: from ISM duty to class rule

The regulation arrived in two waves with different mechanisms. The first puts cyber risk inside the existing safety system that every company already runs; the second builds resilience into the ship at the design stage. Reading them as alternatives is wrong: they sit at different points in a ship’s life and apply to different fleets.

IMO MSC.428(98) and the ISM route

The IMO chose not to write a standalone cyber convention. Resolution MSC.428(98), adopted by the Maritime Safety Committee on 16 June 2017, instead folds cyber risk into the instrument every company already operates under: the International Safety Management (ISM) Code. The resolution affirms that an approved safety management system should account for cyber risk management in line with the objectives and functional requirements of the ISM Code, and it encourages administrations to ensure cyber risk is appropriately addressed in the SMS no later than the first annual verification of the company’s Document of Compliance after 1 January 2021. That last clause is the operative one. It is a verification trigger, not a force-entry date for a new rule: from that first DOC annual verification, a flag or port-state inspector can read a missing, generic, or empty cyber risk assessment as an ISM non-conformity, with the same consequences as any other SMS gap.

The method the IMO recommends sits in a separate, non-mandatory circular: MSC-FAL.1/Circ.3, the Guidelines on Maritime Cyber Risk Management, now at Revision 3. The guidelines are recommendatory, set out the high-level approach, and point to recognized industry and standards frameworks, including the NIST Cybersecurity Framework, rather than prescribing controls. The split is deliberate: MSC.428(98) makes the duty enforceable through ISM, and the circular tells you how to discharge it without freezing a fast-moving technical field into treaty text. A company that has run a real risk assessment, written cyber procedures into its SMS, and can show the crew is trained meets the duty; a company that has bought a policy template and filed it has not.

The circular has been revised as the field moved: Revision 2 was issued on 7 June 2022, and Revision 3 was issued on 4 April 2025; the IMO Maritime Safety Committee approved the revision at its 108th session in May 2024 and the Facilitation Committee cleared it at FAL 49 in March 2025, so the circular itself dates from April 2025 rather than from the 2024 approval. Each revision keeps the same recommendatory character and the same five-element risk-management structure, identify, protect, detect, respond, recover, drawn from the NIST framework, while updating the reference list of industry standards. The practical effect of the recommendatory status is that an inspector does not check the ship against the circular; the inspector checks the SMS against the ISM Code, and the circular is the IMO’s statement of what a reasonable cyber element of that SMS looks like. The two documents work as a pair: the resolution is the lever, the circular is the manual.

Reading MSC.428(98) as a light-touch obligation is the mistake that produces a thin compliance file. The ISM Code is not a paperwork regime; it requires that risks be identified and that safeguards be established, and a port-state control officer who finds the cyber risk assessment is a generic template with no ship-specific systems named, no risk ranking, and no evidence of crew familiarity can raise a non-conformity that, if serious enough, holds the ship. The enforcement is the ordinary ISM enforcement, and that is the strength of putting cyber inside the ISM Code rather than in a separate instrument: it inherits a verification, audit, and detention machinery that already exists and already has teeth.

IACS UR E26 and E27 for new ships

The class societies closed the gap MSC.428(98) leaves at the newbuilding stage. IACS, the International Association of Classification Societies, issued two unified requirements: UR E26, Cyber resilience of ships, and UR E27, Cyber resilience of on-board systems and equipment. Both apply to ships contracted for construction on or after 1 July 2024, so they bite on new ships at the yard rather than retroactively on the existing fleet. The division of labor between the two is the thing to hold: E26 treats the ship as a whole, requiring the owner to maintain a documented inventory of the computer-based systems essential to safe and secure operation, to segment networks, and to integrate those systems with resilience designed in. The IACS UR E26 cyber resilience screen walks a design through the E26 requirement set.

E27 works one level down, at the individual onboard system and piece of equipment, with the weight on the supplier. It requires the makers of computer-based systems, the ECDIS, the automation controllers, the navigation and communication equipment, to build and demonstrate security capability at delivery, so the ship is not assembled from components that each carry an unmanaged vulnerability. The IACS UR E27 OT/IT integration screen checks an item of equipment or a system integration against the E27 requirement. The two URs together mean a ship contracted after the date arrives with a cyber-resilience baseline built and surveyed, rather than bolted on by the operator afterward; the existing fleet stays under the MSC.428(98) ISM approach unless an owner adopts the class notation voluntarily.

The contract-date trigger is worth dwelling on because it sets who is and is not caught. The applicable date is the date the construction contract is signed, not the keel-laying or delivery date, so a ship ordered in June 2024 and delivered in 2027 falls outside E26 and E27 on the contract date even though it delivers years after they took effect, while a ship ordered in August 2024 is caught even if it delivers sooner. This is the standard IACS and IMO convention for newbuilding requirements, and it means the resilient fleet grows ship by ship as new orders are placed rather than arriving all at once. For the owner of a mixed fleet the consequence is a two-tier estate: post-July-2024 newbuildings carry the class-rule baseline, and the rest of the fleet carries whatever the ISM-driven program has built, which is why the company-level SMS approach remains the load-bearing control across most operators for years to come.

The table is the timeline and the division of labor in one view. MSC.428(98) is the enforceable duty on the whole fleet through ISM; the circular is the method; E26 and E27 are the class rules that build resilience into ships contracted from July 2024; and the NIST framework is the reference method both the IMO guidance and the BIMCO industry guidance lean on. None of them replaces the others, and a serious operator works all four layers at once.

The risk-management method: NIST, BIMCO, and defense in depth

The industry did not invent a maritime-specific risk method; it adopted one. The IMO guidelines and the BIMCO Guidelines on Cyber Security Onboard Ships both point to the NIST Cybersecurity Framework, which organizes the work into a small set of functions a non-specialist can hold. The original five, carried into the 2024 CSF 2.0 release, are Identify, Protect, Detect, Respond, and Recover; CSF 2.0, published on 26 February 2024, added Govern as a sixth to put board-level ownership and supply-chain risk on the same footing. The functions are not a checklist to tick once. They are a continuous loop: you identify what you have and what threatens it, protect it, detect when protection fails, respond to contain the incident, and recover to a known-good state.

The BIMCO guidelines, the most widely used industry document and one written by shipping bodies rather than a general IT standards group, map that loop onto the ship. They take the operator from a system inventory through a risk assessment to the technical and procedural controls, and they are the practical bridge between the abstract NIST function and the actual machinery-control network on a specific ship. The Guidelines on Cyber Security Onboard Ships were produced jointly by a group of industry bodies, BIMCO among them with the shipowner and management associations, so they carry the weight of the operators who have to apply them rather than the abstraction of a standards committee. They have been revised across successive versions as the IMO duty took effect and as the threat moved, and they are the document a ship manager most often hands an auditor as the basis of the SMS cyber element. The pairing is the working norm: NIST gives the structure, BIMCO gives the maritime application, MSC.428(98) makes the result an ISM obligation. For industrial control systems specifically, the IEC 62443 series provides the deeper engineering standard for securing the OT side, the automation and control systems that the IT-centric frameworks treat more lightly.

IEC 62443 matters because the ship’s most dangerous assets are control systems, not office computers, and the security thinking for control systems is different. The standard introduces the idea of zones and conduits, dividing a control system into security zones of similar risk and controlling the conduits between them, which is the formal version of the network-segmentation principle applied to industrial automation. It defines security levels that an asset or zone is designed to meet, so a supplier can state, and a buyer can require, a target security level rather than an unmeasurable promise of being secure. IACS UR E27 leans on this body of thinking for its equipment requirements, which is why the class rule and the IEC standard read as complementary rather than competing: E27 makes the supplier deliver capability, and IEC 62443 is the engineering vocabulary that capability is specified in.

The architectural principle under all of it is defense in depth: no single control is trusted to stop everything, so layers are stacked, perimeter controls, network segmentation, host hardening, access control, and monitoring, so that a failure of one does not expose the whole ship. The single most important layer on a ship is network segmentation. A flat network where the crew Wi-Fi, the business IT, and the machinery-control system share one broadcast domain is the condition that let an IT infection like NotPetya spread laterally; segmenting OT from IT with controlled, monitored boundaries means malware that lands in the crew laptop cannot reach the propulsion controller. E26’s inventory and segmentation requirement is precisely this principle written into a class rule. Removable media and remote-maintenance access are the two boundary controls that matter most in practice, because a USB stick carried to the ECDIS and a vendor’s remote link into the automation system are the two paths that bypass the network perimeter entirely.

The method has to map to specific systems to mean anything, and the table below ties the five NIST functions to concrete shipboard controls rather than leaving them as IT abstractions.

The Respond and Recover rows carry the resilience idea that distinguishes a ship from an office. An office that loses IT stops working; a ship that loses ECDIS still has to navigate, and a ship that loses automation still has to control its engine. The fallback to paper charts, to manual engine control from the engine-room, and to celestial or radar position-fixing is the maritime form of incident response, and it only works if the crew has kept the skill and the procedure is written and drilled rather than assumed.

Shipboard OT systems at risk

The OT inventory is where the framework meets the steel, and ranking the systems by the consequence of their compromise is the whole point of the E26 inventory requirement. The integrated automation system (IAS), sometimes the alarm-monitoring-and-control system, is the nervous system of the machinery space: it monitors and controls the main engine, auxiliaries, fuel, cooling, and alarms from a set of operator stations. A compromise here can suppress alarms, send false readings, or in the worst case interfere with control outputs, which is why it sits at the top of the priority list and why E26 requires it inventoried with its network connections mapped.

Propulsion and steering control is the system whose failure is most immediately dangerous, because a ship that cannot steer or that loses propulsion control in confined water has minutes, not hours. Modern propulsion and steering run through programmable controllers networked to the bridge and the engine control room, and the segmentation that keeps that network off the business IT is the protection that matters. The ECDIS sits at the navigation end and is, as covered above, a general-purpose computer that has been infected by commodity malware through its update media; its compromise is a navigation-safety event on a ship that no longer carries full paper-chart backup. The GNSS receiver feeds position into ECDIS, AIS, and where slaved the gyro and dynamic-positioning systems, so its corruption by jamming or spoofing propagates, which is why the navigator’s cross-check is itself a cyber control.

Ballast water control and cargo control round out the OT systems that carry real consequence. The ballast system affects the ship’s stability and trim, and its control network being reachable from IT is a hazard a stability event makes concrete; cargo control on a tanker or gas carrier governs loading, discharge, and the inert-gas and pressure systems whose mismanagement is a safety-of-life matter. On the cargo side the cyber question overlaps the physical-security question, and the ISPS and port-facility security regime covers the access-control side of protecting these systems while the ship is in port, where a contractor or visitor with physical access to a control panel is part of the same threat model. Across the bridge and machinery, the common pattern is that the most dangerous systems are the OT ones, the inventory is the first control, and segmentation is the protection that does the most work.

Why the inventory is the first control

The reason E26 starts with a documented list is that every later control depends on it. You cannot patch firmware you have not recorded the version of; you cannot segment a network whose connections you have not mapped; you cannot detect an anomaly on a system you did not know was there. The inventory E26 requires is specific: each computer-based system essential to safe and secure operation, with its manufacturer, model, firmware version, and network connectivity, so the owner holds a single picture of the OT estate. In practice this is harder than it sounds, because a ship is assembled from many suppliers’ equipment over a build that runs years, and the network diagram the yard delivers is rarely the network as eventually wired and commissioned. The inventory is therefore a living document that the ISM management system has to keep current as equipment is replaced and firmware is updated, not a one-time delivery artifact.

The inventory also forces the risk ranking that the rest of the program runs on. Once every system is listed, the owner ranks them by the consequence of compromise: a corrupted ECDIS or a hijacked steering controller sits at the top, a compromised entertainment system at the bottom, and the protective effort follows the ranking rather than spreading evenly. This is the difference between a security program and a security purchase. A program protects the steering controller harder than the crew Wi-Fi because losing steering in a channel is a different event from losing a video stream; a purchase buys one firewall and treats every system behind it as equally protected, which means the most dangerous system is protected to the same level as the least.

The convergence problem in concrete terms

The OT and IT convergence the threat section named is best understood through one specific failure: the remote-maintenance link left routable to the control network. A vendor needs to reach an automation controller to push a software update, so a path is opened from the satellite link, through the business IT, to the controller. If that path is a controlled, monitored, time-limited conduit, opened for the maintenance window and closed after, it is a managed risk. If it is a standing route through a flat network, it is the single most likely way an attacker reaches the machinery, because it was built to reach the machinery. The same logic applies to the chart-update workflow: a USB stick that moves between an internet-connected office computer and the ECDIS is a conduit across the boundary, and whether it is a risk or a managed control depends entirely on whether the media is scanned and controlled or simply carried. Convergence is not a vague trend; it is a set of named paths, and securing the ship is the work of finding each path and deciding whether it is a controlled conduit or an open door.

Incident response and resilience

Resilience is the word the regulation uses, and it means more than prevention: it means the ship can take a hit and keep operating safely. The first element is a written incident-response procedure inside the SMS, not a separate cyber binder nobody opens, because MSC.428(98) deliberately put the duty inside the safety system the crew already uses. The procedure has to say who does what when a system is suspected compromised: isolate the affected network, fall back to the manual or paper alternative, preserve evidence, notify the company and where required the flag and the affected ports, and restore from known-good backups. The Maersk case is the resilience lesson at the company scale: the recovery took ten days and worked because the company could rebuild from backups and run terminals manually, and a single surviving domain controller in a Ghana office, off the network during the attack, held the directory data the rebuild depended on. The lesson taken into the rules is that recoverability, tested backups and a real restoration plan, is as much a control as any firewall.

On the ship the resilience plan rests on the manual fallback. ECDIS down means the watch navigates on the alternative, which is why a ship that has gone fully paperless needs a tested backup ECDIS on an independent supply rather than a single point of failure. Automation down means the engineers control the machinery locally from the engine-room, which is a skill that atrophies if it is never drilled. GNSS spoofed means the navigator fixes by radar and visual bearings, which only works if the officer of the watch was trained to distrust a confident wrong position. None of these are software; they are the maritime competencies the cyber threat has made newly load-bearing, and the drill that keeps them alive is the recovery control the table above names. Backups close the loop: an ECDIS chart-and-configuration backup and an automation-configuration backup, both tested by restoring them, are what turn a compromised system from a casualty into an inconvenience.

A spoofing event, step by step

Take a concrete sequence to show how the response controls chain together. An officer of the watch on a laden tanker approaching the eastern Mediterranean notices the ECDIS position jump and the speed-over-ground read an impossible value, while the radar picture of the coastline no longer lines up with the charted position. The GNSS has been spoofed. The trained response is not to trust the displayed position: the officer cross-checks against radar ranges to known coastal features and visual bearings, establishes the ship’s real position from those independent fixes, and navigates on them. The AIS position the ship is transmitting is now wrong because it is fed from the same spoofed receiver, so the officer treats the AIS picture, both the ship’s own broadcast and any suspect targets, with the same suspicion. The event is logged, the company is notified, and a navigational-warning channel is checked for a known interference zone.

Every step in that sequence is a control the framework names. The cross-check is the Detect function working at the human level, catching a failure the automation accepted. The navigation on radar and visual fixes is the Respond fallback, the manual alternative the crew kept the skill for. The logging and notification feed the Recover and the lessons-learned loop back into the SMS. Nothing in the sequence is software; it is competence, procedure, and the discipline of not trusting a confident wrong number, which is exactly why the regulation put the duty inside the safety management system the crew already lives by rather than in an IT manual the bridge would never open.

The whole program is auditable through the same ISM machinery that audits everything else on the ship, which is the quiet strength of the MSC.428(98) design. The internal audit, the DOC annual verification, and the management review all now reach the cyber procedures, the risk assessment, the training records, and the drill logs, so cyber resilience is maintained on the same cycle as fire drills and lifeboat maintenance rather than as a one-time IT project. The cluster’s two screening tools, the IACS UR E26 cyber resilience screen and the IACS UR E27 OT/IT integration screen, support the design and survey side of that program for new ships, checking a ship-level resilience posture and an equipment-level integration against the two class requirements. Where the future fleet runs more automation and more remote operation, the cyber surface grows with it, a question the maritime security and risk hub picks up alongside the autonomy and remote-operation work in the wider ship-operations domain.

Limitations

This article maps the maritime cyber security regime and the systems it protects; it is not a substitute for a ship-specific risk assessment, the company’s safety management system, the BIMCO Guidelines on Cyber Security Onboard Ships in full, or the class rules and their guidance notes as the relevant society publishes them. MSC.428(98) sets a duty to address cyber risk in the SMS; it does not prescribe the controls, and what a given ship needs depends on its systems, its trade, and its threat exposure, which only an assessment of that ship can establish.

The IACS UR E26 and E27 applicability stated here, ships contracted for construction on or after 1 July 2024, is the contract-date trigger as IACS published it; the detailed scope, the systems in and out, and any class-society implementation specifics are set in the unified requirements and each society’s rules, and an owner or yard should work from those texts and the surveying society’s interpretation, not this summary. The two screening tools in the cluster check a design against the requirement structure; they do not constitute a class approval, which only the society’s survey delivers. The threat examples, GNSS jamming and spoofing zones, AIS spoofing, ECDIS malware, are documented patterns rather than a current threat advisory, and live navigational-warning and security-advisory sources govern any real transit. None of the material here replaces qualified cyber-security and class advice for a specific ship or company.

See also

• Maritime security and risk: the wider physical and regulatory security picture around the cyber dimension.
• ISPS and port-facility security: the access-control regime that protects shipboard systems in port.
• IACS UR E26 cyber resilience screen: checks a ship-level design against the UR E26 requirement set.
• IACS UR E27 OT/IT integration screen: checks a system or equipment integration against UR E27.