Resilience

Designing for the technologies we lose

The systematic decommissioning of ground-based aviation navigation across Europe and the United States rests on an assumption that satellite systems will always be available. Russian electronic warfare in the Baltic has demonstrated, at scale, that they will not.

P J Laszkowicz

The systematic decommissioning of ground-based aviation navigation across Europe and the United States rests on an assumption that satellite systems will always be available. Russian electronic warfare in the Baltic has demonstrated, at scale, that they will not. The same assumption, that the service will always be there, now underpins the digital infrastructure of every organisation building on a small number of American AI providers, and the working lives of every engineer who has substituted a subscription for a skill.

The beacons go quiet

For most of the twentieth century, aviation navigation worked from the ground up. Non-directional beacons transmitted continuous radio signals that pilots could home toward using an automatic direction finder. Stations providing very high frequency omnidirectional range, known as VOR, gave radial bearings that let pilots fix their position along defined airways. These systems were simple, independently powered, locally maintained, and resilient by design. A beacon is a radio transmitter with virtually no moving parts. Its mean time before failure is around 28,000 hours and its mean time to repair is fifteen minutes.1 A pilot with a working receiver and a chart could navigate to any airport within range without depending on any infrastructure beyond the beacon itself.

These systems are being dismantled.

In the United States, the Federal Aviation Administration's 2018 navigation strategy committed to phasing out all beacon approaches from national airspace by 2030 and cutting the VOR network by roughly 30 per cent, from about 967 stations toward a minimum operational network of 667 by 2025, with the eventual retained network smaller still.2 The survivors would serve a new purpose, no longer the primary means of navigation but a fallback for pilots during a failure of the satellite system replacing them. The agency has already discontinued hundreds of instrument approach procedures and begun removing the physical stations.3

The pattern is not uniquely American. Sweden's air navigation provider announced plans to decommission half of its twenty-two VOR stations before 2027, retaining eleven, contingent on government funding to renovate them; without the funding, the proposal was to remove all twenty-two.4 Canada announced a parallel programme to remove hundreds of aids it had determined were no longer required.5 Across Europe the trajectory is the same. Ground-based infrastructure built over decades, tested in every weather condition, independent of any satellite constellation, is being removed on the assumption that satellite positioning will be continuously available.

The financial rationale is coherent. Running two parallel navigation systems is expensive. VOR stations need periodic calibration; beacon facilities need inspection and power. The cost is modest for any single installation and accumulates across a network of hundreds. Satellite positioning, once the constellation is up, covers the globe with no per-station ground cost to aviation. In pure cost-benefit terms the transition is straightforward.

Cost-benefit analysis is only as sound as its assumptions, though. The analysis justifying decommissioning assumed satellite positioning would remain continuously available at a standard sufficient for every phase of flight. It assumed interference, where it occurred, would be local and brief. It assumed the constellation itself, built and operated by the United States Air Force and therefore subject to the strategic priorities of a single foreign government, would stay accessible to all civil aviation indefinitely. Each assumption was reasonable taken alone. None was guaranteed. And the architecture being built on top of them, with progressively fewer independent terrestrial fallbacks, had a diminishing tolerance for any of them proving wrong.

There is a place where that assumption was tested to failure.

Tartu Airport, in eastern Estonia, sits roughly 50 kilometres from the Russian border and has a single runway. It has an instrument landing system serving one runway direction, and its standard approach procedures were primarily satellite-dependent: aircraft could land using satellite-based approaches from either end, while non-satellite precision options were limited to one direction and one system.6 When the signal was available this was efficient. When it was not, the airport's operational flexibility collapsed to a fraction of normal capacity, and in practice to zero for Finnair's scheduled services.

The design of Tartu's approaches was the logical endpoint of assuming satellite navigation would always work. It was also the point at which the assumption broke.

The Baltic jammer

The satellite signal over the Baltic Sea has been degraded, intermittently and sometimes continuously, since Russia's full-scale invasion of Ukraine in February 2022. What began as sporadic interference near Kaliningrad has become a sustained electronic warfare campaign affecting aviation and maritime navigation across the whole region, from the airspace above Gdańsk through the central Baltic shipping lanes to the skies over Estonia and Finland.7

