The thread: in each story, what counts is what someone can show.

On 19 October the US Coast Guard signed NVIC 02-26, "Cybersecurity Regulations Implementation Guidance for Maritime Transportation Security Act (MTSA) Regulated Entities". Its 61 pages explain the cyber rule in 33 CFR Part 101 Subpart F, in force since July 2025 for US-flag vessels, facilities and Outer Continental Shelf facilities that already need a security plan. The circular "does not change any legal requirements", but it sets out "the Coast Guard's preferred means of complying", and it replaces NVIC 01-20, the 2020 guidance for facilities.

The key date has not moved: "by July 16, 2027, all entities shall have submitted a CSP", a cybersecurity plan. For plans approved before then, every recurring timeline, drills and exercises included, starts on 16 July 2027. Penetration testing "is not required for the initial submission". After that it is needed once in each five-year cycle, and the Coast Guard is still writing guidance on it.

The tone is set on page two: "Owner/operator intent alone is insufficient; performance can and should be validated through documentation and observable evidence of implementation, effectiveness, and risk management." The Coast Guard will not prescribe products or methods, much as the original MTSA rules never required a fence. It says plainly that systems "in the cloud, or remotely anywhere in the world" can still put an entity's operations at risk, and it expects owners to know which software vendors, service providers and equipment makers can reach their IT and OT.

The most practical page is the drill table. Drills test parts of the plan twice a year, "evenly spaced". Exercises test the whole programme at least once a calendar year, never more than 18 months apart. They "must include substantial and active participation" of the cybersecurity officer, must test "communication and notification procedures, elements of coordination, resource availability, and response", and "may be a full-scale, live, or tabletop simulation". We run tabletop exercises for a living, so weigh our interest in that line accordingly. A real incident can count as a drill or exercise if it tested the plan and was documented, and corrective actions "must be addressed and documented as soon as possible".

Why this matters for maritime: the rule binds only US-flag ships and US facilities, but the approach travels. This month a regulator and a classification society (see Resource of the week) described the evidence of a working programme in much the same terms: a schedule, a record of who took part, and what was fixed afterwards.

What to do: If you are under the rule, start with Table 1 in Enclosure (1), which maps each provision to a section of the plan, and with Enclosure (4) on scoping. Put the 2027 drills and exercise in the calendar now, and decide who writes each record and what goes into it. If you are not under the rule, the drill table is a free benchmark. Either way, know which of your suppliers hold your data. Story 2 is why.

Test your response: It is your first cybersecurity exercise under the new rule. Halfway through, the scenario hits a system your plan does not list, and your cybersecurity officer is on leave. What does the record of the exercise say, and who writes it? USCG Cyber Drill: The Final Rule Reality Check →

A week ago we reported that n0n's deadline for 38 shipping and port organisations had passed with no visible change. On Monday morning, 26 October, nothing had moved on the ransomware.live tracker. All 38 entries still end "[NOT PAID — EXPOSED: files publish 2026-10-19 13:27 UTC]", and none has been relabelled or removed. The group has kept listing, mostly US healthcare, legal and retail firms, with no new port or shipping line. We found no statement since 19 October from any of the 38 or from a Korean authority. CyberLogitec, the Seoul maritime software company at the centre of the main hypothesis, last spoke on record on 13 October, saying that the companies named "are indeed our customers" and that it was establishing the facts (our translation).

The retelling has gone further. On 23 October Risky Business, a widely read security newsletter, wrote that n0n "pivoted from the network of a maritime IT services provider to 40+ port authorities, maritime, and global sea shipping companies", that "most have refused to pay and had their data leaked on the site", and that CyberLogitec's website "has been down for weeks". We checked. The batch is 38. The "NOT PAID — EXPOSED" line was on the entries before the deadline, when we recorded it on 17 October: it is the attacker's label, not evidence that files were published. The only analysis we know of that points to CyberLogitec is by Cydome, a commercial partner of our parent company in Poland, and Cydome calls it a hypothesis: "To our knowledge, so far CyberLogitec has not confirmed an incident in this case." We found no source for the jump from a vendor's network to its customers. And CyberLogitec's website loaded normally on Monday morning.

None of this means the hypothesis is wrong. It is still a hypothesis, and some of the most confident accounts of this case go further than the evidence does.

Why this matters for maritime: customers, insurers and boards read the retelling, not the tracker. A vendor named in print as the source of a breach it has not confirmed, and 38 companies said to have had their data leaked when nobody has shown it, are hard to walk back once they reach a board paper or a renewal questionnaire.

What to do: Last week's steps stand: ask your EDI partners among the 38 in writing what they have assessed, search your support tickets for credentials and configuration files, and brief whoever handles payment instructions. One more: before an article about this case goes into an internal report, mark each sentence as confirmed, claimed by the attacker or inferred by the writer. If you are one of the 38, keep a short, dated note of what you know and what you do not. Your customers have now read that their data was leaked.

