How Commercial Space Companies Protect Export-Controlled Technical Data Across Their Supply Chain

SpaceX built a culture of software iteration and moved it into rocket engineering. Rocket Lab, Relativity, Stoke Space, Phantom Space — dozens of commercial launch companies followed, applying software-company operating models to what had previously been the domain of large, compliance-heavy prime contractors.

That is genuinely valuable. Speed matters in commercial space. Tooling matters. The ability to iterate on a Falcon 9 second-stage design in Notion, track issues in Linear, share schematics in Google Drive, and commit changes to a GitHub repository gave commercial space companies structural velocity advantages over legacy primes.

It also gave them ITAR exposure that grows with every engineer added to the repository.

What Category XV of the USML Covers

The United States Munitions List governs what is controlled under ITAR. Category XV covers spacecraft systems and associated equipment — which, for launch vehicles, is substantially comprehensive.

Launch vehicle structural data, propulsion system designs, guidance and navigation system schematics, payload interface specifications — if it's technical data associated with a system that can place payloads in orbit, it is almost certainly ITAR-controlled. The controlling question is not intent but capability: can the system deliver a payload to orbit? If so, its technical documentation is likely USML Category XV.

In October 2024, the State and Commerce Departments issued a final rule adjusting jurisdiction over certain commercial satellite components from the USML to the Commerce Control List, moving some items from ITAR to EAR jurisdiction. This is meaningful for specific component categories with clear civilian applications.

It doesn't change the fundamental picture for launch vehicle technical data. The core engineering documentation for a vehicle that can reach orbit — guidance, propulsion, structural design — remains ITAR-controlled. The penalty regime: criminal fines up to $1 million per violation, imprisonment up to 20 years.

Every email containing that technical data to a non-US person is an export that requires a license or an exemption. Every repository a non-US national can access containing that data is an ongoing export. Every Slack channel with controlled design data where a non-US team member is a member is an active compliance exposure.

The Blast Radius of a Collaboration Platform

This is the structural problem that commercial space companies inherited from their software-company operating model, and it's a blast-radius problem.

Legacy defense prime contractors built their compliance programs before the modern collaboration stack existed. They were already operating sensitive compartmented information facilities, already trained on ITAR handling, already running classified email on separate networks. The compliance culture came first. The tools came after, under compliance review.

Commercial space companies built the tools first. They picked GitHub because it's where engineers work. They picked Google Workspace because it integrates with everything. They picked Slack because it's fast. None of those decisions were wrong in isolation. They became an ITAR-compliant architecture by accident.

When your launch vehicle design repository lives in a cloud-hosted version control system, the blast radius of a single compromised account is the entire program's technical data. Not one file. Not one subsystem. Every commit, every revision, every CAD attachment, every engineering note tagged to the repository. One phished engineer's credentials are an authorized read on the complete export-controlled technical record of your program.

The same logic applies to Google Drive. You didn't choose that blast radius. Your architecture chose it for you.

The Supply Chain Multiplies the Exposure

Commercial space companies source components from supply chains that are, by necessity, global. Propulsion components from specialist manufacturers. Avionics from established suppliers. Structural composites from specialized fabricators. The supply chain that delivers a launch vehicle is not a single company; it's a network of organizations, many of which require technical data to build their components.

Each handoff of technical data in that network is a potential ITAR transfer. When a propulsion supplier in Germany receives an interface specification, that's an export transaction requiring either a license or an exemption. When a composites fabricator receives structural CAD files, that's another transfer. When an avionics integrator receives a guidance-system interface spec, another.

Commercial space companies that manage this through shared cloud drives — a Drive folder for each supplier, or a project workspace that suppliers join — have created a transfer mechanism with no enforcement point at the file level. The file lands in the supplier's environment, accessible to everyone in that environment, without any technical control that enforces the distribution restriction the ITAR requires.

Supplier management agreements and technology control plans are legal instruments, not technical controls. They establish liability. They don't enforce distribution. The difference matters in a DoS enforcement action.

What an ITAR-Compliant File Protection Architecture Looks Like

The ITAR's technical data protection requirement is not about where the data lives. It is about who can access it, under what conditions, and with what evidence of control.

Per-file encryption with context-aware access controls addresses this at the file level. Each controlled technical document carries its own encryption and access policy — a policy that specifies who can decrypt it, under what authentication conditions, and which access events are logged.

When a propulsion supplier receives an interface specification, the file arrives encrypted. Decryption requires authentication against the access policy the originating company set. If the supplier adds a team member who is a non-US national without a license in scope, that team member cannot decrypt the file — not because the folder-level permissions were set correctly, but because the file-level policy was never granted to that identity.

The file defends itself. The control doesn't end at the supplier's environment boundary — it travels into the supplier's environment, enforcing the originating organization's access restrictions regardless of what the supplier's own access controls say.

Every access attempt — successful or refused — is logged against the originating policy. That log is the audit evidence a DDTC examiner looks for when assessing whether technical data transfers were controlled within the terms of the applicable exemptions.

The Repository Problem Is the Hardest One

The blast-radius concern in commercial space isn't primarily about email attachments and supplier portals. It's about the repository.

Version-controlled repositories are where launch vehicle engineering lives. Every commit carries technical data. The access control model is repository-level or branch-level — it grants users access to the repository, not to specific files or specific technical data categories within it.

That means ITAR control in a repository environment currently depends almost entirely on repository-level access management: who is allowed to join the repository, with human review of every new member's citizenship or license status. This is a scalable process right up until someone makes a mistake, or until an authorized team member's credentials are compromised.

Per-file protection at the repository layer — where files within the repository carry their own encryption and access policy, independent of repository membership — would close this gap. When even an authorized repository member cannot decrypt a file they didn't have explicit per-file access to, the blast radius of any repository-level compromise is bounded at the file, not the repository.

That's the architectural model for ITAR compliance that travels with the data, rather than the compliance model that hopes the perimeter held.

Your Blast Radius Isn't a Choice You Made

Commercial space companies are not careless about ITAR. The ones facing exposure built their tools with the same care they brought to their engineering. The exposure came from applying a software-company model to a domain that has ITAR obligations embedded in the technical data itself.

Your blast radius isn't a choice you made. It's an architecture you inherited — from the collaboration stack you built before the ITAR training happened.

The Theodosian Walls of Constantinople held for a thousand years. They failed when the threat changed shape — when the attack came from a direction the walls weren't built to face. Commercial space companies built walls for software companies. The ITAR threat comes from a direction those walls don't face.

The wall needs to move to the file.

FAQs: ITAR Category XV & Commercial Space Data Security