The scale is not speculative. It is measured.

In Swedish airspace, interference incidents rose from 55 in 2023 to 733 by September 2025, a thirteenfold increase in two years, and the Swedish Transport Agency concluded after extended analysis that the interference originated from Russian territory. Across the wider region the escalation was similarly stark. Poland recorded 2,732 cases of jamming and spoofing in January 2025 alone, up from 1,908 in October 2024.8 Estonia reported that 85 per cent of its flights were affected.9 Latvia's electronic communications regulator recorded 820 cases of satellite interference in 2024 against 26 in 2022.10 Between August 2023 and March 2024, aircraft flying over the Baltic reported more than 46,000 instances of potential disruption.11

The interference takes two forms. Jamming overpowers the weak signals from satellites, which orbit some 20,000 kilometres up and arrive at ground level with very low field strength, using stronger transmissions from ground or ship. Spoofing is more insidious, feeding false positional data into receivers so that systems report locations that are plausible and wrong. During 2025, researchers observed Russian tactics shifting from mostly jamming to mostly spoofing, the more advanced technique and the harder one to detect and defend against.12

In October 2024, researchers documented stretches of up to seven hours in which all four major satellite constellations were disrupted at once. Position errors exceeded 30 metres, enough to compromise safe routing for ships and aircraft alike. Matching interference patterns against vessel movements produced evidence that some sources were mobile, operating aboard ships in international waters.13

Tartu is where the consequences became publicly visible. On 25 and 26 April 2024, two consecutive Finnair flights from Helsinki turned back after interference prevented their approach. The following week Finnair, the only international airline serving the airport, suspended all flights from 29 April to 31 May. The reason was disclosed plainly: the approaches at Tartu required a satellite signal, interference in the area was persistent, and the airline could not guarantee safe landings.14 During the suspension, Finnair and Estonian Air Navigation Services worked to implement approach procedures that did not depend on satellites, procedures that would already have existed had the ground-based infrastructure not been progressively deprioritised.15

The response reached beyond Tartu. In May 2025 transport ministers from thirteen EU member states signed a joint letter demanding coordinated European action.16 The International Civil Aviation Organization condemned both Russia and North Korea over interference affecting civil aviation and demanded it stop.17 Sweden formally accused Russia of being the source.18

And a project that had run quietly since 2017, dismissed in its early years as a solution to a problem that did not exist, became strategically urgent.

R-Mode Baltic is a terrestrial navigation system developed by the German Aerospace Centre with partners in Finland, Estonia, Poland, Sweden, and Norway. It uses maritime radio beacons already installed along the Baltic coast to provide positioning independent of any satellite. Ships, and in early trials aircraft, fitted with ranging-mode receivers calculate position by measuring distances to multiple land-based stations. The system needs no satellites, no major new infrastructure, and no dependency on technology controlled by a foreign power.19

The work is funded through the EU's Interreg Baltic Sea programme, led by the German Aerospace Centre, with stations going up in Finland and Estonia, the countries experiencing the worst interference. The target is a pre-operational service by the end of 2026.20 At the 39th Chaos Communication Congress in Hamburg in December 2025, the team set out the current status. Their framing was direct: the Baltic's dangerous dependence on satellite navigation was the problem and a terrestrial backup was the answer. The system they described uses existing medium-wave and very high frequency infrastructure with a range of roughly 300 kilometres, enough to cover the whole Baltic Sea.21

They presented their work as a progression from academic curiosity to critical infrastructure, a system nobody needed becoming one that countries were urgently requesting. The trajectory is instructive. R-Mode was not built in response to the jamming campaign. It was built because a small number of engineers recognised, years before the jamming began, that a navigation system dependent on a single technology however sophisticated is structurally fragile, and that the sensible response is an independent fallback that activates when the primary fails.

The countries now deploying it are, in many cases, the same countries that were decommissioning VORs.

The same pattern, different frequency

The parallel between aviation navigation and digital infrastructure is not metaphorical. It is architectural.

In aviation the transition followed a clear path. A distributed system of independent, locally maintained ground beacons was replaced by a centralised satellite-dependent one. The old infrastructure was decommissioned to reduce cost. The new system worked well under normal conditions. When the signal was deliberately disrupted, the absence of a fallback turned a degraded service into an inoperable one.

