US Export Controls on Encryption: EAR and Commerce Department Rules

US export controls on encryption represent one of the most technically complex compliance domains in US trade law, governing which cryptographic products and technologies may be shipped, transmitted, or made available abroad — and under what conditions. The framework spans the Export Administration Regulations (EAR), administered by the Bureau of Industry and Security (BIS) within the Department of Commerce, and intersects with licensing requirements, classification codes, and foreign policy restrictions maintained across multiple federal agencies. The stakes range from delayed market entry to criminal penalties under 50 U.S.C. § 4819 for willful violations. This page maps the structure of that regulatory landscape for professionals, researchers, and organizations navigating encryption exports.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps (Non-Advisory)
• Reference Table or Matrix

Definition and Scope

The Export Administration Regulations (15 C.F.R. Parts 730–774) define "export" broadly: physical shipment abroad, transmission of technology by electronic means, oral disclosure to a foreign national in the United States (the "deemed export" rule), and in-country transfers. Encryption items fall primarily under Category 5, Part 2 of the Commerce Control List (CCL), titled "Information Security," and carry the designation 5E002 (technology), 5D002 (software), or 5B002 (test equipment). The Bureau of Industry and Security (BIS) publishes the CCL as Supplement No. 1 to Part 774 of the EAR.

Scope extends to:
- Commercial encryption software with key lengths exceeding defined thresholds
- Hardware with integrated cryptographic capability
- Technical data, source code, and design specifications for cryptographic systems
- Mass market encryption products prior to or after review

The definitions intentionally cast a wide net. A cloud service that encrypts stored data using AES-256 — covered in detail at AES Encryption Standard — and then routes that service to foreign users may constitute a deemed re-export requiring classification review.

Core Mechanics or Structure

The Commerce Control List and ECCN 5x002

Every encryption item subject to BIS jurisdiction carries an Export Control Classification Number (ECCN). The 5x002 family (5A002, 5B002, 5D002, 5E002) covers encryption hardware, test equipment, software, and technology respectively. An ECCN determines which countries require a license (via the Country Chart in Supplement No. 1 to Part 738), which license exceptions are available, and what end-use restrictions apply.

License Exceptions for Encryption: ENC and TSU

Two license exceptions are specifically applicable to encryption:

ENC (Encryption) — Codified at 15 C.F.R. § 740.17, ENC allows export of many encryption items without a license, subject to registration, reporting, and review obligations. There are three tiers within ENC:
- ENC(b)(1) — Mass market products after a 30-day BIS review period
- ENC(b)(2) — Non-standard cryptography items requiring prior BIS review
- ENC(b)(3) — Products for certain foreign government end-users, requiring more restrictive handling

TSU (Technology and Software Unrestricted) — Codified at 15 C.F.R. § 740.13, TSU covers publicly available encryption source code when it has been published without restriction (e.g., open-source repositories). However, even publicly available code can lose TSU eligibility if it is not genuinely in the public domain or if it is subject to additional controls.

Annual Self-Classification and Reporting

Under the ENC exception, exporters must file annual self-classification reports with BIS, identifying each product exported, the ECCN assigned, and the countries of destination. Reports are submitted through BIS's online Simplified Network Application Process Redesign (SNAP-R) system. Failure to file annual reports forfeits ENC eligibility.

Causal Relationships or Drivers

The current regulatory structure emerged from the Wassenaar Arrangement, a multilateral export control regime established in 1996 and maintained by 42 participating states (Wassenaar Arrangement Secretariat). The Arrangement defines common control lists for dual-use goods and technologies, including encryption, and the EAR's CCL Category 5, Part 2 is substantially derived from Wassenaar's List of Dual-Use Goods and Technologies.

A second driver is the distinction between civilian and government use. The State Department's International Traffic in Arms Regulations (ITAR), administered through the Directorate of Defense Trade Controls (DDTC) under 22 C.F.R. Parts 120–130, historically covered cryptographic devices designed for military use. A 1996 transfer of jurisdiction — the "600 Series" and prior reforms — moved most commercial encryption products from ITAR to EAR. Products remaining on the US Munitions List (USML) under ITAR include classified cryptographic systems and certain key-management architectures designed for classified government communications.

Foreign policy also drives classification. Cuba, Iran, North Korea, Syria, and Russia are subject to sanctions programs administered by the Office of Foreign Assets Control (OFAC) at the Department of Treasury (OFAC), which layer on top of BIS's CCL controls. An encryption product with a valid ENC license exception for most destinations may still require separate OFAC authorization or be outright prohibited for sanctioned jurisdictions.

The encryption compliance landscape for US regulations covers the intersecting domestic mandates — HIPAA, FISMA, PCI DSS — that often drive the same products into export review.

Classification Boundaries

EAR99 vs. Controlled Encryption Items

Not all encryption products are controlled. An item that does not appear on the CCL and is not subject to ITAR falls into the EAR99 classification. EAR99 items may be exported without a license to most destinations, though they remain subject to end-user and end-use restrictions.

A product using a controlled encryption algorithm — RSA, AES, ECDH — is not automatically CCL-controlled. The control trigger depends on implementation, key length, the primary function of the product, and whether it qualifies as mass market. The RSA encryption reference and elliptic curve cryptography pages cover the underlying algorithms that frequently appear in classification decisions.

Mass Market Determination

The "mass market" carveout is central to the classification boundary. BIS considers an encryption product to qualify as mass market (and thus eligible for ENC(b)(1)) when it:
- Is sold through retail channels without restriction to a wide range of end-users
- Has the same functions and feature set regardless of customer
- Does not require specialized installation by a supplier

