← The Signal Report Work with me

Report 139 · Defense Tech

GPS jamming is not a navigation problem

Almost every story about GPS interference at sea is framed as a navigation story: the position on the chart display jumps, the crew falls back on radar and the paper chart, everyone carries on. The Royal Institute of Navigation published a report in January 2026 that quietly demolishes that framing, and it does it with an inventory rather than an argument. Somebody sat down and counted the systems on a modern vessel that consume satellite positioning or satellite timing. There are more than twenty of them, in seven categories, and fewer than half have anything to do with navigating the ship. The oily water separator is on the list. So is the ballast water treatment system, the voyage data recorder, and the network time protocol server.

I have written about GPS interference here a number of times, mostly from the transmitter side, because that is the side I worked. Jamming and spoofing are different attacks with different signatures. Finding the emitter is a solvable direction-finding problem. The effects outlast the event, because receivers carry bad state out of the interference zone with them. What I have not done is the boring, useful thing the RIN did, which is to enumerate what is actually downstream of the receiver.

That enumeration is the whole report, as far as I am concerned, and it is the part the coverage skipped.

The document

The report is titled Impacts of GNSS Interference on Maritime Safety. Its cover page describes it as "A special report by the RIN Maritime GNSS Interference Working Group" and gives the publication as "Digital Report Published January 2026". The full report sits behind a download form on the Institute's site. What is freely available, and what I read, is an official extract published on the RIN's own content server covering Section 4, "GNSS Connectivity Plot and Impacts of GNSS Interference on a Modern Vessel".

Section 4 is one figure and its caption. Here is the caption, in full:

Figure 4.1 This GNSS connectivity plot shows the sheer scales of the issue with GNSS connectivity on a modern maritime vessel. There can be over 20 systems across 7 categories that process GNSS data or time, with less than half of these systems being associated with the navigation of the vessel.

Read the fourth-from-last word of that sentence again. Time. Not "GNSS position", not "GNSS fix". GNSS data or time. That single conjunction is the difference between the story everyone tells about jamming and the story that is actually true, and the rest of the figure is fifty-odd line items proving it.

The seven categories

The figure groups the systems this way, with the counts being mine from the printed lists rather than the report's own arithmetic:

Ship's Systems (twelve entries) is the category that should stop people. It includes stability and loading computers, the platform management system, the integrated control and monitoring system, engine monitoring, fire safety systems, anchoring and mooring, environmental compliance reporting, oil discharge monitoring equipment, the oily water separator, the ballast water treatment system, fixed gas detection, and electronic recorders and logs.

Navigation (ten entries) is the category everybody already thinks about: ECDIS software and hardware, chart licences, X-band and S-band radar, the gyrocompass, the inertial navigation system, speed over ground, autopilot and track pilot, dynamic positioning, and the ship's log.

Communications (nine entries): AIS, VHF, MF/HF, digital selective calling built into the radios, NAVTEX, satellite internet and phone and LRIT, terrestrial internet and phone, handheld VHF radios, and the ship security alert system.

Other Bridge Systems (eight entries): the voyage data recorder, the ship's clock, the echosounder, weatherfax, wind gauges, automated man-overboard systems, the bridge navigation watch alarm system, and network time protocol servers.

Specific Operations (five entries), for vessels that do work rather than just carry cargo: cable-laying, surveying, dredging, autonomy and robotics, and automated passenger access systems.

Cargo Control (four entries): shipment tracking, custody transfer systems, gas monitoring, and floating storage and regasification units.

Safety of Life at Sea / Emergency Equipment (four entries), which the figure brackets with the Global Maritime Distress and Safety System: the emergency position indicating radio beacon, the AIS search-and-rescue transponder, man-overboard quick-push buttons on ECDIS and GNSS receivers, and the ship's whistle.

Many entries carry an asterisk, and the figure's footnote explains it: "*In some cases, e.g. premium makes/models". So this is not a claim that every ship has every dependency. It is a claim about what the market has built, and about what a buyer specifying the premium option is quietly buying into.

Fifty-two enumerated items, ten of them navigation. That is the shape of the problem.

Why timing is the part that gets missed

Here is the thing that took me a while to internalize when I was doing this for a living, and that almost nobody outside the trade ever internalizes at all.