Digital infrastructure follows the same path. Organisations that once ran their own servers, their own software, and their own engineering capacity have progressively centralised on a small number of cloud providers and, more recently, on an even smaller number of AI model providers. The old capacity, meaning in-house expertise, self-hosted systems, and teams who understood their own codebases from the ground up, has been reduced or eliminated to lower cost and raise efficiency. The new systems work well under normal conditions. When the signal is disrupted, the consequences are immediate and systemic.

That reduction in internal capability was driven by sound financial logic, exactly as the decommissioning of VORs was. Maintaining an in-house machine learning team was expensive. Running self-hosted infrastructure took capital and expertise. Building bespoke systems took time that commercial pressure did not allow. Providers offered better performance at lower marginal cost, with integration friction falling every year. Evaluated quarter by quarter, the rational decision was to outsource more and maintain less. The accumulated effect of a decade of rational decisions is a landscape in which most organisations cannot function without a small number of external dependencies they do not control.

On 20 October 2025 a major outage at Amazon Web Services brought down AI coding tools, customer service systems, supply chain decision engines, and automated analytics across thousands of organisations at once.22 It lasted several hours. For companies whose AI-integrated systems had no fallback path, no rules-based degradation mode, no locally hosted alternative, and no human process to substitute, those hours were a full stop. Engineers relying on cloud-hosted coding assistants could not write code. Customer service teams whose workflows depended on automated triage could not process requests. Decision systems feeding recommendations into logistics chains went silent.23

The financial impact was significant and the structural lesson mattered more: the outage revealed how many organisations had built mission-critical workflows on a single external dependency without planning for its absence. The parallel with Tartu is precise. Tartu had only satellite-dependent approaches, so when the signal went, flights could not land. Thousands of organisations had only cloud-dependent AI workflows, so when the cloud went, work could not continue.

Measured uptime for the major model providers underlines the fragility. Traditional cloud infrastructure operates to service-level agreements of 99.9 per cent, a maximum of roughly 43 minutes of downtime a month. Measured uptime for model interfaces has been consistently lower, with some providers recording effective availability of 99.3 per cent or worse, which is over five hours a month.24 In December 2025 alone, monitoring services recorded 47 incidents across major AI providers, with some individual providers reporting twenty or more distinct disruptions.25 This is not anomalous. It is the operational reality of a technology scaling faster than the infrastructure beneath it can stabilise.

Concentration compounds the availability problem. Most organisations' AI integrations rest on a single provider. The key points at one company, in one jurisdiction, under one set of commercial terms and one set of political pressures. When that provider fails technically, the customer has no alternative. When it changes its terms, its pricing, or its model's behaviour, the customer adapts or migrates, which is rarely simple and never instant. When its relationship with its government changes, the customer absorbs the consequence.

That is not theoretical. The Anthropic-Pentagon crisis of February 2026 showed that access to American AI infrastructure can be revoked overnight, not through technical failure but through an administrative designation. A single executive action removed one of the world's leading AI companies from the entire federal technology stack within hours, and defence contractors began stripping its technology from their systems immediately.26 Any organisation, American or allied, that had built on those models watched a live demonstration of how quickly a dependency can be severed, and how little the customer's investment in integration counts when the decision is taken upstream.

Georgetown's Center for Security and Emerging Technology has described the resulting sovereignty gap: the structural distance between the deployment-layer control customers exercise and the upstream dependencies, meaning chips, cloud infrastructure, and foundational models, that they neither control nor can replicate quickly.27 The CLOUD Act compounds the exposure for organisations outside the United States, since American law permits compelled disclosure of data held by US-headquartered companies wherever it is physically stored.28 For European organisations under data protection law this creates a jurisdictional tension no technical architecture fully resolves while the underlying provider is American.

The Tartu problem, transposed to software: when your only approach depends on a signal you do not control, and that signal is interrupted, whether by electronic warfare, a data centre failure, or a political decision taken in a distant capital, you cannot land.

The pen-and-paper engineer

The pattern operates at one further level, which is the individual.

