GNSS Outages in Defence: Why Recovery Matters as Much as Prevention
The interference has stopped. Your GNSS receiver has reacquired a signal. But is your defence network ready to trust its timing again?
GNSS outage recovery deserves the same attention as attack prevention. Defence timing and synchronisation must remain dependable during disruption and return to a trusted state afterwards.
For communications, sensor networks and command infrastructure, the question is practical: when can connected systems safely rely on that shared time again?
Why GNSS disruption is a defence timing problem
Global Navigation Satellite Systems (GNSS), including GPS, provide timing references as well as positioning. Defence systems can depend on this shared time to coordinate communications and align information across distributed infrastructure.
The UK Space Strategy, updated in September 2026, identifies jamming and spoofing in operational theatres and calls for layered, independent PNT capabilities. Its relevance extends beyond navigation: PNT also supports defence network interoperability.
Two threats require different responses:
- Jamming: interference that prevents or degrades reception of genuine signals.
- Spoofing: false signals that can mislead a receiver about position or time.
The engineering implication is that a timing source may become unavailable or remain available while supplying incorrect information. Recovery planning needs to address both.
Could a timing outage leave your defence systems out of step?
Explore how edgeTime supports timing resilience across secure communications, command infrastructure and distributed networks.
What happens to synchronisation during a GNSS outage?
A GNSS-disciplined clock uses satellite observations to correct a local oscillator. When reception is lost, suitable equipment enters holdover, maintaining time using that oscillator and, where available, its learned behaviour. Timing error then depends on the oscillator and holdover implementation.
Holdover buys time, but its useful duration depends on the accuracy the application needs. In one measurement reported in NIST’s study of GPS timing dependencies, a disciplined rubidium clock stayed within 1 microsecond for approximately 73 hours after its antenna was disconnected. This is a measured example, not a guarantee for all rubidium clocks or operating conditions.
There is also a dependency that can be overlooked: Precision Time Protocol (PTP) and Network Time Protocol (NTP) distribute time; they do not independently establish its correctness. A network using either protocol may still depend on GNSS upstream.
For defence teams, the practical question is how long each critical service can remain within its permitted timing error after losing a trusted reference.
Why a returning signal is not enough
GNSS timing failures do not always involve an attack or a complete loss of reception.
On 25–26 January 2016, incorrect UTC offset information broadcast by GPS satellites caused many thousands of GPS clocks to be wrong by approximately 13 microseconds. NIST documented erroneous information from 15 satellites. This was a timing anomaly, not a jamming incident.
The lesson for recovery design is clear: receiving a signal and validating the time it provides are separate tasks.
After disruption, a returning reference may disagree with a clock that has been operating in holdover. Teams therefore need an agreed method for checking that reference and correcting the difference.
An immediate correction is a clock step. A gradual correction is slewing. The chrony time-synchronisation documentation explains this distinction and cautions against clock steps once applications relying on continuously advancing time are running. Slewing avoids an instantaneous jump but takes longer to remove the offset. The appropriate behaviour depends on the equipment and application.
What should a defence GNSS recovery plan include?
NIST’s published Foundational PNT Profile treats recovery as an explicit part of resilience. It calls for verified recovery procedures, restoration within a predefined acceptable period and system acceptance testing.
Applying those principles to defence timing gives teams five practical checks:
| Recovery priority | What needs checking? | Why it matters |
|---|---|---|
| Holdover and time error | How long can each critical service remain within its permitted timing error without the main reference? | Establishes the usable window for continued operation. |
| Independent sources | Do primary and backup clocks share an antenna, reference or other failure mechanism? | Reveals dependencies that could affect both at once. |
| Returning GNSS signal | Does the recovered time pass stability checks and agree with an independent trusted reference where available? | Reduces the risk of accepting incorrect time. |
| Controlled re-synchronisation | How will the offset be corrected, and can connected applications tolerate the transition? | Helps avoid disruption as clocks return to alignment. |
| End-to-end validation | Are dependent systems within tolerance and operating correctly through repeated source changes? | Demonstrates recovery beyond the receiver itself. |
These are design considerations, not a universal defence specification. Acceptance thresholds must reflect the mission, architecture and equipment.
Do you know how your timing infrastructure will recover?
Our timing consultancy can help you review source dependencies, resilience requirements and distribution across your network.
Build recovery into the timing architecture
Independent timing sources can create options during an outage and provide a reference for recovery checks. For example, NPL operates service nodes in Reading and London that distribute time over dedicated fibre, traceable to UTC(NPL) and independent of GNSS. Availability and suitability still need assessing for each deployment.
For a connected defence site, terrestrial distribution may be an option. For a deployed platform, local holdover capability may carry more of the burden. The design should follow the operational environment.
edgeTime supports defence timing architecture, source strategy, distribution and monitoring, alongside consultancy on resilience and network dependencies.
To assess your requirements, ask: if GNSS becomes unavailable or untrustworthy, how long can our systems maintain acceptable time, and what evidence will confirm they have recovered?
Speak to an edgeTime timing specialist →
Frequently asked questions
What is GNSS outage recovery?
It is the process of restoring trusted positioning, navigation or timing services after disruption. For network timing, that includes validating the reference, correcting clock offsets and confirming that dependent systems are operating within their required limits.
How long can timing remain accurate without GNSS?
There is no universal duration. It depends on the clock, its holdover performance, operating conditions and the maximum time error the application can tolerate.
Does a GNSS receiver regaining lock mean the network has recovered?
Regaining lock confirms reception and tracking. Network recovery also requires confidence in the supplied time and verification that downstream clocks and applications have returned to acceptable operation.
Leave a Reply