ITAR Section 120.54 and the Deemed Export Rule for Cloud Environments

ITAR Section 120.54 allows you to send, take, or store certain unclassified technical data in commercial or government clouds without creating an export, if you meet strict encryption and routing conditions. ITAR treats any release of controlled technical data to a foreign person in the United States as a deemed export to each of that person’s countries of citizenship or permanent residency. Identity, access, and key custody drive risk more than the logo on the cloud tenant.

The deemed export rule in plain terms

ITAR defines an export to include releasing controlled technical data to a foreign person on U.S. soil. DDTC rulemaking materials tie that definition to the cloud carve-out and state that a release to a foreign person counts as an export to each country of that person’s citizenship or permanent residency. You need a license or a license exemption if you plan to let a foreign person view plaintext ITAR technical data, no matter where the server sits. DDTC materials make clear that this treatment stands apart from the encryption rule in Section 120.54, which covers only conditions where no release occurs.

ITAR Section 120.54 on cloud storage

ITAR Section 120.54 lists activities that ITAR does not treat as exports, reexports, retransfers, or temporary imports. The section includes an encryption rule for unclassified technical data in cloud environments. You can send, take, or store the data in a cloud service without creating an export when you meet all of these conditions:

You apply end-to-end encryption using FIPS 140 validated cryptographic modules, and you keep decryption means out of the hands of any third party.
You do not send the data from, and you do not make an intentional storage decision in, any country listed in ITAR 126.1 or in Russia.

The eCFR text also clarifies internet transit. Data that crosses a foreign country in transit does not count as storage in that country. Section 120.54(c) adds one more vital point. The mere ability of a person or a provider to access data that remains encrypted under these criteria does not count as a release.

The carve-out applies to unclassified technical data. DDTC materials exclude classified data from this relief, regardless of encryption.

End-to-end encryption and FIPS 140 in practice

The rule expects encryption from originator to intended recipient with no point where an untrusted party can decrypt. TLS between a client and a service does not satisfy that expectation on its own if the service can access plaintext. You need designs that keep decryption in your control and restrict decryption to intended recipients.

Two concrete patterns help:

Use FIPS 140 validated modules for encryption at rest and in transit, and document the module certificates.
Hold decryption keys under your control, manage key rotation, and separate key custodians from application admins.

You should demonstrate that no cloud operator, subcontractor, or foreign person can decrypt the data. Write this into your system security plan. Prove it with architecture diagrams, key custody procedures, and technical controls that back the claim. If you plan to share data with an external U.S. partner, bind that sharing to cryptography that you control and to identity proof that the partner can defend.

Identity, access, and key management

The deemed export rule shifts the focus to identity. Any foreign person who can view decrypted technical data triggers export licensing. You need an identity and access stack that lets you enforce U.S.-person access for ITAR data and prove it.

Practical steps that hold up under scrutiny:

Tie account issuance to HR and export-control vetting. Record citizenship and permanent residency status, and record license terms where they exist.
Use groups or attributes that mark U.S.-person status, and drive access to ITAR locations from those attributes.

Conditional access needs to enforce the boundary at session time and at data movement boundaries.

Block sign-ins from proscribed countries, require device compliance, and require strong MFA.
Restrict session actions for sensitive locations, including download blocks, clipboard controls, and print blocks.

Keys need the same discipline.

Assign key custodians who meet U.S.-person criteria. Use change control for key rotation and access.
Keep key escrow and recovery in your custody. Do not grant a provider or a third party the ability to decrypt.

Pair these controls with data loss prevention. Label ITAR data, restrict external sharing, and control egress. You can find design patterns for these controls in our posts on Conditional Access for DFARS 7012 and Microsoft Purview CUI DLP.

Microsoft 365 GCC High considerations

Microsoft states that GCC High supports U.S. Department of Defense missions and contractors that hold or process DoD CUI or that operate under ITAR. Microsoft describes assessments against NIST SP 800-53 at a FIPS 199 High impact level and support for demonstrating DoD IL4 equivalency. Microsoft also screens prospective GCC High and DoD customers against export-control lists, including BIS lists and the DDTC Debarred Persons List.

These facts help you make a cloud decision, but they do not close export-control gaps by themselves. Your team must build and run encryption and identity controls that meet Section 120.54 conditions and the deemed export rule. Many contractors select GCC High as the export-controlled enclave for Microsoft 365 workloads. Plan that move with a clear view of identity boundaries, data routing, and key custody. Our GCC High migration decision framework outlines the tradeoffs you will need to manage.

CMMC and DFARS alignment for export-controlled enclaves

Most ITAR programs in the DIB also handle CUI. DFARS 252.204-7012 and NIST SP 800-171 Rev 2 remain the security baseline for that data. DoD CIO materials for CMMC Level 2 point straight at NIST SP 800-171 Rev 2, and the Level 2 Scoping Guide places any asset that processes, stores, or transmits CUI inside the assessment boundary. An ITAR enclave in GCC High sits squarely inside that scope.

A few 800-171 requirements map cleanly to the export-control concerns in this post:

SC.L2-3.13.11. Use FIPS-validated cryptography to protect CUI.
AC.L2-3.1.1 and AC.L2-3.1.3. Limit access to authorized users and control the flow of CUI.
IA.L2-3.5.1. Identify users and tie actions to identities before access.
MP.L2-3.8.3. Sanitize or destroy media before disposal or reuse.
RA.L2-3.11.1. Assess risk tied to CUI processing, storage, and transmission.

Your documentation needs to show how you meet Section 120.54 and these controls at the same time. Write down the encryption design and list the FIPS 140 validations you rely on. Show identity proof for U.S.-person access, show conditional access policies, and show how you enforce device compliance. Diagram mail flow, file storage, and external sharing routes. Include license determinations where foreign persons view plaintext under a license or exemption. Keep all of this in your system security plan and supporting procedures.

Practical edge cases you should settle before go-live

Cloud realities can undermine a clean export-control story unless you settle them up front.

Admin operations. Restrict tenant admins and support contacts to U.S. persons. Use break-glass access with logging and approvals, and keep vendor support out of the decrypted path.
Backups and eDiscovery. Keep key custody and U.S.-person access across backup, archive, and discovery paths. If a service holds keys, revisit the design.

A BIS advisory opinion and related conference materials have described scenarios where a provider receives encrypted technical data, on U.S.-based infrastructure, under U.S.-person administration, while the exporter holds decryption keys, and that scenario does not constitute an export. Treat this as directional context, not a blanket permission slip. Section 120.54 and DDTC materials remain the authority.

Bottom line for DIB leaders

You can run unclassified ITAR technical data in the cloud without creating an export event, if you meet Section 120.54 conditions and keep decryption and access in U.S.-person hands. GCC High offers a strong foundation for that design. Your export-control posture rises or falls on encryption design, key custody, and identity proof backed by records.

Work with export counsel and a DDTC practitioner before you light up collaboration across organizations or across borders. Align the export-control program with your 800-171 control set and your DFARS 7012 reporting and incident response obligations. Tighten the design, write it down, and enforce it every day.