Spotlight: Closing the security gap in space systems – with Terma

This article was developed in collaboration with Terma, a paying participant in the satsearch trusted supplier program. It captures expert insights provided by Andy Armitage, Director of Space Technology & Innovation at Terma, into the critical role of (cyber)security in modern space missions and explores how adopting practical security measures can protect space assets.

Jump to

• The ground reality of space cybersecurity
• The myth of “Zero Trust” and the danger of complexity
• Wearing two hats for space mission design
• Hardware constraints and the real physical threat
• The “lock-out” threat and embracing standards
• Pushing boundaries with end-to-end encryption
• Navigating the post-quantum era
• AI as the systems engineer’s companion
• Recommendations for NewSpace teams
• Terma’s solutions for NewSpace
• References
• Additional resources

---

The ground reality of space cybersecurity

Historically, legacy system architectures implied a non-ideal baseline for space engineering teams, scattering tens or hundreds of configuration parameters containing passwords and credentials across largely dispersed subsystems. Combined with heavy timeline constraints, these inherently complex system environments pressure space operators to focus on immediate functional viability, leaving comprehensive security hardening as a deferred task.

In a widespread, rapidly-changing threat environment (Fig. 1), legacy models that rely on static boundaries and isolated networks are no longer sufficient. Space systems need to move towards adopting new strategies to meet mission security requirements in a rapidly evolving landscape, a shift recently emphasized by the US Cybersecurity and Infrastructure Security Agency (CISA) [1]. However, translating these concepts into actual engineering practices requires moving past industry buzzwords and confronting the operational realities of space.

Figure 1: Landscape of typical threats encountered by the space community (source).

The financial stakes of ignoring systems vulnerabilities can be massive. Across enterprise environments, the average cost to recover from a disruptive cyber incident has reached $2.5 million [2]. In the space sector, where single hardware assets cost millions of dollars, the financial exposure is significant [3]. A single successful attack on a satellite network, such as the 2022 Viasat KA-SAT incident, can disable tens of thousands of modems and inflict widespread collateral damage on economically linked critical infrastructure [4].

While costs of breach are significant, the true stakes in the space sector are measured in critical functional and operational losses. A successful intrusion does not just threaten a line-item budget; it risks the entire functionality of a constellation or mission. For example, if a sovereign system like Europe’s Galileo navigation network were compromised, the consequence would be a loss of strategic autonomy, which could have much deeper consequences than financial losses.

The myth of “Zero Trust” and the danger of complexity

The cybersecurity industry frequently uses the term “Zero Trust” as a goal for system hardening efforts. From an engineering standpoint, this phrase can be misleading. A complex system can never achieve absolute zero trust because operators must inevitably place trust in certain people, software, and hardware. The real goal is to minimize implicit trust and limit the damage a bad actor or a configuration mistake can cause.

A significant trap during this transition is over-engineering access controls. Take the debate between traditional Role-Based Access Control and the more dynamic Attribute-Based Access Control. While dynamic controls promise condition-based security, an architecture relying on a highly complex set of real-time conditions requires engineers to perfectly analyze every single input and output state, and catalog a vast number of failure modes. If they fail to do so, the complexity itself becomes the source of security vulnerabilities. Foundational literature, such as the National Institute of Standards and Technology’s (NIST) Special Publication on Zero Trust Architecture, highlights that it’s actually the action of minimizing complexity that is critical to a successful implementation [5].

Beyond technology, it’s important to understand that organizations change rapidly. If offboarding an engineer requires navigating convoluted manual processes to revoke access across dozens of distinct subsystems, small administrative errors will accumulate over time. Eventually, an unpatched administrative hole becomes an active exploit.

True security is found in architectural simplicity. By limiting the number of technologies used in the stack and relying on standardized protocols, the attack surface is minimized.

Wearing two hats for space mission design

When government agencies publish frameworks for space cybersecurity, the natural engineering response is to build compliance checklists. While these certifications successfully lift the baseline security floor of the entire industry, they are not a silver bullet against targeted attacks.

