ITAR Cloud Compliance Best Practices Beyond Encryption

Most defense contractors I talk to think they've solved ITAR cloud compliance the day their IT provider turns on encryption at rest and in transit. They haven't. Encryption is the entry ticket, not the whole show. The regulation that lets you store and transmit technical data through commercial cloud infrastructure without triggering an export, 22 CFR 120.54(a)(5), sets encryption as one of five conditions that all have to hold at once. Miss the cloud authorization level, get sloppy on access controls, or let a foreign national engineer log into the wrong environment, and the encryption was never the problem you had.

This guide walks through the three pieces that trip up companies after they've checked the encryption box: choosing a cloud environment with the right federal authorization, building access controls that actually satisfy the underlying safeguarding rules, and segregating foreign person access in a way that survives a State Department review.

Why Encryption Alone Doesn't Satisfy ITAR

Start with what 22 CFR 120.54(a)(5) actually says, because most of the confusion in this space comes from people reading the headline ("encrypted data isn't an export") and skipping the fine print.

The exemption applies only when technical data is:

• Unclassified.
• Secured using end-to-end encryption.
• Protected by cryptographic modules compliant with FIPS 140-2 (or its successors), combined with NIST-consistent key management.
• Never intentionally sent to or stored in a country listed in 22 CFR 126.1 or in the Russian Federation.
• Never sent from one of those countries.

That's five conjunctive conditions, and missing even one means the 120.54(a)(5) exemption doesn't apply, though that doesn't necessarily mean the transfer is unauthorized outright; other exemptions or license pathways may still cover it.

Notice what the rule does not say. It doesn't say the cloud provider needs a particular federal authorization. It doesn't say anything about who inside your company can access the decrypted data once it lands on someone's laptop. It doesn't address foreign employees at all. The rule is narrow by design. It addresses one question: does storing or moving encrypted data through a cloud server count as an export? Everything else is governed by other parts of the compliance stack: the FedRAMP baseline of your cloud environment, who has login credentials, and how you keep a foreign person engineer away from technical data he isn't authorized to see. Companies that stop reading at 120.54 usually get surprised by DFARS flow-down clauses or by their own contract's cybersecurity requirements six months later.

FedRAMP and DoD Impact Levels: Choosing the Right Cloud Authorization

DDTC's cloud rule doesn't require a specific FedRAMP baseline. Your prime contract almost certainly does. If your company holds a DoD contract, DFARS 252.204-7012 requires you to implement NIST SP 800-171, and when you use an external cloud provider to store, process, or transmit covered defense information, that provider has to meet security requirements equivalent to the FedRAMP Moderate baseline at a minimum, per the DFARS 252.239-7010 cloud computing services clause. Moderate baseline is the regulatory floor. In practice, for ITAR technical data specifically, the floor is usually too low.

The Defense Information Systems Agency's Cloud Computing Security Requirements Guide maps commercial cloud offerings to DoD Impact Levels, and this is the framework I use with clients to pick a cloud tenant. IL2 covers FedRAMP Moderate for non-CUI, publicly releasable data, which doesn't apply to export-controlled technical data at all. IL4 adds a DoD-specific overlay on top of FedRAMP Moderate and is built for Controlled Unclassified Information, including export-controlled CUI. IL5 requires FedRAMP High plus additional DoD controls and is meant for higher-sensitivity CUI and National Security Systems. IL6 is for classified data and isn't relevant unless your technical data carries a classification, which most USML technical data does not.

A few things I've learned advising manufacturers through this decision. First, a commercial FedRAMP Moderate authorization, the kind a general-business SaaS vendor might hold, is not the same as a DoD IL4 authorization, even though both sit on the FedRAMP Moderate control baseline. IL4 adds DoD-specific controls the commercial baseline doesn't require. Ask your cloud provider for the specific Provisional Authorization number and impact level, not just "we're FedRAMP authorized." Second, Microsoft's GCC High and Google's Assured Workloads, and AWS GovCloud, are the environments built to IL4/IL5 that most small and mid-sized defense manufacturers end up choosing, precisely because standard commercial tenants (regular Microsoft 365, standard AWS commercial regions) are not authorized at that level regardless of how good their encryption is.

