The thread through all three: this was a navigation-stack week. The signal coming in from orbit, the passwords baked into the boxes on the bridge, and the first regulator to write rules around both.

On 2 June 2026, a team from the University of Texas at Austin and Stanford published a paper with a title that reads like a thriller: Chasing Lightning. The substance is more unsettling than the title. They have traced scores of powerful, wide-area GNSS interference events over continental Europe, Greenland, and Canada, going back to 2019, to a single kind of source: a constellation of Russian early-warning satellites in Molniya orbits. "Molniya" is Russian for lightning, hence the paper's name.

The lead author group matters here. Todd Humphreys runs the Radionavigation Laboratory at UT Austin. He is the researcher who, in 2013, took control of a 65-metre superyacht's navigation by spoofing its GPS, and who spoofed a civilian drone for the US Department of Homeland Security a year earlier. When his lab says it can "confidently identify" an interference source, the maritime world should read carefully.

The method is what makes the claim stick. The team did not rely on a single sensor. They built a detection framework around received signal power, then combined data from the International GNSS Service reference-station network with raw wideband samples from two receivers in Europe, and used time-difference-of-arrival measurements, the timing gaps between when a signal reaches different ground stations, to triangulate where the interference was coming from. The geometry pointed up, to a source moving along a highly elliptical orbit consistent with Russia's missile-warning satellites.

Why this matters for maritime: the GNSS signal a ship's ECDIS, gyro, and integrated bridge system depend on is the same signal these events degrade, across exactly the waters European and North Atlantic shipping uses, from the North Sea to the Arctic approaches. And a space-based source rewrites the threat model that crews and authorities have been building around terrestrial jamming. You cannot drive to a hilltop and find the transmitter. You cannot geofence it. It passes overhead on an orbit, painting a wide area at once, and then it is gone, which is exactly why these events looked transient and unexplained for years. Whether the interference is a deliberate weapon or a side effect of the satellites' own powerful radar payloads is not fully settled, and the paper is a preprint, not yet peer-reviewed. The operational point holds either way: the position fix is not a constant, and the reasons it can fail now include hardware in orbit that no one on the bridge can see or switch off.

What to do: Treat GNSS as a sensor that degrades, not a utility that is always on, and build the bridge routine around that. Cross-check position continuously against radar overlay, visual bearings, and a second independent source, and train watchkeepers to notice a slow drift in the first minute rather than the tenth. Log GNSS anomalies with time and position and feed them to your flag state and to the bodies collecting interference data, because attribution like this paper's only happens when enough operators report. And if your passage plans through European, North Atlantic, or Arctic waters assume a reliable fix, revise them now to assume it can vanish for the length of a satellite pass.

Last week we covered a CISA advisory on the MacGregor voyage data recorder, the mandatory black box that turned out to carry default and hard-coded credentials. This week CISA did it again, with a different vendor. On 4 June, advisory ICSA-26-155-01 landed on the NAVTOR NavBox, the gateway many vessels use to distribute electronic charts and route plans to the bridge, alongside the ECDIS. The flaw, CVE-2026-21404, is hard-coded credentials in the device's communication service. That is two pieces of standard bridge equipment, flagged by CISA within a week of each other, failing on the same basic thing.

The finding came from Cydome's research team, the same group that flagged a separate set of NavBox flaws back in March. To NAVTOR's credit, this one was already fixed: the credentials issue affects NavBox up to version 4.16.1.20 and was resolved in 4.17.2.6, released in April. The rating is a medium, 6.3, not a screaming critical. On its own it would be a routine patch note. As the second instance in a fortnight, it stops being about one device and starts being about a pattern.

That pattern is not sophisticated, and that is the uncomfortable part. Neither of these was a clever zero-day. They were credentials shipped in the firmware, the kind of basic hygiene failure the rest of IT stopped tolerating two decades ago, sitting in type-approved equipment that lives on the bridge network and, in the VDR's case, is mandatory under SOLAS. Hard-coded credentials mean a password the operator cannot change and the attacker may already know. On gear that positions, plans, and records the voyage, that is a key to the navigation stack handed out at the factory.

