How Hackers Actually Attack Satellites
The popular image of a satellite hacker is almost cinematic: someone points an antenna at the sky, breaks an orbital computer in minutes and takes control of a spacecraft.
Reality is more interesting—and more dangerous.
A satellite service is not a single machine floating above Earth. It is a distributed cyber-physical system made from spacecraft, mission-control networks, cloud services, tracking antennas, software pipelines, radio links, customer terminals, third-party providers and human operators. An attacker does not need to reach orbit if a forgotten VPN appliance, a stolen administrator session or an over-trusted modem-management network can produce the same operational effect.
That is exactly why the phrase “satellite hack” can be misleading. Some incidents compromise a ground network. Others manipulate customer equipment, interfere with a radio signal, poison navigation data or abuse software already authorised to run onboard. Only a much smaller class of attack reaches a spacecraft's command or flight-software layer directly.
The real question is therefore not, “Can someone hack a satellite?” It is:
Which trust relationship connects an attacker on Earth to an operational effect in space?
This article maps those relationships, explains the main attack paths and shows what serious satellite security looks like—without the science-fiction shortcuts.
Key takeaways
The ground segment is often the most practical entry point because it uses familiar IT: identity providers, VPNs, workstations, APIs, cloud platforms and vendor connections.
A satellite system has at least four major security domains: space, ground, communications link and user—plus a supply chain spanning all four.
Jamming, spoofing and cyber intrusion are different mechanisms. They can create similar outages, but the engineering and defences are not interchangeable.
Encryption alone is insufficient for command links. Commands also need authenticity, integrity, authorisation and anti-replay protection.
The hardest problem is often not preventing every compromise. It is preserving a safe, independently recoverable control path when part of the system is already untrusted.
A satellite is a system, not a box in the sky
Security discussions frequently collapse an entire satellite service into the spacecraft. That hides most of the attack surface.
The NIST satellite ground-segment profile describes space operations as an interdependent cyber ecosystem. A useful working model divides it into the following domains:
DomainTypical componentsSecurity consequence if compromisedSpace segmentSpacecraft bus, payload, flight computer, attitude control, power, propulsion, onboard networks and flight softwareLoss of mission data, unsafe pointing, payload misuse, degraded control or permanent mission lossGround segmentMission operations centre, payload control centre, antennas, baseband systems, cloud workloads, operator consoles and scheduling systemsTheft or manipulation of telemetry, unauthorised commanding, loss of availability or fleet-wide accessLink segmentTelemetry, tracking and command (TT&C), payload links, feeder links, crosslinks and terrestrial backhaulInterception, jamming, spoofing, replay, traffic analysis or command/data corruptionUser segmentConsumer terminals, VSAT modems, GNSS receivers, maritime and aviation equipment, phones and enterprise gatewaysLarge botnets, service disruption, false position/time data or a route into provider management systemsSupply chain and lifecycleChip vendors, firmware, open-source packages, CI/CD, integration labs, launch support, managed services and disposal processesCompromise before launch, poisoned updates, stolen signing keys or inherited third-party access
The spacecraft itself also has two important halves.
The bus keeps the vehicle alive and controllable. It commonly includes command and data handling, electrical power, thermal control, attitude determination and control, and sometimes propulsion. The payload performs the mission: imaging Earth, relaying communications, measuring weather, providing navigation signals or running an experimental workload.
These halves should not share unlimited trust. A compromised payload should not automatically gain the authority to rewrite flight software, disable safe mode or command an unsafe manoeuvre. NASA's Space Security Best Practices Guide explicitly promotes domain separation and least privilege across onboard architecture, communications and control.
What “hacking a satellite” can actually mean
The phrase covers several technically distinct outcomes:
Service disruption — users lose connectivity even though the spacecraft remains healthy.
Ground-system compromise — an attacker enters mission or network operations infrastructure.
Terminal compromise — customer equipment is disabled, conscripted or used as a stepping stone.
Signal interference — legitimate signals are overwhelmed, imitated or manipulated.
Data compromise — payload data or telemetry is stolen, altered or selectively suppressed.
Command-path compromise — an attacker can create, modify, replay or authorise spacecraft commands.
Onboard compromise — malicious code crosses into a payload, control layer or flight computer.
Those outcomes are not equivalent. Disabling 30,000 satellite modems is operationally serious, but it is not proof that an attacker controlled the satellite. Conversely, quietly altering imagery or timing data may be more strategically damaging than an obvious outage.
The security objectives go beyond the standard confidentiality, integrity and availability triad:
Authenticity: Did this command or telemetry frame come from the claimed source?
Freshness: Is it new, or is an attacker replaying a previously valid transmission?
Safety: Can a valid but dangerous command push the vehicle outside physical limits?
Recoverability: Can operators restore trusted control after keys, software or ground infrastructure are compromised?
Attribution: Can defenders distinguish equipment failure, accidental interference and hostile action?
The most realistic attack paths
1. Compromising operator identities
The shortest path toward a high-consequence system may begin with an inbox.
Mission operators, ground-station engineers, software developers, vendors and support staff all hold different pieces of authority. Phishing, session-token theft, infostealer malware, password reuse, push-notification fatigue and compromised contractor accounts can turn a valid identity into an attacker's entry point.
This is especially dangerous when the same identity plane spans ordinary corporate IT and mission operations. A cloud single sign-on account that can reach source repositories, deployment tools, telemetry dashboards and privileged access systems becomes an unusually valuable target.
The critical control is not merely “enable MFA”. Satellite operators need phishing-resistant authentication, hardware-backed credentials, device trust, short-lived privileged sessions and separate administrative identities. Commands capable of changing flight software, cryptographic state or vehicle attitude should require stronger approval than reading routine telemetry.
2. Entering through the ground network
Ground infrastructure contains many of the same weaknesses as any enterprise network:
internet-facing VPNs and firewalls;
remote desktop and vendor-support paths;
unpatched operating systems and appliances;
flat or over-trusted management networks;
exposed APIs and cloud-control planes;
poorly protected secrets, backups and signing keys;
engineering workstations that bridge development and operations;
legacy systems that cannot be patched without disrupting a mission.
The difference is consequence. On a normal enterprise network, lateral movement may end at a database. In a mission environment, it may end at a system that schedules antenna time, generates commands, distributes firmware or manages an entire terminal fleet.
This is why network access and command authority must be separate security decisions. Reaching a mission network should not be enough to issue an operational command. Command generation, validation, approval, transmission and spacecraft acceptance should each create an auditable control boundary.
3. Abusing legitimate management functions
An attacker does not always need custom malware. Existing administration tools may already provide the required destructive capability.
If a trusted management platform can update thousands of terminals, reset configurations or change network policy, compromising that platform gives an attacker scalable impact. To monitoring systems, the traffic may initially resemble legitimate administration because it uses real protocols, valid routes and expected management commands.
This is a recurring lesson across operational technology: the authorised control plane can be more dangerous than an unauthorised packet.
Defenders therefore need behavioural controls around legitimate tools—approval gates, scoped roles, fleet-size limits, staged changes, tamper-evident logs and alerts when one operator or service account attempts an unusual mass action.
4. Attacking user terminals
The user segment is large, geographically distributed and often physically accessible to customers or hostile researchers. It may include inexpensive hardware produced at consumer scale, long-lived firmware, web-management interfaces, supply-chain dependencies and recovery mechanisms designed for convenience.
A compromised terminal can be used to:
disrupt the individual subscriber;
generate abusive traffic toward the provider;
extract credentials or device keys;
inspect the service's protocols and update mechanism;
falsify terminal state or billing data;
pivot toward a management environment where segmentation fails.
Terminal fleets create an asymmetric risk: one weakness may be replicated across hundreds of thousands of devices. Secure boot, per-device identities, signed updates, anti-rollback controls, vulnerability reporting and a reliable recovery path are therefore essential. A fleet-wide update system also needs its own blast-radius controls; its legitimate power makes it a prime target.
5. Jamming the radio link
Jamming is a denial-of-service attack against the signal rather than a conventional intrusion into software. A jammer attempts to reduce the legitimate signal-to-interference-plus-noise ratio at a receiver until that receiver can no longer demodulate the transmission reliably.
The basic propagation problem is captured by the Friis transmission relationship:
$$
P_r = P_t G_t G_r \left(\frac{\lambda}{4\pi R}\right)^2 \frac{1}{L}
$$
where $P_r$ is received power, $P_t$ is transmitted power, $G_t$ and $G_r$ are antenna gains, $\lambda$ is wavelength, $R$ is distance and $L$ represents additional losses.
The equation explains two different attack geometries:
Downlink jamming targets receivers on Earth. Because the malicious transmitter can be much closer to those receivers than the satellite is, local disruption may be achievable without affecting users elsewhere.
Uplink jamming targets the receiver onboard the satellite or a bent-pipe transponder. It is generally more demanding because the interfering signal must survive the path to orbit, but successful interference can affect a much wider service area.
Encryption does not prevent jamming. A receiver can be denied access to perfectly encrypted data if it cannot distinguish the signal from interference. Relevant mitigations include directional antennas, interference monitoring, adaptive coding, redundant links, lawful frequency agility, alternative ground stations and procedures for locating the interference source.
The European Union Agency for Cybersecurity's space threat landscape lists jamming among the principal threats to commercial satellite operations.
6. Spoofing signals and data
Spoofing is deception, not simple noise. The attacker attempts to make a receiver accept a counterfeit signal, message or measurement as legitimate.
GNSS spoofing is the best-known example. A receiver estimates position and time from carefully timed signals. If counterfeit signals are accepted and gradually pull those measurements away from reality, dependent systems may calculate a false position, velocity or clock value without immediately declaring a loss of service.
The downstream consequences can extend beyond navigation. Precise time supports telecommunications, financial infrastructure, power systems and distributed computing. A false but plausible timing input may therefore corrupt another system far from the radio receiver.
Spoofing can also target telemetry or payload data. An operations screen that displays fabricated but believable spacecraft health data could delay incident response. Altered imagery or sensor data could affect decisions without ever changing the spacecraft's orbit.
Resilience requires more than encryption. Systems should cross-check independent sensors, validate physical plausibility, monitor signal characteristics, authenticate messages where the service supports it and fail safely when trusted measurements disagree.
7. Replaying or forging commands
A command can be secret and still unsafe.
Encryption provides confidentiality: it hides content. It does not automatically prove who created a message, whether it changed in transit or whether it is an old valid command being transmitted again. A robust command link needs:
cryptographic source authentication;
message integrity;
anti-replay state, such as counters or sequence controls;
explicit authorisation for the requested operation;
safe handling of lost synchronisation and key rollover.
The Consultative Committee for Space Data Systems' Space Data Link Security guidance distinguishes authentication from authenticated encryption and includes integrity and anti-replay protections. That distinction matters: “the link is encrypted” is not a complete command-security claim.
Key management is equally important. Keys must be generated, stored, distributed, rotated, revoked and recovered across missions that may operate for years or decades. A cryptographically strong protocol can still fail operationally if one shared key is copied across a fleet, stored in a build log or impossible to replace after launch.
8. Exploiting onboard software
Direct onboard compromise is possible, but it usually demands a chain of prerequisites. The attacker needs a path to deliver input to the vehicle, a vulnerability in reachable code, a way to cross privilege or isolation boundaries and enough understanding of the target to create a useful effect without merely crashing it.
Potential entry points include:
payload applications that accept uploaded workloads;
telecommand parsers and file-transfer services;
onboard networking between payload and bus;
unsafe memory handling in flight or payload software;
diagnostic or maintenance functions left enabled;
a vulnerable component introduced before launch;
a malicious but correctly signed software package after a signing-system compromise.
Spacecraft make remediation unusually difficult. Bandwidth may be narrow, contact windows intermittent and latency substantial. Hardware cannot be physically replaced. A failed patch can end the mission, while radiation effects and ordinary component faults can resemble malicious behaviour.
This makes onboard resilience as important as prevention: secure or measured boot, signed software, privilege separation, memory protection where available, command allow-lists, watchdogs, redundant computers, safe mode and a known-good rollback image.
9. Compromising the software and hardware supply chain
A satellite's trust is assembled long before launch.
Commercial off-the-shelf components, open-source libraries, FPGA designs, firmware blobs, test equipment, contractor laptops, build servers and code-signing services all influence what eventually flies. A backdoor inserted during development may be almost impossible to remove once the vehicle is in orbit.
The supply-chain problem continues after launch. Ground software receives updates; terminals receive firmware; cloud services change continuously; vendors retain maintenance access; cryptographic libraries age; and ownership may pass between organisations.
Effective controls include software bills of materials, dependency and provenance checks, protected build pipelines, isolated signing systems, reproducible or independently verified builds where practical, component testing, supplier access reviews and a documented process for vulnerability disclosure and emergency patching. ENISA's 2025 guidance specifically calls for robust supply-chain security and testing before components enter production.
Case study: KA-SAT was a ground-and-terminal attack—not a spacecraft takeover
On 24 February 2022, a cyberattack disrupted KA-SAT broadband service as Russia began its full-scale invasion of Ukraine. The European Union later attributed the operation to the Russian Federation.
The incident is one of the clearest demonstrations of the real satellite attack surface.
According to Viasat's incident report, the attacker exploited a misconfiguration in a VPN appliance to enter a trusted ground-based management segment. After moving laterally, the attacker used legitimate management commands against large numbers of residential modems. Those commands overwrote key data in flash memory, causing tens of thousands of devices to leave the network.
The spacecraft did not need to be compromised. Viasat reported no evidence that the KA-SAT satellite itself, its supporting satellite ground infrastructure or standard firmware-distribution process had been directly compromised.
The attack chain can be summarised without sensationalism: a ground-facing access weakness led into a trusted management network; lateral movement reached legitimate fleet-management capability; destructive commands were then sent to customer modems, producing a large-scale satellite-service outage.
The lesson is uncomfortable but useful: attackers optimise for effect, not for narrative purity. If disabling the terminals produces the desired outage, taking over an orbital vehicle would add difficulty without adding value.
Case study: ESA's OPS-SAT showed what onboard compromise could look like
In 2023, ESA, Thales and CYSEC conducted a controlled cybersecurity demonstration on OPS-SAT, an experimental spacecraft designed to run external experiments.
The authorised team uploaded software that appeared harmless but intentionally introduced a vulnerability. They later exploited it to access a normally restricted control layer. ESA reported that the team could replace an image from the spacecraft's camera and alter the vehicle's attitude—its orientation in space.
This was not an uncontrolled attack on an ordinary operational satellite. ESA supervised the exercise, tested it first on an identical ground copy, retained control and restored the spacecraft to a safe state. OPS-SAT's unusual mission also allowed external teams to execute onboard software, a condition ESA emphasised was not representative of its other satellites.
Even with those caveats, the OPS-SAT demonstration proved several important points:
uploaded payload software must be treated as hostile until proven otherwise;
payload and bus privileges need hard separation;
pre-deployment testing cannot replace runtime containment;
safe-state recovery and known-good rollback are genuine security controls;
offensive testing can expose assumptions that architecture reviews miss.
Why satellites are unusually difficult to secure
Long lifetimes collide with short technology cycles
A spacecraft may remain operational long after its processors, cryptographic choices and development toolchain become obsolete. Ground systems can sometimes be modernised; flight hardware cannot.
Availability is governed by physics
Low-Earth-orbit satellites may only be visible to a particular ground station for minutes at a time. Deep-space missions introduce long delays. A security update that assumes a continuous, low-latency connection may be unusable.
Safety and cybersecurity can conflict
Aggressive account lockout, automatic isolation or an untested patch may prevent operators from recovering a distressed vehicle. Conversely, a broadly accessible emergency path may become an attacker's bypass. These controls must be engineered together, not added independently.
Resource constraints are real
Cryptography, logging, endpoint monitoring and redundant storage consume processing time, power, bandwidth and mass. Modern systems can support much stronger protections than earlier generations, but every control still competes with mission requirements.
Failure and attack can look alike
Radiation-induced bit flips, antenna misalignment, clock drift, software defects, congestion and deliberate interference can all produce anomalies. Detection logic needs engineering context; conventional IT alerts alone cannot explain the vehicle's physical state.
Multiple organisations share the service
Commercial space is moving from vertically integrated missions toward hybrid architectures assembled from independently owned spacecraft, payloads, cloud platforms, ground stations and networks. NIST IR 8441 warns that this increases the need for a shared understanding of risk across stakeholders.
A defensible satellite-security architecture
There is no single product that “secures a satellite”. Resilience comes from layered controls that assume some components will eventually fail or be compromised.
Protect the command chain end to end
Treat the full path—from the operator's action to the spacecraft's command decoder—as one security-critical transaction.
Use authenticated encryption or authentication plus integrity and anti-replay controls.
Keep mission keys in hardware-backed systems and separate them from general IT secrets.
Use unique keys and security associations rather than one fleet-wide secret.
Apply two-person integrity to mission-ending commands.
Bind approval to the exact command, target vehicle and validity window.
Make the spacecraft reject stale, malformed, unauthorised or physically impossible commands.
Design and test emergency key rollover before launch.
Isolate mission operations
Corporate email, web browsing and collaboration tools should not share an unrestricted trust path with TT&C systems.
Segment mission operations, payload operations, engineering, terminal management and corporate IT.
Place protocol breaks and policy enforcement between zones.
Restrict vendor access by time, device, identity and task.
Use dedicated privileged workstations for critical administration.
Require outbound as well as inbound controls; compromised ground software may call an attacker's infrastructure.
Monitor every path capable of reaching the command-generation process.
Isolation does not mean pretending interconnections do not exist. It means making each interconnection explicit, narrow, authenticated and observable.
Make legitimate administration safe at scale
Fleet-management systems require guardrails proportional to their reach.
Limit how many devices one operation can affect.
Roll out changes in stages with health checks and automatic stop conditions.
Require independent approval for mass destructive or reset actions.
Keep immutable records of who approved, generated and transmitted a change.
Test terminal recovery at fleet scale, not only in a laboratory.
Build resilience into the spacecraft
The vehicle must retain a minimal trusted core even when a payload or ground component is hostile.
Separate payload, bus and safety-critical control domains.
Enforce least privilege between processors and onboard networks.
Verify software before execution and protect the verification root.
Maintain safe mode, watchdogs and independently recoverable command paths.
Store a known-good image with anti-rollback policy that still permits authorised emergency recovery.
Constrain high-risk commands using vehicle state, timing and physical safety rules.
Detect cyber events in operational context
Satellite detection engineering must join cyber telemetry with RF and spacecraft telemetry.
Useful signals include:
a new operator device issuing commands;
impossible travel or abnormal privileged-session timing;
command volume outside the mission plan;
a valid command transmitted through an unusual antenna or ground provider;
signal-power, Doppler or timing characteristics inconsistent with the expected source;
disagreement between commanded state and independent sensor measurements;
simultaneous terminal failures clustered by firmware, gateway or management partition;
unexpected changes to build, signing or scheduling systems.
Logs should connect identity, approval, command generation, ground routing, RF transmission, spacecraft receipt and resulting state change. If those records live in separate organisations and cannot be correlated quickly, incident response will stall at the worst possible moment.
Practise recovery before it is needed
Recovery plans that have never been exercised are architectural guesses.
Operators should test scenarios including:
loss of the primary mission operations centre;
compromise of an identity provider;
suspected theft of command keys;
malicious terminal updates;
jamming at the primary ground station;
corrupted telemetry;
a payload attempting to cross into the bus;
loss of trusted time or navigation;
recovery using a secondary station, clean environment and emergency keys.
NASA's security guidance frames resilience around preventing adversaries from denying, degrading, disrupting, deceiving or destroying mission information and technology. That last part matters: a mission can remain physically intact while its data becomes untrustworthy.
What satellite security teams should prioritise first
For an operator starting from an uneven security baseline, the following sequence reduces high-consequence risk quickly:
Map the real system. Inventory every organisation, identity, application, radio link, terminal class, key store, software pipeline and vendor connection that can influence mission or service state.
Trace every command path. Document how a command is requested, approved, generated, protected, transmitted, accepted and audited.
Remove implicit trust. Separate network reachability from authority; eliminate shared accounts and permanent vendor access.
Strengthen command authenticity. Implement integrity, anti-replay, granular authorisation and workable key rollover—not encryption alone.
Control blast radius. Prevent a single account, management server or update action from changing an entire fleet without staged approval.
Preserve independent recovery. Maintain clean backups, known-good onboard software, alternate ground capability and credentials that do not depend on the compromised identity plane.
Exercise realistic incidents. Include RF engineers, flight dynamics, safety, cloud teams, terminal operations, legal teams, suppliers and executive decision-makers.
The CISA space-systems guidance, NIST's commercial satellite and ground-segment publications, NASA's mission-security guidance and ENISA's commercial space threat landscape provide useful starting points. None replaces a mission-specific threat model.
Five satellite-hacking myths that need to disappear
Myth 1: An attacker needs a giant dish
Not if the initial target is an operator's identity, a cloud API, a VPN appliance, a software repository or a customer terminal.
Myth 2: Encryption stops hostile interference
Encryption can protect content. It cannot stop a jammer from preventing the receiver from obtaining that content.
Myth 3: If the satellite stayed healthy, the attack failed
KA-SAT demonstrated the opposite. Disabling the user segment can create a strategically significant service outage without touching the spacecraft.
Myth 4: Valid commands are safe commands
A stolen account or compromised management system may generate syntactically and cryptographically valid actions. Safety constraints, authorisation and independent approval still matter.
Myth 5: Space systems are isolated
Modern missions depend on cloud infrastructure, software suppliers, internet-connected business systems, shared ground networks and remote support. Isolation must be demonstrated at each trust boundary; it cannot be assumed from the satellite's altitude.
The next attack surface is already arriving
Software-defined payloads, cloud-hosted mission control, ground-station-as-a-service, optical and radio crosslinks, autonomous operations, direct-to-device connectivity and very large constellations are changing the economics of space.
They also change the security model.
Automation can reduce human error but allows one compromised control plane to act faster. Shared ground infrastructure can improve resilience but adds third-party trust. Reprogrammable payloads extend mission life but create new update and isolation requirements. Inter-satellite links improve coverage while allowing security failures to propagate across a mesh. Long-lived spacecraft also need cryptographic agility so algorithms and keys can change without replacing the hardware.
The industry cannot bolt security onto the last integration milestone. Decisions about processor isolation, key storage, safe mode, software update authority and recovery are architectural. Once the rocket leaves the pad, some mistakes become permanent.
The real lesson
Hackers do not care whether defenders classify an asset as “space”, “cloud”, “telecoms” or “enterprise IT”. They follow trust.
They look for the account that can approve an upload, the appliance guarding a management network, the API that controls a terminal fleet, the payload that trusts the bus, the receiver that cannot authenticate its input or the recovery process that depends on the same systems already compromised.
That is how satellite attacks should be modelled: not as a dramatic leap from a laptop to orbit, but as a chain of ordinary and extraordinary technologies whose permissions eventually converge on a physical mission.
The satellite may be hundreds or thousands of kilometres away. Its attack surface is often much closer.
Frequently asked questions
Can hackers really take control of a satellite?
Yes, it is technically possible if an attacker gains a usable command path or exploits reachable onboard software. However, a full spacecraft takeover is more difficult than compromising ground systems, customer terminals or radio services. Public reports often use “satellite hack” for incidents in which the spacecraft itself was not breached.
What is the easiest part of a satellite system to attack?
There is no universal answer, but internet-connected ground infrastructure and user terminals often present more familiar and accessible attack surfaces than flight hardware. Identities, VPNs, remote-support paths, cloud APIs and fleet-management systems deserve particular attention.
Can someone hack a satellite with a home antenna?
Receiving an unencrypted downlink is not the same as controlling a spacecraft. Transmitting a valid command requires the correct radio path, protocol, timing and—on a properly designed system—cryptographic authentication and authorisation. Unauthorised transmission may also be illegal and dangerous.
What is the difference between satellite jamming and spoofing?
Jamming attempts to deny reception by overwhelming or degrading a signal. Spoofing attempts to deceive a receiver into accepting a false signal or data source. Jamming primarily threatens availability; spoofing primarily threatens authenticity and integrity.
Does encrypting a satellite link make it secure?
Not by itself. Secure links also need message integrity, source authentication, anti-replay protection, authorisation, safe key management and resilience against radio-frequency interference. Encryption alone does not prevent jamming or the abuse of valid credentials.
What was the KA-SAT cyberattack?
It was a February 2022 attack that disrupted satellite broadband in Ukraine and other parts of Europe. Viasat reported that attackers entered a trusted ground-management network through a misconfigured VPN appliance and used legitimate management commands to disable tens of thousands of customer modems. Viasat found no evidence that the KA-SAT spacecraft itself was compromised.
Sources and further reading
NIST IR 8270: Introduction to Cybersecurity for Commercial Satellite Operations
NIST IR 8441: Cybersecurity Framework Profile for Hybrid Satellite Networks
CCSDS: Space Data Link Security Protocol—Summary of Concept and Rationale
ENISA: From Cyber to Outer Space—A Guide to Securing Commercial Satellite Operations
European Space Agency: OPS-SAT In-Orbit Cybersecurity Demonstration
Stay Ahead of the Threat
Get the latest cybersecurity insights, breaking news, and threat intel straight to your inbox.