Paper Summary: Cyber Resilience for Cislunar Space
This post summarizes my 2025 IEEE SMC-IT paper "Cyber Resilience in Cislunar Space: Security Strategies for Large-Scale Space Infrastructure" co-authored with Gregory Falco.
A round-trip signal to the Moon takes approximately 2.56 seconds. For assets at Earth-Moon Lagrange points, it's longer. That number sounds small until you think about what an attacker can accomplish in the time between detecting a compromise and getting a response command back to the spacecraft. In LEO, ground operators have near-real-time control. At lunar distances, they don't. And that's before accounting for the periods when communication is blocked entirely -- by the Moon itself, by solar interference, or by an adversary who jams your uplink at the moment you need it most.
This paper argues that the entire security paradigm has to change for cislunar space, and not incrementally.
Seven Problems That Don't Exist in LEO
We identified seven challenges that distinguish cislunar cybersecurity from the Earth-orbit security problem most people are thinking about. Communication latency is the obvious one, but it's not the hardest.
Stakeholder complexity is, in my view, the most underappreciated. A traditional satellite mission has one operator. Cislunar infrastructure involves national space agencies, commercial companies, startups, academic institutions, and international consortia -- all with different security postures, different encryption protocols, different risk tolerances. Joint missions where partners use incompatible communication frameworks aren't hypothetical; they may well become the norm. Every interface between organizations is an attack surface.
Constrained computing makes the security engineer's job difficult in ways that have no LEO equivalent. Radiation-hardened processors are optimized for reliability, not performance. Power comes from solar arrays with variable output. Every CPU cycle and every watt spent on security is a cycle and a watt not spent on the mission. You can't just run a full intrusion detection suite when your processor was designed for deterministic real-time control, not general-purpose computing. The paper argues for lightweight cybersecurity solutions that balance resource efficiency with protection -- encryption that minimizes processing overhead, anomaly detection that operates within tight telemetry bandwidth -- and sketches what this could look like, but the engineering is far from solved.
The other five -- diverse mission profiles, open communication channels vulnerable to interception, the high stakes of attacks on life-support or resource extraction, the impossibility of physical repair, and the communication intermittency I already mentioned -- each independently complicates the security picture. Together, they demand a different approach entirely.
Who Attacks a Spacecraft?
The paper lays out four categories of threat actors. The one people rarely discuss in the space context is insider threats. Not the dramatic spy scenario, but the mundane reality of collaborative missions with dozens of stakeholders. A contractor with inadequate security training clicks a phishing email. A disgruntled employee on a multi-stakeholder program introduces a vulnerability. These aren't exotic threats -- they're the same ones that plague every large organization on Earth, except the system being compromised is 384,400 kilometers away and can't be physically accessed.
Nation-states targeting competitors' lunar resource extraction, criminal organizations deploying ransomware against a habitat's life-support systems, hacktivists sabotaging autonomous mining operations they consider unethical -- the threat landscape is as varied as it is consequential. Supply chain compromise is particularly concerning in this context. A tampered component with dormant malware, activated once the satellite reaches its operational orbit. You've launched your vulnerability into cislunar space, and there's no recall.
Twelve Ways to Stay in the Fight
The core of the paper maps the NIST SP 800-160 Volume 2 cyber resilience techniques onto the cislunar environment. Twelve techniques, each adapted to the specific constraints and threats we'd identified.
A few stood out as particularly well-suited to the problem:
Adaptive response is the direct answer to the latency problem. Systems that use AI and machine learning to identify anomalies and act without waiting for ground commands. The paper gives the example of detecting navigation signal spoofing by comparing received data against historical patterns and onboard camera imagery, then autonomously switching to a verified backup signal. The system responds in milliseconds. A ground operator would take seconds at minimum -- if they're even in contact.
Non-persistence is elegant in its simplicity. Periodically reset non-critical components. Regenerate cryptographic keys on a schedule. Disable unused network ports. You're not trying to find the adversary's foothold -- you're wiping the surface they'd attach to. In cislunar space, where you can't send a forensics team, preventing persistent access is more practical than hunting for it.
Deception is the most unconventional of the twelve. Deploy a decoy relay satellite transmitting fake telemetry data, and an adversary wastes resources attacking it while you gain intelligence on their tactics. It also acts as a deterrent by increasing the cost and complexity of successful attacks -- particularly useful given the expanded attack surface of cislunar networks, where it's harder for an adversary to distinguish real assets from decoys across vast distances.
The remaining nine -- redundancy, segmentation, analytic monitoring, dynamic reconfiguration, substantiated integrity, privilege restriction, realignment, diversity, and coordinated protection -- are each discussed with specific cislunar applications. Redundancy through multiple relay satellites on different orbits. Segmentation isolating life-support from public communication interfaces. Coordinated protection sharing threat intelligence between lunar habitats, relay satellites, and ground stations in real time.
The Window Is Open
What makes this paper urgent rather than academic is timing. Cislunar infrastructure is being designed and built right now. The architectural decisions being made today -- communication protocols, trust models, access control frameworks -- will be locked in for the operational lifetimes of these systems. We have the chance to build security in from the start instead of bolting it on after the architecture is frozen, which is exactly what happened with the terrestrial internet. The NIST resilience framework gives us a structured way to do it. Whether the community uses it is a different question.