Join our Newsletter — 33% off our NHI Course
Home› Guides› GNSS Spoofing and Jamming Guide: Detecting Interference and…
Guide OT & IoT Security

GNSS Spoofing and Jamming Guide: Detecting Interference and Building Resilient Positioning and Timing

PDF for newsletter subscribers · free to read online

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 11 min read
On this page

Satellite positioning and timing signals are so weak at the Earth's surface that cheap transmitters can block them and more capable ones can replace them with false positions and times. GNSS (GPS, Galileo, GLONASS and BeiDou) underpins aircraft navigation, ship positioning, telecom and power grid timing, financial timestamps and logistics tracking, and widely reported interference has turned a theoretical risk into an operational one for airlines and shipping. CISA states plainly that GPS can be disrupted or spoofed and that this is becoming easier. This guide explains jamming and spoofing at a defensive level, where they show up, how to detect them and how to build positioning and timing that degrades safely. It is for OT and network engineers, timing and infrastructure owners, and security teams in aviation, maritime, energy, telecom and finance. It does not describe how to build or operate interference equipment.

Key takeaways

  • Jamming denies, spoofing deceives: jamming causes loss of fix that receivers notice, while spoofing feeds a plausible but false position or time that systems may accept silently.
  • Timing users are exposed even if nothing moves: data centres, telecom networks, power grid synchrophasors and trading systems that take time from GNSS can drift or jump when the signal is attacked.
  • Treat GNSS as an untrusted input: cross-check it against inertial, terrestrial, network and other constellation sources, and alert when they disagree.
  • Authentication is arriving, slowly: Galileo OSNMA Initial Service was declared operational on 24 July 2025 and authenticates the navigation message, but it does not stop jamming and needs receiver support.
  • Use the government frameworks: NIST IR 8323 Rev. 1 applies the Cybersecurity Framework to PNT, and DHS and CISA publish a Resilient PNT Conformance Framework for receivers.

How the attack works

GNSS satellites broadcast from about 20,000 km, and their signals arrive below the thermal noise floor. A receiver recovers them only because it knows the spreading codes. That design creates three broad kinds of interference.

TypeWhat happensTypical receiver symptomWho notices
JammingRadio energy in the GNSS bands drowns the real signalsLoss of satellites, rising noise, no fix or degraded accuracy, integrity alarmsUsually the operator: the system reports it has lost GNSS
SpoofingCounterfeit GNSS-like signals are transmitted so the receiver computes a false position or timePosition jumps or slow drift, implausible speed, time steps, sometimes after a period of jammingOften nobody, unless position or time is cross-checked
Meaconing (replay)Genuine signals are recorded or relayed and rebroadcast with a delayPosition appears where the relay antenna is; time offsetHard to see without authentication or independent sources
Unintentional interferenceFaulty equipment, personal privacy devices in vehicles, test transmissions, solar weatherSimilar to jamming, often local and repeatableSpectrum monitoring, regulator investigations

In ATT&CK for ICS terms, a spoofed position or time feeding a control or monitoring system is a form of T0832 Manipulation of View: operators see a false picture of the process. Interference may be deliberate (military electronic warfare, criminal cargo theft, privacy jammers in vehicles) or accidental, and the defensive response is largely the same. In the United States, operating, marketing or selling jammers is prohibited under federal law with no exemption for business or vehicle use, and penalties include fines, equipment seizure and criminal sanctions.

Where it shows up

  • Aviation: aircraft can lose GNSS-based navigation and approaches, and systems that depend on GNSS position can be affected. EASA has issued, and repeatedly revised, Safety Information Bulletin 2022-02 on GNSS outages and alterations, most recently in July 2026. Pilots in US airspace can file a GNSS anomaly report with the FAA. See the Aviation Cybersecurity Guide.
  • Maritime: a wrong GNSS position can feed ECDIS and be broadcast through AIS, which raises navigation risk in narrow or busy waters. See the Maritime Cybersecurity Guide.
  • Critical timing: mobile networks, power grid phasor measurement units, data centre time servers and broadcast networks discipline their clocks from GNSS. A spoofed time can step clocks, break time-based authentication and certificate validity checks, and corrupt event ordering in logs.
  • Financial services: trading venues and firms timestamp orders against UTC, often from GNSS-disciplined servers; time errors affect regulatory reporting and audit trails.
  • Logistics and fleet tracking: criminals use jammers to hide stolen vehicles and cargo from trackers. See the Cybersecurity for Logistics and Shipping Guide.
  • Drones: uncrewed aircraft rely heavily on GNSS for navigation and geofencing. See the Drone and Counter-UAS Security Guide.

