Signal authentication is not navigation integrity

No audio available for this content.

Interference and spoofing have become routine enough across European airspace that regulators keep revising their guidance to operators, most recently in July. The policy response has converged on authentication, and reasonably so. Galileo’s Open Service Navigation Message Authentication (OSNMA) passed its first year as an operational service in July 2026; receiver manufacturers are embedding it, and it is already mandatory for the European Union’s second-generation smart tachographs.

That is real progress, and the agency running the service is careful about what it delivers. In its own words, the service does not prevent spoofing or protect against jamming; it mitigates the impact of spoofing by letting systems identify unauthenticated navigation data. The distinction deserves more weight than it usually receives in procurement language. Authentication answers where a signal came from. Integrity answers whether the navigation solution in use right now should still be trusted.

Verification happens at moments; navigation happens continuously

Authentication is a periodic check. A receiver confirms provenance when the cryptographic material allows it, and between those confirmations it goes on computing, filtering, and delivering a position several times a second. Autopilots, timing distribution, weapons systems, and autonomous platforms consume that output continuously, not at authentication intervals.

Nothing about a later successful check reaches backward. A confirmation at one moment says nothing about the interval that preceded it, and it certainly does not undo an operational decision taken during that interval on a solution that had degraded. The system therefore needs to carry two distinct states, not one. Signal provenance is the first. Solution validity is the second, and it is the one that governs whether the output is safe to act on.

The gap between those two states reflects no defect in authentication. It is a property of any intermittent verification applied to a continuous process, and it must be managed as its own requirement rather than assumed away.

The checkbox problem

Program specifications increasingly carry a line requiring that equipment support signal authentication. As a procurement instrument, that line does very little, because it describes a capability rather than a behavior.

A specification that does not answer the following questions has not specified assurance. How long has the receiver been operating since its last successful verification, and does anything downstream know that? Against what independent evidence is the current solution being checked in the meantime? What happens when confidence in that solution falls, and who is told? Does the operator, or the autonomous function consuming the output, see a change in status, or only a position that looks the same as it did an hour earlier? Does the system enter a declared degraded mode, or does it keep presenting a confident-looking answer?

None of those questions is exotic, and none of them is answered by a checkbox.

Three things worth writing into requirements

First, a continuous integrity state rather than a binary flag. Authenticated or not authenticated is insufficient information for a system that must decide whether to act. What a consuming system needs is the age of the last successful authentication, the status of the source, the current integrity assessment, an expression of uncertainty, and a reason code when the solution has been downgraded. Each of those is producible, and each is useless if it stops at the receiver instead of propagating to whatever is making decisions.

Second, required behavior when the evidence runs out. Where independent evidence is insufficient to support the solution, the system should downgrade it, state the limits of its use, and where necessary decline to provide one at all. Abstention is a legitimate output and should be specified as such. It is also incomplete on its own: unless downstream software is prohibited from silently carrying forward the last valid value or substituting a nominal default, the platform declines and something further along quietly fills the gap, which reproduces the original risk with an extra layer of concealment.

Third, certification that tests the interval and not just the check. Acceptance testing should establish how the system behaves between authenticated moments: how quickly a degraded solution is identified, what the operation does during false alarms, whether the declared degraded mode engages, and whether downstream consumers honor an invalid navigation state or ignore it. Alongside that, someone needs to own the end-to-end requirement. Constellation operators, receiver manufacturers, platform integrators and mission owners each hold one piece of the assurance chain, and a requirement that belongs to all of them in general belongs to none of them.

What authentication is for

Cryptographic authentication is a significant improvement and the operators deploying it have been honest about its scope. It is not, and was never presented as, a complete navigation-assurance architecture. The next generation of positioning, navigation and timing requirements should specify not only whether a signal can be authenticated, but what the system is obliged to do whenever authentication alone can no longer justify continued trust in the solution built on it.