ITAR & EAR Compliance for Multinationals: A SaaS Guide

Multinational defense, aerospace, and dual-use technology firms face a structural problem. Their workforces, supply chains, and cloud applications span borders. A single SaaS tenant accessed by a foreign-person employee can trigger a regulated export, under ITAR and EAR, regardless of where the servers physically sit. 

What Counts as Export-Controlled Data

The two primary U.S. regimes are the International Traffic in Arms Regulations (ITAR) under 22 CFR Parts 120 to 130, and the Export Administration Regulations (EAR) under 15 CFR Parts 730 to 774.

ITAR governs defense articles, services, and technical data tied to the U.S. Munitions List. EAR governs dual-use items on the Commerce Control List.

ITAR vs EAR at a Glance

Both regimes regulate the underlying technical data: drawings, source code, specifications, manufacturing know-how, and training materials. The format does not matter. A CAD file in a SharePoint folder is regulated the same way as a printed blueprint in a vault. 

Why Multinationals Carry the Most Risk

Export control law treats access by a foreign person as a regulated event, not just the movement of data across a border. Two cases matter for a multinational.

When a foreign person inside the United States views controlled technical data, that release is a deemed export. The Bureau of Industry and Security explains the concept here. Under 15 CFR §734.13, a release of controlled technology to a foreign person is deemed an export to that person's most recent country of citizenship or permanent residency. ITAR carries the equivalent rule for technical data at 22 CFR §120.17.

When a foreign person abroad accesses the same data, it is a straightforward export to that country. Either way, access is the trigger. A U.S. contractor opening a USML-tagged drawing in a global Jira tenant alongside a German colleague is a regulated export to Germany. A U.S. firm sharing a NetSuite record with an Indian services provider is a regulated export to India. A foreign-national administrator at a cloud provider with access to plaintext data is a regulated event whose treatment depends on where that administrator sits.

Splitting Tenants Doesn't Solve the Person Problem

Some multinationals split their SaaS into regional tenants to limit export control exposure.

It can help with data residency and reduce some cross-border movement, but it does not solve the foreign-person access problem.

The control point that matters most is not where the tenant sits. It is who can read which data fields inside it.

Where SaaS Use Can Break Export Compliance

Even with the right tenant structure, SaaS compliance gaps show up in many places. Three failure points stand out.

First, role-based access in SaaS platforms cannot enforce US-person-only access at the field level. Native SaaS access controls are built around roles, not U.S.-person status. A "Sales Engineer" role applies to US and foreign-national engineers alike. Citizenship is not an attribute that platforms typically understand. 

Second, plaintext data inside the SaaS is visible to the provider's administrators, support staff, and increasingly to AI tools integrated into the platform. Microsoft 365 Copilot, Salesforce Einstein, and ServiceNow Now Assist can all access data that the underlying account can see. Once that access happens, governing who saw which regulated record is very difficult.

Third, integrations and analytics frequently pull regulated data into regions or systems that the compliance team never approved. Connectors carry user or machine-level permissions, not data-level classifications, so a tagged record can move into a less protected environment without anyone noticing.

The table below maps these and other common failure points to the specific regulation each one puts at risk.

Common Issues With SaaS For ITAR and EAR Compliance

The Encryption Carve-Out and What It Actually Requires

22 CFR §120.54 creates a narrow but important exception. Sending, taking, or storing unclassified ITAR technical data is not an export when specific conditions are met. The EAR equivalent sits at The EAR 15 CFR §734.18.

The conditions are strict. The data must be unclassified. It must be secured with end-to-end encryption using FIPS 140-2 or later validated modules. It must be encrypted before it leaves the originator's security boundary and stay encrypted until it reaches the intended recipient's. The means of decryption cannot be given to a third party, and no foreign person can hold the keys. The data also cannot be intentionally sent to or stored in a country listed in ITAR §126.1 or the Russian Federation.

The practical implication is direct. Vendor-managed encryption does not qualify. The keys and the unencrypted data must remain under the data owner's control.

Reducing Scope With Tokenization and Field-Level Encryption

The cleanest architectural response is to keep regulated data out of the SaaS in plaintext form. Tokenization replaces technical data fields with non-sensitive tokens before the data reaches the cloud platform.

The original remains under the data owner's control, in an approved jurisdiction. Field-level encryption with customer-held keys produces a similar result: the SaaS holds ciphertext, the keys never leave the company's environment.

The benefit for a multinational is twofold. The export control surface area shrinks because regulated data is no longer present in foreign-accessible systems in usable form. And the §120.54 carve-out conditions become technically demonstrable rather than contractually asserted.

Enforcing Person-Based Access

The remaining layer is identity. A U.S.-person-only field still needs an access policy enforced at request time.

Gateway-based identity controls, like those in the StratoKey CDP Platform, authenticate users and apply rules that combine identity provider attributes, group membership, and location to decide whether to release plaintext data. U.S.-person status is represented through IdP-managed groups or attributes that the gateway evaluates before any decryption or detokenization decision. The SaaS sees an authenticated user. The gateway decides whether that user can view the data.

This pattern allows a multinational to maintain a single global SaaS tenant while controlling who can decrypt or detokenize which fields. The CDP Platform's audit log captures every decryption and detokenization decision, which matters when DDTC or BIS asks how the company enforces its export control program.

The Takeaway

Export control compliance in a multinational SaaS estate is not solved by region splits or by trusting SaaS provider encryption.

It is solved by keeping plaintext-regulated data out of the vendor's environment in the first place, controlling the keys directly, and enforcing person-based access at the gateway layer. 

StratoKey does just that. Get in touch to learn more.

Frequently Asked Questions