Device Authorization on a Deep Space Ground Network

This is a hypothetical exercise. I'm using device authorization on a deep-space ground network as a worked example to demonstrate how I approach large-scale security program management: scoping, stakeholder coordination, phased enforcement, and the operational disciplines that make a change like this actually land. It is not a description of any real system, deployment, or organization. The reference architecture is drawn from publicly available material on deep-space ground operations; the methodology is mine.

I've spent enough time in large-scale enterprise device authorization rollouts to have a feel for what makes them work. The pattern is consistent: clear architecture up front, a long registration window, infrastructure audit before any enforcement, multi-channel communication that over-communicates without creating noise, and phased enforcement by criticality. None of that is exotic. What's interesting is how that same pattern adapts when the network isn't a corporate campus but a mission ground segment, where the "users" are flight projects, the "buildings" are deep-space communications complexes, and the consequence of a misconfigured switch is a missed pass on an active spacecraft.

This piece walks through what that adaptation looks like, using device authorization on the ground network equipment inside the complexes (routers, switches, and the management infrastructure that moves command and telemetry between project and antenna) as the running example.

Strategic Planning & Architecture Design

I'd start where any enterprise rollout starts: defining the end state. An authorization framework that ensures only approved, registered network equipment can participate in the operational network, designed to scale with the mission set for the next decade and to integrate cleanly with whatever the security organization rolls out next.

The architectural foundation is a centralized authentication database the network queries in real time, capturing the identifiers that matter: the device's role in the mission system architecture, hardware identifiers including MAC, and a device certificate issued by an internal PKI for cryptographic validation. Dual-mode authentication (MAC-based for legacy equipment that can't carry a certificate, certificate-based as the target state) gives the rollout a migration path rather than a cliff.

The architecture decision that matters most in this environment isn't cryptographic. It's whose database is authoritative for what counts as a "known" device. On a corporate network, the asset management system can be the source of truth. On a mission ground network, the source of truth has to reconcile network engineering's inventory, the security organization's accredited systems list, and the flight projects' own equipment registers. Getting those three to agree, before the database is populated, is the first real piece of program work.

Infrastructure Audit & Data-Driven Readiness Assessment

Before any enforcement, the network has to be understood. I'd run a complex-by-complex audit of every switch and router in the operational path: location, accessibility, firmware version, NAC integration readiness, and gaps that would block deployment. Some equipment in any long-lived ground system pre-dates modern authentication standards; identifying that early determines what the legacy-bypass exception process needs to handle.

In parallel, deploy the NAC solution in monitoring mode across one complex. Passive observation only: every device that participates in the network is logged, and any device not present in the authorization database is flagged. Daily automated reports go to three audiences:

Network engineering, for direct remediation of devices that should be in the database but aren't.
The flight projects, so they can confirm which devices on the management segments are theirs.
Complex operations leadership, to track burn-down rate against the enforcement deadline.

This reporting loop is the same pattern I'd use on any enterprise rollout, but the operational stakes are higher: an unknown device on a corporate VLAN is a finding to investigate; an unknown device on the management segment of an antenna's control system is a finding to investigate now.

Change Management & Multi-Channel Communications

Communication on this scale has to over-communicate without creating fatigue. The stakeholder set isn't generic users. It's flight projects who have direct operational equities, network operations staff who run the day-to-day, security and configuration management who own the controls and the change record, and the export control reviewers who have to sign off on anything PKI-related.

The channel mix I'd layer:

Network-wide announcements through the standard mission communication systems and email distribution lists, on a scheduled cadence so the timeline is predictable.
Direct outreach to each flight project's mission ops lead and security point of contact, with project-specific impact summaries.
Governance board presentations at the network change board, the security board, and the relevant project change boards, each tailored to what that board cares about.
Intranet-hosted FAQs, registration procedures, exception request workflows, and troubleshooting guides.
Office hours for projects with large or complex equipment footprints, especially those with legacy equipment requiring exception handling.

The principle is the same one I've used on every device authorization rollout: by the time enforcement happens, no stakeholder should be able to claim they were unaware.

Phased Enforcement with Risk Mitigation

Phasing by operational criticality maps cleanly to phasing by mission impact:

Pilot phase. A non-critical management segment at one complex. Enforcement workflows validated end-to-end, with the bypass path immediately available.
Low-to-moderate criticality. Operational segments at one complex, brought online in batches. This catches the integration issues: interactions with existing identity infrastructure, edge cases in the device inventory, equipment that turns out to not support the required EAP method.
High-criticality, single complex. Full coverage at one complex, with documented exceptions for equipment that genuinely can't be retrofitted.
Cross-complex expansion. Other complexes brought online in sequence, with the lessons from the first complex applied.
Enforcement mode. Bypass paths removed. Unauthorized devices rejected at the network layer.

Each phase begins with advance warning to affected projects, direct outreach to key contacts, and pre-positioned support to address access issues in real time during the cutover. The NAC moves from monitoring to enforcement segment-by-segment as compliance is verified.

The temptation to compress this is constant. I've held the line on phasing in enough rollouts to know that the projects pushing to skip phases are the same ones who file the incident report when something breaks. The phasing logic gets documented at the start, in writing, with the reasoning behind each phase, not just the schedule.

Results & Lessons Learned

If the rollout goes as designed, every device in the operational path is registered and cryptographically authenticated by completion. Unauthorized devices are systematically blocked at the network layer. Business continuity is preserved through phasing and exception handling, and mission operations continue without disruption.

The patterns that hold up across this kind of work:

A long registration window is non-negotiable. Compressing it shifts risk from the program to operations, and operations will absorb that risk by skipping verification steps.
Automated reporting accelerates remediation. Daily burn-down data to the right audiences turns a sprawling rollout into a tractable one.
Phased enforcement is structural, not optional. The lessons from early phases inform the late ones, and the late phases are the ones with the highest stakes.
Multi-channel communication is what makes phasing work. The technical readiness of a switch matters less than the operational readiness of the team responsible for it.
The asset inventory is upstream of everything. If you can't tell what's on your network, you can't tell what should be authenticated to it.

What makes this work on a mission ground network rather than an enterprise campus isn't the technology. It's the disciplined application of the same methodology under tighter operational constraints. The patterns transfer. The stakes change.