AI-assisted software development has become, in roughly three years, a standard feature of professional practice. Subscriptions run from about twenty to two hundred euros a month. The tools are effective. An engineer working with a capable assistant can generate, review, and iterate on code at a pace that would have been impractical a few years ago. Codebases that once took weeks to scaffold can be produced in days, and patterns that would have needed extensive research surface instantly. The productivity gains are real, measurable, and for teams under delivery pressure difficult to refuse.

Productivity and capability are not the same thing.

What AI-assisted development produces is volume: more code, more quickly, across more domains than any individual could cover alone. What it does not necessarily produce is understanding. The engineer who prompts a model for a database migration, a networking layer, an authentication flow, and a deployment pipeline has a working system at the end. Whether that engineer understands the system, can reason about its failure modes, debug it unaided, and modify it when the underlying assumptions change, is a separate question that productivity metrics do not capture.

The accumulation matters. Organisations using these tools are building technical assets at an unprecedented rate, and every generated module, scaffolded service, and suggested architectural decision becomes part of a codebase that must be maintained, extended, debugged, and eventually replaced. The volume of code an organisation must support grows in proportion to the speed at which it is produced. Human capacity to understand that code does not scale at the same rate, particularly where the understanding was never fully developed in the first place, because the tool handled the complexity that would otherwise have forced the engineer to learn.

This is not an argument against AI-assisted development. The tools are good and they will improve. It is an observation about what happens when the signal fails. If the provider suffers an outage, changes its model's behaviour, alters its pricing, or loses access to its market through a political decision, the engineer is left with a codebase they may not fully comprehend and no tool to mediate their relationship with it. The team has not shrunk. But concentrating its productivity on a single external dependency means that removing that dependency, for an hour or permanently, is not a minor inconvenience. It is an operational crisis.

The deeper shift is in the nature of engineering knowledge. A generation of engineers is developing skills calibrated to a specific workflow: formulate a prompt, evaluate the output, iterate, ship. That is a valid and increasingly necessary skill, and it presupposes the continuous availability of the tool. An engineer who can design an architecture on a whiteboard, reason about data flow on paper, sketch a state machine in a notebook, and debug a failure by reading code line by line holds capabilities independent of any external service. An engineer whose practice is organised entirely around AI mediation holds capabilities contingent on that mediation continuing.

I think about this through a memory from the beginning of my career. In 2000, at nineteen, I was working at my first real engineering job. One morning we arrived to find the building had no electricity. The backup power had been severed, cut through by a telecommunications company working nearby. No power meant no desktop computers, which in 2000 meant no development environment of any kind. There were no laptops to speak of, no cloud to fail over to, no mobile devices capable of running an editor.

Our line manager arrived, surveyed the darkened office, and asked why we were not working. This confused us, since the answer seemed self-evident. He would not accept it. He suggested, with what appeared to be complete seriousness, that we write code by hand on paper and type it up when the power returned.

The instruction was absurd as stated. Nobody was going to hand-write compilable code on A4 paper. Something happened that I have thought about many times since, though. We picked up the pens and paper. Not to write code, but to do the work that did not require a compiler. We sketched architectures. We outlined data models. We mapped integration points between components. We drew sequence diagrams. We debated design decisions we had been too busy implementing to think through properly. By the time the power returned several hours later we had produced some of the most useful design work of the project, not because the instruction was good management but because the skills we had were not dependent on a single tool. We could think about software without software.

The question is whether that independence persists. If every AI coding assistant disappeared tomorrow, not permanently but for a week or a month, could the engineers who depend on them still reason about the systems they have built? Could they debug a failure by reading the code rather than pasting it into a chat interface? Could they design a new component on a whiteboard, from first principles, without a model to suggest the architecture?

For many the answer is yes. Experience, education, and professional discipline have built a foundation that these tools augment rather than replace. For a growing number, particularly those who entered the profession after AI-assisted development became the norm, the answer is less certain. The tool has become so integrated into the workflow that the workflow may not function without it. The signal has become the skill.

This is not a failure of individual engineers. It is a systemic outcome of how the tools are adopted. An organisation measuring productivity in lines shipped, commits merged, or features delivered per sprint is measuring output rather than understanding. Promotion decisions that reward engineers who deliver faster reward efficient use of tools, not the depth of knowledge that would let someone work without them. The incentive structure optimises for the signal being present. It does not reward the resilience that would matter if the signal disappeared.

