ITAR 120.54 Cloud Storage: Encryption and Access Rules

If you store ITAR-controlled technical data in a commercial cloud environment, the rule that decides whether you have an unauthorized export problem is 22 CFR 120.54, specifically the carve-out at 120.54(a)(5) for encrypted electronic storage and transmission. Unauthorized disclosure of ITAR technical data to a foreign person is a violation regardless of where the server sits, and getting the encryption and access architecture wrong does not become less serious just because IT configured it correctly on paper.

I'm Jared Clark, principal consultant at Certify Consulting (certify.consulting), and this guide walks through what 120.54 actually requires, the encryption standard that satisfies it, what access control means in practice once you move past server location, and the audit trail your program needs to survive a Directorate of Defense Trade Controls (DDTC) review.

One correction up front, because it matters for anyone citing this rule to a customer or an auditor: 120.54's cloud-encryption exemption is younger than a lot of guidance material suggests, including some of my own earlier writing on this topic. It did not come out of the 2016 ITAR overhaul. It came three years later, from a different rulemaking, and the date matters because it changes which version of the rule applies to older data-handling decisions your company may still be relying on.

What 22 CFR 120.54 Actually Says

22 CFR 120.54 lists activities the ITAR does not treat as an export, reexport, retransfer, or temporary import. The cloud-storage provision inside it, 120.54(a)(5), was added by an interim final rule the State Department published on December 26, 2019, titled "International Traffic in Arms Regulations: Revision of Definitions of Export, Reexport, Retransfer, and Temporary Import," at 84 FR 70887. The rule became effective March 25, 2020.

That is a separate action from the 2016 ITAR rulemaking (81 FR 35611), which restructured the technical data definition under 22 CFR 120.33 and introduced the current export/reexport/retransfer/release vocabulary. The 2016 rule built the frame the 2019 rule was added to. It did not itself create a cloud-encryption exemption. If you have seen the 2016 date attached to 120.54's cloud provision elsewhere, that is very likely a mix-up with the Export Administration Regulations' equivalent, 15 CFR 734.18, which really was added in 2016. They are different rules on different clocks, and the three-year gap between them is why a lot of contractors' cloud policies cite the wrong provision or the wrong year.

The operative test in 120.54(a)(5) has three parts:

1. The technical data must be unclassified and protected by end-to-end encryption, implemented through cryptographic modules that meet FIPS 140-2 or its NIST successor. Encryption that the provider, not you, can turn off or bypass does not qualify.

2. The data cannot be intentionally sent to, or stored in a data center located in, a country described in 22 CFR 126.1, or in the Russian Federation — and it cannot be sent from one of those countries either. This is a destination test, independent of the encryption test.

3. The exemption covers the data while it is encrypted, in transit and at rest. It does not authorize releasing decrypted technical data to a foreign person once it lands somewhere. That release is governed separately by the deemed-export rule at 22 CFR 120.50, and 120.54 does not touch it.

The rule's supplementary discussion is explicit on a point that trips up almost every company I've reviewed: the exemption depends on the data remaining unavailable in decrypted form to the cloud service provider at all times. If your provider holds keys that let it decrypt your data, for support purposes, for e-discovery, or for its own operational reasons, the exemption does not apply to that data no matter how strong the algorithm is.