Systems engineers designing a mission must wear two hats simultaneously (Fig. 2).

Figure 2: Managing the compliance and adversary hats concurrently to buttress space cybersecurity.

The first is the compliance hat.

Engineers must follow prescriptive checklists, implement government mandates, and earn necessary certifications and credentials. The experts who drafted these documents know what they are doing, and this baseline is vital for operations.

The second is the adversary hat.

Engineers must think entirely like the opponent. An adversary does not care about compliance checkboxes. They look for the path of least resistance. Frequently, the easiest path into a space system is not a highly technical cryptographic break but social engineering. Persuading a human operator to reset a password under pressure is exponentially easier than writing custom malware. Engineering architectures must account for these mundane intrusion vectors.

Hardware constraints and the real physical threat

When thinking like an adversary, engineers must accurately assess their physical threat vectors. There is a growing industry trend to specify complex access control hardware, such as Trusted Platform Modules (TPMs), directly into satellite payloads. In terrestrial environments like industrial IoT, these modules are vital because an attacker can physically steal a remote sensor, tamper with it, and spoof the network. Space is however a unique operating environment. Once a spacecraft is in orbit, an adversary cannot easily access it physically or plug into its hardware ports (for the moment at least).

Therefore, the true vulnerability window for hardware tampering is on the ground. If an adversary wants to compromise the cryptographic keys of a payload, their best opportunity is to infiltrate the testing facility or integration cleanroom before launch. Security budgets and engineering efforts should prioritize securing these pre-launch ground environments rather than aggressively over-engineering space hardware against physical tampering risks that do not apply in flight.

The “lock-out” threat and embracing standards

Cryptographic key rotation is one of the most delicate operations in maintaining a secure satellite link over a multi-year lifespan. Keys must be periodically updated to force bad actors to restart their cryptoanalysis. If the key management facility is overly complex, it becomes incredibly fragile.

If key management processes fail, the spacecraft and the ground system become desynchronized. The very cryptographic gates designed to protect the satellite suddenly turn against the operators, effectively locking them out of their own spacecraft. While recovery is usually possible, it forces operators to reset continuously, wasting precious orbital passes and effectively losing value during that downtime.

An important contributing factor to this fragility is the space industry’s historical tendency to build custom, proprietary solutions for problems that have solutions stemming from other domains. Rather than engineering solutions from scratch, the space sector can look to these well-established terrestrial approaches for hardening measures.

For instance, the Consultative Committee for Space Data Systems (CCSDS) has established highly tested key management standards. Documented in official publications like the CCSDS Symmetric Key Management protocol, these standards are closely based on battle-tested terrestrial technologies like IPSec, providing a highly reliable foundation to build upon [6][7].

Pushing boundaries with end-to-end encryption

Currently, space system security suffers from artificial boundaries. Authentication and encryption often stop prematurely at the ground system interface or halt at the spacecraft bus.

To truly secure a mission against modern threats, the industry should transition to rigorous end-to-end encryption. The data flow is ideally cryptographically sealed from the original payload owner, routed entirely through the mission control system, transmitted across the space link, and delivered directly into the specific satellite payload.

Establishing boundaries as close to the data source and destination as possible is especially critical, as ground segments migrate to public cloud deployments. While hyperscale cloud providers are generally trustworthy regarding baseline infrastructure security, engineers cannot blindly trust the data transport layer. The architecture must be designed to assume the transport network is already compromised.

Navigating the post-quantum era

The threat of quantum computers using brute force to break current encryption algorithms is a serious concern for long-duration missions. Standardization bodies have already identified post-quantum algorithms (Fig. 3), such as Kyber, to counter this emerging threat [8].

Figure 3: Four Post-Quantum Cryptography algorithms announced as acceptable for general use by NIST (source).

While the threat demands active preparation, engineers eager to deploy these algorithms today are best placed exercising restraint. If every organization independently implements post-quantum algorithms right now, this will likely lead to proprietary, non-reusable systems. Satellites will lose interoperability, and ground systems will be locked into singular ecosystems. Engineers should thoroughly study these emerging post-quantum algorithms to understand their requirements.

