CUI Is Not an Export License — ITAR and EAR as a Separate Overlay

Two questions, two bodies of law

A defense contractor handling technical data is really answering two independent questions at once:

1. The safeguarding question. Is this information protected to the required standard? Answered by FAR 52.204-21, DFARS 7012, NIST SP 800-171, and CMMC.
2. The authorization question. Is this transfer, release, or access permitted at all — to this person, in this country, by this path? Answered by ITAR, EAR, or another export authority.

You can be fully compliant on the first question and committing a violation on the second. Encryption protects data. It does not grant authorization.

The controlling authority, classification, destination, end user, nationality, access path, license or exemption, and the technical facts determine whether a transfer or release is authorized. A CUI banner tells you almost none of that.

Marking precision

The NARA CUI Registry lists CUI//SP-EXPT for specified export-control authorities, with CUI or CUI//EXPT alternatives for basic authorities. Use the banner and dissemination controls supplied by the government or determined under the applicable authority.

ITAR and EAR are not one test

People say “ITAR/EAR” as though it were a single regime. It is two, with different scopes and different analyses:

The deemed-export trap

The rule that surprises engineering teams most: releasing controlled technology or source code to a foreign person can be an export even if nothing crosses a border. A foreign-national employee at a desk in Ohio reading a controlled drawing may be a licensable event.

This is where cybersecurity and export control collide productively. Your access control implementation (IT-01) and your asset and identity inventory (IT-02) are the mechanisms that make person-level export restrictions enforceable. If you cannot answer “exactly which humans can reach this repository, and what is their person status,” you cannot demonstrate export compliance either.

The encryption safe harbor — narrow, conditional, all-or-nothing

Both regimes provide a path where properly encrypted unclassified data may not be treated as an export. These are narrow, conditional safe harbors, not general permission to put controlled data anywhere with encryption turned on. Typical conditions include:

• End-to-end encryption — the data remains encrypted from origination to destination, with no intermediate decryption point.
• Cryptographic strength — FIPS-validated or equivalent, per the applicable rule.
• Key control — the keys, and the access information required to derive them, are not provided to a third party or stored where an unauthorized party can obtain them.
• Destination limits — under the EAR, intentional storage in Country Group D:5 falls outside the §734.18(a)(5) safe harbor.

The conditions are conjunctive. Miss one — a provider that can decrypt, a key escrowed with the vendor, an unexamined replication region — and you are outside the safe harbor entirely. This is why “our cloud provider encrypts at rest” is not an export answer.

Cloud and enclave decision framework

When you evaluate a cloud service or enclave for export-sensitive work, answer all seven of these — not just the first two:

1. Contract security. Does the offering meet DFARS 7012 (or the proposed FAR CUI) cloud requirements, including incident reporting, preservation, and forensic cooperation?
2. CMMC scope. Is the offering FedRAMP authorized at Moderate or higher, or can you document and assess FedRAMP Moderate equivalency as permitted by the applicable rule?
3. Export authority. What jurisdiction and classification apply, and can any foreign person, destination, or support path receive decrypted data or access information?
4. Source allowability. Is the exact vendor, model, API, marketplace route, integration, and material subprocessor permitted for this contract and mission?
5. Operational controls. Who controls keys, support escalation, backup locations, logging, incident evidence, and administrative access?
6. Offering-specific evidence. Do not rely on the product-family name. Validate the exact tenant, region, SKU, authorization boundary, contract terms, and shared-responsibility matrix.
7. AI dependency evidence. Maintain an AI bill of materials and software bill of materials covering models, hosting platforms, agents, libraries, data sources, routing services, integrations, and downstream consumers.

Where GCC High actually fits

GCC High is often a strong design choice for DoW CUI and export-sensitive workloads — sovereignty, screened support personnel, and a government-oriented authorization posture genuinely simplify several of the questions above.

But three precisions matter:

• It is not a universal clause requirement. DFARS 7012 does not name it. The determination is offering-specific.
• It is not a substitute for export classification. Choosing a tenant does not classify your technical data or authorize a release.
• It is not a source-allowability decision. A compliant environment can still contain a component that is not permitted on a given contract.

Select the environment from the combined contract, cybersecurity, supply-chain, export, and mission analysis. For the cost and licensing side of that decision, see GCC High vs. Commercial Microsoft 365 and What a GCC High migration should cost.

Key takeaways

• Safeguarding and authorization are different questions. CMMC status never establishes export compliance.
• Markings vary and are often absent. Determine the controlling authority; don't pattern-match on banners.
• ITAR and EAR are two regimes, with different scopes, exemptions, and safe-harbor conditions.
• Deemed exports make person status a security control. Your access control and identity inventory are export-compliance mechanisms.
• The encryption safe harbors are narrow and conjunctive — miss one condition (keys, decryption point, destination) and you are outside them.
• GCC High is a design choice, not an export answer. Decide from the combined analysis, and treat source allowability as its own gate.