Designing for the signal we might lose

None of this is an argument against satellite navigation, cloud computing, or AI-assisted engineering. Each delivers genuine value. Satellite positioning transformed aviation safety. Cloud infrastructure opened access to computing resources previously available only to the largest organisations. Coding assistants have made software development faster and more accessible. The question is not whether to use these technologies. It is whether to use them in a way that assumes they will always be available.

R-Mode offers a model of what resilient design looks like in practice. The team did not set out to replace satellite navigation. They set out to build something that would activate when it failed, a terrestrial complement rather than a terrestrial replacement. The design principle was explicit: any navigation system depending on a single technology, however reliable, is structurally fragile, and the response is not to reject the primary system but to maintain an independent fallback operating on different principles, using different infrastructure, and not vulnerable to the same failure modes.29

That principle, design for the signal you might lose, applies directly to digital infrastructure.

At the organisational level it means architectural choices that account for provider failure. Multi-provider configurations, where critical capabilities can fail over from one provider to another, are the digital equivalent of maintaining both satellite and terrestrial navigation. Graceful degradation paths, where a system drops from AI-augmented operation to simpler but functional rules-based processing, are the equivalent of a pilot switching to a VOR when the satellite signal is lost. Local capabilities, whether self-hosted models for critical functions, cached decision logic, or manual processes documented and rehearsed, are the equivalent of keeping the ground beacons running after the constellation is in place.

At the governance level it means treating dependency as a risk category. Organisations routinely audit financial, security, and compliance risk. Few rigorously audit their AI dependency chains, mapping which business processes rest on which external services, identifying single points of failure, and testing what happens when those services become unavailable. Fewer still audit the human dependency: which skills exist within the organisation only in mediated form, reachable through a tool but not embedded in the people using it? What institutional knowledge has been externalised to a provider that could change its terms, its pricing, or its availability at any time?

The aviation parallel is instructive. The minimum operational network concept, retaining enough VOR stations to allow navigation during a satellite failure, is a dependency audit applied to physical infrastructure. The same discipline applied to digital infrastructure would ask: if this provider fails, what still works? If this interface is revoked, what do we fall back to? If this model changes its behaviour, how do we detect it and adapt?

At the level of individual capability it means preserving the skills that precede the tools. An engineer who understands algorithms, data structures, system design, and software architecture holds knowledge independent of any particular model. An engineer who can reason about a problem on paper, diagram a system, trace a data flow, and identify a failure mode unaided holds a resilience no subscription provides. This does not mean refusing to use the tools. It means ensuring their use does not erode the foundation on which effective use of them depends.

Norway illustrates both the principle and its difficulty. Avinor, the national air navigation provider, has historically maintained non-satellite alternatives across its network, a backbone of VOR, distance measuring equipment, beacons, and instrument landing systems alongside satellite-based procedures. The transition to satellite-dependent navigation is under way there too. In late 2025, plans to remove ground-based systems from nineteen of Norway's smaller airports drew sharp criticism from pilots and airlines, with the president of the Norwegian Pilot Union warning that the transition had moved too fast given record interference. The regional airline Widerøe considered weight restrictions on flights from affected airports. Political leaders called for reassessment, citing the British decision to abandon a full phase-out of legacy aids in favour of running old and new side by side. Avinor's chief executive maintained that enough conventional systems would remain nationally. The debate turns on a question reaching well beyond aviation: should critical infrastructure rely on a single advanced technology, or must it be built on technological diversity for resilience?

I have some personal experience of what this looks like in practice. I trained as a pilot two decades ago, in aircraft with analogue instruments, what pilots call steam gauges. Six round dials in the standard panel: airspeed, attitude, altimeter, turn coordinator, heading, vertical speed. Navigation was a VOR receiver and a direction-finding needle. You flew by scanning the instruments, building a mental model of the aircraft's state from six independent readings, and cross-referencing your position against ground beacons. It was demanding, manual, and entirely independent of any satellite.

