ITAR, the cloud, and your CAD library

For an aerospace or defense manufacturer, a CAD file is not just engineering data. If the part it describes appears on the United States Munitions List, that file is ITAR-controlled technical data, and the rules governing where it can live and who can see it are strict, federal, and backed by criminal penalties. This single fact reshapes the entire question of what software a defense engineering team can use — and it is the reason the most modern, capable, cloud-based engineering tools are often the ones they cannot touch.

This article is a plain-language look at how export-control rules intersect with CAD libraries, why “just use the cloud” is not an option for controlled programs, and what an architecture that actually fits these environments looks like. It is general information, not legal advice — export-control compliance is genuinely specialized, and the details of any program should go through your own compliance function.

Why a CAD file becomes controlled data

The International Traffic in Arms Regulations (ITAR), administered by the U.S. State Department’s Directorate of Defense Trade Controls, govern defense articles and the technical data needed to design, produce, manufacture, or modify them. In practice, that technical-data definition sweeps in exactly the artifacts an engineering team works with daily: CAD models, drawings, specifications, manufacturing process documentation, test results, and performance data for items on the Munitions List.

The companion regime, the Export Administration Regulations (EAR), covers dual-use items — commercial technologies with potential military application — with its own classification and end-use rules. Between them, a large share of aerospace, defense, space, and even some industrial geometry is controlled in some form.

The core obligation is access control: only authorized U.S. persons — citizens and lawful permanent residents — may access ITAR-controlled technical data without an export license. And critically, an “export” does not require shipping anything overseas. Letting a foreign national view controlled data on a screen, or storing it on a server outside the United States, can itself constitute an unauthorized export.

Why the stakes are not theoretical

The penalties for getting this wrong are severe and individual, not just corporate. Civil penalties can exceed a million dollars per violation; criminal penalties include imprisonment. There are documented cases of engineers prosecuted and sentenced for sharing controlled technical data with foreign nationals, and of companies fined heavily for storing ITAR data on servers located overseas. Beyond fines, a violation can mean debarment — losing the ability to win future defense contracts at all, which for a defense supplier is existential.

This is why defense primes flow these obligations down to their suppliers, and why the moment ITAR work intersects with a Department of Defense contract, the supplier is typically also pulled into the CMMC and NIST SP 800-171 cybersecurity frameworks — 110 security controls covering access, encryption, monitoring, and handling of controlled information.

Where the cloud runs into the wall

Cloud software is, by design, about moving data to someone else’s computers. For controlled technical data, that premise collides with the rules in several places:

• Data residency. Controlled data must generally stay on U.S.-based infrastructure. A standard commercial cloud spread across global regions cannot guarantee that.
• Personnel access. Administrators and support staff with access to the data must themselves be vetted U.S. persons — a constraint most commercial SaaS vendors cannot meet across their global engineering and support organizations.
• Multi-tenancy. Controlled data sharing infrastructure with other tenants raises isolation and residency questions that are difficult to fully resolve.
• AI and third-party processing. The moment controlled geometry is sent to an external inference API or a third-party processing service, it has potentially been exported. Modern AI features that quietly call out to a vendor’s servers are a particular hazard.

There are real, compliant answers for some of this — government-cloud regions built on isolated, U.S.-resident, vetted-personnel infrastructure exist precisely to host controlled workloads. But they are a specific, heavyweight category of offering, not the default cloud, and they do not cover the case where a tool you want to adopt sends geometry to a general-purpose cloud or external API as part of how it works.

The download problem

There is a subtler issue that even compliant cloud platforms struggle with. The riskiest moment in the life of a controlled file is often not while it sits in a secure platform — it is the moment it moves. An engineer downloads a model to review offline. A subcontractor forwards a specification. A laptop travels. The platform’s audit log records a clean access event, and the controlled data is now outside any platform’s control. A tool whose security model depends on the data staying inside its walls is only as good as everyone’s discipline about never taking it out.

What an architecture that fits actually looks like

The cleanest way to satisfy these constraints is to not move the data at all. If a tool runs entirely inside the customer’s own network — indexing geometry where it already sits, computing everything locally, and never sending a byte to an external service — then most of the hard questions never arise. There is no data residency question because the data never leaves. There is no foreign-administrator question because there is no vendor with access. There is no AI-export question because inference happens locally.

Concretely, an on-premise, export-control-friendly architecture for a geometry tool means:

1. Indexing in place. The tool reads geometry from the existing file server over the internal network. Files are never copied out.
2. Local computation only. Shape signatures, search, and any AI — including natural-language query parsing — run on hardware inside the perimeter. No external API calls.
3. Air-gap compatibility. The system can run with no internet connection at all, inside a VPC or a physically isolated network.
4. No egress, provable. The architecture should make it demonstrable that zero bytes of geometry leave the customer boundary — because for a compliance officer, “trust us” is not an answer.

This is the inverse of the usual cloud-software pitch, and it is not an accident. The same choice that locks a cloud competitor out of these accounts — refusing to centralize data on vendor infrastructure — is precisely what makes an on-premise tool usable in them.

The bottom line for engineering leaders

If your library contains controlled technical data, the question to ask any prospective software vendor is blunt: does our geometry ever leave our network — to your cloud, to a third-party API, to an AI service — under any circumstance? If the answer is anything other than a clear no, the tool may be unusable for your controlled programs no matter how good it is. For the manufacturers with the largest and most sensitive libraries, on-premise is not a deployment preference. It is the only architecture that is legal to run.