Electronic fog: GNSS interference beyond the bridge

This article is also available in French.

Every year, in northern Norway, several public agencies authorise a few days of GNSS jamming and spoofing transmissions around the island of Andøya, so that manufacturers and operators can put their equipment through real conditions. The exercise is called Jammertest [1], and it is the largest of its kind open to the public. During the 2022 edition, one participant left the Strava app running on their phone in the middle of a spoofing trial. They promptly posted an accidental personal best [2]: 6.44 kilometres in 5 minutes and 50 seconds, with 495 metres of elevation gain. Their phone was not part of the trial. A falsified positioning signal travels into everything that listens to a GNSS receiver, including equipment that has nothing to do with navigation.

The Royal Institute of Navigation makes that case in Impacts of GNSS Interference on Maritime Safety [3], published on 23 January 2026 at the end of a working group convened four months earlier. The report commits to a formulation I find sound: on a modern digital bridge, protected by digital equipment mandated under the SOLAS convention on safety of life at sea, GNSS interference is more of a cybersecurity problem than a navigation one. Quite simply because the interference enters the information system domain the moment it leaves the GNSS receiver.

A contested satellite signal is nothing new on this blog, and I have written before that GNSS vulnerability reaches well past the question of position. What this report adds is a piece-by-piece account of what actually happens on board under those conditions.

A survey of 271 mariners

The report draws on three sources: an online survey of 271 mariners, a technical review of bridge equipment, and the discussions of more than 130 contributors, among them authorities, manufacturers, integrators, the United Kingdom Hydrographic Office [4], the international association of marine aids to navigation [5] (IALA), the German aerospace centre [6], Inmarsat [7] and, on the French side, Exail [8].

The headline results: 79% of respondents have already experienced GNSS interference, 75% believe the situation is not improving, and more than 80% of those who transited the Persian Gulf met the phenomenon there¹. Then come the affected systems²: the GNSS receiver for 85% of them, AIS for 75%, ECDIS for 70%, radar for 51%. Finally, 14% report having ended up in an unsafe or unlawful situation, and 42% having lost trust in their vessel and its systems.

The sample is self-selected, since this is a public survey answered first and foremost by mariners already alert to the subject. The authors say so themselves, acknowledging the absence of any control mechanism and the good-faith basis of the answers. The ±6% margin of error quoted elsewhere comes from a formula that assumes random sampling, and therefore does not cover that recruitment bias. Add to this a very particular composition: 61% tankers and product carriers, a segment overexposed to the Persian Gulf and the Baltic, while fishing, leisure boating and coastal trade are all but absent.

These percentages therefore describe how often the problem occurs among mariners who have already met it, which does not transpose to the world fleet. What remains is 212 accounts describing the same effects on the same equipment.

Over twenty onboard systems consuming GNSS data

On a modern vessel, whose equipment is often heavily integrated, over 20 systems across 7 categories can process position or time derived from GNSS, and fewer than half of them are there to navigate. The gyrocompass is affected for 38% of respondents, the autopilot for 32%, with erroneous manoeuvres reported under spoofing, the Doppler log for 21%. More awkwardly still, some radars and gyrocompasses carry an internal GNSS receiver that no procedure allows anyone to switch off.

The communications figures deserve a pause, because we instinctively file them outside the field of navigation: VHF, MF and HF radios disrupted for 29% of respondents, the maritime safety information receiver (NAVTEX) for 15%, satellite communications for 33%. Yet this equipment depends on GNSS, in three different ways.

The first is the Global Maritime Distress and Safety System (GMDSS). A VHF set fitted with digital selective calling transmits a GNSS-derived position in its distress alert on channel 70. The rescue chain depends on it directly. The second lies in the antennas: most satellite communication systems carry their own GNSS receiver, which they need in order to point in the right direction of the sky and search in the right frequency range. The report notes that no human intervention can then correct the erroneous position. The Long-Range Identification and Tracking (LRIT) message also goes out by this route, every six hours, with a false position.

The third reason is the most structural, and the report never names it: on board, this equipment sits on the same data bus as the rest of the bridge, the NMEA (National Marine Electronics Association) standard through which onboard equipment exchanges position, heading and time. A falsified position sentence travels along it without every device needing a receiver of its own. On top of that come purely convenience connections, such as showing the time on a VHF set, calibrating a log or filtering NAVTEX messages by geographical proximity, which were never conceived as dependencies.