A GPS receiver is not a position sensor with a clock bolted on. It is a clock, and position falls out of the clock. The receiver solves for four unknowns at once: three coordinates and its own time offset. That is why you need four satellites for a fix and not three. The consequence is that a receiver which is being denied, whether by broadband noise or by a counterfeit constellation, is not producing a bad position and a good time. It is producing a degraded solution, and both halves come out of the same solve.

Now look back at that inventory with that in mind. The network time protocol server on the bridge is not navigating anything. It is handing a timestamp to every networked box on the ship. The voyage data recorder is not navigating either. It is writing the legally significant record of what happened and when, which is the artifact an investigator, an insurer, and a court will all read afterward. Custody transfer systems are how cargo quantity gets agreed between two parties who have money riding on the number. Environmental compliance reporting and oil discharge monitoring produce the records that prove you did not discharge inside a restricted zone, and "inside" is a statement about position and "when" is a statement about time.

None of those failures show up as the chart display jumping. Several of them do not show up at all until much later, when somebody asks for the record.

The fallback that is not a fallback

The standard reassurance, offered every time this comes up, is that mariners have redundancy: lose the satellites and you have radar, you have the radios, you have terrestrial aids, you have a paper chart and a competent watch officer. I have made a version of that argument myself, in the report on navigating by the seabed, and I still think the underlying skills matter enormously.

But the redundancy argument assumes the fallbacks are independent, and the RIN's finding is that they are not. In the Institute's own announcement of the report, this is the sentence that carries it:

The report also highlights unnecessary dependencies between GNSS receivers and a range of onboard electronics — including RADAR, radios (VHF/MF/HF), NAVTEX, speed logs, ship clocks and satellite communications — many of which do not require GNSS data for their primary function, creating avoidable points of failure and compounding operational risk.

Radar does not need GPS to paint a target. A VHF radio does not need GPS to pass voice. A speed log measuring speed through water is measuring a mechanical quantity. The dependency in each case is a design convenience: it is cheaper to take a timestamp or a position off the one box that already has it than to give every system its own source. That is a perfectly rational engineering decision made forty times independently, and the aggregate result is a vessel with one hidden common-mode input.

"Unnecessary" and "avoidable" are the operative words, and they are the report's words, not mine. This is not a lament about physics. It is an indictment of an architecture, which means it is fixable at the specification stage and almost nowhere else.

What the Institute's own people said

Two quotes from the RIN's announcement are worth reproducing because they say the quiet part directly. The first is from the Institute's director:

The report has highlighted serious safety concerns and has underlined the fact that these issues are rooted in significant cybersecurity vulnerabilities, and are not just disruptions to navigation

The second, from Retired Commodore James Taylor OBE, generalizes it past shipping entirely:

Despite measures to improve resistance to jamming, spoofing and other harassment measures, the threat is real and growing. And this threat is not only to positioning and navigation; it is to every part of every transport and navigation means and to every part of national infrastructure where timing is derived from space-based timing signals.

He is right, and the reach of that statement is larger than most readers will assume on first pass. Cell networks, power grid phasor measurement, financial transaction timestamping, and broadcast synchronization all pull time from the same constellations. A ship is simply an unusually legible example, because it is a self-contained infrastructure with a documented equipment list, so somebody could sit down and count.

The part that genuinely alarms me

Of everything in the report's summary, this is the line I would put in front of a regulator:

Survey data exposes the vulnerability of critically important systems such as Global Maritime Distress and Safety Systems (GMDSS) and other SOLAS-mandated equipment that rely on satellite positioning and timing.

GMDSS is the layer of last resort. It is the equipment that is supposed to work when the rest of the ship does not, and its legally mandated status is precisely a statement that society has decided this must not fail. An EPIRB whose distress message carries a position depends on that position being real. A search-and-rescue transponder is a rendezvous device. If the same interference that put you in trouble also degrades the systems that summon and guide help, then the failure is correlated in exactly the direction you would least want.

I want to be careful here, because I have not read the survey data itself and I am not asserting that GMDSS fails wholesale under jamming. The report's claim, as summarized in its own announcement, is that these systems rely on satellite positioning and timing and that survey data exposes their vulnerability. That is a narrower statement than "the distress system stops working," and I am going to leave it at the narrower statement.

What to actually do with this