Takeaway: FedRAMP Moderate authorization alone does not satisfy the practical requirements for hosting export-controlled technical data on a DoD-flowdown contract. IL4 is the floor most primes and DCMA assessors expect to see.

Access Controls Beyond Encryption: What NIST 800-171 Requires

If DFARS 252.204-7012 is in your contract, and it is in nearly every defense subcontract at this point, you're on the hook for the 110 controls in NIST SP 800-171, not just encryption. Several of those controls speak directly to cloud access, and they're the ones auditors and DCMA assessors actually check.

Six controls do most of the work:

• 3.1.1 — Limit system access to authorized users, processes, and devices, which means your cloud tenant needs a real identity and access management layer, not a shared login.
• 3.1.3 — Control the flow of CUI in accordance with approved authorizations, forcing you to think about where technical data can move once it's inside your environment, not just whether it's encrypted getting there.
• 3.1.5 — Enforce least-privilege access, so engineers get access to the specific program folders they work on, not the whole technical data repository.
• 3.5.3 — Require multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts; single-factor password logins don't satisfy this no matter how strong the password policy looks on paper.
• 3.13.11 — Use FIPS-validated cryptography when cryptography protects CUI, which is the NIST-side mirror of what 120.54(a)(5) already demands on the ITAR side.
• 3.3.1 — Create and retain system audit logs, which is what lets you prove, months later, who touched a given technical data file and when.

None of these controls are optional add-ons. They're the baseline DFARS 252.204-7012 contractually obligates you to self-attest against, and as of the CMMC program rule at 32 CFR Part 170, CMMC Level 2 certification requires an assessment against this same NIST SP 800-171 control set. A cloud environment that's encrypted but doesn't enforce least privilege, doesn't require MFA on privileged accounts, and doesn't log access, fails these controls regardless of what the encryption looks like. In my experience, this is the gap that shows up most often in a pre-audit review: the encryption is fine, but access is managed through a flat permission structure where everyone in the company can technically open every program folder.

Foreign Person Data Segregation: Solving the Deemed Export Problem

This is where cloud compliance intersects with the part of ITAR that trips up even well-run companies: the deemed export rule. Under the ITAR, releasing technical data to a foreign person inside the United States is treated as an export to that person's country of nationality, even if the data never physically leaves U.S. soil. A foreign person granted network credentials to a system containing ITAR technical data has received a deemed export the moment access is possible, regardless of whether the person ever opens the file. Access, not use, is what matters.

That rule doesn't care that your cloud environment is FedRAMP High and encrypted end to end. If a dual-national engineer, a foreign national intern, or a contractor from an overseas staffing firm can log into a shared drive that contains USML technical data, you have a compliance problem the moment the account is provisioned, not the moment someone downloads a file.

Physical data segregation, running a completely separate server or data center for foreign nationals, is rarely what a cloud environment needs and is almost never practical for a small or mid-sized manufacturer. What works instead is logical segregation enforced through identity and access management: role-based or attribute-based access control where nationality is a tracked attribute in your identity provider, and technical data folders, SharePoint sites, or PLM/PDM repositories are permissioned against that attribute automatically rather than through manual, ad hoc folder sharing. Practically, that means:

• Nationality and export authorization status captured at onboarding and tied to the user's identity record, not tracked in a spreadsheet somewhere in HR.
• Technical data repositories segmented by program or product line, with access groups mapped to a documented need-to-know list, not company-wide default access.
• Automatic access reviews triggered when an employee's visa status, citizenship, or role changes, since a green card holder today and a foreign national contractor tomorrow are two different access profiles.
• A documented Technology Control Plan that specifies exactly which systems, folders, and physical spaces are restricted, and who approved each foreign person's limited access, if any, under a license or license exemption.
• Conditional access policies in the cloud tenant itself (most IL4-authorized environments support this natively) that block or flag login attempts inconsistent with the user's authorized access profile.

Companies that get this wrong tend to make the same mistake: they build excellent perimeter security and excellent encryption, then leave internal folder permissions wide open because nobody assigned ownership of "who can see what" once the file is inside the corporate network. The deemed export rule doesn't care about your perimeter. It cares about internal access.

Cloud Service Provider Selection Checklist

