Protecting classified information aboard satellites is one challenge. Demonstrating that this protection actually works throughout a mission is another.
At the moment an Earth observation satellite captures an image, the question of information security has already begun. Long before the data reaches a ground station, it passes through detector electronics, processing units, onboard communication buses and storage systems. Depending on the mission, the image may contain classified intelligence, reveal sensitive operational capabilities or provide information whose disclosure would compromise the interests of a government or commercial operator. Yet many discussions about satellite security concentrate primarily on encrypted communication links between space and Earth. What happens to sensitive information before transmission receives considerably less public attention.
This is a particularly difficult problem in the space industry. A satellite may operate for fifteen years or longer without any possibility of physical maintenance. Its hardware is exposed to radiation, temperature variations and demanding power constraints, while its software must remain sufficiently reliable to perform mission-critical functions. Security mechanisms designed for terrestrial data centres cannot always be transferred directly to orbital systems. Even a comparatively simple cryptographic modification can affect processing capacity, memory consumption, communication performance and the ability to recover from unexpected failures. The consequences of a design decision made before launch may therefore remain with a mission for its entire operational lifetime.
The attack against the KA-SAT satellite communications network on 24 February 2022 demonstrated another aspect of this dependence. According to the incident report published by Viasat, the attackers exploited a misconfigured VPN appliance to gain access to a ground-based network management environment. From there, they issued destructive management commands against large numbers of customer terminals, disrupting satellite broadband services across parts of Europe. Viasat reported no evidence that the spacecraft itself had been compromised. The incident was primarily an attack against service availability, not a demonstrated breach of classified satellite information. Nevertheless, it exposed a structural weakness that remains relevant to both civilian and military missions: a technically functioning spacecraft does not guarantee the security of the system that operates it.
For secrecy protection, the implications extend well beyond the satellite’s communication equipment. Ground stations, mission planning environments, software development systems and the facilities of subcontractors can all process information related to the same mission. In some cases, even the existence of a particular tasking instruction, the timing of an observation or the identity of a recipient may be more sensitive than the resulting data product. Classification is not an inherent property of satellite imagery or telemetry; it depends on the applicable governmental rules and the information concerned. Distinguishing classified material from other sensitive information is therefore a prerequisite for designing appropriate safeguards.
The information that never leaves the spacecraft
Consider a satellite carrying a high-resolution imaging payload. After acquisition, the sensor data may undergo correction, compression, temporary buffering and storage before it becomes available for transmission. Some processing steps require access to unencrypted information. Depending on the architecture, that information may move between several electronic components, potentially manufactured by different suppliers and integrated under different security assumptions. Encrypting the finished image immediately before downlink protects the transmission, but it does not automatically protect the preceding processing stages.
For missions handling classified information, the protection architecture must therefore address the internal movement of data as carefully as the external communication link. Encryption may be applied close to the point of acquisition, provided the payload design allows it. Where information must remain available in plaintext for processing, isolation between components, controlled memory access and restrictions on data movement become especially important. The relevant security boundary is not necessarily the spacecraft itself. It may surround an individual payload, a processing environment or a cryptographic component within the satellite.
Cryptographic keys introduce a further difficulty. If the same software environment that processes sensitive data can freely access the keys protecting it, the security benefit of encryption may be substantially reduced. Dedicated cryptographic hardware, protected key storage and carefully separated security functions can provide stronger protection, although their suitability must be established under actual spaceflight conditions. Radiation tolerance, fault behaviour and resource limitations are not secondary engineering details. A security mechanism that becomes unreliable in orbit can threaten both confidentiality and mission availability.
Communication with the spacecraft presents a related but distinct problem. The CCSDS Space Data Link Security Protocol, 355.0-B-2, specifies mechanisms for applying authentication and confidentiality services at the space data link layer. Its complementary Extended Procedures standard, CCSDS 355.1-B-1, addresses functions including key management, security association management and security monitoring. These are established technical standards, but their implementation does not automatically create end-to-end protection for every piece of information handled aboard a satellite. Internal data transfers, application-level processing and ground-based distribution may require additional safeguards.
The authenticity of commands deserves particular attention. A spacecraft must be able to distinguish instructions from authorised operators from manipulated or replayed messages. Cryptographic authentication, integrity protection and anti-replay mechanisms can help prevent an adversary from issuing apparently legitimate commands. They do not, however, eliminate the risk of compromised operational credentials or an attacker gaining control of an authorised ground system. The mechanisms for revoking keys, recovering secure communications and maintaining control of the spacecraft must be considered before such an incident occurs.
Software integrity is equally important. Modern satellites increasingly rely on complex onboard software, sometimes involving components with origins in commercial development environments. Their security depends partly on whether the spacecraft can establish that the software it executes is authentic and has not been modified without authorisation. Secure or verified boot procedures, authenticated software updates and separation between critical spacecraft functions and payload applications are possible protective measures. Their effectiveness depends on the architecture, the implementation and the ability to maintain trusted components throughout the mission.
This challenge becomes more pronounced where different customers or organisations share space infrastructure. A common satellite platform may carry several payloads whose operators have different security requirements. An internal interface that appears harmless from a functional engineering perspective can become significant if it permits one component to influence another. Technical separation must then be demonstrated rather than assumed. The same is true of maintenance interfaces, debugging functions and development capabilities that may be necessary during integration but should not remain unrestricted in operational service.
Security must be demonstrated, not merely specified
The central difficulty is evidentiary. A manufacturer may state that a satellite encrypts mission data, protects cryptographic keys and authenticates commands. Those statements describe intended capabilities. They do not establish whether the functions work correctly, whether sensitive information can bypass them or whether the configuration ultimately launched into orbit corresponds to the one that was tested.
A meaningful security assessment begins by tracing sensitive information through the actual system architecture. If a classified image is captured, the assessment must establish where it is temporarily stored, where it remains readable, which components can access it and how it is transferred to an authorised recipient. The analysis must also consider less obvious locations, including diagnostic records, processing buffers and intermediate products. Sensitive information can be exposed through supporting functions even when the primary data path has been carefully protected.
The necessary evidence extends from documented security requirements and implementation records to component evaluation, integration tests and independent technical assessment. Cryptographic functions can be tested against defined requirements, while security testing can examine malformed communication packets, unauthorised access attempts, unexpected software states and failures during key changes. Hardware evaluation may reveal weaknesses associated with fault injection or unintended information leakage. Testing on representative spacecraft hardware is particularly valuable because security mechanisms often interact with timing, processing and communication constraints in ways that are difficult to reproduce through software simulation alone.
The European Space Agency maintains a Cybersecurity Laboratory with facilities for evaluating space-related hardware, software and communication protocols. Its published capabilities include hardware security testing, cryptographic evaluation, protocol fuzzing, adversarial testing and flat-sat environments. Such facilities illustrate how the security of space technologies can be investigated experimentally rather than assessed solely through documentation. The results, however, remain specific to the components, configurations and test conditions examined. Laboratory testing is not equivalent to an unrestricted guarantee of security, nor does it automatically constitute formal accreditation for the processing of classified information.
The difficulty continues after launch. Mission software may be updated, cryptographic keys replaced and operational responsibilities transferred between organisations. Each change can affect the assumptions under which the original security assessment was performed. Authenticated telemetry, controlled configuration records and, where technically supported, remote software integrity measurements can provide additional evidence about the spacecraft’s operational condition. These mechanisms have limitations. A compromised component may be unable to produce trustworthy evidence about its own state, and a monitoring system cannot necessarily detect every form of interference. Continuous assurance in orbit therefore means maintaining justified confidence in defined protective functions, not claiming to have proven the complete absence of compromise.
Long-duration missions also face the problem of cryptographic ageing. Algorithms regarded as suitable during spacecraft development may require reassessment years later. The emergence of standardised post-quantum cryptographic mechanisms makes this increasingly relevant. NIST approved its first three principal post-quantum cryptography standards in August 2024, providing an established basis for new approaches to key establishment and digital signatures. Their existence does not mean they are already deployed across operational spacecraft. Integration into satellite systems requires evaluation of processing requirements, communication overhead, implementation security and compatibility with mission hardware. For a spacecraft that may remain active for decades, the ability to adapt cryptographic mechanisms can be more important than selecting a particular algorithm at the beginning of development.
The broader organisational environment introduces another dimension. Space programmes frequently involve international manufacturers, specialist subcontractors, research institutions, launch providers and governmental customers. Sensitive technical documentation may cross company and national boundaries long before the spacecraft is assembled. Access to design files, cryptographic specifications and mission parameters must be governed by the applicable contractual and legal requirements. Where formally classified information is involved, personnel authorisations, industrial security arrangements and national or intergovernmental classification rules may impose additional restrictions.
This is where security engineering and formal secrecy protection must be distinguished. The European standard ECSS-E-ST-80C, Security in Space Systems Lifecycles, published in July 2024, establishes requirements addressing security throughout the lifecycle of space systems, including space, ground, launch and support segments. It is applicable to unclassified missions and may be tailored for classified governmental projects in accordance with the relevant national and intergovernmental rules. The standard expressly excludes the formal System Security Accreditation process from its scope. Consequently, demonstrating conformity with an engineering standard cannot, by itself, establish that a spacecraft is authorised to process a particular class of governmental information.
Even the end of a mission requires attention. A satellite may cease operations while sensitive information, cryptographic material or protected software remains in onboard storage. Decommissioning plans should address data sanitisation, key destruction and the consequences of losing the ability to communicate with the spacecraft. Securely destroying the cryptographic keys protecting stored information may, under appropriate conditions, render that information inaccessible. Whether this can be demonstrated depends on the storage architecture, key management design and the possibility of residual copies. A remotely issued deletion command should never be treated as conclusive evidence without examining how the underlying hardware implements it.
Unlike conventional information systems, a satellite cannot simply be returned to a secure facility for inspection, replacement or forensic examination. Its protective architecture must account for that limitation from the outset. The ability to demonstrate secrecy protection rests on traceable design decisions, verified technical safeguards, controlled operational procedures and an honest understanding of the evidence that can still be obtained after launch.
The question is therefore not merely whether information aboard a satellite is encrypted. It is whether the mission operator can explain, and substantiate, where sensitive information becomes accessible, how unauthorised access is prevented and why the protective mechanisms can still be trusted years after the spacecraft entered orbit.
Distance from Earth does not create confidentiality. The ability to keep a secret in space must be engineered before launch — and justified by evidence throughout the mission.