What the rule does not do is name a cloud provider, require a specific FedRAMP authorization level, or mandate a particular architecture. It sets an outcome (encrypted, provider can't decrypt, right destination) and leaves the implementation to you.

Why Cloud Providers Don't Automatically Qualify

Companies frequently assume that using a major provider's government-cloud offering — AWS GovCloud, Microsoft Azure Government, Google Cloud for Government — automatically satisfies 120.54. It does not, and the gap is almost always the same one.

These platforms have the architecture to support 120.54 compliance, but the default configuration of a commercial account does not get you there on its own. By default, most providers hold encryption keys in their own key management service. Support personnel with elevated privileges may retain the technical ability to access customer data, whether or not they exercise it. And automated data replication for redundancy can place copies in regions where the workforce is not subject to your access controls.

The exemption runs with your encryption and access architecture, not with the provider's brand, certification portfolio, or government-cloud marketing.

The Encryption Standard That Satisfies 120.54

The federal cryptographic-module standard referenced by 120.54(a)(5) is NIST FIPS 140-3, Security Requirements for Cryptographic Modules, approved by NIST in March 2019 as the successor to FIPS 140-2. NIST's Cryptographic Module Validation Program stopped accepting new FIPS 140-2 submissions in September 2021, though modules validated earlier under 140-2 remain listed and usable. In practice, this is what compliance requires:

Neither FedRAMP nor a specific authorization level appears anywhere in 120.54's text. That said, many defense contractors benchmark their cloud architecture against the FedRAMP High baseline and the Department of Defense Cloud Computing Security Requirements Guide (SRG), Impact Level 4 or 5 controls, because those frameworks impose a documented, independently assessed set of physical and administrative controls that maps cleanly onto what an auditor will ask about. Neither is a 120.54 mandate. Both are common industry reference points for contractors who want a defensible starting configuration rather than building one from scratch.

If your environment is using provider-managed keys today, treat that as an open finding in your compliance program regardless of what your service agreement says about security.

Access Control: The Part That Actually Gets Companies in Trouble

Encryption is the foundation, but access control is where violations actually happen. The deemed-export rule at 22 CFR 120.50 treats the release of ITAR technical data to a foreign national inside the United States as an export to that person's country of nationality. That rule does not pause because the data happens to be sitting in cloud infrastructure.

Here is where the gap usually shows up:

Provider support access. Opening a support ticket can hand a support engineer, who may not be a U.S. person, the technical ability to access your environment. Some enterprise agreements let you restrict support access to U.S. persons, but you have to affirmatively select and enforce that option; it is rarely the default.

Identity federation and single sign-on. If your identity provider federates with a parent company or partner organization that includes foreign nationals, those users can inherit access to repositories containing technical data. IT teams typically configure federation for convenience and don't separately audit the downstream ITAR access implications.

Shared administrative accounts. Service accounts and admin credentials shared across a team that includes foreign nationals create deemed-export exposure even when no individual deliberately opens a controlled file.

Replication and backup. Automated disaster-recovery processes can copy data to regions staffed by non-U.S. personnel. If the keys used at the backup facility are accessible to staff there, the exemption is compromised even though the primary copy is fine.

The fix that actually holds up under review is a documented access control matrix: every user, every service account, and every provider-support role, mapped to a citizenship or nationality determination under 22 CFR 120.62 (U.S. citizens, lawful permanent residents, protected individuals under 8 U.S.C. § 1324b(a)(3), and entities incorporated in the U.S.), reviewed and recertified at least annually.

Consolidated Control Reference: What DDTC Expects to See

A Technology Control Plan (TCP) is where all of this gets written down. Most TCPs were drafted for a physical facility, badge readers and locked file cabinets, not a cloud tenant. Rather than treat encryption, access control, logging, and record-keeping as separate documentation exercises, use one reference across your TCP, your internal audits, and whatever DDTC or a Blue Lantern check asks to see. For a broader walkthrough of what belongs in a TCP beyond the cloud-specific elements below, see this site's guide to technology control plans.

If you can produce every row of this table on demand, you're in a defensible position. If a row is missing or stale, that's a finding, and depending on severity, potentially a disclosure obligation.

Building the Architecture: A Short Procedural Walkthrough

The sequence matters more than the individual steps. Clients who skip ahead to the technical build before resolving the policy questions end up with a configured environment that sits idle for months while legal, HR, and compliance catch up.

1. Inventory first. Identify every repository, drawing, spec, and model that qualifies as ITAR technical data under 22 CFR 120.33, and flag anything that might instead be EAR-controlled. The USML/CCL classification line has to be resolved before you know which rule governs a given file — this site's USML categories guide is a useful reference for that first pass.
2. Segregate the tenant. If your current environment is shared with international users or parent-company accounts outside the U.S., stand up a separate tenant where access can be controlled independently.
3. Turn on customer-managed keys. Provision an HSM, generate customer-managed keys, and configure storage services to use them instead of provider-managed defaults.
4. Configure IAM against the access control matrix, not the org chart. Repositories containing ITAR technical data should be reachable only by roles whose membership is tied to a documented nationality determination.
5. Restrict and log provider support access, using the contractual options in your enterprise agreement plus technical controls that require your explicit authorization for any support session.
6. Close the loop. Update the TCP, train everyone who touches the environment, and put an annual recertification date on the calendar. Every row in the control table above needs an owner and a review date — that's what turns this into a program instead of a one-time project.

ITAR vs. EAR: Does the Cloud Exemption Apply on Both Sides?

Companies working under both regulatory regimes sometimes assume 120.54 covers everything in their cloud environment. It doesn't. The Export Administration Regulations have their own, separate encrypted-cloud-storage provision, and it predates the ITAR version by about three years.

The practical implication: if your environment holds both ITAR technical data and EAR-controlled technology, you need both exemptions satisfied, separately, for the data each one covers. Note also that 15 CFR 734.13, not the older 734.2(b)(2)(ii) numbering, is the current EAR provision addressing release and deemed export; Part 734 was reorganized in 2016 and the older citation no longer reflects the current rule. For the broader jurisdictional question of which items fall under which regime in the first place, see this site's ITAR vs. EAR comparison guide.

Common Mistakes Worth Naming Directly

Assuming "encrypted" equals "compliant." Encryption is necessary but not sufficient. If a foreign national, including provider support staff, can access the decryption keys, the exemption does not apply to that data.

Relying on provider certifications as a substitute for your own controls. A FedRAMP authorization means the provider's infrastructure meets a federal security baseline. It says nothing about whether your specific configuration of that infrastructure satisfies 120.54's key-custody and destination requirements.

Treating the cloud policy as an IT-only document. Confidentiality and availability are IT concerns. Nationality of the people who can access the data is a different question, and it needs its own answer in writing.

Bringing compliance in after the architecture is live. When technical data moves to the cloud, the compliance team needs to be part of the design decision, not asked to bless a configuration that's already in production.

Frequently Asked Questions

When did the ITAR cloud storage exemption take effect? March 25, 2020. The State Department published the interim final rule creating 22 CFR 120.54(a)(5) on December 26, 2019, at 84 FR 70887, with a 90-day effective date.

Does 22 CFR 120.54 mean I can use any commercial cloud provider for ITAR technical data? No. The exemption depends on your specific encryption and key-custody configuration, not the provider's brand or government-cloud certification. If the provider can decrypt your data under any circumstance, the exemption doesn't apply, regardless of which platform you're using.

Is there an EAR equivalent to 120.54? Yes. 15 CFR 734.18 is the EAR's analogous encrypted-cloud-storage carve-out, added in 2016, roughly three years before the ITAR version. It covers CCL-controlled technology and software, not ITAR technical data, so a dual-regulated company needs both exemptions satisfied for the respective data each one governs.

What's the actual penalty exposure for storing ITAR technical data in a non-compliant cloud configuration? Two separate tracks apply. The civil penalty ceiling under 22 CFR 127.10 is adjusted annually under the Federal Civil Penalties Inflation Adjustment Act and currently stands at $1,271,078 per violation. Separately, the Arms Export Control Act's criminal provision, 22 U.S.C. § 2778(c), sets a penalty of up to $1,000,000, up to 20 years imprisonment, or both, per willful violation. These are distinct exposures, not alternatives to each other.

Do I need FedRAMP High to comply with 120.54? No. FedRAMP authorization level isn't mentioned in the rule. FedRAMP High and the DoD Cloud Computing SRG Impact Level 4/5 controls are common industry reference points that give you a documented, assessed baseline, but the regulation itself only requires the encryption, key-custody, and destination conditions described above.

Where People Get Stuck

In my experience, the bottleneck is rarely technical. IT can stand up customer-managed keys in a few days. What takes months is the legal question of exactly who qualifies as a U.S. person under 22 CFR 120.62, the HR question of how you verify and document that status, and the vendor-management question of what your cloud contract actually obligates the provider to do about support access. Those three tracks need to run in parallel, with people from legal, HR, IT, and compliance working from the same project plan. Run them one after another and the technical build finishes and sits idle for half a year while the policy questions get resolved.

The 120.54 exemption is genuinely useful. It lets defense contractors use modern cloud collaboration tools without treating every file share as an export licensing question. It only works, though, if the architecture and the program around it match what the rule actually requires, not what a provider's marketing page implies.

Last updated: 2026-09-21