No Hands on the Hardware: Why Satellite Cybersecurity Is Different
Satellites seem protected by distance, which is why satellite cybersecurity is so easily misunderstood. They are above the weather, above borders, above fences and server rooms and locked cabinets. No attacker can walk up to one with a screwdriver. No careless employee can leave one open in a café. No technician can plug in a mysterious USB stick during a maintenance visit. Orbit feels like security by physical impossibility.
That is the comforting half of the truth.
The same distance that protects a satellite from casual tampering also makes it extraordinarily hard to recover. A server can be rebuilt. A router can be replaced. A laptop can be wiped. Even a damaged undersea cable can, with enough money and patience, be repaired. Remote terrestrial infrastructure can also be difficult to reach, but space makes that difficulty permanent and non-negotiable. A satellite must carry its recovery plan with it from the moment it leaves the ground. Once launched, it has no repair desk, no spare cable, no engineer standing beside it, and no final resort except the commands it can still receive and the fallback behaviours it already contains.
That changes the meaning of cybersecurity. For satellites, security is not only about keeping intruders out. It is about preserving trust, command authority, and recoverability in a machine no one can physically touch.
The usual mental picture of satellite hacking is therefore misleading. The dramatic version imagines someone seizing control of a spacecraft and steering it like a stolen car. That scenario is not impossible in principle, but it is not the most useful place to begin. A satellite is not a lonely computer floating in the dark. It is the most visible part of a larger system: ground stations, mission control networks, operators, suppliers, software repositories, cloud services, radio links, user terminals, encryption keys, update pipelines, and human procedures. The spacecraft is exotic. Much of the surrounding trust chain is not.
That is where our review of Ghost in the Wires and last year’s reading of Sandworm begin to converge. Kevin Mitnick’s world was one of assumptions, access, procedures, and misplaced trust. Sandworm describes something colder: infrastructure as a battlefield, where the goal is not curiosity but disruption. Satellite systems sit uncomfortably between these two domains. They rely on specialized engineering, but they also depend on ordinary institutions making ordinary security decisions under cost, time, and operational pressure.
Orbit does not remove the human attack surface. It concentrates authority in it.
The Satellite Is Not the System
When people ask whether satellites can be hacked, they usually mean the spacecraft itself. Can someone send a false command? Can they take control of its orientation? Can they shut down a payload? Can they corrupt onboard software?
Those are real questions, but they are too narrow. In practice, the system includes every place where authority over the satellite is created, stored, transmitted, delegated, or updated. A compromised operator account may matter more than an intercepted radio signal. A weak supplier may matter more than the satellite’s processor. A poorly protected terminal may be easier to attack than the spacecraft it connects to. The ground segment — the terrestrial machinery used to command, monitor, and operate satellites — is often the more realistic path into the system. This is why NIST’s satellite ground-segment cybersecurity guidance treats command and control of satellite buses and payloads as a central security problem, not a secondary administrative concern.
This is not because satellites are easy targets. The best government and commercial systems are designed to be hard targets, with cryptographic command protection, disciplined operations, redundancy, monitoring, access controls, and specialized mission procedures. But the space industry is not made only of flagship military assets and billion-euro science missions. It now includes university CubeSats, low-cost commercial spacecraft, mass-produced constellations, outsourced ground stations, software-defined payloads, and user terminals deployed at scale.
The attack surface has expanded because space has become more useful. Satellites are no longer only prestige instruments or strategic curiosities. They are communications networks, weather systems, navigation infrastructure, financial timing sources, military enablers, environmental monitors, maritime tools, aviation tools, logistics tools, and broadband platforms. The more ordinary they become, the more they inherit the ordinary problems of networked infrastructure.
The danger is not that satellites have become easy targets. It is that they have become normal targets.
What It Means to Hack a Spacecraft
A “satellite hack” can mean several very different things.
The most severe version is command compromise: an attacker obtains the ability to send unauthorized instructions to the spacecraft. Depending on the system, that might mean changing its attitude, disabling a payload, altering software, misusing fuel, corrupting data, or forcing the spacecraft into a degraded state. Modern systems are designed to make this extremely difficult, but the reason it receives so much attention is simple. Command is sovereignty. Whoever can issue trusted commands can shape the mission.
A second category is service disruption. A satellite does not need to be controlled to be made less useful. Signals can be jammed. Navigation can be spoofed. A system can be flooded, degraded, confused, or forced into repeated recovery states. In a military or crisis setting, temporary unreliability may be enough. One does not need to destroy a communications network if one can make it untrustworthy at the decisive moment.
A third category is ground-segment compromise. This is where satellite cybersecurity begins to look much less like science fiction and much more like the rest of cyber conflict. Mission control systems, engineering workstations, identity systems, VPNs, cloud services, software repositories, build systems, vendor access, and monitoring tools are all terrestrial. They exist in buildings, data centres, and networks. They are operated by people. They can suffer from bad passwords, phishing, supply-chain compromise, misconfiguration, insufficient segmentation, and stale software.
A fourth category is user-terminal compromise. The satellite may remain intact while the service collapses around its users. The Viasat KA-SAT incident at the start of Russia’s 2022 invasion of Ukraine is useful precisely because it punctures the theatrical version of the problem. Viasat described the event as a disruption to part of its consumer-oriented satellite broadband service and said it had no evidence that the KA-SAT satellite itself, its gateways, or core network infrastructure had been impaired. The public lesson was not that a satellite had been physically hijacked in orbit. It was that satellite-dependent infrastructure could be disrupted through the access and terrestrial parts of the system. The effect was still strategic.
The most realistic satellite cyberattack may look less like taking over a spacecraft and more like breaking the nervous system around it.
Command Is the Sacred Channel
Satellites communicate through several broad channels. There is telemetry: the spacecraft reporting its health, position, state, and performance. There is tracking: the ground determining where the spacecraft is and how it is moving. And there is command: the ground sending instructions to the satellite.
Of these, command is the channel where legitimacy becomes survival.
Encryption is part of the answer, but it is easy to say “encryption” too quickly. Confidentiality matters. It may be important that outsiders cannot read sensitive mission data or understand operational patterns. But for command links, authenticity is often even more existential than secrecy. A satellite can survive if an attacker learns that a routine command was sent. It may not survive if it accepts a false command as genuine.
The spacecraft must therefore be conservative about obedience. It needs to know that a command came from an authorized source, that it has not been altered, that it is fresh rather than replayed from an earlier contact, and that it is meant for this spacecraft in this state. This is where cryptographic authentication, command counters, anti-replay protections, key management, and strict command procedures matter. The technical details vary, but the principle does not: the satellite must treat the radio environment as hostile until a command proves itself. The CCSDS Space Data Link Security Protocol, for example, is built around security services for space data links, including authentication, encryption, and authenticated encryption.
This is a very different security posture from much everyday computing. A personal device can ask for confirmation, retry, download a patch, contact a server, or display an error message to someone sitting in front of it. A satellite may have a short communication window, limited bandwidth, constrained processing, radiation-hardened hardware, and no human witness. It cannot rely on improvisation. The trust model must be built before the failure.
The worst command is not necessarily the most dramatic one. A malicious instruction does not need to explode the spacecraft. It may waste propellant, degrade pointing, shut down a payload, corrupt an observation, interrupt service, or push the satellite into a mode from which recovery is difficult. In space, small losses can become permanent. Fuel spent on recovery is fuel no longer available for station-keeping. A damaged battery does not get replaced. A corrupted memory image may have to be recovered through a thin radio link, if the radio link is still available.
Security is therefore not just a lock on the door. It is a discipline of obedience.
The Machine Must Know How to Fail
The most distinctive feature of satellite cybersecurity is that recovery must be designed into the spacecraft before it is needed. On Earth, recovery is often operational. Someone drives to the site. Someone replaces a component. Someone reboots the machine. Someone restores from backup. Space denies that final act of human reassurance.
Satellites therefore need safe modes and survival behaviours. If something goes wrong, the machine should stop trying to be clever and try to remain alive. It may point solar panels toward the Sun, preserve power, maintain thermal limits, reduce activity, keep a basic communications path open, and wait for instructions. In more severe cases, it may enter a survival mode where nearly everything except basic self-preservation is suspended.
Safe mode is usually an engineering response to abnormal conditions, not a cybersecurity product. But in a system that can be attacked through commands, software, radio links, or operational state, the boundary between fault recovery and cyber resilience becomes thin. A spacecraft that can fall back to a minimal trusted state is harder to kill through confusion. If commands conflict, software misbehaves, sensors disagree, or power margins deteriorate, the satellite needs some way to retreat into a state that favours survival over mission performance.
Safe mode also has an ambiguous role. It can be a shield, but it can also be a target. An attacker who cannot take over a satellite might still try to force it repeatedly into safe mode. That could interrupt service, consume operational attention, reduce confidence, and slowly spend finite resources. The mission is not binary. It can be degraded.
This is one of the important differences between ordinary hacking and infrastructure attack. In consumer cybercrime, the attacker may want data, money, or access. In infrastructure conflict, degradation itself is valuable. A satellite that works unreliably at the wrong moment may be almost as useful to an adversary as one that does not work at all.
The machine must know how to fail because failure is not hypothetical. It is part of the mission environment.
Patching Without Hands
Satellites can be patched, but the phrase is too casual. Patching a satellite is not like updating a phone. It is closer to remote surgery on a patient who cannot be reached if the procedure goes wrong.
A modern spacecraft may be able to receive new software, configuration changes, firmware updates, rule sets, or payload instructions. Sensible designs use signed updates, checksums, staged uploads, redundant memory banks, fallback images, ground testing, simulation, and rollback procedures. Operators may test changes on engineering models or hardware-in-the-loop systems before sending them to orbit. They may upload in pieces, verify integrity, activate only during controlled windows, and keep the previous known-good image available.
The central rule is simple: do not let an update strand the spacecraft.
Yet this creates a tension. The ability to patch is necessary because no system can be assumed perfect for an entire mission lifetime. Threats change. Vulnerabilities are found. Software ages. Operational needs shift. A satellite that can never be updated may become brittle. But the act of updating is also a risk. A bad patch can disable the very machine it was meant to protect.
This is where the glamour of “software-defined” space needs some discipline. Software-defined payloads and modern constellations can be more flexible than older spacecraft. They can adapt, reconfigure, and improve. But flexibility also means complexity, and complexity is where security failures breed. More updates mean more signing keys, more build pipelines, more operator procedures, more test environments, more chances for supply-chain compromise, and more opportunities for human error.
Older spacecraft may be rigid but simpler; newer spacecraft may be adaptable but more entangled. Neither model is automatically safe.
Standards Exist, but Reality Is Uneven
There are standards and frameworks for this world. Space data-link standards address telemetry, telecommand, security services, authentication, encryption, and reliable communication. NIST has applied its cybersecurity framework specifically to the satellite ground segment, with emphasis on assuring satellite command and control. U.S. Space Policy Directive-5 explicitly calls for protecting command, control, and telemetry links with effective, validated authentication or encryption and for guarding against jamming and spoofing.
The gap is not awareness.
The problem is implementation across a rapidly widening ecosystem. Space is no longer a small club of national agencies and a few prime contractors building exquisite machines slowly. It is also commercial broadband, Earth observation start-ups, university missions, rideshare payloads, outsourced ground-station services, cloud-based operations, software-defined payloads, mass-produced terminals, and constellations whose scale would have seemed implausible not long ago.
This produces unevenness. The strongest systems may be extremely difficult to compromise. The weaker end of the ecosystem may include systems designed under older assumptions, tighter budgets, or less mature security practices. Legacy systems may have been designed when obscurity, specialized equipment, and limited access were treated as meaningful protection. Low-cost missions may accept risks that would be unacceptable for a strategic asset. Commercial speed may outrun institutional caution. Suppliers may become part of the trust boundary without being treated as such.
A satellite launched with weak assumptions may carry those assumptions for years. That is the brutal arithmetic of orbit. In terrestrial infrastructure, old hardware is a nuisance. In space, old hardware is an enduring fact.
When Space Becomes Ordinary Infrastructure
The strategic issue is not only the security of individual satellites. It is the transformation of space into ordinary infrastructure.
Navigation systems shape finance, logistics, transport, agriculture, emergency response, and military operations. Weather satellites inform planning and disaster preparation. Communications satellites connect ships, aircraft, remote regions, armies, journalists, governments, and consumers. Earth observation feeds markets, climate monitoring, insurance, intelligence, and border control. Satellite timing signals help synchronize systems that most people never associate with space.
This changes the attacker’s incentives. A satellite system no longer needs to be glamorous to be worth attacking. It only needs to be useful. If disrupting a service creates confusion, slows response, blinds an adversary, raises costs, damages confidence, or forces a government into visible dependence, then the system has strategic value.
This is the Sandworm logic applied upward. The object is not necessarily spectacular destruction. It may be interruption, distrust, delay, and exhaustion. It may be the slow conversion of technical fragility into political leverage.
The public imagination still treats space as a frontier. Operationally, it is becoming infrastructure. And infrastructure attracts the kind of adversary who does not care whether the target is elegant. They care whether it matters.
Orbit Is Not Immunity
Satellites are protected by distance in one sense and endangered by it in another. Physical inaccessibility reduces some risks and magnifies others. It prevents casual tampering, but it also removes physical repair. It makes the machine remote, but not isolated. Every command path, every ground station, every software update, every operator credential, every terminal, every supplier, and every cryptographic key becomes part of the satellite’s real body.
That is why satellite cybersecurity cannot be understood as ordinary IT with a radio attached. It is a problem of trust under irreversibility. The satellite must know whom to obey. It must know how to reject false authority. It must know how to retreat into survival. It must accept updates without being killed by them. It must depend on ground systems without letting ordinary terrestrial compromise become orbital failure.
The deeper risk is not that a hacker will theatrically seize a satellite and steer it across the sky. The deeper risk is that space systems are becoming normal networked infrastructure while retaining one abnormal constraint: once launched, they are almost impossible to repair.
A server can be rebuilt. A router can be replaced. A terminal can be swapped. A satellite must carry its repair shop, emergency procedure, and trust model with it from the beginning. Orbit gives distance, but not immunity. It turns unresolved weakness into something harder to touch.
Comments
Post a Comment