A position symbol can remain crisp while the information behind it becomes unreliable. That is the uncomfortable feature of navigation interference: the display may continue to look ordinary at precisely the moment when its relationship to the physical world needs to be questioned. A blank screen announces a problem. A plausible but incorrect answer can travel quietly through other systems.
On October 1, 2026, the UK's Maritime and Coastguard Agency published guidance on operating in degraded or denied Global Navigation Satellite System environments. It describes dependencies extending beyond a ship's position display to traffic management, communications and timing-dependent services, and encourages operators to examine their own dependencies and contingency arrangements. The document is maritime guidance, not proof that every vessel has the same vulnerabilities or that any proposed replacement is universally ready. The MCA's October 2026 guidance
The broader public-interest question is how a society should reason about a service whose outputs are embedded in so many activities. Satellite navigation provides positioning, navigation and timing, often abbreviated PNT. Losing one of those functions can affect another organization that never thought of itself as a satellite-service user. A port timetable, a tracking display and a synchronized record may share more infrastructure than their different appearances suggest.
This article explains that dependency problem at a high level. It does not provide instructions for generating interference, defeating receivers or operating an aircraft or vessel during an incident. Qualified personnel must use approved procedures and current official guidance. The fictional North Quay port and all numerical examples below are teaching constructions, not descriptions of an actual attack, accident or equipment specification. Sources were checked on October 31, 2026, with publication dates kept distinct from access dates.
Conceptual dependency map. It does not diagnose an incident or prescribe navigation procedures; actual systems vary.
Interruption and deception create different questions
Jamming and spoofing are often discussed together because both can undermine navigation information. At a conceptual level, jamming interferes with reception; spoofing introduces misleading information that may be accepted as genuine. Neither label should be assigned to a particular event solely because a map looks wrong. Equipment faults, configuration problems and other environmental effects also require consideration.
The distinction matters for the operator's information problem. An unavailable position tells the system that its ordinary input is missing. A misleading position can appear available and therefore continue to influence decisions. The two situations can produce different symptoms, and neither can be reduced to the number of satellites indicated on a screen without understanding what that indicator actually means.
Consider a fictional delivery vehicle whose location suddenly jumps outside a port. The observation establishes a discrepancy between the displayed position and other evidence. It does not, by itself, identify a transmitter, an actor or an intention. A responsible incident account separates what was observed from the explanation being investigated. That separation protects both safety analysis and public reporting from premature attribution.
The same discipline applies to a loss of reception. A service outage may be local to one installation, shared across a site or part of a wider regional disturbance. Investigators need enough context to distinguish those possibilities. The useful initial question is what functions became unreliable, over what interval and with what corroboration, rather than which dramatic label makes the event sound most consequential.
A resilient design acknowledges both missing data and data that may be misleading. It defines how uncertainty reaches downstream applications instead of allowing an old or suspect value to retain an appearance of freshness. This is a general information-quality principle, not a recipe for a particular navigation system. The appropriate response depends on the platform, task and approved operating arrangements.
For readers, the practical distinction is between availability and trustworthiness. A receiver that produces an answer is available in a narrow sense. Whether that answer is suitable for a particular use requires additional evidence about its quality and provenance. A dashboard that shows only whether data are arriving can therefore miss the question that matters most to the user of those data.
Draw the dependency map before buying a backup
North Quay has three displays in its control room. One shows vessel positions, another estimated arrival times and a third the timestamps of operational events. Staff describe them as separate systems because they came from different suppliers. A dependency review discovers that all three ultimately use a shared position-and-time feed. Three screens have provided convenience, not three independent references.
This is the first distinction worth making in any resilience discussion: duplication of presentation is different from diversity of evidence. Two applications can disagree because of different processing while sharing the same underlying error. They can also agree perfectly because both received the same misleading input. Agreement is reassuring only when the relationship between the sources is understood.
NIST's January 2023 revision of its foundational PNT profile presents a voluntary risk-management framework for organizations using positioning, navigation and timing services. It addresses dependencies in systems, networks and assets and recognizes disruptions and manipulation from different causes. The publication is a foundation for organizational and sector-specific work, not a universal performance specification for a receiver. NIST IR 8323 Revision 1
An original dependency map for North Quay would begin with the function the organization needs: knowing where a vessel is, ordering events, or coordinating an operation. It would then trace the information backward through applications, network services, clocks and external references. The point is to discover shared assumptions, including those hidden behind a vendor's convenient interface.
A backup can share more than a signal source. Two devices may rely on the same power supply, network switch, configuration process or maintenance team. A single error in those shared elements can affect both. Conversely, two technically different systems may still provide useful diversity if their failure mechanisms and operating constraints are understood. Counting boxes alone cannot answer the resilience question.
This exercise also identifies ownership. A navigation specialist may understand the receiver while an information-technology team manages the time distribution. If each assumes the other owns the end-to-end quality check, an important gap can remain. A dependency map should therefore connect functions to responsible roles as well as to equipment. The map becomes useful when someone can act on what it reveals.
Position, movement and time do not have identical tolerances
A public map can tolerate an error that would be unacceptable for a tightly constrained operation. A timestamp adequate for a visitor log may be inadequate for reconstructing the sequence of a fast event. The word accurate has little practical meaning until the task, scale and acceptable uncertainty are specified.
At North Quay, an arrival estimate might remain useful even if a vessel's position is not precise enough for close maneuvering. A historical logistics report might remain valid despite a brief timing interruption that prevents a different real-time process from continuing normally. A resilient organization should distinguish these uses rather than treating all PNT-dependent applications as equally demanding.
This distinction helps avoid two opposite mistakes. One is to continue every operation because some data remain available. The other is to assume that every activity must cease because a particular high-demand function is degraded. Appropriate decisions depend on approved task-specific limits and on knowing which information can still support which purpose.
A useful service description therefore includes more than a nominal position accuracy. It describes availability, continuity, uncertainty, freshness and the conditions under which those characteristics are expected. For timing, it should identify the relevant reference and the uncertainty accumulated during interruptions. For navigation, it should explain the operational context rather than implying that one number covers every movement and environment.
The arithmetic can be simple even when the engineering is difficult. Suppose a fictional clock accumulates a one-microsecond error each second after losing its reference, with a constant rate assumed only for illustration. After one minute the accumulated error would be sixty microseconds; after one hour it would be 3,600 microseconds, or 3.6 milliseconds. These are invented values, not a claim about a class of commercial clocks.
The example shows why the duration of an interruption matters. A backup that is suitable for a brief gap may not remain suitable indefinitely. It also shows why the application must define its tolerance before a supplier's holdover claim can be evaluated. An impressive-sounding duration without a stated error limit does not establish fitness for a particular task.
A warning is useful only if it reaches the decision
A receiver may detect a problem while the downstream application continues to display the last value without a visible qualification. In that situation, detection has occurred inside one component but has not yet protected the decision made by another component or person. Resilience depends on how quality information travels through the whole chain.
North Quay's fictional dashboard might show a vessel icon at its last confirmed position. That can be useful if the icon is clearly marked as stale and its age is visible. It can be misleading if animation or routine refresh makes it appear current. The same stored value can support or undermine understanding depending on how its status is communicated.
A quality flag also needs a defined meaning. Does it indicate that reception is unavailable, that an inconsistency was detected, that an estimate has exceeded its allowed age, or simply that a routine check has not run? Combining all of these into a single green or red light may be convenient, but it can remove information needed to choose the correct response.
Human factors matter here. An alert must be noticeable without requiring personnel to interpret an unfamiliar technical code during a demanding task. It must also avoid claiming more certainty than the detection method supplies. A message identifying suspect input is different from a message attributing deliberate interference. The first may be justified well before the second can be established.
The organization needs to know whether the warning reaches every dependent use. A tracking application may receive the quality flag while a separate logging service receives only coordinates and timestamps. An apparently minor interface choice can therefore preserve uncertainty in one system and erase it in another. Testing should examine the consumers of the data, not only the receiver's front panel.
This is why an end-to-end exercise can reveal weaknesses that component specifications do not. The exercise asks whether staff see the right status, whether dependent records retain it, and whether responsibilities are clear. It need not involve broadcasting interference or exposing live operations to danger. Authorized, controlled evaluation can focus on the information and decision chain without reproducing an adversary's methods.
The maritime problem is larger than a chart symbol
A vessel's navigation display is the obvious place to look for a positioning problem. The wider maritime system includes shore coordination, arrival management, tracking and records used by several organizations. A discrepancy that begins in one part of this chain can become confusing when different parties see different representations or updates at different times.
Imagine that North Quay's traffic display places a vessel near an entrance while the vessel's own crew has independent reasons to doubt that location. The port's schedule system may have already updated its expected arrival. A third organization may copy the same feed into a customer notification. Resolving the situation requires more than correcting one screen; it requires identifying which downstream conclusions relied on the suspect information.
The example is deliberately generic. It does not suggest that staff should follow an improvised navigation procedure. Its purpose is to show why communications and data lineage matter. A clear statement about the status of information can prevent another party from treating a provisional estimate as an independently confirmed position.
There is also a distinction between a vessel reporting its own position and an observer measuring a vessel through another means. When both are drawn on a shared map, their visual similarity can conceal different origins and uncertainties. A reader of the map may assume every symbol has the same evidential status unless the system explains otherwise.
The information retained after an incident should preserve that distinction. If a historical record merges several feeds without provenance, investigators may struggle to identify which observations were independent and which were copies. A polished combined track can then look more authoritative than the underlying evidence supports. Retaining source identity and quality status helps prevent that retrospective illusion.
For a port, the broader planning question is how to continue essential coordination when some inputs are degraded while respecting the limits of each activity. That question belongs to established maritime competence, approved systems and organizational planning. A public article can clarify the structure of the problem without replacing the procedures that qualified personnel must use in practice.
Aviation adds a network-capacity dimension
An aircraft's navigation capability is connected to the airspace system around it. A disruption can alter the kinds of operations available, increase communication demands and affect the workload of crews and controllers. Even when safety is maintained, the system may have less capacity to handle traffic in the usual way. Resilience includes this organizational consequence as well as the receiver's behavior.
EASA's July 3, 2026 announcement identifies Revision 4 of its GNSS-interference safety bulletin. The announced changes include pilot-controller phraseology, electronic-flight-bag integration, operational and training matters, and air-traffic capacity considerations. This article relies on the agency's summary of the update, not an independent interpretation of every provision in the bulletin. It does not turn the announcement into universal cockpit instructions. EASA's July 2026 bulletin update
The capacity issue can be understood through a fictional planning example. Suppose a service can normally support twelve movements in a planning interval but a degraded operating arrangement safely supports only eight. The shortfall is four movements for that interval. Maintaining the original schedule by ignoring the degraded condition would not restore capability; it would merely conceal the mismatch between demand and the available arrangement.
The figures are invented and do not describe an airport or air-traffic procedure. They illustrate why contingency planning needs demand management and communication, not just a technical backup. An organization must understand what service level remains feasible under its approved alternatives and how delays or diversions affect the rest of the network.
This also explains why local events can have consequences elsewhere. A change at one point can alter arrival times, crew plans and the availability of other resources. The navigation problem may be geographically bounded while its operational consequences travel through a network. Public reports should distinguish the area of suspected interference from the larger area experiencing indirect disruption.
For travelers, a delay caused by a precautionary operating change should not automatically be interpreted as evidence that an aircraft was uncontrolled. Equally, the absence of an accident does not mean that interference imposed no cost or workload. A careful account can recognize successful safety management while still describing the seriousness of the underlying disruption.
Coordination is a technical requirement with institutional owners
Different organizations can observe different parts of the same event. A receiver records an anomaly, an operator notes a service interruption, a regulator receives a report and a network manager sees wider patterns. If those records cannot be aligned in time and meaning, the shared picture can remain fragmented even when each organization has acted responsibly within its own remit.
The EASA–EUROCONTROL action-plan announcement in March 2026 describes coordinated monitoring, information sharing, operational guidance and assigned actions over different time horizons. The page carries a March 25 header and a March 26 dateline; this article refers to the month rather than pretending those timestamps are identical. The plan's aims are not represented as already completed improvements. The joint aviation action-plan announcement
For North Quay, coordination would begin with agreed vocabulary. A report of loss of position, inconsistent position and suspected interference should not automatically collapse into one category. The distinction can be retained while still allowing organizations to identify a possible common event. Consistent definitions make aggregate analysis more useful and reduce the risk of overstating certainty.
Shared records also need an account of their clocks. If timing itself is suspect, timestamps from affected systems may not align perfectly with independent records. Investigators should preserve the uncertainty rather than force every event into an exact sequence that the evidence cannot support. A reconstruction can be informative while acknowledging that some ordering remains unresolved.
Roles matter as much as formats. Who receives a report? Who assesses whether several reports concern the same event? Who communicates an operational advisory, and who has authority over spectrum investigation? A coordination plan should connect these tasks rather than assuming that sending a message into a general mailbox completes the response.
The benefits extend beyond major incidents. Repeated smaller anomalies can become visible when reports are comparable across organizations and time. Conversely, a growing number of reports may partly reflect improved detection or reporting rather than an equal growth in underlying events. Analysts need to distinguish those explanations before using a count as evidence of a trend.
Authenticating a message answers a specific question
Authentication is an important development because it allows a receiver to check something about the origin and integrity of information. It should nevertheless be described with the object of authentication intact. A statement about a navigation message is not automatically a statement that every possible error in a complete positioning solution has been eliminated.
EUSPA describes Galileo's Open Service Navigation Message Authentication service as enabling users to verify that navigation data come from Galileo and have not been modified. Its public explanation says receivers must implement the specified protocol and associated requirements; it identifies initial service as operational in July 2025. The service adds a layer of protection rather than making receiver integration irrelevant. EUSPA's OSNMA service explanation
The distinction can be explained without discussing attack methods. Imagine a signed document from a trusted institution. Verifying the signature answers a question about the document's origin and integrity. Whether the document is current, relevant to a particular decision and combined correctly with other information remains part of the application. Navigation systems likewise need end-to-end reasoning about the use of authenticated information.
Authentication also differs from availability. A system can be capable of recognizing authentic data while being unable to receive enough usable data at a particular moment. A protection against accepting altered information does not, simply by its name, guarantee uninterrupted reception. The procurement question should therefore specify which failure modes a feature addresses and which require other measures.
An organization should avoid treating a service declaration as proof that every installed device already uses the capability. Hardware, firmware, integration, configuration and application behavior can matter. The exact requirements belong in official specifications and qualified engineering review. The public-facing point is that the existence of a service and its effective use in a particular installation are separate facts to verify.
This is also a reason to avoid a binary narrative in which a navigation system is either completely vulnerable or completely protected. A new capability may reduce some risks while leaving others to be managed through diversity, monitoring and operating arrangements. Accurately describing its scope gives the improvement credit without encouraging dependence on a protection it was never claimed to provide.
A diverse reference still has limitations
The phrase independent backup can sound like a complete solution until the new reference's own constraints are examined. A source may be independent of satellite reception but depend on communications infrastructure. Another may operate locally but accumulate error over time. A useful alternative is one whose characteristics fit the task, not merely one whose technology has a different name.
Consider North Quay's hypothetical choice between a local timing reference and a remotely delivered timing service. The local reference may remain available during a communications outage but need its accumulated uncertainty tracked. The remote service may offer access to another reference while sharing a network dependency with other critical applications. Neither is universally superior; the decision depends on the failure scenarios and required performance.
The same logic applies to position information. An alternative observation can provide a valuable cross-check within its coverage and operating conditions. It should not be promoted as a universal substitute outside those conditions. The point of diversity is to avoid relying on the same vulnerable assumption everywhere, while understanding the different limitations introduced by the alternative.
Correlation is the central issue. If two sources tend to fail for the same reason, their apparent redundancy may provide less protection than expected. If they fail differently, disagreement can become useful evidence that deserves investigation. But disagreement does not automatically identify which source is correct. A system needs an appropriate way to handle uncertainty rather than a simplistic majority vote among correlated inputs.
A numerical illustration makes the common-mode issue clear. Suppose two fictional displays each have a ten-percent chance of being affected by a particular event because both use the same upstream feed. If their failures are perfectly linked, the probability that both are affected is ten percent, not one percent. Multiplying probabilities would require independence that this example explicitly lacks.
These numbers are invented, not reliability estimates for navigation equipment. The lesson is mathematical: independence is an assumption that needs evidence. A procurement claim of two independent systems should therefore be examined through architecture and failure mechanisms, not accepted merely because two product names appear on an invoice.
Training should include uncertainty, not only alarms
Personnel can be trained to recognize a loud failure indication and still be poorly prepared for conflicting but plausible information. An exercise should therefore examine how the organization communicates uncertainty, maintains appropriate task boundaries and records what it knows. The aim is competent handling of degraded information, not confidence that every anomaly will arrive with a convenient label.
At North Quay, a tabletop exercise could give different teams different views of the same fictional event. One team sees stale position data, another a timing discrepancy, and another a customer-facing delay. The useful outcome is whether they identify dependencies and coordinate their understanding. This description is an organizational exercise concept, not a live navigation procedure or interference-generation plan.
The exercise should preserve role boundaries. A communications team does not become a navigation authority because it receives a screenshot. A technical team does not gain operational command merely because it understands a sensor. Effective coordination lets each role contribute its evidence while the designated authority makes decisions under the organization's approved arrangements.
Training also needs to address recovery. When an input returns, personnel should know how the organization determines whether it is suitable for its intended uses again. An apparent return to normal presentation may precede confidence in all downstream records. Some applications may need reconciliation, and historical data may need to remain marked as uncertain rather than silently rewritten.
The FAA's GNSS interference resource page, updated December 8, 2025, directs US operators and pilots to relevant information and explicitly warns that documents may change between updates. It distinguishes official FAA material from non-FAA information supplied for reference. That is a useful reminder that training and operating documents require version control, not reliance on a bookmarked page assumed never to change. FAA's interference resource guide
A good exercise ends with specific organizational findings: an unclear responsibility, a quality flag lost at an interface, an outdated contact route or a recovery criterion that was never documented. The value comes from correcting those findings and checking the correction. A successful drill photograph is much less informative than evidence that the identified weakness no longer persists.
Reporting without inventing an attacker
Public attention often moves quickly from a navigation anomaly to an attribution claim. The temptation is understandable: deliberate interference has serious implications. But an accurate report should distinguish direct observations, technical interpretations, operational consequences and attribution. Each level requires its own supporting evidence.
A vessel's displayed position being inconsistent with its known surroundings is an observation. Several nearby receivers reporting related anomalies may support a broader interpretation. Establishing the source, intent or responsible actor requires additional investigation that a public map alone may not provide. The article should not collapse these stages simply because one explanation seems plausible in a tense region.
This discipline also protects useful reporting from becoming weaker through overstatement. A clearly documented disruption remains important even if the responsible actor is unknown. Insisting on an immediate attribution can distract from the practical evidence about affected functions and the measures needed to manage risk. Uncertainty about cause does not require uncertainty about every observed consequence.
In March 2025, IMO, ICAO and ITU jointly urged states to protect satellite navigation from harmful interference. Their statement called for resilience, conventional contingency infrastructure, cross-authority cooperation and reporting mechanisms. This is a documented institutional response to the problem, not a source for attributing every subsequent event to a particular state or organization. The joint UN-agency statement
A useful public incident summary can state what was affected, the evidence window, the confidence in the classification and the status of the investigation. It can distinguish observed service interruption from potential consequences. Saying that interference could contribute to an unsafe situation is different from claiming that a particular accident was caused by interference without an investigation supporting that claim.
Privacy and security also matter. Public reporting need not expose sensitive operational details or personal records to be informative. Aggregate patterns, bounded case descriptions and clear methodology can support understanding while detailed evidence goes to authorized investigators. The goal is accountable reporting, not publication of everything a system recorded regardless of consequence.
Procurement should ask for evidence of behavior
A specification that asks only for nominal accuracy risks buying a device rather than a usable resilience arrangement. North Quay's hypothetical procurement team would get a clearer answer by describing the functions that must be supported, the relevant operating conditions and the expected behavior when information becomes unavailable or suspect. Suppliers could then explain the scope of their evidence.
Claims should be separated into demonstrated performance, modeled expectations and planned capabilities. A laboratory demonstration under a defined condition is valuable, but it should not become proof of performance under every condition at the installation site. A feature on a roadmap should remain a future feature until delivery and verification establish otherwise.
The evidence package should describe how quality status is exposed to dependent applications. If a component can detect an anomaly but the integration discards that status, the installation may not deliver the advertised benefit. Acceptance testing therefore needs to include interfaces and user presentation, with appropriate authorization and safeguards, rather than examining only a standalone device.
Maintenance belongs in the decision as well. A system can lose its intended resilience through undocumented configuration changes, expired support, broken monitoring or staff turnover. The organization should understand who maintains the relevant information, how changes are recorded and how the end-to-end arrangement is rechecked after significant modifications.
A useful contractual discussion can focus on observable behavior without demanding impossible guarantees. What does the system report when it cannot support a stated requirement? What evidence establishes recovery? Which assumptions about power, communications and external services are necessary? How are updates documented? These questions are concrete enough to evaluate and more useful than a promise that a product is interference-proof.
Finally, the business case should include the cost of degraded operation, not just the cost of an outage at the receiver. Reduced capacity, delayed coordination, uncertain records and recovery work can all matter. Their importance varies by application. The point is to examine the service as a whole so that resilience investment follows the organization's real dependencies rather than the most visible equipment cabinet.
The archive must retain uncertainty too
A live display can be corrected quickly while an exported record preserves the earlier error indefinitely. North Quay's fictional staff might resolve an arrival discrepancy during a shift, yet the daily spreadsheet, customer message and later performance report could still contain the original estimate. Recovery therefore includes the information already distributed, not only the current screen.
This does not mean erasing the initial record. An investigation may need to know what personnel saw at the time, even when that information was wrong. A useful archive distinguishes the originally received value, its quality status and any later correction. Replacing the old value without a trace can make retrospective analysis look tidier while obscuring the actual decision environment.
Imagine that an event was recorded at 10:00 by a clock later found to have uncertain synchronization. Another independent record places it within a broader interval. The honest reconstruction may retain that interval rather than assign a falsely exact time. Precision in a stored format should not be mistaken for precision in the underlying observation.
The same principle applies to positions. A coordinate with many decimal places can be inaccurate or derived from a suspect source. Copying it into a database does not improve its evidential quality. Metadata describing source, age and uncertainty should remain associated with it wherever the record is used for a consequential analysis.
Organizations should therefore consider the full lifecycle of PNT-dependent information: acquisition, use, distribution, correction and retention. A failure at any stage can change what later readers believe happened. Preserving uncertainty is not an admission that records are useless. It is what allows investigators, analysts and affected parties to use them at the level of confidence the evidence genuinely supports.
Preserve what the evidence can support
Civil navigation has benefited from convenient, widely available satellite information. The task now is to keep convenience from hiding dependence. A position, velocity or timestamp should arrive with enough context for its users to understand whether it remains suitable for the decision they are making. That requirement becomes especially important when one value is copied into many systems.
The strongest resilience story is therefore not that every threat has been defeated. It is that an organization knows its dependencies, can recognize meaningful degradation, has appropriately evaluated alternatives and can manage the consequences within approved arrangements. These are capabilities that can be examined and improved without pretending uncertainty has disappeared.
For North Quay, success would mean that a suspect input does not silently become a confident arrival estimate, an authoritative historical record and an apparently independent second opinion. It would mean that each application preserves the information's status and that responsible people understand what follows from it. The same principle applies beyond the fictional port wherever PNT information travels through an organization.
New authentication services, better monitoring and coordinated guidance can all contribute. Their value is clearest when each is described at its actual scope. A message-authentication capability should be credited for the question it helps answer. A contingency reference should be judged within its coverage and uncertainty. An action plan should be evaluated through implementation rather than its announcement alone.
The public should be able to recognize both progress and limits. Navigation resilience is not a reason to abandon satellite services, nor a reason to accept every displayed coordinate without question. It is the work of maintaining a defensible connection between information, physical reality and the decisions built on that information, including the moments when the connection is uncertain.