GNSS spoofing detection looks for evidence that received signals or the navigation solution do not behave as expected. Different methods examine different things: signal power and correlation shape, consistency between measurements, agreement with an independent motion reference, or the directions from which signals arrive. Navigation-message authentication adds another kind of evidence. None of these checks is interchangeable with the others, and an alert is not automatically a corrected position.
For integrators, the useful question is not simply whether a product says “spoofing detection”. It is what the detector observes, what deception would disturb that observation, and what could remain consistent despite a false solution. This article explains that reasoning; the separate existing-receiver detection guide covers which inputs and integration work a proposed implementation requires.
Start with the observation, not the alarm label
A receiver can examine information that a downstream position-only application never sees. NovAtel, for example, describes its OEM7 detection algorithms as monitoring metrics at multiple stages of signal processing. Its documented result is a warning that the solution may be untrustworthy—not a blanket promise that the receiver continues producing the correct position. See NovAtel’s GNSS spoofing-detection description.
That distinction separates three questions: Was something suspicious detected? Is the navigation output still usable? What action should the host take? A product description that answers the first does not necessarily answer the other two.
The main evidence families can be compared on the same basis:
| Evidence family | What the detector compares | Why the result needs context |
|---|---|---|
| Signal power and correlation shape | Observed energy or tracking-peak shape against an expected signal model or reference | Multipath and interference can change these observations too; some false-signal conditions leave little distinctive distortion. |
| Measurement and navigation consistency | Ranges, time, position or motion against a prediction, redundant observations or a separate reference | A coherent false set can remain internally consistent. A reference with its own drift provides only a limited cross-check. |
| Spatial evidence | Measured signal arrival directions against expected satellite directions | The multi-antenna method discussed here requires suitable direction measurements and treatment of array orientation and angular uncertainty. |
| Navigation-message authentication | Supported navigation data against cryptographic authentication information | Authentication of a message is not verification of every received signal path or assurance of uninterrupted reception. |
These are evidence families, not a ranking of products. Sweden’s FOI similarly distinguishes information available to a standalone receiver from that added by antenna arrays, protected signals or other sensors in its GNSS jamming and spoofing detection recommendations.
Power and correlation shape: useful clues, different blind spots
Signal power is one clue. An unexpected increase can be suspicious, but a power threshold is not a universal authenticity test. It also responds to non-spoofing RF conditions, and a detector designed around conspicuous excess power does not cover every false-signal condition.
Correlation-shape monitoring looks more closely at how the received signal matches the receiver’s local ranging-code replica. When authentic and false components overlap, their combined correlation function can differ from the expected peak. Readers wanting the underlying mechanism can use the GNSS correlation and processing-gain explanation.
The original power-and-distortion monitoring research by Wesson and colleagues explains why the two observations complement each other. Power-only monitoring has limitations against low-power deception; distortion-only monitoring can lose its distinguishing evidence when one component dominates. The paper explicitly develops a detector under stated signal and threat assumptions. Its results are not a universal detection rate for other receivers or conditions.
Multipath can also distort the correlation function, as the original vestigial-signal defense evaluation demonstrates. Therefore, “distorted peak” is evidence to interpret, not a unique diagnosis of spoofing. Combining observations is useful precisely because an observation that is ambiguous on its own can become more informative alongside another.
Consistency: ask what is independent of what
A navigation check can reject an implausible position jump or compare measured ranges with values predicted by a model. Jeong’s original sliding-window spoofing-detection study, for example, compares measured and estimated pseudoranges over time. This is a particular research method, not evidence that every receiver implements it.
The important limitation is the reference. Measurements that agree with one another are not thereby proven authentic. A consistent false set may preserve the relationships being tested. Likewise, two calculations derived from the same suspect measurements are not fully independent evidence merely because they produce two outputs.
An independent sensor changes the comparison, but not into an unlimited guarantee. An inertial system predicts relative motion while accumulating error. Septentrio explains that a gradual false GNSS trajectory can remain inside an inertial system’s growing uncertainty, even when a sudden discrepancy would be detectable. Its GNSS/INS security discussion describes that distinction.
Consequently, a statement such as “cross-checked against INS” needs a time interval, an uncertainty model and a defined discrepancy test to be meaningful. It does not establish that the inertial sensor will identify every slowly developing error. Nor does a navigation jump by itself establish a hostile cause.
Arrival direction: test satellite geometry, not just signal strength
Spatial detection asks whether signals arrive from directions consistent with the satellites they claim to represent. This is a different question from using an array to suppress interference energy.
DLR’s original direction-of-arrival assisted detection research compares measured arrival directions with expected directions computed from satellite information. It also deals with array attitude and elevation-dependent measurement statistics. Those details matter: the expected direction has to be expressed relative to the measurement system, and angular errors are not identical for every observation.
The practical distinction is between having multiple antenna elements and having the measurements and processing required for this particular geometry check. Element count or a null-steering specification alone does not establish that a product performs direction-of-arrival spoofing detection. Conversely, spatial detection and spatial interference suppression can be complementary functions; one label does not specify the other.
Authentication answers a narrower, valuable question
Galileo OSNMA authenticates supported navigation-message data. The official Galileo service description defines that service; it is not a claim that all reception is protected from jamming or every form of deception. A cryptographically authenticated message and a trustworthy receiver position are related but different assurances.
For the received-path issue, the existing meaconing explanation covers why relaying a genuine signal differs from inventing its message. Authentication should therefore be evaluated alongside the relevant signal, timing and navigation checks, rather than treated as a replacement for all of them.
Read detection results as a set of trade-offs
A detector has to distinguish suspicious observations from legitimate variation. A useful evaluation therefore reports more than one successful demonstration:
- Missed detections: which defined deception cases failed to produce an alert?
- False alerts: how often did the same decision rule flag the specified clean or non-spoofing conditions?
- Time to alert: measured from which event, and at which output boundary?
The power-and-distortion paper reports results for its own experiment and decision rule. Borrowing its percentage for a different detector would remove the conditions that make the number meaningful.
Illustrative arithmetic, not a product result: one false alert in 50 clean trial windows is an observed fraction of 2% of those windows. It is not automatically a 2% probability per mission, per hour or per independent event. Window duration and dependence between observations matter. Likewise, zero alerts in a finite clean run does not prove a zero false-alert rate.
For time to alert, separate the detector’s internal decision from the host’s receipt and response. A rapid internal decision does not by itself establish when an application stopped using suspect data. Keep the event definition and the logged output boundary consistent when comparing two results.
This leads to a concrete selection method: first match the evidence family to the deception and operating conditions of concern; then compare missed detections, false alerts and delay under stated conditions; finally establish what the host actually receives and does. A long list of detector features cannot replace those three steps.
Connect the method to the equipment being selected
Use the existing-receiver guide to decide whether the proposed implementation reads a supported status, processes available measurements or needs additional acquisition hardware. Use this article to decide whether its evidence and demonstrated conditions address the problem you care about. These are different decisions.
The ResiNav product catalogue is the next equipment entry point for GNSS protection requirements. Compare the published record for the model under consideration; this explanation does not assign the research methods above to a ResiNav product or add an undocumented detector interface. Keep detection, interference suppression and the required host response as distinct items in the discussion.
NEXT STEP
Turn available platform information into an engineering review.
Use the Technology centre to frame the discussion, review relevant application scenarios, then send the available platform and receiver details for confirmation.