NASA’s October 8, 2026, Artemis architecture briefing places lunar cybersecurity across ground facilities, spacecraft, relay networks, and proposed surface infrastructure. Presented by Johnson Space Center’s Brian O’Hagan at the Global Cyber Research Institute Summit, the document describes security as a design requirement for interconnected lunar operations. Its central issue is how systems supplied by NASA, commercial companies, and international partners can exchange information without losing control of commands and access.
The NASA Artemis Plan is a planning presentation, not a completed security standard or evidence that the illustrated infrastructure has been deployed. Its diagrams connect landing systems, rovers, habitats, power facilities, and communications services across proposed development phases. Those relationships identify where compatibility and security decisions will be needed before equipment from different organizations can function together.
The briefing begins its security discussion on Earth. Ground stations, networks, mission control, and launch control remain part of the systems that operate spacecraft. Protecting a vehicle’s onboard computer would leave an incomplete defense if unauthorized activity could enter through the facilities that prepare or transmit its commands. The presentation identifies these terrestrial systems as immediate areas of concern because they are comparatively accessible.
It then separates low Earth orbit, Earth–Moon transit, lunar orbit, and the lunar surface as operational domains. That division reflects differences in infrastructure and mission activity rather than independent networks with no connections between them. A command can originate on Earth, pass through communications infrastructure, and affect equipment on the surface. Responsibility for protecting that command must account for the complete route and the organizations handling it.
Interoperability means that separately developed systems can work together through agreed interfaces and procedures. For lunar missions, it concerns more than compatible radio hardware. Participants also need consistent ways to represent data, request services, identify equipment, and interpret information. New Space Economy’s coverage of lunar communications providers describes the practical relationship between shared infrastructure and the missions that would purchase or use it.
NASA’s networking service description identifies the LunaNet Interoperability Specification as a framework for compatible assets around and on the Moon. It is not a single satellite mission or a completed constellation. That distinction is necessary because the Artemis briefing uses LunaNet within a broader architecture that also includes physical relay services and partner contributions.
The same NASA description explains delay/disruption tolerant networking, which stores information and forwards it when a communications connection becomes available. This approach addresses interruptions that conventional continuously connected networks may not accommodate well. It does not make every transmission immediate or guarantee uninterrupted coverage. A mission still depends on available links, compatible terminals, and operational service arrangements.
Security and connectivity address different requirements. Successful delivery shows that information reached an endpoint; it does not, by itself, establish that the sender had authority to issue a command. Authentication establishes identity, authorization controls permitted actions, and integrity protection helps detect unauthorized changes. These distinctions explain why common networking protocols must be accompanied by security arrangements rather than treated as proof of secure operation.
The October briefing also links communications with positioning, navigation, and timing. Positioning determines location, navigation supports movement, and timing provides consistent time references. Shared infrastructure can support these functions, but they remain distinct services. A communications relay is not automatically a navigation system, and a compatible data format does not establish the accuracy of a position estimate.
For commercial providers, these relationships imply coordination at interfaces between organizations. A rover operator, relay provider, and ground facility may have separate equipment and operational responsibilities. Their agreements and technical designs must make those responsibilities clear enough to test. This is an implication of the architecture, not a statement that the October presentation awards contracts or specifies every resulting commercial obligation.
The briefing’s discussion of post-quantum cryptography requires particular care. Such cryptography uses mathematical methods intended to resist attacks by both conventional computers and future quantum computers. The principal migration concern involves vulnerable public-key systems used for functions such as establishing shared secrets and verifying digital signatures. It does not establish that all existing encryption must be replaced in the same way.
The presentation describes a transition from the Advanced Encryption Standard to post-quantum algorithms, but that wording is too broad to apply as general technical guidance. The National Institute of Standards and Technology’s cryptography guidance distinguishes the quantum risk to public-key methods from attacks on symmetric encryption. NIST permits continued use of the Advanced Encryption Standard with its approved key lengths. An accurate migration plan identifies the cryptographic function and algorithm involved.
For a lunar architecture, this distinction implies that organizations need to identify their cryptographic dependencies before specifying a replacement. That includes understanding which systems rely on particular keys, certificates, protocols, and software components. Changing one endpoint without coordinating the other could prevent authentication or interpretation of an exchange. The relevant assessment concerns the complete connection and its required functions, rather than the algorithm name alone.
Testing is necessary because individually functioning components can still interact incorrectly. The NASA briefing explicitly identifies laboratory test and verification as an area for collaboration. Tests involving representative systems can expose mismatched assumptions about interfaces, security procedures, or interrupted communications. A successful test supports a defined configuration and set of conditions; it should not be presented as proof that every planned service is secure.
The presentation’s recommendation to incorporate security during architecture development follows from these dependencies. Retrofitting can require coordinated changes across several organizations and already designed systems. Early decisions do not remove the need for later updates, but they can establish who controls access, how changes are approved, and what evidence demonstrates compatibility. Those are engineering and operational questions that remain relevant even if mission schedules change.
NASA’s briefing identifies the security relationships that planned lunar infrastructure will create, rather than demonstrating their resolution. The next useful evidence would be specific requirements, tested interfaces, and documented responsibilities for the systems actually selected. Lunar cybersecurity will depend on those verifiable arrangements across organizations, including the ground facilities that operate them, as much as on any single encryption algorithm.
Useful Books Available on Amazon