The review period is 30 days after filing a mass market request via SNAP-R. BIS may extend review or request additional information.

Open Source and the TSU Boundary

Open-source cryptographic libraries — OpenSSL, libsodium, Bouncy Castle — frequently qualify for TSU if the source code is publicly available and not restricted. The TSU exception does not cover binary-only distributions of software that happens to incorporate open-source code, unless the binary itself is also publicly available without restriction.

Tradeoffs and Tensions

Security Strength vs. Export Access

Stronger encryption — longer key lengths, newer algorithms like those explored in post-quantum cryptography — provides greater security but historically triggered higher-level controls. The practical tension: enterprises building products that meet NIST cryptographic recommendations (NIST Cryptographic Guidelines) for domestic compliance may simultaneously face more restrictive export treatment.

Deemed Export and Remote Work

The deemed export rule creates operational tension for employers with foreign national employees. A software engineer with a non-US citizenship who has access to controlled encryption source code during employment may trigger a deemed export. Organizations must implement access controls or obtain appropriate licenses, creating HR and compliance costs that smaller companies may underestimate.

Open Source Ideology vs. Export Law

Open-source communities have historically contested the application of export law to cryptographic code. The 1999 case Bernstein v. United States Department of Justice (9th Circuit) held that source code qualifies as protected speech under the First Amendment, pressuring BIS to liberalize TSU eligibility for publicly available source. The tension between cryptographic openness and national security-based controls remains unresolved as post-quantum algorithms develop.

Common Misconceptions

Misconception: AES-256 encryption is automatically export-controlled.
Correction: AES-256 is ECCN 5D002 when embedded in a controlled software product, but products using AES-256 may qualify as mass market or TSU depending on how they are distributed. The algorithm's presence does not by itself determine the ECCN — the product's function, sales channel, and distribution model all factor in.

Misconception: Open-source encryption software requires no export review.
Correction: TSU eligibility requires that the code be publicly available without restriction. Code posted to a password-protected repository, distributed under export-restrictive licenses, or compiled into a closed binary distribution does not qualify for TSU.

Misconception: ITAR no longer applies to encryption products.
Correction: The 1996 reforms moved most commercial encryption to BIS/EAR, but cryptographic equipment designed for classified government communications, certain satellite encryption systems, and NSA Type 1 cryptographic devices remain on the USML under ITAR.

Misconception: Hosting encrypted data on a US server for foreign users is not an export.
Correction: Providing access to controlled encryption software or technology via SaaS platforms to foreign end-users can constitute an export or re-export under the EAR, depending on whether the user is accessing the software's functionality or receiving technical data.

Misconception: Annual BIS reporting is optional if no license violations occurred.
Correction: Annual self-classification reports are a mandatory condition of the ENC exception. Failure to file results in automatic loss of that exception for the filing period.

Checklist or Steps (Non-Advisory)

The following sequence describes the classification and compliance process as structured under BIS regulations. It is presented as a procedural reference, not as legal or compliance advice.

Step 1 — Determine jurisdiction
Assess whether the item is subject to EAR (BIS) or ITAR (DDTC). Encryption products that are purely commercial and not designed for military end-use are generally under EAR jurisdiction following the 1996 transfer.

Step 2 — Identify or assign an ECCN
Review the Commerce Control List, Category 5, Part 2. Determine whether the product's encryption functionality maps to 5A002, 5B002, 5D002, or 5E002. If none apply, confirm EAR99 classification through a self-classification process or request a Commodity Classification from BIS.

Step 3 — Check applicable license exceptions
Assess eligibility for ENC (§ 740.17) or TSU (§ 740.13). For ENC(b)(1) mass market, file a product registration in SNAP-R. For standard products, file a 30-day review request.

Step 4 — Screen destination, end-user, and end-use
Consult the Country Chart (Supplement No. 1 to Part 738), OFAC sanctions lists, BIS Entity List (BIS Entity List), and Denied Persons List. Encryption exports to embargoed destinations require either a specific license or an applicable general policy of denial applies.

Step 5 — Apply for a license if no exception applies
Submit a license application through SNAP-R. BIS coordinates with interagency reviewers including the Departments of State, Defense, and Energy.

Step 6 — Maintain records
EAR § 762.2 requires retention of export records for 5 years from the date of export. Records include shipping documents, export classifications, SNAP-R filings, and end-user statements.

Step 7 — File annual self-classification report
Submit the annual encryption report to BIS no later than February 1 of each calendar year covering the prior year's exports. Required regardless of whether a license or license exception was used.

Reference Table or Matrix

The encryption key management reference covers technical architectures — such as hardware security modules — that may independently trigger CCL controls under 5A002 or related ECCNs. The FIPS 140 encryption standards framework also intersects with export classification, as FIPS-validated modules are sometimes referenced in BIS licensing review to confirm algorithm and implementation standards.

References

• Bureau of Industry and Security (BIS), US Department of Commerce
• Export Administration Regulations (EAR), 15 C.F.R. Parts 730–774 — eCFR
• Commerce Control List, Category 5 Part 2 (Information Security) — BIS
• License Exception ENC, 15 C.F.R. § 740.17 — eCFR
• BIS Entity List
• Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies
• Office of Foreign Assets Control (OFAC), US Department of the Treasury
• Directorate of Defense Trade Controls (DDTC), US Department of State
• SNAP-R (Simplified Network Application Process Redesign) — BIS
• 50 U.S.C. § 4819 — Export Control Reform Act Penalties, via Cornell LII