Your hardware team just hired a brilliant propulsion engineer based overseas to accelerate your development timeline. You shared the CAD files, the thruster specifications, and the integration manuals via a secure cloud drive. You just saved three months of development time.

You also just committed a federal crime.

The International Traffic in Arms Regulations (ITAR) and the Export Administration Regulations (EAR) do not just govern the physical shipment of hardware across borders. They govern the transfer of technical data. Sharing controlled technical data with a foreign national, even if they are sitting in your office or working remotely from another country, constitutes a “deemed export.”

Here are the three operational realities of the ITAR deemed export trap that space startups must internalize before writing their first line of code or drafting their first schematic.

The open-source GitHub illusion

Many software teams assume that because their flight software is built on open-source frameworks, it is exempt from export controls. This is a dangerous misconception that has resulted in massive federal penalties for tech companies.

The Department of State explicitly states that while publicly available open-source code is generally exempt, the moment you modify that code to interface with ITAR-controlled hardware (like a specific star tracker or reaction wheel), the entire modified repository becomes controlled technical data.

If a foreign national contributor commits code to that repository, or if you grant a foreign national access to the private repository, you have just executed an unlicensed deemed export. We covered the broader financial exposure of these violations in our guide on export controls compliance risks most cubesat companies ignore. The State Department does not care that the violation happened on GitHub.

The remote contractor liability

The most dangerous aspect of the deemed export trap is that intent does not matter. You do not have to intend to violate export controls to be held liable. Ignorance of a contractor’s citizenship status is not a valid legal defense.

When you hire a remote engineering firm or an independent contractor, you are legally required to verify their citizenship and ensure they are not a “foreign person” as defined by ITAR. If they are a foreign person, you must either obtain a specific export license from the State Department before sharing any technical data, or you must restrict their access entirely to publicly available information.

At the end of the day, the burden of verification rests entirely on the US company. A simple Slack message containing a controlled schematic sent to an overseas developer is enough to trigger an investigation, massive fines, and permanent blacklisting from the US space supply chain.

The operational workflow for data security

Protecting your company requires building export compliance directly into your hiring and software development pipelines. You cannot treat ITAR and EAR as a legal problem to be solved after a violation occurs. It must be a proactive engineering gate.

The most sophisticated operators are implementing a three-step workflow to eliminate deemed export risks.

Step one: Strict access control and verification

Implement mandatory citizenship and export control training verification for every employee and contractor before granting access to any technical data. Use role-based access control (RBAC) to ensure foreign nationals only see publicly available or EAR99 information.

Step two: Segregated development environments

Maintain strictly separated code repositories and CAD environments. ITAR-controlled technical data must be housed in secure, access-restricted systems that are physically and logically isolated from any systems accessible by foreign nationals.

Step three: Automated data classification

Use software tools to automatically scan code commits and document uploads for keywords or file types associated with controlled technical data. If a file is flagged, the system automatically blocks the transfer and alerts the compliance officer.

In a nutshell, technical data security is no longer just an IT problem. It is a core regulatory requirement. The operators who automate their access controls will scale their engineering teams safely. The operators who rely on trust and informal sharing will eventually face the Directorate of Defense Trade Controls.

The era of treating data sharing as a frictionless engineering process is over. Your technical data is a controlled asset. The federal government expects your data governance to be just as rigorous as your physical security.

Look at your current engineering workflow. Do you verify the export status of every remote contractor before sharing CAD files? Are your code repositories strictly segregated based on citizenship and data classification?

If the answer is no, you are carrying an existential legal risk. We built Astrolytics specifically to eliminate this blind spot, giving you automated compliance tracking and structured data governance workflows so your engineering team can collaborate globally without triggering a deemed export violation. See how we secure your mission architecture at Astrolytics.