ITAR Compliant File Sharing: A Practical Guide for Defense Subcontractors

Your engineers need to send a CAD file to a partner contractor. The prime requires ITAR compliance. You open your standard file-sharing tool and pause. Is this legal?

The frustrating reality is that most guidance on this topic is either too vague ("use encrypted channels") or too buried in regulatory text to be actionable. Meanwhile, your engineers are making judgment calls, and some of those calls are creating ITAR violations that nobody in the organization is aware of yet.

This guide cuts through that. Here is what ITAR-compliant file sharing actually requires, which tools fail the standard and why, and what a properly implemented solution looks like.

What "ITAR Compliant File Sharing" Actually Means

ITAR (International Traffic in Arms Regulations) controls the export of defense-related technical data. Under ITAR § 120.33, "technical data" includes information required for the design, development, production, or operation of defense articles, which in practice means CAD files, engineering drawings, schematics, specs, test data, and manuals related to covered defense articles.

Sharing that data requires either a valid export license or a license exemption. The most practically relevant exemption for day-to-day file sharing is the encryption safe harbor under EAR § 734.18(a)(5), which applies to ITAR-adjacent technical data: if a file is encrypted using FIPS 140-2 validated cryptography or its successors (FIPS 140-3 qualifies), and the encryption provider has no ability to access the decryption keys, the transfer is not classified as an export event.

That single provision, properly applied, is what makes secure file sharing possible for defense contractors without needing a specific license for every transfer. Most contractors do not know it exists. Most of the tools they use do not satisfy it.

There are four requirements that any file-sharing solution must meet to qualify under this standard:

FIPS 140-3 Validated Encryption: Not just AES-256, the specific cryptographic implementation must be validated by NIST's Cryptographic Module Validation Program (CMVP) and appear on the active modules list at csrc.nist.gov. AES-256 is an algorithm; FIPS 140-3 validation is a certification of the implementation. Many tools use AES-256 without ever submitting to CMVP validation.

Zero Provider Key Access: The file sharing provider must have no ability to decrypt content. If the provider holds the encryption keys, even under a "customer-managed key" model where keys live in the provider's key vault, the data has technically been exported to that provider.

Access Limited to Authorized Recipients: For ITAR-controlled data, access must be restricted to US persons unless an export license (DSP-5 or equivalent) covers the specific recipient. This requires identity verification at the file level, not just at the login screen.

A Complete Audit Trail: Every access attempt, successful and denied, must be logged with timestamp, user identity, and device. DDTC enforcement investigations pull these logs. If you cannot produce them, you cannot demonstrate compliance.

The Three File Sharing Tools Defense Contractors Use (and Why Two Create Violations)

Consumer Cloud Storage (Dropbox, Google Drive, Box)

The provider holds encryption keys. Even if your data is encrypted in transit and at rest, the provider can decrypt it — and under compulsory legal process from a foreign government or a non-US court, they may be obligated to. The encryption is a protection against external attackers, not a guarantee that the data stays controlled.

More specifically: if your files sit on a server operated by a non-US subsidiary of a cloud provider, or are processed by engineers outside the US in a support capacity, the data has been exported. Most enterprise cloud storage agreements contain provisions that allow exactly this.

Standard Email (Outlook, Gmail)

No encryption at rest on the recipient side, no access audit, no revocation capability. Once the file is sent, control is gone. If the email is forwarded to a non-US person — intentionally or by accident — that is a deemed export. The forwarding chain is invisible to you and outside your control.

Email is the single most common channel for unintentional ITAR violations among defense subcontractors. It is also the hardest to remediate after the fact because there is no mechanism to make an already-sent email inaccessible.

FIPS-Validated, Zero-Knowledge File Sharing

This is the only category that satisfies both the ITAR encryption requirement and the EAR § 734.18 safe harbor. End-to-end encryption, FIPS 140-3 validated at the implementation level, with the provider holding zero decryption capability. Access is controlled to specific recipients, verified against identity and role at every open attempt, and every access event is logged.

The file is encrypted at the point of creation and remains encrypted regardless of where it travels. If it is intercepted, forwarded to an unauthorized recipient, or exfiltrated, the attacker has encrypted data with no accessible key. The export safe harbor applies because the data was never accessible outside your authorized recipient list.

