IN Brief:
- The proposed EU Space Act introduces tailored cybersecurity obligations for space operators.
- Certain serious incidents would trigger early warnings within 12 or 24 hours, followed by fuller reporting.
- Threat-led penetration testing could become a pre-launch and recurring requirement for covered high-risk systems.
The proposed EU Space Act would bring cybersecurity deeper into spacecraft design, production, testing, and supply-chain management, treating digital resilience as a core engineering requirement throughout the system lifecycle.
Although the legislation remains under negotiation and its final wording may change, the current proposal establishes resilience obligations for space operators serving the European market, including incident reporting, risk management, business continuity, and security testing.
For significant incidents affecting Union-owned space assets, an early warning could be required within 12 hours. Other covered incidents would generally carry a 24-hour early-warning period, followed by a fuller notification within 72 hours as more reliable technical information becomes available.
Threat-led penetration testing could also be required before launch and at least every three years for operators and systems falling within the relevant high-risk scope. For satellites, where physical access disappears after deployment, finding weaknesses before launch is substantially more valuable than documenting them after the spacecraft reaches orbit.
A terrestrial product with a security flaw can often be recalled, patched locally, or isolated. A satellite may remain in service for 10 or 15 years with limited computing resources, constrained communications, radiation-hardened electronics, and a command architecture fixed years before launch.
Compliance begins during design
Manufacturers will need to identify which processors, operating systems, cryptographic modules, communications links, ground interfaces, and supplier components sit within the security boundary. That inventory must remain accurate as designs change and substitute parts are introduced.
Software assurance will extend across flight code, payload applications, ground systems, mission planning, telemetry, tracking and control, update mechanisms, and cloud services. A weakness in any one of those areas can affect spacecraft availability even when the satellite remains physically healthy.
Pre-launch penetration testing cannot be left until final integration if engineers need time to redesign hardware, alter interfaces, or replace components. Representative development units, security test points, and controlled access to software baselines must be planned early enough to support meaningful assessment.
Contracts between primes and lower-tier suppliers will increasingly require evidence of vulnerability-handling processes, secure development, component histories, software inventories, update commitments, and rapid technical support after an incident.
Smaller suppliers may face a disproportionate burden because a company producing one sensor interface or cryptographic device could receive different assurance demands from several operators and national authorities. Consistent European guidance would reduce duplication and allow suppliers to build common evidence packs around qualified products.
Without that consistency, contractors could spend heavily satisfying different interpretations of the same requirement while delivering little additional security.
Hardware choices become cyber decisions
Satellite electronics are selected years before launch and often prioritise radiation tolerance and reliability over the latest commercial performance. Cryptographic agility and updateability must therefore be designed into systems with tight constraints on power, memory, processing, bandwidth, and physical space.
Hardware-rooted protection is already moving into satellite links, including Xiphera’s development of dedicated cybersecurity technology for ESA communications. Dedicated components can improve assurance and performance, although they also create lifecycle obligations around trusted fabrication, key provisioning, firmware updates, and secure disposal.
Ground infrastructure can be upgraded more readily, but commercial cloud platforms, third-party networks, remote maintenance, and globally distributed stations expand the attack surface beyond the operator’s direct facilities.
The proposed reporting deadlines will require stronger monitoring because credible notification within hours is impossible when operators need days to distinguish malicious activity from radiation effects, component failure, interference, or operator error.
Spacecraft and ground systems will need improved telemetry, logging, time synchronisation, and forensic data retention. Those functions consume processing, bandwidth, storage, and engineering effort, giving cybersecurity a measurable effect on physical design.
Non-European manufacturers could also be affected where operators supply services into the EU. Primes may favour common compliant product baselines rather than create separate European variants, gradually extending the regulation’s influence into global satellite supply chains.
Defence and dual-use constellations will require careful handling where commercial reporting obligations intersect with national-security controls. Authorities need enough information to coordinate incidents without exposing sensitive configurations, vulnerabilities, or operational activity.
The industrial effect will depend on proportionality. Excessive prescription could slow programmes and deter smaller entrants, while weak requirements would do little to protect the space services increasingly used by governments, armed forces, logistics networks, energy systems, and communications providers.
By placing security testing before launch, the proposal moves assurance to the stage where engineers can still alter hardware, software, and architecture. Cyber weaknesses discovered after a satellite has been sealed, integrated, or placed in orbit are expensive to manage and sometimes impossible to remove.
