UR E26 and E27 formally apply only to newbuildings with contracts signed after 1 July 2024. Concluding from this that existing fleets remain untouched by cyber requirements would be a dangerous error. The regulatory reality looks different.
Since 2021, IMO Resolution MSC.428(98) requires that cyber risks be addressed in the Safety Management System. This applies to all vessels regardless of build year. Port State Control inspectors can and will check whether cyber risks are addressed in the SMS. An empty section or a generic risk analysis with no connection to the actual systems onboard is increasingly assessed as insufficient.
Additionally, existing fleets are in practice often more vulnerable than newbuildings. Networks that have grown over years, retrospectively installed VSAT systems, OEM remote access without documentation, operating systems that have not been updated since build — all of this creates an attack surface that would not exist in a purposefully planned newbuilding.
Insurers are observing this development as well. Cyber insurance clauses are becoming more detailed, and questions about cyber risk management are increasingly appearing at P&I renewals. An operator who cannot provide a traceable answer to the question "How do you manage cyber risks onboard?" will in the medium term pay higher premiums or accept coverage gaps.
The first and most important step is a clean system inventory. This sounds trivial but is in practice the single greatest hurdle. Many existing vessels have no complete register of all networked systems. There is no central overview showing: which CBS are onboard, how they are connected to each other, which software versions are running, and who has remote access.
A pragmatic approach: during the next survey, systematically record every system with a network connection. This includes obvious systems such as ECDIS and automation PCs, but also frequently overlooked ones such as networked printers, CCTV systems with network connectivity, ballast water treatment controls and digital tank gauging systems.
For each system, the following should be recorded at minimum: manufacturer, model, software version, operating system, network connection (IP address, subnet, physical port), remote access capability and last update date. This produces a working table that serves as the basis for all subsequent steps.
This inventory need not be perfect in one pass. What matters is that the process begins and is systematically continued. An inventory covering 80% of systems and being actively maintained is infinitely more valuable than a document aiming for 100% completeness that therefore never gets finished.
The most common problems with existing fleets can be summarised in four categories. First: uncontrolled remote access. OEM technicians connect to onboard systems via TeamViewer, AnyDesk or VPN. Often it is not documented who accesses what and when. In some cases permanent VPN tunnels have been set up that the operator is not even aware of — the OEM installed them during commissioning and never deactivated them.
Second: outdated operating systems. Windows XP and Windows 7 are still in use on many vessels — on ECDIS computers, automation workstations and cargo computers. These systems no longer receive security updates. Every known vulnerability remains permanently open. Patching is often not possible because the OEM only supports specific OS versions and an upgrade could jeopardise type approval.
Third: missing or inconsistent documentation. Network plans either do not exist or reflect the state at delivery, not the current condition. Over the years, systems were added, replaced or reconfigured without updating documentation. This leads to a situation where nobody onboard or ashore has a complete picture of the network topology.
Fourth: lacking network separation. On many existing vessels, OT systems and crew internet share the same physical network. This was not a problem at commissioning because there was hardly any internet connectivity. Since broadband VSAT became standard, automation systems suddenly sit in a network connected to the internet — via a path that was never intended in the original installation.
A realistic improvement path for existing fleets consists of four phases: inventory, prioritisation, network discipline and recovery capability.
Phase 1 — inventory — has already been described. Without a current CBS register, every further measure is guesswork.
Phase 2 — prioritisation — means: do not try to solve everything at once. The risk assessment should weight systems according to their safety relevance and their vulnerability. An ECDIS with an outdated operating system and remote access has higher priority than a networked printer. Prioritisation creates a realistic roadmap achievable with limited resources.
Phase 3 — network discipline — encompasses measures often achievable without major investment: change default passwords, deactivate unnecessary network services, document and control remote access, deactivate physical ports not in use. On vessels with mixed networks, retrofitted segmentation via VLANs or additional switches can be a pragmatic solution.
Phase 4 — recovery — is strategically the most important. For critical systems, restart procedures must be defined and tested. What happens when ECDIS will not start? Is there a backup? Who restores automation when the server is compromised? How does the vessel navigate when all digital systems fail? These questions must be answered and the answers regularly exercised.
Patch management on existing vessels is one of the most complex topics in maritime cyber resilience. The fundamental problem: many CBS run on operating systems specified and certified by the OEM. An operating system update can jeopardise the system's type approval or cause incompatibilities with application software.
Windows XP Embedded is a prime example. For years it was the standard for maritime ECDIS systems and automation terminals. Microsoft ended support in 2014, extended support in 2019. Yet in 2026, thousands of CBS onboard still run this operating system. An upgrade is often impossible because the OEM's application software has not been tested on newer Windows versions.
Pragmatic solutions for this situation include: network isolation of affected systems so they cannot receive uncontrolled traffic. Application whitelisting that permits only authorised programmes to execute. Strict access control preventing USB sticks or other media from being connected without oversight. And a documented recovery plan describing how the system is restored in case of compromise.
For systems where an OS upgrade is feasible, the process should be coordinated with the OEM. Many manufacturers now offer update packages that refresh the operating system while maintaining application certification. This involves costs but reduces risk significantly.
Operators with limited budgets face the question: where to invest first? The answer follows from the risk assessment but in practice follows a recurring pattern. Highest priority goes to remote access points — they are the most likely attack vector and simultaneously the easiest to control. Second comes documentation — a current CBS inventory and network plan cost little but create the foundation for all further measures.
Third comes recovery capability for critical systems. Creating backups, documenting restart procedures and testing them once — this is achievable with manageable effort and delivers the greatest operational benefit in an actual event. Only fourth come hardware investments — additional firewalls, network segmentation, new switches. These measures are important but without the fundamentals of the first three steps, their benefit is limited.
Free initial consultation – we analyze your situation and find the best path forward.
Request Consulting