The Five Requirements for ITAR Compliant File Sharing

These requirements come directly from ITAR regulations and the EAR encryption safe harbor. Use this as a checklist against any tool you are currently using or evaluating:

1. FIPS 140-3 Validated Encryption at the File Layer: The algorithm must be validated by NIST CMVP with an active certificate. Check your tool against the CMVP active modules list. If it is not there, AES-256 encryption alone does not satisfy this requirement.

2. Zero Provider Key Access: The provider cannot hold decryption keys; not in a key vault, not in escrow, not transiently during encryption/decryption operations. Organizational control of keys means your organization generates, distributes, and destroys them outside the provider's infrastructure.

3. Identity-Verified Access Controls at Every Open Attempt: Access must be enforced at the moment of opening, not just at the time of initial share. An authorized recipient who subsequently becomes unauthorized (license expiry, employment change, project end) must be denied access at the next open attempt, not just locked out of the sharing portal.

4. Encryption in Transit and at Rest: Both states are required. In-transit only (TLS) is standard practice and does not satisfy ITAR requirements for controlled technical data.

5. Complete Audit Trail: Every access event logged. Every denied attempt is logged. Timestamp, user identity, device context. Producible on demand without needing to contact a third-party provider to retrieve.

The Deemed Export Problem Most Subcontractors Ignore

A deemed export is not just sending a file abroad. Under ITAR § 120.17, releasing controlled technical data to a foreign national inside the United States constitutes an export, regardless of where the data physically resides. The "export" event is the release of information to the person, not the transfer of a file across a border.

This creates a specific operational problem: if your engineering team includes non-US nationals, and ITAR-controlled files are accessible to those individuals through normal work systems, you have deemed exports occurring inside your own office. The tool does not need to cross a border. The access does.

Solving the deemed export problem requires identity verification at the file level — specifically, access controls that evaluate the identity and authorization status of the person attempting to open a file, not just whether they are logged into the network. The license status of the recipient matters. Their citizenship status matters. These checks need to happen at every open attempt, in real time, against the current authorization state — not against the state at the time the file was originally shared.

What Happens When ITAR File Sharing Goes Wrong

The DDTC published 11 enforcement actions in 2024 alone. The standard resolution is a consent agreement with civil penalties — averages range from $10M to $30M for systemic violations — plus a Special Compliance Officer, mandatory remediation, and in severe cases, export debarment that removes the company from defense contracting entirely.

The companies that appear in these enforcement actions are not universally negligent. Many had security programs. Most had some encryption in place. The violations occurred because the specific implementation did not satisfy the regulatory requirements — AES-256 without CMVP validation, cloud storage with provider key access, and email sharing without audit capability.

The pattern is consistent: contractors assume "encrypted = compliant" without verifying whether the specific implementation satisfies the specific regulatory standard. ITAR does not accept close approximations.

How To Implement ITAR Compliant File Sharing Without Disrupting Operations

The practical implementation challenge is that most ITAR-compliant solutions have historically required users to change their workflow significantly — separate portals, dedicated client software, file conversion steps, and additional login screens. Engineers working under deadline pressure do not use tools that create friction. They use email.

The alternative is per-file encryption that travels with the document. The file is encrypted at creation, carries its own access policy, and can be opened by authorized users in any environment — no separate portal, no workflow change required. If the access policy check fails (wrong recipient, expired authorization, unauthorized device), access is denied. The file does not open. The user is not given an error message that exposes the file's contents.

Theodosian's per-file FIPS 140-3 encryption works this way. Every file is encrypted individually using patent-pending architecture, with a zero-knowledge key management system — Theodosian never holds decryption keys. Access is enforced at every open attempt against the recipient's identity, role, device compliance posture, location, and time context. An engineer at a partner contractor opens the file on their authorized device: access granted. The same file forwarded to an unauthorized recipient: access denied before the moment of opening, before any content is visible.

The audit trail is automatic — every access event, every denial, timestamped and logged without any action required from the sender.

FAQ’s: ITAR Compliant File Sharing