Link to the code: Zae-Project / arkspace-core

War in Space: Securing Orbital Computing against Cyber and Physical Threats in 2026

The assumption embedded in every orbital computing proposal is that satellites, once deployed, can operate without interference. That assumption is becoming harder to defend. In 2026, space is not just a platform for infrastructure. It is a contested domain, and the distinction matters for anyone building communications networks, data centers, or AI systems above the atmosphere.

Linda Dawson’s 2026 book War in Space: The Science and Technology Behind Our Next Theater of Conflict surveys a threat landscape that has moved well beyond theory. Jamming, spoofing, directed energy weapons, co-orbital anti-satellite systems, and cyberattacks against ground stations are not speculative scenarios. They are documented operational capabilities held by China, Russia, the United States, and an expanding list of secondary actors.

What the Threat Landscape Actually Looks Like

The SpaceSec 2026 workshop, co-located with the Network and Distributed System Security Symposium in February 2026, published a set of research papers that catalogued attack surfaces across satellite infrastructure. The findings are consistent with what military analysts have been reporting, but expressed in engineering terms that make the scope concrete.

Ground stations represent the most accessible attack surface. Every satellite requires command and control uplinks. These ground segment interfaces, often operated at commercial facilities under varying security standards, provide the most direct path to disrupting or seizing control of a space asset. The 2022 Viasat KA-SAT attack, in which Russian military hackers disabled modems across Ukraine at the start of the invasion, remains the defining example. The attack exploited a ground segment management system, not the space segment itself.

The space segment presents different challenges. CubeSats and small commercial satellites frequently use commercial off-the-shelf components, including processors and radios not designed with adversarial threat models in mind. The same open protocols that make small satellite development affordable make them easier to reverse-engineer and exploit. A 2025 academic paper from researchers at the University of Texas demonstrated command injection against a simulated CubeSat ground control interface using techniques available to any competent security researcher.

Inter-satellite links introduce a third vector. The optical inter-satellite link architectures being deployed across Starlink Gen 2 and proposed for systems like China’s Three-Body Computing Constellation create mesh networks where a compromised node can potentially intercept or corrupt routing. Optical links are harder to jam than radio frequency systems, but they are not immune to denial through directed energy or physical interception at scale.

The Physical Threat: Anti-Satellite Weapons in 2026

The cybersecurity concern exists alongside a physical threat environment that has evolved significantly since 2007, when China’s direct-ascent anti-satellite test created 3,500 trackable debris pieces and demonstrated that LEO assets are vulnerable to kinetic attack.

By 2026, co-orbital anti-satellite systems, spacecraft that maneuver close to targets and can disable them through electronic interference, physical grappling, or directed energy, represent a more operationally attractive option than kinetic kill. They avoid the debris creation problem that makes kinetic ASAT politically costly. Russia’s Cosmos-2576 satellite, which maneuvered within miles of a U.S. intelligence satellite in 2024, demonstrated co-orbital inspection capabilities that are one design decision away from active interference.

This context shapes how orbital infrastructure needs to be designed. The space debris problem analyzed in detail elsewhere focuses on accidental collision risk. The co-orbital threat is deliberate. A constellation designed only to survive debris strikes will not necessarily survive a coordinated effort to degrade it.

What Distributed Architecture Actually Provides

The security implications of distributed versus centralized orbital infrastructure are not obvious on the surface. A single large orbital data center is an attractive, high-value target. A constellation of thousands of smaller nodes with distributed compute and redundant communication paths offers a different security profile: individual node loss, whether from debris, jamming, or physical attack, degrades service rather than eliminating it.

This is one of the arguments for constellation architectures like those proposed by SpaceX’s orbital data center filing and demonstrated at smaller scale by edge AI systems in the D-Orbit AIX constellation. A mesh architecture with distributed compute naturally provides resilience against localized attacks in ways that a centralized hub cannot.

The tradeoff is operational complexity. Managing cryptographic key distribution, certificate rotation, and firmware attestation across thousands of satellite nodes is harder than securing a single facility. The software-defined satellite architectures becoming standard in 2026 help here: over-the-air updates that can patch vulnerabilities without physical access are increasingly table stakes for operational constellations.

Encryption at the Orbital Edge

The SpaceSec 2026 research highlights several architectural requirements for securing small satellite systems. End-to-end encryption of the command and control link is the baseline, but many operational systems still use proprietary or legacy protocols with known weaknesses.

Forward secrecy, the property whereby a compromised session key does not retroactively expose past communications, is particularly relevant for satellites where ground contact windows are limited and key rotation schedules must account for orbital geometry. A satellite that cannot receive a key refresh during a multi-hour contact blackout needs session management systems designed around that constraint.

Authentication of command sources, making sure a satellite obeys only legitimate ground operators, is complicated by the distributed ground station architectures that commercial operators use to maintain higher contact frequency. Multiple ground station operators handling the same constellation creates a larger authentication perimeter than a single dedicated facility.

The AES-256-GCM encryption approaches analyzed for orbital systems provide a technical baseline, but implementation details matter. The latency budget for key exchange in a satellite communication system, explored in the context of the 50ms challenge facing orbital networks, constrains which cryptographic protocols are viable in practice.

Military and Commercial Infrastructure: The Dual-Use Problem

Starlink’s role in the Ukraine conflict established a precedent with significant implications for commercial orbital infrastructure. A commercial communications constellation became a critical military communications network, and as a result, it became a military target. Russia attempted jamming and reportedly evaluated kinetic options against Starlink ground infrastructure.

The dual-use trajectory of orbital computing infrastructure creates the same dynamic. A distributed orbital AI network that provides commercial compute services will, if it proves operationally valuable, attract attention from military planners on all sides. Designing for military-grade resilience is not a choice that commercial orbital operators can defer indefinitely.

This is the core tension that Dawson’s analysis identifies: commercial space infrastructure is being built at a pace that outpaces the security standards and regulatory frameworks designed for it. The gap between what is being deployed and what those deployments need to survive in a contested environment is a risk that the entire commercial space industry is collectively accumulating.

The telecommunications satellite roaming infrastructure being built in 2026 is illustrative. Direct-to-device connectivity, where satellites connect directly to standard mobile phones, creates a communication layer with national security implications in every country where it operates. Regulators are beginning to understand this, but standards development lags well behind deployment timelines.

Path Forward

The trajectory of orbital security is likely to follow the pattern of terrestrial internet security: vulnerabilities will be discovered, exploited, disclosed, and patched across an extended period, with significant incidents along the way. The orbital environment adds physical constraints, latency, and remote management limitations that make the security lifecycle harder than terrestrial equivalents.

What distinguishes the next five years is scale. The mega-constellation race between Logos Space, Kuiper, and Starlink will put tens of thousands of additional nodes in orbit. Each of those nodes is a potential attack surface. The security architecture decisions being made today in constellation design, ground segment software, and inter-satellite link protocols will determine the actual threat resilience of an orbital computing ecosystem that will serve not just commercial customers but increasingly critical infrastructure.

The physical environment in orbit does not forgive poor design choices. Neither, as the Viasat incident demonstrated, does the geopolitical one.

Official Sources