When I'm evaluating a cloud environment for a client handling ITAR technical data, I work through this list before anything else:

1. Confirm the specific DoD Impact Level authorization (IL4 minimum for export-controlled technical data), not just a general FedRAMP claim.
2. Verify the provider's cryptographic modules are FIPS 140-2 or successor validated, and confirm key management practices align with NIST guidance, satisfying both 22 CFR 120.54(a)(5)(iii) and NIST SP 800-171 control 3.13.11.
3. Confirm data residency: the environment must not store or route data through a country listed in 22 CFR 126.1 or through Russia, per 120.54(a)(5)(iv)-(v).
4. Require multifactor authentication on all privileged and network accounts (NIST 800-171 control 3.5.3).
5. Confirm the environment supports attribute-based access control so nationality and need-to-know can be enforced logically rather than through manual folder permissions.
6. Confirm audit logging is enabled and retained long enough to support an internal investigation or a voluntary disclosure timeline.
7. Get the flow-down commitments in writing: your cloud provider's contract should explicitly reference its Impact Level authorization and its NIST SP 800-171 compliance posture, not leave you inferring it from marketing material.

Common Mistakes We See in Cloud ITAR Programs

The most common failure pattern isn't a bad cloud provider. It's a good cloud provider configured badly. A company buys Microsoft GCC High, which is a legitimate IL4/IL5-capable environment, and then recreates its old flat-permission file structure inside it, undoing most of the benefit. The second most common mistake is treating the Technology Control Plan as a document you write once for the DDTC registration file and never update, when in reality it needs to track actual personnel changes, actual folder structures, and actual access grants as they happen. The third is assuming a signed non-disclosure agreement with a foreign national employee substitutes for an access restriction. It doesn't. An NDA controls what someone can say. It does nothing to control what a login credential lets them see.

If you're building or auditing an ITAR compliance program that touches cloud infrastructure, it's worth reviewing how access segregation fits into your broader deemed export exposure and how the rest of your compliance program is structured to support it.

FAQ

Does encrypting technical data in the cloud automatically satisfy ITAR? No. Encryption satisfies one of five conjunctive conditions under 22 CFR 120.54(a)(5). You also need to avoid storing or transmitting through countries listed in 22 CFR 126.1 or Russia, use FIPS-validated cryptographic modules with proper key management, and keep the data unclassified. Separately, your contract's cybersecurity clauses and internal access controls govern who can view the decrypted data.

What FedRAMP level do I need for ITAR technical data? There's no FedRAMP requirement written directly into the ITAR. Your DoD contract's DFARS 252.239-7010 clause requires FedRAMP Moderate baseline at minimum, but in practice, DoD Impact Level 4, built on the FedRAMP Moderate baseline with an added DoD overlay, is the realistic floor most primes and assessors expect for export-controlled technical data. IL5 is appropriate for higher-risk programs.

Do I need to physically separate foreign national employees from U.S. systems? Usually not. Logical segregation through role-based or attribute-based access control, tied to nationality data in your identity management system, is generally sufficient and far more practical than maintaining separate hardware or data centers. What matters is that a foreign person cannot access technical data without documented authorization, not that they work in a different building.

Is a signed NDA enough to let a foreign national employee work near ITAR data? No. An NDA is a confidentiality commitment, not an access control. The ITAR deemed export rule is triggered by the ability to access controlled technical data, regardless of any confidentiality agreement. You need actual technical and administrative controls restricting access, documented in a Technology Control Plan.

How is CMMC different from these cloud requirements? CMMC, under the program rule at 32 CFR Part 170, verifies through third-party or self-assessment that a contractor has implemented NIST SP 800-171 controls, which include many of the access control and cryptography requirements discussed here. CMMC doesn't replace ITAR's deemed export or 120.54 cloud rules; it verifies a separate but overlapping cybersecurity control set that most defense contracts now require alongside ITAR compliance.

If your cloud environment, access control structure, or foreign person screening process hasn't been reviewed against these three layers, that's the gap worth closing before your next DCMA assessment or license application, and it's a conversation I have with manufacturers starting ITAR compliance programs fairly often, usually right after they've already dealt with the deemed export basics but haven't translated that into cloud access architecture.

Last updated: 2026-09-28