Running Cyber Security On Board

Everything so far has been about how ships and systems are built. This lesson is about the part that fails more often: how they are run. An owner can take delivery of a flawlessly segmented, E26-compliant vessel and undo the whole design within a year, one standing vendor connection here, one shared password there, a crew that treats the SMS cyber chapter as something to sign rather than something to do. Paper resilience is not resilience.

The crew is the sensor network

Start with people, because every incident does. Effective crew awareness has nothing to do with turning seafarers into network engineers. It aims at something more familiar: extending the shipboard habit of noticing to a new class of symptom. A deck officer who would never step over an oil sheen should be equally unable to ignore an ECDIS behaving strangely, an email that does not smell right, or a USB stick of unknown history heading for a chart update. The awareness programme succeeds when odd system behaviour becomes a reportable event, logged, mentioned at handover, passed to shore, rather than something rebooted quietly and forgotten.

Two habits carry most of the weight: portable media discipline (dedicated, scanned sticks for updates; personal devices never touch ship systems) and password hygiene (no shared logins on OT, no defaults left in place, no credentials taped inside cabinet doors: the classics remain classics because audits keep finding them).

Drill it like a fire

An incident response plan that has never been exercised is a document, not a capability. The remedy is the industry's oldest tool: the drill. Run the scenario, ECDIS lost to malware mid-passage, engine automation behaving suspiciously, ransomware note on the planned-maintenance terminal, and walk it: who isolates what, where local manual control is taken, what is safe to disconnect, who calls whom ashore, what gets written down for the investigation. The first drill is always revealing. Someone discovers the fallback procedure references an officer who signed off two years ago; someone learns the automation cabinet key lives in a drawer nobody can name. Better at anchor than in a traffic separation scheme.

Response logic follows damage control, not IT support: contain first: isolate the affected system where it is safe to do so, keep essential functions running on the independent local controls that E26 made sure exist, then report and recover. The one reflex to train out of the crew is the blanket shutdown: powering down everything "to be safe" can convert a contained nuisance into a real casualty.

Guard the remote doors

The steadiest operational risk is the one installed with good intentions: vendor remote access. Makers dial in to diagnose engines, tune automation, update software: genuinely useful, and collectively a set of doors into OT that no one person on board can usually list. The discipline is the gangway watch, transplanted: every remote session gets permission before it starts, supervision while it runs, a log entry saying what was done, and a closed connection when it ends. The anti-pattern, the permanent, always-on maker's link that nobody remembers, is precisely how systems acquire unwatched doors. An inventory of remote access points, kept as current as the crew list, is among the cheapest security controls a fleet can own.

Updates deserve the same deliberateness. On an office laptop, patches install themselves overnight; on OT, an update is a modification to a machinery control system and is managed like one: planned with the maker's guidance and class requirements in mind, tested, and timed for a safe operational window rather than auto-installed at sea. An unpatched system is a risk; an unplanned patch is a different one. Guidance aimed at exactly this operational layer, organisation, training, response, is set out in the Indian Register of Shipping's Guidelines on Maritime Cyber Safety.

Proving it: the class notations

How does an owner show all this to a charterer, an insurer, a vetting inspector? Class notations, and Bureau Veritas' rule note NR659 (July 2024) is a clean example of how they now work. It carries three main notations, each for a different job. CYBER RESILIENT is how BV applies UR E26 and E27: for ships in the IACS scope contracted on or after 1 July 2024 it is assigned, not chosen, while other ships may earn it as an additional notation. CYBER MANAGED is for existing ships and ships outside that scope: organisation, procedures and crew training, written to support the risk-management thinking of MSC.428(98). CYBER SECURE sits on top of RESILIENT, for ships secured by design, with architecture and equipment hardening beyond what either of the others asks. (A fourth, CYBER MANAGED PREPARED, survives only on ships that held it before 2023.) The scheme's value is honesty: it lets an owner claim exactly as much as the fleet can prove, and gives the market a vocabulary finer than "we take cyber seriously."

A ship run this way, noticing crew, drilled responses, guarded doors, provable claims, is ready for the question the next lesson raises: what happens when the network is not just on the ship, but is the ship, because the crew is ashore in a remote operation centre?