Why this matters for maritime: this is exactly the gap that IMO MSC 111's new software-maintenance guidelines and Italy's circular, our Story 3 below, are trying to close, and it is why "type-approved" cannot be read as "secure." Type approval tests that the equipment does its navigational job, not that it resists an attacker. The credentials are baked in now, on equipment already aboard, while the rules to force them out are still being written.

What to do: Build an inventory of the navigation and bridge OT you actually run, the VDR, the ENC and route-planning gateway, the serial-to-IP converters, and put a name and firmware version against each. Ask each vendor a direct question: does this device ship with default or hard-coded credentials, and which version removes them? Then get to the fixed firmware, NavBox 4.17.2.6 or later and VDR V5.250 or later being two current examples, and until you are there, treat the device as untrusted: segment it, restrict who and what can reach it, and change every credential you are able to change. If a vendor cannot answer the credentials question, treat that as the finding.

While most of the sector still treats cyber risk management as IMO guidance to be interpreted, Italy has made it binding. MIT Circular 177/2025, "Maritime Cyber Risk," issued by the Ministry of Infrastructure and Transport through the Coast Guard's General Command and the national transport NIS authority, sets mandatory cyber requirements for Italian-flagged ships, for the ISM companies that manage them, and for port facility operators. It was published in December 2025 and comes into force on 1 November 2026.

The circular is notable for how completely it folds cyber into structures the industry already runs. On ships, cyber measures must live inside the Safety Management System, the same SMS that resolution MSC.428 already pointed to, rather than in a separate binder nobody opens. In ports, the Port Facility Security Assessment and Security Plan, the ISPS documents operators already maintain, must now carry a dedicated cyber-risk assessment. And the scope of "critical systems" is spelled out in a way that leaves little room to argue: propulsion and steering, power generation, internal and external communications including GMDSS, navigation systems such as ECDIS and AIS, access control, and the dedicated networks behind port infrastructure and VTS.

It also does two things that go beyond most national guidance. It makes training a requirement, not a recommendation, naming the crew, the Company Security Officer, the Port Facility Security Officer, and the IT and OT technicians who actually touch these systems. And it ties incident notification to CSIRT Italia, wiring maritime reporting into the same national machinery that NIS2 and its Italian transposition, Legislative Decree 138/2024, already built for everyone else.

Why this matters for maritime: Italy has just shown the rest of Europe what NIS2 plus IMO guidance looks like when a member state makes it concrete and binding for shipping, and the 1 November 2026 date is a real deadline for anyone operating Italian-flagged tonnage or Italian port facilities. It is also a preview. The same pressure, IMO guidance hardening, NIS2 landing on transport, is building in every EU maritime state, and the operators who treat the Italian circular as a template now will not be scrambling when their own flag does the same.

What to do: If you run Italian-flagged ships or operate at Italian port facilities, read Circular 177/2025 against what you actually do today and close the gap before 1 November 2026, starting with where cyber lives in your SMS and your PFSA. If you do not touch Italy, read it anyway as the most concrete model yet of where EU maritime cyber regulation is going, and check whether your SMS, your security plans, and your training records would survive the same requirements when your own administration adopts them.

And on these pages: as the Italian circular's 1 November deadline approaches, we will track which other EU flag states follow with binding maritime cyber rules of their own.

CYTUR 2026 Maritime Cyber Threat Report (CYTUR, February 2026)

CYTUR's annual report documents 828 maritime cyber incidents in 2025, up 103 percent year on year, with DDoS, ransomware, and malware each more than doubling. Its more useful contribution is the framing: two attack axes, direct attempts at vessel control through navigation and OT, and supply-chain attacks on ports, logistics IT, and vendors. It is a citable, external benchmark when you need to argue that maritime cyber risk is rising, not flat. Available at cytur.net.

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 →

"Pinpoint: How GPS Is Changing Technology, Culture, and Our Minds" by Greg Milner — the best single account of how completely the world came to depend on a fragile signal from space, and what happens when it fails. After a week in which that signal was traced to interference from orbit, it is the right book to understand why a navigator's instinct to distrust the screen is not paranoia but seamanship.

Browse maritime cyber book recommendations →