Does Galileo OSNMA Replace GNSS Anti-Jamming Hardware?

Galileo OSNMA is not a replacement for GNSS anti-jamming hardware. It gives a suitably implemented receiver a way to authenticate particular Galileo navigation-message data. It does not remove interference from the RF reception path. For a buyer, the useful choice is whether the project needs data authentication, interference mitigation, or both—not which label sounds more secure.

This guide is for system integrators and equipment buyers deciding whether to enable a receiver feature, change receiver configuration or evaluate a separate protection product. It explains the purchase boundary without assuming that a ResiNav model implements OSNMA.

What does OSNMA authenticate?

Open Service Navigation Message Authentication checks that supported navigation data originates from Galileo and has not been altered. EUSPA identifies the current service with Galileo I/NAV data and authentication information carried on the E1-B signal component. Its roadmap distinguishes this from protection at the pseudorange level. An authenticated message is therefore not, by itself, a certificate for every ranging measurement or the complete position, velocity and time solution. Read EUSPA’s service and scope explanation.

To understand why authentic message content can still arrive through a misleading signal path, read the explanation of GPS meaconing and relayed-signal timing.

A multi-constellation receiver can use observations from several systems. Do not treat a Galileo authentication status as proof that every GPS, BeiDou or GLONASS input has also been authenticated. Compare the receiver’s actual solution policy: which inputs it accepts, which it excludes and what status it exposes to the host.

RF receptionMitigate specified interference in the reception path.

Navigation-message dataVerify supported Galileo data using an OSNMA-capable implementation.

Application decisionUse documented status and validity rules to decide whether to use the output.

When can OSNMA change the purchase?

The European GNSS Service Centre FAQ explicitly states that OSNMA does not protect against jamming or prevent every form of spoofing. If the existing receiver has a documented OSNMA implementation, enabling and integrating that feature may address the authentication requirement without buying another antenna. If reception is being disrupted by interference, authentication alone does not address that RF problem. The existing monitoring-versus-protection guide addresses the separate choice between observing interference and mitigating it.

Layered implementations exist: Septentrio’s interference documentation distinguishes its RF mitigation from data authentication. That is an example of one manufacturer’s design, not evidence of ResiNav compatibility with its receivers.

“Supported” and “authenticated now” are different

Galileo reception alone does not establish an OSNMA implementation. The GSC identifies additional receiver processing, cryptographic material and time-synchronization requirements. Compare the exact receiver/firmware configuration rather than buying from a constellation logo. The service being freely accessible does not establish that a particular receiver option, implementation or integration service is free.

A useful documented example is u-blox’s configuration and verification application note, R03. It describes key and trusted-time assistance, a setting that restricts the solution to signals with authenticated navigation data, and distinct authentication status messages. In its documented NMA fix status, “Unknown” means verification cannot be performed; it does not imply spoofing. These semantics belong to that implementation, not to every receiver.

That distinction affects procurement: a system that requires authenticated data only needs a defined response when authentication is unavailable. Continuing with a broader navigation solution and refusing an unauthenticated solution are different operating policies. Choose the policy that meets the application’s requirement, and ensure the host can distinguish it from ordinary fix validity.

For example, an integrator comparing two receiver offers should not accept “Galileo supported” as an answer to “Can our controller tell whether authenticated data is being used?” A documented authentication status and solution policy may change the shortlist even when both receivers track the same band. Conversely, an authentication requirement alone does not justify buying an external anti-jamming terminal.

Does OSNMA require a live internet connection?

Do not add a permanent internet connection solely because the receiver uses Galileo OSNMA. The authentication data are broadcast with the Galileo signal; internet access is also used to obtain trusted cryptographic material. The buying decision is whether the offered receiver is correctly provisioned and can maintain authentication under the intended operating conditions—not whether every machine has a modem.

The GSC service description distinguishes initial installation of certified cryptographic material from later key renewal. It describes renewal through the signal in space or retrieval from the official websites. This provides more than one maintenance route; it does not establish how an unspecified receiver implements them.

Separate three parts of the order. Receiver implementation: an enabled, documented OSNMA function. Commissioning: verified trust material installed through the receiver’s supported process. Operation and maintenance: a documented time-synchronization and key-update approach that works for the platform. An E1 antenna listing supplies none of these receiver functions by itself.

The official Internet Data Distribution interface distributes public keys, Merkle-tree material and certificates. Access requirements differ between the GSC and EUSPA interfaces. Access to those materials is a provisioning route, not proof that each installed vehicle needs its own continuous internet subscription.

The GSC OSNMA FAQ also identifies receiver time synchronization and storage integrity as requirements. Thus, “preloaded keys” alone is not a complete offline specification. In a hypothetical fleet order, a documented receiver commissioned at a connected workshop may avoid a modem bought only for that initial task. A different implementation that relies on a network for a required operating function changes the order. These are conditional scope examples, not approved receiver configurations.

OSNMA being freely accessible does not make receiver options, commissioning or supplier maintenance free. Keep those charges separate from the Galileo service itself. If the platform also needs RF interference protection, continue to the published product comparison below for that separate item; buying a protection terminal does not provision an OSNMA receiver. No ResiNav OSNMA implementation, provisioning service or offline capability is established here.

Separate navigation-data authentication from authenticated receiver output

OSNMA concerns the Galileo navigation data received from satellites. If the purchasing requirement also says that the controller must verify the origin and integrity of messages received from the GNSS receiver, that is a second boundary: receiver-to-host delivery. An OSNMA status alone does not establish that this output path is authenticated.

A concrete manufacturer example is Septentrio’s mosaic-G5 P8 product record. It lists Galileo OSNMA and serial authentication and encryption as separate capabilities. Those are that manufacturer’s features, not ResiNav interfaces or a compatibility endorsement.

If the project needs authenticated Galileo navigation data and the existing output interface is otherwise acceptable, compare the documented OSNMA implementation without automatically buying another antenna. If the controller must also verify the output’s origin and integrity, shortlist a documented authenticated-output implementation together with the host verification function. An offer that lists OSNMA but does not define that delivery function leaves the second requirement unanswered—not proven unsupported.

The distinction works in both directions. Authentication of the delivered message does not, by itself, prove that the receiver computed a correct position or time. The receiver’s navigation-data authentication, solution policy and the host’s validity and freshness decisions remain separate.

Buy RF protection for a separate reception-path requirement; do not add an anti-jamming terminal solely to satisfy an authenticated-output requirement. Record the receiver-to-host function in the receiver interface definition. The ResiNav product records below remain entry points for the protection portion of the purchase, not evidence of authenticated receiver-to-host delivery.

Where the ResiNav catalogue fits

Use the ResiNav product catalogue for the interference-protection portion of the comparison. If Galileo E1 is part of the required reception path, the RN2504-3T7A21C-WG-DT record lists Galileo E1 among its published signals. That is a signal-band screen—not an OSNMA capability statement or a claim of compatibility with a particular authentication-enabled receiver.

If the requirement instead concerns a combined anti-jamming/anti-spoofing product for the published BDS B1 and GPS L1 configuration, review RN2501-AJS-4CH-DPA. It is a different starting point, not a substitute for a Galileo OSNMA requirement. No ResiNav OSNMA implementation is established by the public records used here.

Make the next step specific: shortlist the receiver implementation for authentication and the product configuration for the required protection path. For the latter, discuss RN2504’s published configuration or use the catalogue to choose another documented signal set. Keep authentication as a separate requirement rather than assuming it is included in a protection label.