Test your response: A security newsletter your customers read says your data has been leaked. You have no evidence that it was, and none that it was not. Your software vendor is not answering. What goes into the note to customers today? CMA CGM: Ransomware in the Container Kingdom →

Disclosure first: we worked with ClassNK on an exercise in Panama this year.

On 30 September ClassNK added a class notation to its Guidelines for Advanced Safety Measures: a-SAFE(GIMS), for GNSS Interference Mitigation System. It covers ships with a system that supports "situational awareness of seafarers by detecting the effects of jamming (radio interference) and spoofing (signal falsification) on positioning information obtained from GNSS" and raises an alarm. Splash247 reported it on 22 October.

The paragraph after it matters more. It lists what owners might fit, from interference detectors and multi-frequency and multi-constellation receivers to anti-jamming antennas and dead reckoning, and then says: "the installation of such systems alone is not, in itself, deemed to provide the detection and alarm functions specified". The notation is for a function, detection and alarm, not for a parts list. Owners submit system outlines, operation manuals and performance test reports. Splash adds that the notation "does not mean a ship is immune to interference", and reports that ClassNK has clarified that IACS UR E26 and E27 "do not directly mandate protection against GPS spoofing or jamming". We could not find where ClassNK said that, so treat it as Splash's report.

Why this matters for maritime: last week Kpler warned that onboard systems "often share one bad input", and we wrote that the cause of a false track can be shown only if the bridge recorded it at the time. An alarm is how the bridge knows at the time, and it gives the log a timestamp. The notation lets an owner have that function checked. It does not keep the position right while the signal is being faked.

What to do: Ask your bridge equipment supplier whether your setup detects spoofing as well as jamming, and whether its alarm is one the officer of the watch will notice. Test it in a drill, not only at commissioning. Log every alarm with the time and an independent position fix. And put loss of GNSS, and loss of its integrity, into your written incident procedures: ClassNK's management guidelines in this week's Resource name it explicitly.

Test your response: Your new interference alarm goes off twice in an hour off a busy anchorage. The officer of the watch silences it the second time. Was that a spoofing event, and what will the log show a charterer next week? Ghost Ships of the Black Sea: When GPS Lies →

Full calendar, with cyber tracks flagged: https://mc3.maritime-ogmios.tech

Unconfirmed signals from open-source and regional channels we monitor. Confidence is flagged on each item. Treat these as early warning, not fact, until confirmed.

Aveva (single source: the attackers' listing), listed by Mimori on 20 October. The tracker flags Mimori as an emerging group and says its claim "should be treated with caution until independently verified". The domain on the listing, aveva[.]com, belongs to the Cambridge-based industrial software company, part of Schneider Electric, whose products include hull and outfitting design software for shipyards. The group claims 177 234 files; the publication date it set, 23 October, has passed. We found no statement from the company.

Last week's Patriot Maritime and Codar listings drop out: neither company has said anything, and nothing has confirmed them.

"Guidelines for Cyber Security Management System for Ships", Second Edition (ClassNK, 2 October 2026)

The first edition came out in April 2019. The second is a full revision, and the same disclosure as in Story 3 applies. Part 1 sets out the requirements, now with reference to ISO/IEC 27001 and 27002. Part 2 sets out, for each requirement, the assessment criteria ClassNK applies in its audits and the objective evidence it expects to see. That second part makes the document useful even if your ships are not in ClassNK class: it is a list of what an auditor will ask to be shown.

Start with chapter 9 of Part 2. Response procedures must cover, among other situations, loss of navigational equipment, loss of availability or integrity of GNSS, loss of connectivity with the shore including GMDSS, loss of control of propulsion or steering, and ransomware or denial of service. They must also be "available in non-electronic form". The drill programme in 9.2 needs a set frequency, a record of each drill with its date and participants, and a post-drill review that records improvement points and agreed corrective actions. Read it next to the drill table in Story 1.

ClassNK CSMS page and guidelines →

Maritime Cyber Intelligence Brief covers what the weekly cannot: full incident timelines, regulatory analysis, GNSS threat data, and OT advisory breakdowns. The latest issue is a free preview.

Read the Intelligence Brief →

"Cybersecurity Tabletop Exercises: From Planning to Execution", by Robert Lelewski and John Hollenberger, 2024.

A practitioner's guide to running tabletop exercises: setting objectives, designing the scenario, choosing participants, facilitation, managing injects, and the report afterwards.

Relevant this week because both Story 1 and the Resource ask for the same thing after an exercise: a record of what happened and what will change.

Browse maritime cyber book recommendations →