From this the report draws a recommendation I am happy to take up: every owner should establish the GNSS connectivity plan of each of their vessels, sister ships included, whose bridges differ more often than one might think. The recommendation is not new. I was writing back in 2020 that the dependency of installations and operations on GNSS, position and clock alike, had to be clearly established. What was missing then, and what the report supplies, is the list of what to go and look at. It is the same gesture as the inventory of onboard information systems, applied to a single dependency. One caveat is needed on the typical connectivity plot the report publishes: it describes a theoretical, fully integrated vessel and everything it could connect to GNSS. Read it as a template to adapt vessel by vessel. The report does not say, and cannot say, how many vessels actually have a NAVTEX or a gyrocompass wired to GNSS.

Contamination is also near-instantaneous, and false data propagates within the first milliseconds of spoofing. By the time the anomaly becomes visible on the bridge, isolating the systems is of little use.

Time as the payload

Spoofed time produces effects that outlive the departure from the area, and to my mind that is the most useful part of the document.

The mechanism will be familiar to any system administrator. On a vessel, the onboard time server regularly resynchronises on GNSS, then redistributes the time to every connected system through the Network Time Protocol (NTP). A false time going in becomes a false time everywhere: custody transfer of cargo, oil discharge monitoring, ballast, gas detection, fire alarms, stability computer, bridge watch alarm, electronic logs.

The consequences described go beyond inconvenience. Digital certificates can be invalidated and block a system, which the report explicitly treats as an exploitable attack vector. Electronic chart licences expire, and the corresponding charts vanish from the ECDIS. The report also suggests, in the conditional, that a false position could trigger the automatic purchase of charts for areas the vessel will never enter. An ECDIS buys nothing by itself, though. The case can only concern the subscription schemes where charts are paid for as you sail, of the Pay As You Sail kind, and the report’s own figure files them among premium options. For my part I have no field observation to support it. Above all, falsely timestamped data is written to memory, then read back later as if nothing had happened.

Hence the most concrete operational rule in the report. A GNSS receiver may appear to have recovered after leaving the area, output a position and a time that look normal, then later bring out corrupted data stored in its memory. Around 5% of respondents describe this behaviour. The only remedy is to mandate a full power cycle, or a cold reset, of every receiver once the area is behind you.

One last case bears directly on evidence. Some vessels carry, under the MARPOL convention, an oily water discharge recorder, timestamped and geolocated by GNSS. Under spoofing, this equipment can log events that never happened, or help conceal a discharge that did. The reasoning holds for everything that stands as proof on board, from the Voyage Data Recorder (VDR) to the electronic logs: GNSS timestamping is their silent foundation.

The beacon that sends rescuers elsewhere

The report places this recommendation at the top of its list, and it is hard to argue with. GMDSS, distress beacons, the search and rescue transponders you carry on you (AIS-SART) and man-overboard buttons all transmit a GNSS-derived position. On equipment of that kind, nothing tells the person carrying it what state the received signal is in, and they would have no way of acting on it anyway. The position therefore goes out at risk of being false, under jamming as under spoofing, which amounts to a serious safety failing. Spoofing remains the more treacherous of the two, since the beacon then emits a position that looks normal, and sends rescuers to the wrong place. An AIS-SART, in particular, can take no source of position other than its internal receiver.

The authors sum the situation up in one sentence: “Fundamentally the mariner’s skills with a sextant are irrelevant if they fall overboard wearing an AIS-SART within a GNSS interference region.” The argument for falling back on traditional methods, often heard in discussions on this subject and one I largely share for conning the vessel, stops dead here. A man overboard does not fix his position by dead reckoning.

The report gives a second example, from the leisure sector. Some digital selective calling VHF sets aimed at that market drive the fog sound signals, selecting the regulatory pattern from the declared vessel type and triggering it from the movement information supplied by GPS. The model the report cites is an off-the-shelf set whose manual describes exactly this [9]. Under jamming, the horn may then sound the wrong pattern, or stop sounding altogether. The authors also envisage, in the conditional, that spoofing placing the vessel far from the fog bank would suppress any signal at all; they put it forward as a failure mode to be tested, and recommend putting such equipment through interference trials.

From there follows a question the authors raise without settling it: vessels are today chartered to cross known interference regions, when we know their safety equipment will not work properly there. Who carries the responsibility, the owner, the vessel or the regulator? Class or flag exemptions are not cut out for an intermittent, variable effect. The authors anticipate insurance claims arriving without being able to say how they will be decided.

Plenty of work still to do

Four subjects strike me as deserving the next stage of the work.