If you own or specify vessels, the useful output of this report is not the alarm. It is the inventory format. Somebody in your organization can build the equivalent plot for your own hulls, and the exercise is mostly a procurement records exercise rather than an engineering one. Which boxes take a GNSS feed? Which of them take it for position, which for time, and which for both? Which of those genuinely need it, and which acquired the dependency because the vendor's default configuration offered it?

That last question is the one with money attached, because a dependency that was never required is a dependency that can be specified away at the next refit at close to zero marginal cost. A holdover clock that free-runs on a decent oscillator through a multi-hour outage is not exotic hardware. Neither is a radar that will run standalone. In most cases what is missing is not the capability but the requirement, because nobody wrote the requirement down.

For everyone else, the transferable lesson is the one I keep coming back to on this beat. Interference is not an attack on a display. It is the removal of a shared input, and the blast radius is the set of everything that consumes that input, which is almost always larger than the set of things anyone remembers consuming it. I made this argument in the report on friendly jamming from the emitter's side: the jammer does not know whose receiver it reaches. The RIN report is the same observation seen from the receiving end, on a ship, with the equipment list written out.

What I did not verify

My primary source is the Section 4 extract of the RIN report, published as a PDF on the Institute's own content delivery server. I downloaded it and extracted the text directly rather than reading a summary of it. Everything I quote from the figure caption, and every system named in the seven category lists above, comes from that file. The category counts are my own tally of the printed entries and are not stated by the report.

I did not read the full report. It is available on the RIN's website behind a download form, and the Institute's site refused automated access from here, returning HTTP 403 to every request. So the extract is all I hold. Everything above that is not from the extract is from the RIN's own announcement text, which I read in full at two independent outlets that reproduced it, the Resilient Navigation and Timing Foundation and GPS World. Where I quote the director and Commodore Taylor, I am quoting that announcement as those outlets carried it, not the report body.

There are survey percentages circulating in coverage of this report, including a figure of seventy-five percent of respondents believing the situation is not improving. I could not open a source that stated it in a form I was willing to quote, so I have left every percentage out. The methodology figures I do use, more than one hundred sector experts and three hundred vessel captains, appear identically in both outlets I read.

One small discrepancy worth recording rather than smoothing over: the two outlets spell the name of the chair of the RIN Maritime Navigation Group differently, as Carionni-Burnett and Carrioni-Burnett. I have not resolved which is correct, so I have not quoted her, though the quote attributed to her in both versions is substantively identical.

Finally, I have not independently verified any specific vessel's equipment against this list, and the report does not claim to describe a particular ship. Figure 4.1 is a composite of what can be present on a modern vessel, hedged by the report's own asterisk footnote. Treat it as a map of the possible dependency surface, not as a bill of materials.

Sources

  1. RIN Maritime GNSS Interference Working Group, "Impacts of GNSS Interference on Maritime Safety," Royal Institute of Navigation, digital report published January 2026. Extract covering Section 4, "GNSS Connectivity Plot and Impacts of GNSS Interference on a Modern Vessel," pages 44 to 46, hosted on the Institute's content server. (Primary source. PDF downloaded and text extracted locally rather than read through a summary. Source of: the cover-page title, working-group attribution and January 2026 publication date; the Figure 4.1 caption quoted in full; the seven category names and every individual system named in them; and the asterisk footnote. The per-category counts are my tally of the printed entries, not the report's. The full report is behind a download form at rin.org.uk, which returned HTTP 403 to automated retrieval and which I therefore did not read.)
  2. Resilient Navigation and Timing Foundation, "GNSS Interference in Maritime – RIN Deep Dive," 26 January 2026. (Opened and read in full as raw page text. Reproduces the RIN's own announcement. Source of: the survey methodology of over 100 sector experts and 300 vessel captains; the unnecessary-dependencies passage quoted above; the GMDSS and SOLAS passage; and the quotes from the Institute's director and from Commodore James Taylor.)
  3. "RIN report: How GNSS interference harms maritime safety," GPS World, February 2026. (Opened and read in full as raw page text. Used as an independent second reproduction of the same RIN announcement, to confirm the quoted passages word for word against the RNTF version before quoting them. The two agree throughout except in the spelling of one name, noted above.)
Onur Oncer
Onur Oncer

U.S. Army combat veteran (Counter-IED / Electronic Warfare), peer-reviewed researcher in microwave spectroscopy, and founder & CEO of Shroombiosis. Consults on laboratory operations, AI, and supplement formulation.

← All reports