I do not work in the space industry. I do not design satellites, operate ground stations, or analyze orbital telemetry in real time. Worth saying upfront, because it is the right starting point for this kind of analysis. You do not need to live inside a domain to assess the risk it creates for your organization. You need to recognize when your business depends, even indirectly, on infrastructure it does not control. Space has quietly become one of those dependencies.
Over the past eighteen months, space has moved from a niche conference topic to a concrete risk surface for logistics, finance, energy, transport, and telecommunications. Not because of science fiction, but because of verifiable facts. Aircraft pushed off course by falsified GPS signals. Ships losing their position in the Baltic Sea. Starlink terminals disrupted by electronic warfare systems. A 2024 plane crash in which investigators cited external interference as a contributing factor. This piece looks at these signals with the same discipline a CTI analyst would apply to a ransomware campaign or a phishing wave.
What happened, why it matters, and what actually changes for defenders.
A common mistake when discussing space cybersecurity is picturing an attacker who “hacks a satellite” the way it happens in a movie. The operational reality is more mundane and more unsettling. A space system is built from three connected segments, and most of the incidents observed so far have hit the weakest links, not the most dramatic ones.

The framework the industry is using to put a shared name on these threats is SPARTA (Space Attack Research and Tactic Analysis), developed by The Aerospace Corporation on the conceptual model of MITRE ATT&CK. SPARTA exists to solve a very concrete problem. For years there was no shared, unclassified vocabulary to describe how a space system could be compromised, leaving commercial operators without a common reference while government threat briefings stayed locked behind classified channels.
What makes SPARTA useful for a CTI analyst is its definition of attack surface. It does not stop at radio receivers or the onboard computer. It explicitly includes “every contractor laptop, every ground station antenna, every software repository, and every logistics chain that touches the mission from design through decommissioning”. In other words, a supply chain, and supply chains are exactly the kind of target modern CTI already knows how to model.
In January 2026, thirteen European states plus Iceland issued a joint warning on GPS/GNSS interference threatening maritime safety and global commerce across the Baltic Sea and the North Sea. This is not an isolated episode. Public interference maps show persistent disruption zones concentrated around Kaliningrad, extending across Poland and the Baltic region, while Finland has reported continuous disturbance to satellite navigation and northern Norway has recorded sustained active jamming near Kirkenes.
In March 2025, ICAO, ITU, and IMO (the three international bodies regulating aviation, telecommunications, and maritime transport) issued a joint warning describing GNSS disruptions as an “urgent threat” to public safety, telecommunications networks, and international commerce. That is not the language three UN agencies use for a marginal phenomenon.
In the Gulf region, the Joint Maritime Information Center has documented continuous electronic interference near the Strait of Hormuz and the port of Bandar Abbas. One analysis showed a jump from 1,225 vessels affected by jamming in the first quarter of 2025 to more than 5,800 in the second quarter of the same year. The Secure World Foundation, in its 2026 Global Counterspace Capabilities report, noted that some actors have demonstrated electronic warfare capability able to persistently interfere with commercial satellite signal broadcasts and with Starlink terminals, with more limited capability against protected military signals.
The point worth holding onto here is simple. These are not cyber exploits in the traditional sense. They are attacks on signal availability, carried out with relatively accessible electronic warfare means, that still produce the same operational effect as a successful cyberattack. Loss of data integrity, loss of service availability, decisions made on false information.
On December 25, 2024, Azerbaijan Airlines Flight 8243, an Embraer 190 traveling from Baku to Grozny, crashed near Aktau, Kazakhstan. Early investigations cited “external physical and technical interference” as a factor in the sequence of events, in a context where the aircraft reportedly experienced jamming followed by spoofing. This is a case that deserves analytical caution. Aviation accident investigations take time and rigor. It was still enough to push the FAA and EASA to update their operational guidance. EASA published the fourth revision of its GNSS safety bulletin in July 2026, flagging growing severity and sophistication in these events. The FAA issued an updated GPS/GNSS interference guide the same year.
For anyone working in CTI, the most instructive case remains February 2022, when an attack against Viasat’s KA-SAT satellite network knocked out tens of thousands of modems across Europe through a vulnerability in the ground segment management VPN, not through the satellite itself. The malware used to wipe device configurations, known as AcidRain, caused disruption that spread far beyond the original target, remotely disabling thousands of wind turbines in Germany. This is the textbook case for the central point of this piece. The most disruptive attack on European satellite connectivity in recent years did not require touching a satellite at all. It required compromising a ground management network, the exact same way any other corporate network gets compromised.
A common reflex when reading these cases is to think “not my problem, we do not operate space infrastructure”. That reasoning is one CTI should already be wary of. It is the same reasoning that, for years, led teams to underestimate software supply chain risk.
Direct and indirect dependencies on space include the following.
The regulatory landscape is moving accordingly. ENISA published a dedicated guide on securing commercial satellite operations, noting that the commercial use of space has become “the backbone of key economic activities” and that digital threats in this domain carry cascading effects capable of fueling geopolitical tension. In the United States, the Satellite Cybersecurity Act passed the Senate, requiring the Government Accountability Office to examine efforts to secure commercial satellites from cyber threats and assess how these systems integrate into critical infrastructure sectors. In India, CERT-In published a space cybersecurity framework in February 2026 introducing mandatory six hour incident reporting, zero trust principles, and stronger satellite protection requirements, explicitly treating satellites as critical infrastructure.
These are not isolated initiatives. They are a signal that regulators have stopped treating space as a domain separate from ordinary cybersecurity.
Doing threat intelligence on space does not mean chasing science fiction scenarios. It means applying the same analytical discipline already familiar from other domains, intelligence requirements, indicators, dependency mapping, to a domain with different physics but a familiar risk logic.
Domain-specific intelligence requirements
Signals worth watching, with proper attribution caution
A non negotiable point of analytical discipline
Attributing a specific satellite interference event to a named actor requires a high evidence bar. Demonstrated capability is not the same as confirmed attribution, and the line between a technical fault, unintentional interference, and a deliberate act is not always immediately clear. The value of CTI in this domain, more than in most others, lies in communicating uncertainty honestly rather than offering certainty the data does not support.
Space did not become dangerous because attackers learned to “hack satellites”. It became a risk domain because organizations built up dependencies on infrastructure that, for years, nobody treated as part of their security perimeter. The honest parallel is not a science fiction movie. It is the evolution CTI already lived through with the software supply chain, when open source libraries were dismissed as “developer stuff” for years, until a single compromised component proved how central they really were.
The question every security team should be asking is not whether it owns satellites. It is whether it knows, with documented certainty, how much of its operational continuity runs through a signal arriving from orbit, and what happens on the day that signal stops telling the truth.
Incident data and figures on affected vessels and aircraft cited in this piece come from the regulatory, intergovernmental, and public reporting sources listed above. Attribution to specific state actors draws on public reporting (for example, the Secure World Foundation) and should be treated as an assessment with variable confidence levels, not as a judicially established fact. The Azerbaijan Airlines Flight 8243 incident remains subject to verification through the official investigation ongoing at the time of writing.