The first is regulatory. The report calls for GNSS interference to be handled within cybersecurity frameworks, yet cites only IMO circular MSC-FAL.1/Circ.3/Rev.3 [10]. Nothing on unified requirements E26 and E27 of the International Association of Classification Societies (IACS) [11], which apply to vessels contracted for construction since 1 July 2024 and already mandate an inventory of systems and cyber resilience requirements. A GNSS connectivity plan would sit naturally within the inventory E26 requires, and that would spare owners the trouble of building a parallel scheme.

The next is European. The annex devoted to Vessel Traffic Services (VTS) describes virtual aids to navigation that disappear, channel lights synchronised by GNSS that flash incorrectly, and corrupted VTS recordings. In Europe these installations fall under the obligations of the NIS2 directive. The bridge between the two was worth building.

Then comes evidence, already touched on above. The report lists the logs and the VDR among the affected systems, without ever addressing their evidential value once the timestamping is compromised. Post-casualty investigations rest on those recordings. Their integrity is therefore cardinal.

The last is more down to earth: France is absent from the document, save for Exail among the contributors. Neither the French Navy, nor the regional operational surveillance and rescue centres (CROSS), nor the traffic services of the Ushant lane appear in it, although the subject is followed closely on this side of the Channel. Perhaps that is also a sign that we should contribute more to this kind of collective work.

A last word on Galileo authentication, which the report presents by asserting that the era of relying on open signals for safety-critical systems is finally over. The phrasing is a little brisk. Open Service Navigation Message Authentication (OSNMA) covers only one of Galileo’s frequencies, it detects spoofing without preventing it, with a latency of several seconds that calls for an inertial unit to bridge the gap, and it requires compatible receivers that the SOLAS fleet does not have. The source the report itself cites on this point is, soberly enough, titled “OSNMA, necessary but not sufficient”.

The connectivity plan, first

At the risk of repeating myself yet again, five steps strike me as within reach without waiting for a standard… or an accident.

Establish the GNSS connectivity plan of each vessel, equipment by equipment, hunting for the internal receivers nobody has inventoried. Document in the safety management system a procedure for fully power cycling the receivers on leaving an interference area, and check while you are at it that crews are allowed to do so, since 7% of respondents report that they are not. Ask manufacturers, before any purchase, for the results of their jamming and spoofing trials, and for the documented procedure to isolate an internal GNSS. Remove the connections nobody uses, probably the cheapest measure on this whole list.

Above all, train and exercise. I rank this step highest, and the report gives the measure of how far behind we are: 18% of respondents have received no training to avoid, detect or manage interference, 46% only informal training or training drawn from experience, and just 30% believe what they received genuinely helps them. A crew needs to recognise jamming, tell it apart from spoofing, and apply the right response without deliberating. The distinction is far from obvious. Jamming silences the receiver, which eventually shows. Spoofing produces a position that looks normal and raises no alarm. This calls for short quick-reference cards, kept current and posted on the bridge, and for drills that put them to the test. The report supplies the framework, with three cards organised into prepare, act and recover, tailored for the owner, the master and the officer of the watch. Each owner will have to adapt them to their vessels and keep them alive.

On the institutional side, two of the report’s recommendations strike me as particularly useful. The broadcast of navigational warnings on GNSS interference by area coordinators, which meets the existing criteria for maritime safety information. And a maritime interference mapping, overlayable on the ECDIS, since the public maps available today rest on aviation data, whose radio horizon bears no relation to that of a vessel. To which I add a more personal request: that the 67% of mariners who would like to be warned before entering an area eventually are.

The report closes on a suggestion that says a great deal about how ordinary this has become: a modern weather report should include the current state of electronic interference. We are not there yet, I started that service a few years ago, and I can only be glad the idea has stopped being far-fetched.

Sources

• [1] Jammertest, the annual Norwegian GNSS resilience trial
• [2] Morrison et al., Jammertest 2022: Jamming and Spoofing Lessons Learned, Engineering Proceedings 54(1), 2023
• [3] Royal Institute of Navigation, Impacts of GNSS Interference on Maritime Safety, January 2026
• [4] United Kingdom Hydrographic Office
• [5] IALA, international association of marine aids to navigation
• [6] DLR, the German aerospace centre
• [7] Inmarsat
• [8] Exail
• [9] Yachting Magazine, review of a VHF/DSC set with automatic fog signals
• [10] IMO, MSC-FAL.1/Circ.3/Rev.3, guidelines on maritime cyber risk management
• [11] IACS, unified requirements E26 and E27 on the cyber resilience of ships