Impact

The impact depends less on the signal and more on how the dependent system behaves when GNSS is wrong. Three questions decide it: does the system know GNSS is degraded, does it have an independent source, and does it fail safe or fail silent?

  • Safety: wrong position in aviation and shipping is a direct safety hazard, especially where crews have come to rely on GNSS as primary and conventional aids have been withdrawn.
  • Availability: timing loss can cascade: base stations lose synchronisation, grid protection that compares phase angles misbehaves, and distributed databases reject writes.
  • Integrity and evidence: wrong time breaks log correlation, Kerberos and TOTP validation windows, certificate checks and legal timestamps, which harms both operations and forensics.
  • Persistence of effects: some receivers may retain bad time or navigation data after a spoofing event and may need a reset before they work properly again.

Detection

SignalWhat it suggestsWhere to collect it
Carrier-to-noise density (C/N0) drops across all satellites at onceJamming nearbyReceiver diagnostics, timing server SNMP or syslog
Unusually uniform or high signal strength across satellitesPossible spoofing (one transmitter, many simulated satellites)Receiver diagnostics
Position or time disagrees with inertial, odometry, radar or terrestrial navigationSpoofing or meaconingNavigation system integrity monitors, ECDIS, flight management alerts
Time server offset against other references (PTP grandmasters, NTP peers, a second constellation)Time spoofing or receiver faultTime monitoring, clock comparison dashboards
Sudden time step, week rollover anomaly or leap second errorSpoofing or bad dataNTP and PTP logs, application logs
Authentication failure on Galileo OSNMANavigation message not from the system or modifiedOSNMA-capable receivers
Fleet-wide pattern: many assets report anomalies in one areaRegional interferenceFleet telematics, AIS analytics, crowd-sourced interference maps

CISA lists resources that help with detection, including the Epsilon spoofing-detection algorithms, the PNT Integrity Library and an RF Interference Best Practices Guidebook. Feed receiver and time-server telemetry to the SOC so a sudden offset is investigated like any other security event; see the OT Network Security Monitoring Guide.

Useful metrics:

  1. Percentage of GNSS-dependent systems inventoried with a named fallback source.
  2. Holdover time each critical clock can sustain within its accuracy requirement, tested rather than quoted.
  3. Number of GNSS anomaly events per month by site or route, with mean time to detect.
  4. Percentage of timing servers with at least two independent references and offset alerting.
  5. Percentage of receivers on current firmware and on a resilience-assessed allow list.

Prevention and hardening

Decide what level of resilience you need

Use caseMinimum approachHigher assurance
Enterprise IT time (logs, authentication)Several NTP sources, not all GNSS-derived; alert on offsetLocal stratum-1 servers with holdover oscillators and diverse references
Telecom and grid timingGNSS-disciplined clocks with rubidium or OCXO holdover, PTP distribution, offset monitoringTerrestrial time from a national timing service over fibre, multi-band receivers, anti-jam antennas
Vessels and aircraftCross-check GNSS with inertial and conventional aids; crew procedures for loss and spoofingMulti-constellation, multi-frequency receivers with authentication; controlled reception pattern antennas
Fleet and asset trackingJamming detection that raises an alert, cellular positioning fallbackTamper and jamming reports to a monitoring centre with response procedures

Steps

  1. Map dependencies: list every system that takes position or time from GNSS, including hidden ones such as building management, cameras and network appliances. NIST IR 8323 Rev. 1 structures this as a CSF profile.
  2. Set requirements: define for each system the accuracy it needs and how long it must keep running without GNSS.
  3. Add independent sources: inertial navigation, terrestrial time over fibre, a second constellation and frequency, or network time from a trusted provider. No single backup is enough for safety-critical use.
  4. Harden receivers: choose receivers assessed against the Resilient PNT Conformance Framework, keep firmware current, enable plausibility checks and OSNMA where supported, and reject large time steps.
  5. Site antennas well: place antennas with a clear sky view away from roads and car parks, use anti-jam or controlled reception pattern antennas for critical sites, and protect antenna cabling physically.
  6. Write procedures and rehearse: crews and operators need clear steps for loss of GNSS and for suspected spoofing, including how to revert to other sources and how to report.
  7. Test safely: test holdover and failover by disconnecting the antenna or using a lab simulator in a shielded environment. Never transmit GNSS signals over the air without regulator authorisation.

