Every Satellite Is an Endpoint
Massimo ·
There are roughly 10,000 active satellites in orbit today. Five years ago, there were fewer than 3,000. By the end of the decade, if current launch rates hold and planned constellations reach their filing targets, there will be more than 50,000. Every one of them is a networked device, receiving commands, transmitting data, communicating with ground stations and often with each other. Every one of them is, in the language of information security, an endpoint.
The terrestrial internet took decades to grow from a research network to a global attack surface. The space segment is compressing that trajectory into years. The difference is that the terrestrial internet had the luxury of learning its security lessons incrementally, each breach producing new defenses, each vulnerability class spawning a remediation industry. Satellites do not get that luxury. Once launched, their hardware is fixed. Their software is difficult to update. Their communication protocols cannot be retroactively encrypted. Whatever security architecture they carry into orbit is the security architecture they will have for the duration of their operational life, five years, fifteen years, sometimes longer.
This is the attack surface expansion problem, and it is the foundational challenge of space cybersecurity. Not because any single satellite is uniquely vulnerable, but because the aggregate surface is growing faster than the defenses, and the gap is structural.
The constellation math
The arithmetic of modern satellite constellations changes the security calculus in ways that are not immediately obvious.
A traditional geostationary communications satellite is a single, expensive, hardened asset. It costs hundreds of millions of dollars. It is built by one of a handful of prime contractors, Airbus, Thales, Boeing, Lockheed Martin, over a timeline measured in years. Its ground segment consists of a small number of dedicated earth stations, operated by specialists, connected through controlled networks. The attack surface is narrow: a few ground stations, a few command links, a limited number of personnel with access. Security through scarcity, there simply are not many points of entry.
A modern low Earth orbit constellation inverts every one of these properties. Instead of one satellite, there are hundreds or thousands. Instead of a purpose-built, hand-assembled spacecraft, each satellite is manufactured on a production line, using commercial off-the-shelf components shared across the industry. Instead of a few dedicated ground stations, the constellation connects to dozens or hundreds of ground points, gateway stations, direct-to-device links, inter-satellite laser connections. Instead of a handful of specialist operators, the user base may number in the millions, each with a terminal that communicates directly with the satellites overhead.
SpaceX’s Starlink operates over 6,000 satellites and more than three million user terminals worldwide. Amazon’s Project Kuiper plans to deploy 3,236 satellites. OneWeb operates 634. Telesat’s Lightspeed, the European Union’s IRIS2, China’s Guowang, the list grows quarterly. Each constellation adds not just satellites but ground terminals, gateway stations, inter-satellite links, and management systems. Each component is a potential entry point. The attack surface does not grow additively, it grows combinatorially, because the number of possible communication paths between nodes scales with the square of the node count.
This is not an abstract concern. A Starlink user terminal is a sophisticated piece of radio equipment sitting on a rooftop, connected to the internet, running firmware that can be updated over the air. In 2022, security researcher Lennert Wouters demonstrated a voltage fault injection attack on a Starlink terminal using approximately $25 in hardware, gaining root access to the device. SpaceX responded with firmware patches and invited Wouters to join their bug bounty program, a responsible and effective response. But the incident illustrated a fundamental truth: when you deploy millions of networked devices, the attack surface includes every single one of them. The terminal on a Ukrainian farmhouse and the terminal on a Pentagon rooftop run the same firmware. A vulnerability in one is a vulnerability in all.
The supply chain beneath the constellation
The most underappreciated dimension of the orbital attack surface is not the satellites or the ground stations. It is the supply chain that produces them.
Modern small satellites are not built from scratch. They are assembled from subsystems, reaction wheels, star trackers, solar panels, radios, onboard computers, sourced from a relatively small number of specialized suppliers. A handful of companies produce the majority of the world’s small satellite buses. A few semiconductor manufacturers produce the radiation-hardened chips that run onboard software. The same real-time operating systems, the same communication protocol stacks, the same flight software frameworks appear across constellations built by different companies, in different countries, for different purposes.
This is efficient. It is also a monoculture, and monocultures are fragile in precisely the way that matters for security. A vulnerability in a widely used satellite bus affects every constellation that uses it. A backdoor in a popular flight software package compromises every spacecraft running it. A compromised component from a second-tier supplier can propagate through multiple prime contractors and into orbit before anyone detects it.
The SolarWinds attack of 2020 demonstrated this pattern on the ground: a compromise of a single software update mechanism gave attackers access to thousands of organizations, including US government agencies. The space industry’s supply chain has the same structural properties, centralized suppliers, shared components, update mechanisms that propagate code across fleets, and there is no reason to believe it is more resilient. If anything, it is less so, because the space industry’s supply chain security practices are less mature, the number of suppliers is smaller, and the consequences of a compromise are harder to remediate when the affected hardware is in orbit.
The problem extends beyond hardware. Ground station software increasingly relies on cloud infrastructure, open-source libraries, and commercial platforms. Satellite tasking, the process of commanding a satellite to perform specific operations, is moving from dedicated command-and-control systems to API-driven platforms accessible over the internet. This is a necessary evolution: no operator can manage thousands of satellites through manual commanding. But every layer of abstraction, every API endpoint, every cloud dependency adds to the surface that must be defended.
The protocol problem
Satellite communication protocols were designed in an era when the primary engineering challenges were link budgets, spectrum efficiency, and reliability, not adversarial security. The consequences of those design choices are now becoming visible.
The CCSDS (Consultative Committee for Space Data Systems) standards, which govern how most satellites communicate with their ground segments, were developed by space agencies for whom the threat model was primarily natural, radiation, thermal cycling, signal attenuation. Authentication and encryption were optional extensions, not mandatory requirements. Many operational satellites use CCSDS protocols with no encryption on their telemetry downlinks and minimal authentication on their command uplinks. The data flowing between these satellites and their ground stations is, in many cases, transmitted in the clear.
This was not negligent at the time. The assumption was that intercepting satellite communications required expensive, specialized ground equipment and knowledge of the operating parameters, frequency, modulation scheme, encoding, that was not publicly available. That assumption has been invalidated by the commoditization of software-defined radios. An SDR capable of receiving satellite signals costs a few hundred dollars. Open-source software for decoding satellite protocols is freely available. Hobbyists routinely decode weather satellite imagery, AIS ship tracking data, and ADS-B aircraft positions from satellite downlinks using equipment that fits in a backpack.
The step from passive reception to active interference is shorter than most people assume. Transmitting on satellite frequencies requires more power and more sophisticated equipment than receiving, but the barriers are not prohibitive for a determined attacker, let alone a nation-state. The International Telecommunication Union allocates and regulates spectrum use, but enforcement is essentially complaint-driven, and in a conflict scenario, ITU regulations are among the first norms to be disregarded. The same SDR that a hobbyist uses to decode weather satellite images can, with different software and a power amplifier, transmit jamming signals on the same frequencies. The dual-use nature of the technology is inherent, there is no technical distinction between a receiver and a jammer, only a difference in intent and transmitted power.
The implications extend beyond deliberate attacks. As the electromagnetic environment in low Earth orbit becomes more crowded, more satellites transmitting on more frequencies, more ground stations, more inter-satellite links, the risk of unintentional interference grows alongside the risk of deliberate interference. A congested spectrum is a noisier spectrum, and a noisier spectrum is one in which malicious signals are harder to distinguish from accidental ones. The fog of orbital war, if it ever comes, will be electromagnetic.
For newer constellations, the picture is better but uneven. SpaceX has invested heavily in the security of Starlink’s communication architecture, including end-to-end encryption and regular firmware updates. But Starlink is exceptionally well-resourced. Many smaller constellation operators, particularly those building Earth observation, IoT, or scientific missions, face the same cost-security tradeoff that has historically favored cost in every technology sector. Encryption adds computational overhead. Authentication adds latency. Key management adds operational complexity. For a startup building a 50-satellite constellation on $30 million in venture funding, these are not abstract concerns. They are line items competing against propulsion, sensors, and launch costs.
The terrestrial parallel
The pattern is familiar because we have lived through it before.
In the 1990s, the internet was growing from an academic network into commercial infrastructure. The protocols that powered it, TCP/IP, HTTP, SMTP, DNS, were designed for interoperability and performance, not security. Encryption was an afterthought. Authentication was primitive. The assumption, like the assumption in early satellite design, was that the network’s users were fundamentally cooperative and that the effort required to attack the system exceeded the value of doing so.
That assumption held until it did not. The first worms, the first major breaches, the first demonstrations that critical infrastructure could be reached through network connections, each one forced a reactive security investment that was more expensive than building security into the original design would have been. The cybersecurity industry today, a $200 billion global market, exists largely because the internet was not designed to be secure, and every subsequent generation of connected devices has repeated the same pattern. Smartphones, IoT devices, industrial control systems, medical devices, each wave deployed first and secured later, and each wave produced its own category of breach and its own remediation industry.
The space industry is entering the deployment-first phase of this cycle. Satellites are going up at unprecedented rates. Constellations are scaling from dozens to thousands. Ground infrastructure is proliferating. Communication links are multiplying. And security, while increasingly discussed, increasingly studied, increasingly funded, is not yet a design requirement in the way that structural integrity, thermal management, or radiation hardening are design requirements. It remains, in most programs, an additional consideration rather than a foundational constraint.
The parallel to IoT is particularly instructive. The first generation of internet-connected devices, cameras, thermostats, industrial sensors, were deployed in the millions with minimal security. Default passwords, unencrypted communications, no update mechanisms. The Mirai botnet of 2016 exploited these weaknesses to conscript hundreds of thousands of IoT devices into a distributed denial-of-service attack that disrupted major internet services across the United States. The devices were not the target, they were the weapon. A compromised satellite constellation could serve the same function at a far larger scale, providing an attacker with communications infrastructure, processing capacity, or interference capability that leverages the constellation’s own global reach.
The difference between space and terrestrial systems is that the remediation phase will be harder. You cannot recall a satellite for a hardware upgrade. You cannot send a technician to a spacecraft in low Earth orbit to install a security patch. You cannot replace an unencrypted radio with an encrypted one after launch. Whatever security the satellite has when it separates from its launch vehicle is, with narrow exceptions, the security it will have for its entire operational life. The window for getting it right is the design phase. Once the satellite is in orbit, the architecture is fixed and the attack surface is permanent.
The expanding perimeter
The question is not whether the orbital attack surface will continue to grow. It will. The economics demand it, satellite-based communications, Earth observation, navigation, and timing services are becoming more valuable, not less, and more satellites will be launched to meet that demand. The question is whether the security architecture will grow with it, or whether the space industry will build the largest undefended network in history and spend the subsequent decades learning why that was a mistake.
The answer, at this point, is ambiguous. The awareness is there, every major space conference now includes cybersecurity panels, every new constellation RFP includes security requirements, every space agency has published guidelines. The investment is beginning, venture capital is flowing into space security startups, government programs are funding research, and the first regulatory mandates are emerging. But the gap between awareness and implementation remains wide, and the satellites launching today are the satellites that will be in orbit in 2035. Their security posture is being decided now, in design reviews and budget meetings and trade studies where security competes against every other engineering constraint.
Every satellite is an endpoint. The fleet is growing by thousands per year. And the attack surface, like the debris field that accompanies it, is a problem that is easier to prevent than to clean up.