Back to Blog

GPS as a Hidden Cryptographic Infrastructure: What Changes for Your Threat Model Under NIS2 and DORA

·5 min read
GPS as hidden cryptographic infrastructure - NIS2 and DORA threat model

On 26 May 2011, all 31 operational GPS satellites transmitted the same identical signal within a few hours of each other. This was no technical anomaly: it was the coordinated activation of OTAD, the system the Pentagon uses to distribute military cryptographic keys via satellite — hidden inside the civilian GPS signal for at least fifteen years, without any public documentation.

On 5 June 2026, 404 Media published research by Steven Murdoch, Professor of Security Engineering at UCL (University College London), who analysed more than 12 million observations from the public GNSS dataset collected since 2007. Murdoch found 3,994 unique 176-bit messages in Subframe 4, Page 17 of the L1 C/A signal — the structurally open civilian GPS signal — where the technical specification simply reads: «reserved for special messages with the specific contents at the discretion of the Operating Command». Bruce Schneier commented on the findings on 9 June 2026, noting that the system has been active «for nearly twenty years».

OTAD — Over-the-Air Distribution — is the GPS variant of the OTAR (Over-the-Air Rekeying) protocol, developed by the NSA (inventor: Mahlon Doyle) and introduced operationally in 1988. Lt. Cmdr David Winters (US Navy) oversaw its first large-scale deployment in the Navy between 1988 and 1994. Declassified military documents from 2015 — a presentation by Maj Scott Tyley, Space and Missile Systems Center — confirm continuous operational use of OTAD across all GPS satellites from March 2011. The earliest trace in the public dataset dates to February 2010.

What Changed with the OTAD Discovery

The significance is not the military technical detail. It is structural: a publicly available infrastructure universally regarded as «passive» (GPS broadcasts, it does not receive) was simultaneously carrying classified cryptographic data in a field formally documented only as «reserved» — receivable by any civilian GPS receiver anywhere in the world.

The «Smoking Gun» of 26 May 2011

In the public GNSS archive, on 26 May 2011 all 31 operational satellites transmitted the same identical sentinel signal within a few hours. Murdoch identifies this as the decisive proof: the probability that 31 independent satellites would produce the same content in the 176-bit reserved field by coincidence is negligible. It was a globally coordinated key distribution operation.

How OTAD Works Inside the Civilian Signal

Subframe 4, Page 17 of the L1 C/A signal contains a 176-bit field left «at the discretion of the Operating Command». The content is encrypted — inaccessible to civilian receivers — but the field's existence and the pattern metadata are visible in the public dataset: 3,994 unique messages across 12 million observations. The military M-code signal (introduced from 2005 on Block IIR-M satellites) is a separate, additional layer; OTAD operates on the civilian L1 C/A channel.

Contrast with Galileo

Europe's Galileo system introduced OSNMA (Open Service Navigation Message Authentication), which became fully operational in July 2025. OSNMA includes OTAR for key renewal, but with a fundamental difference from GPS OTAD: it is publicly documented, designed for civilian anti-spoofing use. GPS OTAD remained undocumented for at least fifteen years.

Why This Matters for Italian SMEs Under NIS2 and DORA

GPS Is Not Just Navigation

For an SME with GPS-dependent systems, the operational risk is not navigation. Commonly exposed systems include: NTP-GPS synchronisation for legally valid log timestamps (relevant under GDPR and NIS2), POS terminals with network timing, SCADA systems with time synchronisation, fleet management and tracking. The OTAD discovery does not create an immediate new technical vulnerability. It does reveal that the threat model for any organisation using GPS includes a dependency on an undocumented military key distribution system, operated by a third party with no SLA, no contract, and no operational transparency.

NIS2 Art. 21 and DORA Art. 8: The Obligation to Map Dependencies

Directive (EU) 2022/2555 (NIS2), Art. 21(2)(d), requires measures for «the security of the supply chain, including security-related aspects concerning the relationships between each entity and its direct suppliers». A GPS-dependent system has the US GPS Command as an indirect supplier — an entity that signs no contracts with Italian SMEs, but on which concrete operational functions depend.

Regulation (EU) 2022/2554 (DORA), Art. 8, requires the identification and classification of all business functions dependent on ICT systems, including dependencies on third-party providers. DORA applies directly to financial entities (banks, insurers, payment institutions, and other entities listed in Art. 2); for non-financial SMEs, the relevance is indirect, as potential critical ICT providers to in-scope entities. In either case, GPS is an ICT provider of timing and synchronisation — it must appear in the critical dependency register, not remain as an invisible background infrastructure.

What to Do Now

The discovery calls for no emergency response, but for a methodical update of the risk assessment:

  1. Map your GPS dependencies: identify every component that uses GPS for timing (NTP-GPS), legal timestamps, authentication, or synchronisation. POS systems, SCADA, GDPR event logging, time-stamped digital signatures — all must be explicitly inventoried.
  2. Update your ISO 27001 asset register: public infrastructures (GPS, BGP, NTP) must be catalogued as third-party assets with explicit risk ratings. ISO/IEC 27001:2022 control 8.24 (use of cryptography) is the starting point for systems dependent on external timing.
  3. Revise your GPS threat model: add the category «infrastructure with opaque dependencies» — a system carrying classified data in undocumented channels presents continuity risks that standard spoofing/jamming models do not capture.
  4. Review contracts with GPS-dependent suppliers: under NIS2 Art. 21(2)(d), third-party suppliers who themselves depend on critical public infrastructures must be covered in your supply chain risk analysis.
  5. Monitor ENISA and ACN: the ENISA Space Threat Landscape 2025 (March 2025) covers risks to satellite systems in general; ACN publishes updated NIS2 guidelines for dependency mapping. Subscribe to alerts from both for GNSS updates.

The Sanctions That Clarify What Is at Stake

Failure to map critical third-party infrastructure dependencies is a direct gap against NIS2 Art. 21(2)(d) obligations. For essential entities, NIS2 Art. 34 provides for administrative fines of up to €10 million or 2% of total worldwide annual turnover (whichever is higher). For an SME with €10M in revenue, 2% is €200,000; for one with €50M, it is €1,000,000 — concrete, calculable figures proportional to turnover.

Under DORA Art. 8, a gap in ICT dependency identification does not produce an immediate direct fine, but it is detectable in audits by Banca d'Italia and the ECB, and forms the basis for mandatory remediation plans — with tangible reputational and operational consequences.

For further detail on NIS2 obligations and Italian deadlines, see NIS2 Italy: the 31 October 2026 deadlines.

Sources