ITAR Compliant ERP: What the Requirement Actually Is
No ERP is ITAR certified. The regulation constrains who can read technical data and where it sits. What that means for software, and where vendors overstate it.
There is no such thing as an ITAR certified ERP. ITAR is a regulation your organization complies with, administered by the State Department, and no software vendor can hold a certification against it. What vendors mean when they say "ITAR compliant" is that their product can be configured and hosted in a way that supports your compliance. That is a real and useful thing, and it is not the same claim.
This matters because the phrase gets used as a checkbox, and the actual requirement is narrower and harder than a checkbox suggests. It is worth being precise about what ITAR constrains before evaluating anything.
One caveat first: this is written from delivery experience, not from a law firm. Your export compliance officer decides what satisfies your obligations, and nothing here substitutes for that.
What ITAR actually constrains
ITAR governs defense articles and defense services on the United States Munitions List, and it governs the technical data associated with them. For a manufacturer, technical data usually means drawings, specifications, process sheets, and the operational records that describe how a controlled item gets made.
The constraint that drives software decisions is this: releasing technical data to a foreign person is treated as an export, whether or not anything crosses a border. A foreign national reading a controlled drawing on a screen in Ohio is an export. This is often called a deemed export, and it is the reason ITAR ends up being an access control problem before it is a hosting problem.
So the question to ask a vendor is not "are you ITAR compliant." It is "who, precisely, can read our technical data in your system, including your own staff."
The four things your system has to be able to do
1. Restrict access by person, not just by role. You need to be able to say that this drawing is visible to these named, verified US persons, and to demonstrate it. Role-based permissions get you part of the way. What most systems handle poorly is proving after the fact who could have seen a record on a given date.
2. Control where the data physically sits. Storage and backups need to be somewhere you can point to. This includes the places people forget: backup replicas, disaster recovery regions, log aggregation, and analytics pipelines that quietly copy records somewhere else.
3. Control vendor and support access. This is the requirement that eliminates most SaaS options and the one buyers ask about last. If the vendor's support team can view your records to troubleshoot a ticket, and that team is not screened, their access is part of your problem. Ask specifically whether support can see customer data, who those people are, and whether their access is logged.
4. Produce an access record you can hand to an auditor. Who accessed which controlled record, when, from where. If that history lives only in a vendor's system and you cannot export it, your ability to answer depends on their cooperation.
What changed with cloud, and what did not
For years the working assumption in defense manufacturing was that ITAR data could not live in a public cloud. That changed with a State Department rule that took effect in 2020, which provided that technical data secured with end-to-end encryption is not treated as an export when it moves through or rests on foreign infrastructure, subject to conditions including that it is not stored in certain restricted countries.
Two things follow, and the second gets missed. Properly encrypted cloud storage became a legitimate architecture, which is why the government-cloud offerings exist and why the market shifted. But encryption changes the transmission and storage question, not the access question. If a foreign person at your vendor or in your own organization can decrypt and read the data, that is still a release. The binding constraint is still who holds the keys and who can read the plaintext.
Treat any vendor who answers an ITAR question purely with the word "encrypted" as having answered a different question.
Where the options land
| Approach | Vendor staff can read your data | You control access records | Effort to demonstrate compliance |
|---|---|---|---|
| Commercial multi-tenant SaaS | Usually yes | Their logs | High, depends on their attestations |
| Government or defense cloud tier | Screened personnel only | Partly | Moderate, and priced accordingly |
| Self-hosted commercial ERP | Only if you grant it | Yes | Moderate |
| Partner-built on your infrastructure | Only if you grant it | Yes | Lower, scoped to your posture |
| Spreadsheets on a controlled share | No | Weakly | High, access history is thin |
The last row deserves a note, because it is where a lot of defense work actually lives. A locked-down file share satisfies the residency question easily and fails the access-record question, since knowing who opened which file six months ago is exactly what shared drives are worst at.
The uncomfortable part: AI and ITAR
Every manufacturer is being sold AI right now, and for controlled work the default posture of most AI products is disqualifying. Sending a controlled drawing to a commercial model endpoint is a release of technical data to whoever operates that endpoint and wherever it runs. Encryption in transit does not resolve it, because the service decrypts in order to process.
This is the entire reason we deploy retrieval and assistant infrastructure inside client networks rather than calling a hosted API. If a system is going to read controlled technical data, the reading has to happen somewhere you control. That constraint shapes the architecture from the first day, and retrofitting it later usually means rebuilding.
It is also why an MCP server running inside your network is a different proposition from an assistant with a cloud connector. The tool surface, the logs, and the data all stay on your side of the boundary.
A five-question check for any vendor
Ask these before a demo, because the answers determine whether the demo is worth booking.
1. Can your support staff view customer records, and are all of them US persons?
2. Where exactly does our data rest, including backups, replicas, and logs?
3. Can we restrict a specific record to a named list of verified people and prove it later?
4. Can we export the full access history ourselves, without asking you?
5. If we terminate, what happens to the controlled data in your system and on what timeline?
A vendor who answers 1 and 4 crisply is usually serious. A vendor who redirects every question to a compliance page is telling you something.
Questions we get
Is any ERP ITAR certified? No. There is no certification to hold. Organizations register with the State Department and comply with the regulation. Software can be built and hosted to support that, which is worth a great deal and is a different sentence.
Do we have to be on-prem? Not since the 2020 rule, provided the encryption and access conditions are genuinely met. Many defense shops still choose on-prem or a private tenant because it makes the access question far simpler to answer and far cheaper to demonstrate.
What about our existing shared drive? It probably satisfies residency and probably fails on access history. That gap is usually invisible until someone asks who viewed a drawing before it went out, which is precisely when you need the answer.
How does this interact with AS9100? They overlap in the record-keeping but they are different obligations. AS9100 is a quality management standard about demonstrating your process. ITAR is an export regulation about controlling access. A system can satisfy one and fail the other. The AS9100 side is covered here.
Can we use commercial AI tools on non-controlled work? Yes, and many shops do exactly that, with a hard boundary between the two data sets. The failure mode is a boundary that exists on paper and not in the system, so an operator can paste a controlled drawing into a general tool without anything stopping them.
Our prime contractor asked about our software. What are they looking for? Usually that you can restrict and evidence access to the technical data they flowed down to you. Being able to answer questions 3 and 4 above concretely is most of what they are checking.
What is next
Before evaluating software, get clear on which of your data is actually controlled. Many shops treat everything as ITAR because sorting it is work, and that decision quietly rules out tooling that would be fine for the majority of the operation. The scoping conversation with your compliance officer is usually the highest-value hour in this whole process.
If your constraint is that data cannot leave the building, that narrows the field usefully rather than painfully. Manufacturing data sovereignty covers the four dimensions worth scoring any system against, and residency is only one of them. For the records side of the same problem, traceability and audit readiness covers deployment that stays inside your boundary. Or tell us what you are working with and we will tell you honestly whether it is a fit.