Space cybersecurity starts on the ground: The hidden risks in satellite supply chains

Benny Czarny is the founder, CEO and chairman of OPSWAT, a global cybersecurity company specialising in critical infrastructure protection. Since founding the business in 2002, he has grown it from a one-person start-up into an organisation with more than 1,000 employees, serving enterprise and government customers in over 100 countries. With more than two decades of experience in encryption, vulnerability management and secure architecture, he leads the company’s strategy and technology development, championing a prevention-first approach to cybersecurity across sectors including energy, defence, transport and finance.

Many large enterprises now put serious resources into mapping the risk buried in their supply chains, poring over SaaS vendors, cloud providers, and software dependencies. Yet too few of them look one layer further down, at the infrastructure those services ultimately depend on.

Or rather, too few look up. Satellite services underpin an estimated 18% of UK GDP, from financial transaction timing to navigation and communications.

Because most organisations don’t build, launch or maintain satellites, they assume securing them is someone else’s job. However, the risk begins long before launch, in everything feeding into the spacecraft.

As above, so below

Strip away orbital mechanics and space infrastructure faces many of the same security risks as any ground-based facility. Whether it’s a nuclear power plant or a satellite in low Earth orbit, one of the most pervasive attack vectors against cyber-physical infrastructure is infiltration of the hardware or software supply chain.

A report commissioned by the UK Space Agency rated supply chain compromise among the most likely threats facing UK space capabilities, on a par with intercepting live satellite data.

Software is vulnerable to insertion, modification, or corruption during development and updates, while hardware is vulnerable to defects, backdoors, or tampering introduced anywhere along a long, often international manufacturing chain.

Despite the orbital setting, many attack paths sound familiar to any enterprise security team.

One possible scenario: an attacker gains unauthorised physical access to a satellite’s assembly line or shipping container, then uses a USB drive to introduce malicious code before the spacecraft leaves the ground. The entry point could be an engineering workstation loosely integrated into the wider IT network, or a removable drive connected without its contents being checked.

It’s the same weak link that has been behind breaches in factories, hospitals, and power stations for years. Space hasn’t invented a new problem; it’s inherited an old one.

Space adds one extra complication: once hardware launches, physical repair or replacement becomes difficult. Commands and software updates sent from the ground remain essential, making those connections some of the remaining doors into the system.

A widening circle of responsibility

Responsibility for securing space infrastructure has shifted rapidly in recent years with the commercialisation of the industry.

Once, access was tightly held, with governments and a handful of defence contractors controlling who could build, launch, and operate anything leaving the atmosphere. Now, however, private operators, commercial suppliers, and specialist technology vendors sit at every stage of a mission, from component manufacture to ground station operation, each with its own security posture, vetting standards, and vulnerabilities.

ENISA’s threat landscape report reflects this shift, listing state-nexus groups, financially motivated cybercriminals, hacktivists, and even untrained or careless employees among the actors now capable of reaching space systems. Attackers do not need to breach a satellite operator directly; they can target the weakest supplier in a long chain.

The assessment commissioned by the UK Space Agency tells the same story. The National Risk Register identified space weather as its sole space-related risk in 2020 but, by 2023, its coverage had grown to encompass asset interference and infrastructure vulnerabilities too.

Space cybersecurity can no longer sit solely with the handful of organisations that own satellites. It has to be a shared obligation across every supplier and integrator with a hand in the mission.

Why prevention has to come first

Most cybersecurity strategy assumes a problem, once spotted, can be fixed quickly. An engineer can get remote access or, in some cases, get on site to the hardware. That is already difficult on Earth. It becomes harder a few hundred miles up.

A satellite can’t be updated on demand like an office laptop. Communication windows with ground stations may be short, bandwidth is costly, and much of today’s hardware was locked in years before launch. It is difficult to swap out afterwards, let alone reach with an engineer.

Some defensive tools depend on a live link back to base to analyse a file or obtain a verdict. Space adds the dimension of time: a security check that arrives after the operational deadline is too late. Functions that cannot tolerate communication and ground-processing delays need cybersecurity computing onboard the spacecraft. Local checks must meet tested processing deadlines, without waiting for ground contact.

Getting ahead of this threat demands an approach to security built around prevention rather than response. Nothing bound for a spacecraft, whether it’s a routine update, a command sequence, or a data package, should reach mission-critical systems until it’s been checked and cleared.

For supported files, Content Disarm and Reconstruction (CDR) should deterministically remove disallowed content and rebuild the file under defined rules, without first recognising malware. Files that cannot be processed successfully must be blocked. Software updates and commands need separate authentication, integrity and authorisation checks.

That discipline must extend to how systems are built, not just how files are checked. Engineering and testing environments should stay separate from live operational systems, with controlled transfers.

Hardware data diodes add deterministic protection: they physically enforce one-way data flow, allowing telemetry out of a protected ground control network without a return path through that connection. They do not sanitise content. Necessary command and update routes need separate controls. Multiple antivirus engines and supported CDR should inspect files on the ground; onboard checks must meet the spacecraft’s computing, power and timing limits.

Familiar solutions in a new environment

This preventative approach is the same rigour aerospace engineers already apply to physical components, extended to cover the code running through them.

The UK’s space economy has grown too large, and society’s dependence on it too deep, to leave this to chance. The next serious space cyber incident could start on the ground: an unchecked file, a compromised supplier, a compromised update, long before the mission reaches the sky.