Actual implementation should align closely with formal standardization frameworks to guarantee wide-reaching interoperability. Real progress is already underway on this front; for instance, the European Space Agency’s (ESA) recently mobilized R&D program actively prioritizes space cybersecurity, driving the industry directly toward a standardized, unified adoption of post-quantum encryption protocols [9].

AI as the systems engineer’s companion

The future of mission security and design will inevitably involve artificial intelligence (AI). Beyond simply using AI tools to identify malicious patterns in telemetry, AI has practical utility for engineers navigating complex architectural decisions.

Engineers can use AI as a sounding board. By detailing a planned security architecture to an AI model and explicitly asking it to challenge the design and find blind spots, engineers can uncover vulnerabilities they might have otherwise missed. Systems engineers can view AI as an integrated mission assistant capable of parsing complex documentation or suggesting real-time recovery plans based on degraded telemetry states.

But the key is to learn by doing. It’s not until security engineers get their hands dirty with AI that they can glean the usefulness for their applications. Utility is ultimately unlocked by experimenting through hands-on, regular, incremental steps.

Recommendations for NewSpace teams

Securing the next generation of space operations requires an operational mindset shift. The focus needs to remain grounded in reality by balancing the deployment of standard technologies against the specific constraints of the space environment.

For space engineers looking to harden their systems and processes, here are a core set of recommendations that cut across organizational size, mission type, and geographic location:

• avoid complex dynamic access controls in favor of auditable architectures,
• protect your ground supply chain before launch,
• embrace CCSDS security and key management standards (Space Data Link Security (SDLS) and Extended Procedures (SDLS EP)) to avoid naive vulnerabilities,
• adopt public standards where possible to promote interoperability and end-to-end integration across the value chain, and
• continuously hunt for the lowest-hanging security holes.

In the NewSpace age, these measures become all the more important, given the increasing speed of development and growing mission complexity.

Terma’s solutions for NewSpace

Terma has more than 50 years of experience delivering mission-critical electronics, software, and services for space missions operating in extreme environments.

Through the Terma Ground Segment Suite (TGSS), Terma supports spacecraft development and mission operations with end-to-end ground segment solutions tailored to mission needs. TGSS has been used in over 40 missions across Earth Observation, Science, Telecommunications programs for both civilian and military customers, supporting programs starting from single satellites to full constellations. Today, TGSS supports more than 1,000 satellites, giving operators a mission-proven, secure, and scalable solution for NewSpace missions.

For space mission operators, Terma offers an array of solutions, including:

For more information, check out Terma’s capability hub on satsearch.

References

1. Cybersecurity and Infrastructure Security Agency (CISA). (2024). Space Systems Security and Resilience Landscape: Zero Trust in the Space Environment.
2. Telecoms Tech News. (2026). Average cyberattack cost hits $2.5M as recovery lags.
3. United States Studies Centre. (2024). Looking to the skies: The importance of satellite cybersecurity.
4. arXiv. (2026). Orbital Escalation: Modeling Satellite Ransomware Attacks Using Game Theory.
5. National Institute of Standards and Technology (NIST). (2020). Zero Trust Architecture (SP 800-207).
6. Consultative Committee for Space Data Systems (CCSDS). (2015). Space Data Link Security Protocol (CCSDS 355.0-B-1).
7. Consultative Committee for Space Data Systems (CCSDS). (2015). Symmetric Key Management (CCSDS 354.0-B-1).
8. National Institute of Standards and Technology (NIST). (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard (FIPS 203).
9. European Space Agency (ESA). (2026). Strengthening Space Cybersecurity through ESA’s GSTP.

---

Additional resources

• Spotlight: Your mission planning system will break before your rockets do – with Terma
• Scalability and expandability of ground stations with SDR technology – with Terma (podcast)
• Overcoming Challenges in Space Processor Emulation – with Terma (podcast)

---