US Export Controls on Encryption: EAR and Commerce Department Rules

US export controls on encryption impose licensing requirements, classification obligations, and compliance procedures on any person or organization that exports, re-exports, or transfers encryption products, source code, or technology outside the United States. Administered primarily by the Bureau of Industry and Security (BIS) within the Department of Commerce, these rules operate under the Export Administration Regulations (EAR), codified at 15 C.F.R. Parts 730–774. The regulatory framework intersects directly with encryption product providers and affects cryptographers, software developers, hardware manufacturers, cloud service providers, and compliance officers operating across every sector that touches cryptographic technology.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

The Export Administration Regulations govern the export of "dual-use" goods and technologies — items with both civilian and potential military or national-security applications. Encryption is explicitly dual-use: the same AES-256 algorithm that protects a medical record database can secure military communications. Under 15 C.F.R. § 730.3, BIS jurisdiction extends to any US person, any item subject to the EAR, and any transaction that results in the release of controlled technology to a foreign national — including releases occurring entirely within the United States.

The scope of "export" under the EAR is broader than physical shipment. It encompasses electronic transmission, email, cloud hosting accessible from foreign IP addresses, and the deemed export rule, under which disclosing controlled technology to a foreign national on US soil constitutes an export to that person's home country (15 C.F.R. § 734.13). Open-source encryption code published on the internet without restriction occupies a specific carve-out under 15 C.F.R. § 742.15(b), but that carve-out has conditions that must be satisfied before reliance is valid.

The page provides additional orientation on how cryptographic categories map to regulatory treatment across the broader encryption services sector.

Core mechanics or structure

The EAR's control structure centers on the Commerce Control List (CCL), maintained at 15 C.F.R. Part 774, Supplement No. 1. Encryption items primarily appear under Export Control Classification Number (ECCN) 5E002 (encryption technology), 5D002 (encryption software), and 5A002 (encryption hardware). These ECCNs fall under Category 5, Part 2 — "Information Security" — of the CCL.

Each ECCN entry specifies:

1. What the control covers — the technical parameters that trigger the classification (e.g., key length thresholds, algorithm types, interface specifications)
2. Reasons for control — primarily NS (National Security), AT (Anti-Terrorism), and EI (Encryption Items)
3. License requirements — which destinations, end-uses, and end-users require a license versus which qualify for a license exception

License exceptions are the primary compliance pathway for most commercial encryption. The most significant for encryption are:

• ENC — the encryption license exception under 15 C.F.R. § 740.17, which permits exports of many encryption items to most destinations without an individual license, subject to annual self-classification reports and, for certain items, a 30-day review notification to BIS
• TSR (Technology and Software — Unrestricted) — available for certain low-sensitivity items to government end-users in Country Group A:1
• ENC Tier 1 / Tier 2 distinctions — under § 740.17, items are split into two tiers based on key length and end-user type; Tier 2 items require a 30-day BIS review before the first export under ENC

The annual self-classification report, due by February 1 of each calendar year (15 C.F.R. § 740.17(e)(3)), must be submitted electronically to both BIS and the National Security Agency (NSA).

Causal relationships or drivers

The regulatory structure governing encryption exports emerged from Cold War-era controls under the International Traffic in Arms Regulations (ITAR), which initially treated strong encryption as a munition. The Commerce Department assumed primary jurisdiction over commercial encryption exports in 1996, following Executive Order 13026, which transferred most commercial encryption from the US Munitions List to the CCL. BIS subsequently liberalized the ENC exception through rulemakings in 2000 and 2010, reducing license burdens for mass-market encryption products.

Three structural pressures sustain current regulatory complexity:

1. National security imperatives — The NSA retains a consultative role in BIS licensing decisions for encryption items, reflecting the dual-use tension embedded in cryptographic technology. Under 50 U.S.C. § 4824, the Secretary of Defense has formal rights to review and appeal export license decisions on national-security grounds.

2. Wassenaar Arrangement obligations — The United States is one of 42 participating states in the Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies. Wassenaar's dual-use list Category 5, Part 2, directly shapes the CCL's encryption entries. Changes to Wassenaar's control parameters propagate into the EAR through US implementing rules, creating a multilateral constraint on unilateral liberalization.

3. Embargoed and sanctioned jurisdictions — Even where BIS would permit an export under a license exception, the Office of Foreign Assets Control (OFAC) at the Treasury Department independently prohibits transactions involving embargoed countries (Cuba, Iran, North Korea, Syria, and the Crimea/Donetsk/Luhansk regions under active sanctions programs). EAR compliance alone does not satisfy OFAC obligations.

Classification boundaries

ECCN 5A002 captures hardware that performs encryption, decryption, or cryptanalysis functions with a key length exceeding 56 bits for symmetric algorithms — a threshold established in CCL Category 5, Part 2 technical notes. Below that threshold, or for items meeting specific mass-market criteria, EAR99 classification may apply (items subject to the EAR but not verified on the CCL).

Critical classification boundaries include:

• Mass-market software — encryption software meeting the criteria at 15 C.F.R. § 740.17(b)(3) (generally available to the public, sold without restriction, cannot be modified by the buyer) may qualify for ENC Tier 1 without prior BIS review
• Open-source code — encryption source code that is publicly available and not subject to a payment or access restriction is eligible for the § 742.15(b) carve-out, but the exporter must submit a one-time notification to BIS at the internet URL where the code is posted
• Products for government end-users — exports of 5A002/5D002 items to non-US government end-users require a 30-day BIS notification review under ENC Tier 2, regardless of the destination country (with exceptions for Country Group A:1 allies)
• Specially Designed components — the "specially designed" definition at 15 C.F.R. Part 772 determines whether a component embedded in a larger system carries the ECCN of the encryption function or is subsumed by the end-item classification

EAR99 classification does not mean no controls apply. EAR99 items remain subject to end-use and end-user restrictions under 15 C.F.R. Part 744, including prohibitions on exports to entities on the BIS Entity List.

Tradeoffs and tensions

The EAR encryption framework generates persistent friction between 3 competing interests that cannot be fully reconciled within a single regulatory instrument.

Security versus interoperability — Restricting strong encryption exports does not prevent adversaries from developing or acquiring equivalent algorithms independently; it primarily burdens US exporters while potentially weakening the global adoption of US cryptographic standards. The liberalization of AES export rules after 2000 reflected a policy judgment that widespread AES deployment strengthened rather than undermined US national security interests.

Compliance cost versus market access — The annual self-classification report, ECCN determination processes, and Tier 2 30-day review windows impose real administrative costs on software vendors, particularly startups and small development teams. Companies with a single encrypted product may find the compliance overhead disproportionate to the market risk.

Wassenaar multilateralism versus unilateral policy — A 2015 proposed BIS rule implementing a Wassenaar decision on intrusion software and surveillance technology generated significant industry pushback, with commenters arguing the rule would have restricted security research tools. BIS withdrew the proposed rule and issued a revised version in 2017, illustrating the friction between multilateral negotiating outcomes and domestic implementation feasibility. More detail on how encryption products intersect with these compliance structures appears on the how-to-use-this-encryption-resource page.

Common misconceptions

Misconception: Open-source encryption software is always exempt from EAR controls.
Correction: Open-source code qualifies for the § 742.15(b) notification exception only if it meets specific public availability criteria. Encryption source code that is available to the public but distributed under a restrictive license, or posted in a repository that requires registration or payment, may not qualify. A one-time BIS notification is still required even for qualifying open-source code.

Misconception: A product classified as EAR99 requires no compliance analysis.
Correction: EAR99 items remain subject to Part 744 end-user and end-use restrictions. Exporting EAR99 encryption software to an entity on the BIS Entity List or to a prohibited end-use (weapons of mass destruction programs) remains a violation regardless of ECCN classification.

Misconception: The ENC license exception covers all destinations.
Correction: The ENC exception is not available for exports to Country Group E:1 (terrorist-supporting countries) or to end-users subject to denial orders. OFAC embargoes operate independently and may block transactions that BIS would otherwise permit.

Misconception: Disclosing encryption source code to a foreign colleague in the United States is not an export.
Correction: The deemed export rule at § 734.13 classifies this as an export to the colleague's country of nationality if the technology is EAR-controlled. This applies to code reviews, joint development work, and academic collaboration involving controlled encryption technology.

Misconception: Cloud-hosted encryption products do not require export compliance.
Correction: BIS guidance (published in FAQ format on bis.doc.gov) confirms that making encryption software or functionality accessible via cloud API to foreign users constitutes an export. Cloud providers must assess whether their encryption offerings are accessible to users in restricted countries or from entities on denial lists.

Checklist or steps

The following sequence describes the compliance determination process for encryption exports under the EAR, as structured by BIS regulatory guidance:

1. Determine EAR jurisdiction — Confirm the item is "subject to the EAR" under 15 C.F.R. § 734.3. Items exclusively controlled by ITAR (State Department) or exclusively within the public domain are not EAR-subject.

2. Classify the item — Determine the ECCN by reviewing the CCL at 15 C.F.R. Part 774. For encryption products, evaluate whether Category 5, Part 2 parameters (key length, algorithm type, interface) trigger 5A002, 5D002, or 5E002. If no ECCN applies, classify as EAR99.

3. Identify the destination and end-user — Determine the ultimate country of destination and the identity of the end-user. Check the BIS Entity List, Denied Persons List, Unverified List, and OFAC Specially Designated Nationals list.

4. Check OFAC embargo status — Independently verify whether the destination country or end-user is subject to OFAC sanctions. OFAC administers sanctions programs separate from BIS; a clean BIS analysis does not confirm OFAC clearance.

5. Identify applicable license exception — For 5A002/5D002/5E002 items, evaluate ENC exception eligibility under § 740.17. Determine whether the item qualifies as Tier 1 (mass-market, no prior review) or Tier 2 (30-day BIS notification required before first export).

6. Submit Tier 2 notification if required — If Tier 2 applies, submit the notification to BIS through the Simplified Network Application Process Redesign (SNAP-R) system and wait the 30-day review period before the first export.

7. File the annual self-classification report — By February 1 of each year, submit the self-classification report to BIS and NSA for all encryption items exported under the ENC exception during the prior calendar year (§ 740.17(e)(3)).

8. Maintain transaction records — Retain export documentation for 5 years from the date of export (15 C.F.R. § 762.6), including ECCN determinations, exception eligibility analyses, and screening results.

Reference table or matrix