When I first flew aircraft with glass cockpits, where those six instruments are replaced by integrated digital displays rendering the same information as computed graphics, it made me nervous. The information was better presented, more precise, and easier to interpret. It was also mediated. The system between me and the aircraft's state had gained a layer of abstraction, and with it a new category of failure. A steam gauge fails visibly: the needle stops, the gyro topples, the reading diverges from its neighbours. A digital display can fail in ways that are harder to catch, because the presentation stays clean and confident even when the data behind it is degraded.

Eventually I became comfortable with glass cockpits and I would not willingly go back. The situational awareness they provide, with moving maps, terrain overlays, traffic information, and coupled approaches, is a genuine safety improvement. I maintain simulation time on a variety of aircraft types, including those with conventional panels, specifically to keep the older skills sharp. I fly precision and satellite-based approaches when they are available and I benefit from them. I also make sure I can fly a VOR approach, hold a heading on a directional gyro, and navigate without satellites if the situation demands it. Whichever cockpit I am sitting in, I am safe, not because I have chosen one generation of technology over another but because I remain adaptive, able to use the newest capabilities when they are there without depending on them, and grounded in the fundamentals that make a competent pilot whatever is fitted to the panel.

This is not nostalgia. It is operational discipline, and it is the same discipline the R-Mode engineers applied to Baltic navigation, that Norway is arguing about for its airspace, and that any responsible approach to technology requires.

The countries investing most urgently in alternatives are the ones closest to the interference. Finland, Estonia, Poland, and Germany, the nations that experience Baltic jamming daily, are the ones deploying R-Mode stations, demanding international action, and reinforcing their ground-based infrastructure. They did not invest in resilience because they anticipated the specific threat. They invested because the threat arrived, and they discovered that the infrastructure they had allowed to atrophy was the infrastructure they now needed most.

The parallel holds for organisations and for individuals. The companies that will handle a provider outage best are those that invested in multi-provider architectures and maintained human processes beforehand, not because they predicted a specific failure but because they designed for the possibility of failure in general. The engineers who will stay productive when their tools are unavailable are those who never let the tools become a substitute for their skills.

The distinction between augmentation and replacement is not always visible in the moment. An engineer using a tool to generate boilerplate while giving their own attention to architecture and design is being augmented. An engineer using a tool to generate architecture and design while giving their own attention to prompting is being replaced, gradually and perhaps without noticing, because the output looks the same. The difference only appears when the tool is removed. The augmented engineer continues to work, less efficiently but competently. The replaced engineer discovers the competence was in the tool.

There is a sentence from the team's presentation in Hamburg that captures the philosophy precisely. Describing R-Mode, they asked what happens when a group of engineers decides to build a navigation system that "simply doesn't care about the jammer".30 The system works whether the satellite signal is present or not. It does not depend on the absence of interference. It does not require the threat to be resolved. It operates on its own terms, from its own infrastructure, with its own physics.

That is what resilient design means, in aviation, in digital infrastructure, and in the capabilities of the people who build and operate both. Not a rejection of the sophisticated, the efficient, or the new, but an insistence that when the signal fails—and it will fail—the ability to navigate does not fail with it.

The beacons are going quiet. Some of them should be kept on. Not all of them, because the transition to satellite navigation is real and valuable and maintaining every legacy installation would be wasteful. But enough of them, in the right places, so that when the signal is lost people can still find their way. The same principle applies to the digital systems we are building and to the skills of the people who build them. Keep the beacons on. Not because the new technology is bad, but because the people who depend on it deserve a system designed for the day it stops working.

