Resilient Position, Navigation, and Timing

Where compatible authentication services are available, GNSS receivers used for spacecraft position, navigation, and timing (PNT) must authenticate the navigation information and its asserted GNSS system source before treating that information as trusted. Navigation-message authentication must not be treated as complete protection against spoofing because it may not authenticate the ranging signal or prevent all replay, meaconing, or signal-manipulation scenarios. Authenticated GNSS information should therefore be combined with PNT integrity monitoring and alternate navigation or timing sources appropriate to mission risk. The spacecraft must maintain a fault-tolerant authoritative time architecture capable of maintaining time within mission-defined accuracy and uncertainty limits when the primary source is degraded, rejected, or unavailable. The architecture should support the time-dependent cryptographic controls, command sequencing, telemetry correlation, fault-management logic, and other functions that rely on synchronized time. Each onboard processor must synchronize its internal clock to the authoritative time source whenever the measured time difference exceeds a threshold defined in the flight software (FSW), preventing clock drift from accumulating to levels that corrupt time-dependent functions. Where SpaceWire is used to distribute time, the spacecraft must implement the mission-defined synchronization protocol and achieve the accuracy required by the functions that consume that time. An accuracy of approximately one microsecond should be applied where required by the mission architecture and verified for the applicable SpaceWire nodes and operational configurations.

Sources

  • CCSDS 301.0-B-4 — Time Code Formats
  • CCSDS 500.0-G-4 — Navigation Data—Definitions and Conventions
ID: CM0048
Tier: I
Onboard SV CM 
Created: 2022/10/19
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should address resilient position, navigation, and timing (PNT) as a system-level security and reliability requirement, specifying that GNSS receivers incorporate signal authentication capabilities where such capabilities are available and compatible with the mission's GNSS signals, and that the authentication mechanism's coverage of both signal content and transmitter identity be documented and evaluated. Requirements should mandate a fault-tolerant authoritative time architecture, specifying the backup time sources, failover/voting logic, and maximum allowable time error under degraded conditions, with the architecture documented as a security engineering deliverable given the dependency of cryptographic and command authentication functions on time accuracy. Contract language should require that FSW-defined clock synchronization thresholds and SpaceWire time synchronization protocol selections be documented and approved before flight software integration, with deviation from approved parameters treated as a configuration change. Evaluation criteria should assess offerors' proposed PNT architecture for resilience against GNSS spoofing and signal denial, their fault-tolerant time source design, and their demonstrated experience with precision time synchronization in space applications. Verification should include testing of GNSS authentication behavior against applicable altered, unauthenticated, stale, and replayed navigation information; testing of the residual spoofing scenarios not prevented by the selected authentication service; failover and holdover testing of the authoritative time architecture; and measurement of synchronization accuracy for processors and SpaceWire nodes subject to mission timing requirements.

Pre-Operations Developer/Supplier

GNSS receiver selection must evaluate the authentication services supported by the applicable GNSS constellation and the receiver’s implementation of those services. For missions where PNT integrity is security-relevant, compatible navigation-message or signal-authentication capabilities should be included where available, together with the trusted time, cryptographic material, key-update, and service-status functions required for their secure operation. The authoritative time architecture should be designed with redundancy at both the source and distribution levels, providing at least one backup time reference capable of maintaining acceptable accuracy during periods when the primary GNSS-derived time source is unavailable due to signal denial, spoofing detection, or equipment fault. FSW clock synchronization logic must define explicit thresholds for when resynchronization is triggered, the maximum acceptable time step that can be applied in a single correction to avoid disrupting time-dependent processes, and the behavior of time-dependent functions during periods when the authoritative source is unavailable or its integrity is uncertain. For spacecraft utilizing SpaceWire networks, the time synchronization protocol and distribution master must be selected and configured during the network architecture design phase, with the target synchronization accuracy of approximately one microsecond verified through hardware-in-the-loop timing measurements rather than assumed from protocol specifications alone. The security implications of time manipulation must be addressed in the threat model, including the consequences of an adversary successfully spoofing the GNSS time signal to introduce clock errors that corrupt cryptographic validity windows, command sequence timing, or telemetry correlation.