Cyber-Class Ready Newbuilds and Fleet Retrofits

Every owner needs a clear list of computer-based systems before the project becomes too far advanced. That register should include navigation, propulsion, power management, steering, cargo control, ballast, communications, safety systems, automation, remote monitoring, engine control, cybersecurity appliances, hotel systems where relevant, and vendor service connections.

For newbuilds, the register should sit inside the owner’s specification and yard deliverables. For existing fleets, it should become the baseline for retrofit priorities. A ship cannot be protected well if nobody agrees which systems are in scope.

Segmentation is one of the most important practical controls because shipboard systems do not all carry the same risk. The navigation network, cargo control network, propulsion systems, crew internet, business systems, remote support channels, passenger services, and vendor access points should not be treated as one flat environment.

The owner should ask for drawings that show network zones, conduits, firewalls, managed switches, access controls, remote support paths, and any connections between OT and IT. On existing vessels, even partial segmentation can reduce risk if it targets the most dangerous pathways first.

Remote access is often where cyber policy meets messy reality. Owners need to know which vendors can connect, which systems they can reach, who approves access, whether sessions are logged, whether multi-factor authentication is used, and whether access is disabled after work is complete.

Newbuild buyers should require vendor access rules in the procurement package. Existing fleets should build a remote-access register and remove old accounts, shared credentials, abandoned modems, undocumented satellite links, and permanent vendor tunnels that no longer have an active business reason.

E27 makes equipment-level cyber resilience harder to ignore. Owners should expect vendors to explain password policy, account roles, service ports, logging, update methods, malware protection where suitable, backup and restore capability, secure configuration, and system documentation.

For older vessels, the owner may not be able to demand newbuild-level capabilities from every legacy system. The practical approach is to identify the most critical systems and add compensating controls, such as network isolation, access restrictions, manual recovery procedures, spare hardware, offline backups, or stricter vendor attendance rules.

Detection is not useful if nobody sees the alert, understands it, or knows which system is affected. Owners should define which cyber and system events matter: failed logins, unauthorized configuration changes, malware alerts, unusual remote access, firewall events, loss of logging, suspicious USB use, and unexpected network traffic where monitoring exists.

The owner should also decide who receives alerts. A vessel-only alert may be missed during a busy port call. A shore-only alert may be too far from the system. A practical model gives the master, chief engineer, ETO where carried, superintendent, and cyber support provider clear escalation rules.

A cyber-resilient vessel must be able to recover critical functions. Owners should not stop at “backup exists.” They need to know where backups are stored, how often they are tested, who can restore them, whether vendor support is required, whether spare hardware exists, and which manual fallback procedures keep the ship safe.

Newbuilds should include restore tests and handover evidence. Existing fleets should prioritize backup and restore proof for the systems that can create safety, navigation, propulsion, cargo, or port-state consequences if unavailable.

Many newbuild cyber weaknesses appear after delivery because the owner receives systems, but not enough usable documentation. The owner should request network diagrams, system inventories, administrator account list, vendor contacts, software versions, patch status, backup process, incident contacts, hardening records, test results, and open cyber exceptions.

Existing fleets need the same discipline in a more realistic form. If the vessel lacks documentation, the first step is not perfection. The first step is building a trusted evidence pack for each vessel, then updating it after every vendor attendance, system change, drydock, and major repair.

A cyber incident response plan should not read like a shore-office policy pasted into the SMS. It should tell the vessel who to call, which systems to isolate, which evidence to preserve, which functions must be kept running, which manual procedures are available, and when the incident becomes a safety, class, flag, charterer, insurer, or customer issue.

The plan should also recognize the shipboard chain of command. Masters and chief engineers need practical steps, not abstract cybersecurity language. Shore support needs a clear trigger for escalation and technical assistance.

Cyber risk increases when nobody controls system changes. A supplier updates software, a crew member replaces a router, a service engineer connects a laptop, a shore team changes firewall settings, or a vendor installs a patch without a full record. The owner needs a vessel change log that captures approval, date, system, vendor, reason, backup status, test result, and rollback plan.

This is especially valuable for existing fleets because many cyber weaknesses are created gradually through undocumented changes. A simple change-control process can deliver more risk reduction than a complex tool that crews do not use.