Footnotes

  1. Southern Avionics Company, "Why Is the FAA Decommissioning NDBs?" ↩

  2. Federal Aviation Administration, Navigation Programs Strategy, 2018; AOPA, "NAVAID Decommissioning," September 2018. The original target was 500 VORs by 2020, revised to 867 by 2020 and 667 by 2025 after industry feedback on coverage. The agency's eventual retained network is smaller again, in the region of 580 to 610 stations. ↩

  3. AOPA, "FAA Releases List of Instrument Approaches to Be Eliminated," April 2015. The initial round proposed eliminating 736 VOR and NDB approach procedures. ↩

  4. LFV, Sweden's air navigation service provider, presented the plan publicly. Eleven of twenty-two VOR stations would be decommissioned by 2027, contingent on funding to renovate the remainder; without funding, all twenty-two. Thirty-four distance measuring stations would be retained for performance-based navigation. ↩

  5. Aviation International News, "Canada to Decommission Hundreds of VORs, NDBs," March 2019. ↩

  6. Estonian Air Navigation Services, via ERR News, April 2024, which confirmed Tartu's approaches were primarily satellite-based with visual capability in good weather, and that the instrument landing system serves one runway direction only. ↩

  7. Defense News, "Researchers Home In on Origins of Russia's Baltic GPS Jamming," July 2025. Researchers at Gdynia Maritime University and the German Aerospace Centre traced interference to the Kaliningrad region. ↩

  8. GPS World, "13 EU Member States Demand Action on GNSS Interference," June 2025. ↩

  9. DISA, "NSDC Reports Intensified Russian GPS Jamming in the Baltic Sea," September 2025. ↩

  10. PBS News, "What to Know About Russia's GPS Jamming of a European Official's Plane," September 2025, reported alongside coverage of the jamming of the European Commission President's aircraft on 1 September 2025. ↩

  11. ComplexDiscovery, "Cyber Warfare: GPS Disruptions in the Baltic Challenge Global Security," May 2024. ↩

  12. Defense News, July 2025, citing Jarosław Cydejko of Gdynia Maritime University. ↩

  13. Spire Global, "GNSS Interference Report: Russia 2024/2025, Kaliningrad and the Baltic Sea," September 2025. ↩

  14. Finnair press statement, 29 April 2024; Helsinki Times and ERR News, April 2024. ↩

  15. FlightGlobal, "Estonian Authority Seeks Alternative to GPS Navigation as Finnair Suspends Tartu Flights," April 2024. Estonia installed supplementary distance measuring equipment at five locations to support navigation above 3,000 metres, while acknowledging that lower-altitude support remained a concern. ↩

  16. GPS World, June 2025. The signatories were Lithuania, Latvia, Estonia, Germany, Slovakia, Finland, Slovenia, the Czech Republic, Italy, the Netherlands, Spain, Denmark, and Romania. ↩

  17. AeroTime, "ICAO Condemns Russia and North Korea Over GPS Signal Jamming," October 2025. ↩

  18. The Moscow Times, September 2025. Andreas Holmgren, head of aviation at Sweden's Transport Agency: "We have done analyses over a longer period and collected data. We can conclude that the interference is originating from Russian territory." ↩

  19. IALA, "GNSS Jamming and Spoofing: Navigating Challenges in the Baltic Sea," December 2024; Deutschland.de, "GPS Interference: EU Project R-Mode Baltic," November 2024. ↩

  20. Defense News, July 2025. Ralf Ziebold of the German Aerospace Centre confirmed expansion to Finland and Estonia, targeting pre-operational status by 2026. ↩

  21. Heise Online, "39C3: Navigation System 'R-Mode' Against the Baltic Jammer," December 2025. The team reported testing on Bavaria's Ammersee with water rescue services at roughly 10 metres accuracy, and initial aviation trials over Hamburg with a research motor glider showing deviation of roughly 200 metres. ↩

  22. CloudFactory, "Strengthening AI Resilience: 3 Lessons from the 2025 AWS Outage," October 2025. ↩

  23. InfoWorld, "Cloud-Based LLMs Risk Enterprise Stability," March 2026. ↩

  24. Universal.cloud, "AI Uptime: The Forgotten Risk in Your Application Landscape," April 2026. ↩

  25. IsDown, "LLM Providers Status Report—December 2025," January 2026. ↩

  26. P J Laszkowicz, "Military AI is governed by contract, not law," Responsible, March 2026. ↩

  27. Center for Security and Emerging Technology, Georgetown University, "The Sovereignty Gap in U.S. AI Statecraft," 2026. ↩

  28. The CLOUD Act (2018) permits United States law enforcement to compel disclosure of data held by US-headquartered companies regardless of where it is physically stored. ↩

  29. Media CCC, "Who Cares About the Baltic Jammer? Terrestrial Navigation in the Baltic Sea Region," 39th Chaos Communication Congress, December 2025. ↩

  30. Ibid. The full framing: "What happens when a group of engineers decides to build a navigation system that simply doesn't care about the jammer?" ↩