Where identity fits

Time is a dependency of authentication. Kerberos tickets, TOTP codes, SAML assertions, JWT expiry and certificate validity all assume correct clocks, so a time spoofing event can cause mass authentication failures or extend the life of expired credentials. Include time sources in identity infrastructure risk assessments and protect NTP configuration on domain controllers. See the Certificate Revocation Guide for why short certificate lifetimes make correct time even more important.

Common failure patterns

  • Hidden GNSS dependencies: a network appliance, camera system or time server takes GNSS time without anyone recording it, so it is missing from the risk assessment and the fallback plan.
  • Backup that shares the weakness: two NTP servers that both discipline from GPS antennas on the same roof are one source, not two.
  • Holdover quoted, never tested: datasheet holdover figures assume stable temperature and a healthy oscillator; real holdover is often shorter.
  • Silent acceptance of time steps: clients configured to accept any correction will jump hours or years when a spoofed time arrives, breaking authentication and logging.
  • Procedures written for jamming only: crews and operators know what to do when GNSS disappears but not when it confidently reports a wrong position.
  • Over-the-air testing: transmitting test signals without authorisation causes interference to others and is unlawful in many jurisdictions; use cabled simulators or shielded rooms.

Lessons from incidents

NHI Mgmt Group's breach database does not hold a GNSS interference incident, so this section draws on the official record. CISA's own framing is that disruption and spoofing are getting easier, and US aviation reporting forms now ask pilots not only for position errors but for clock discrepancies, diversions and crew workload, which reflects how interference shows up in practice. The common lessons from public reporting are consistent: systems that alert on GNSS loss are manageable, systems that silently accept a false position or time are dangerous, and crews or operators who have rehearsed fallback procedures cope far better.

Framework mapping

FrameworkReferenceHow it applies
NIST IR 8323 Rev. 1Foundational PNT ProfileIdentify, protect, detect, respond and recover for PNT users
NIST CSF 2.0ID.AM-05, ID.RA-01, PR.IR-03, DE.CM-09, RS.MA-01Prioritise PNT-dependent assets, record PNT weaknesses, resilience mechanisms, monitoring, coordinated response
NIST SP 800-53 Rev. 5SC-45, SC-45(1), CP-2, CP-8, SI-4Time synchronisation with authoritative sources, contingency planning, communications alternatives, monitoring
MITRE ATT&CK for ICST0832 Manipulation of View, T0830 Adversary-in-the-MiddleFalse position or time presented to operators and control systems
US Executive Order 13905Responsible use of PNT servicesPolicy basis for the NIST profile and DHS conformance work

Practitioner checklist

  • Inventory every system that uses GNSS for position or time, including network and building equipment.
  • Define accuracy and holdover requirements for each and test that they are met with GNSS disconnected.
  • Provide at least one independent position or time source for every critical system.
  • Configure time servers to reject large steps and alert on offset against other references.
  • Send receiver and time-server diagnostics (C/N0, satellite count, offset) to monitoring.
  • Prefer multi-constellation, multi-frequency receivers with OSNMA support and current firmware.
  • Write and rehearse procedures for GNSS loss and suspected spoofing, including reporting routes.
  • Include time sources in identity and PKI risk assessments.

Standards and references

Related NHI Mgmt Group resources: Maritime Cybersecurity Guide · Aviation Cybersecurity Guide · OT Security Guide · Drone and Counter-UAS Security Guide

PDF for subscribers

Take this guide with you

Every section, table and checklist in one PDF, with links to the sources and related guides. Subscribe to our weekly NHI & AI Identity Journal and we’ll email you a download link.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org

PDF Downloads for Newsletter Subscribers

Get the guide

Enter your details and we’ll email you a download link.

The full guide is free to read online. The PDF is a thank you for subscribing.

Fill in all fields marked * and tick the PDF box to continue.