Calder & Vance International Sanctions & Compliance Counsel

Export Controls & Dual-Use · OFAC

OFAC vs BIS / EAR: Encryption export controls: the key divergences

A technology company finalises a software licensing deal. Its product includes strong encryption. The compliance team assumes that once the encryption review is complete under the Export Administration Regulations ("EAR," the primary US dual-use export-control instrument administered by BIS, the Bureau of Industry and Security), the transaction is cleared. Then a sanctions screen flags a downstream distributor with links to a designated party. The BIS review and the OFAC analysis are different exercises – and conflating them is one of the most common and costly errors we see in cross-border technology transactions.

As of April 2026, encryption export controls under OFAC and BIS operate under separate legal bases, separate authorities, and separate tests. BIS administers encryption classification and licensing under the EAR; OFAC administers sanctions-based prohibitions under IEEPA and related statutes. A product that is freely exportable under the EAR may still be prohibited under OFAC if the destination, end-user, or end-use engages a sanctions programme. The stricter prohibition governs – and both analyses are mandatory.

This analysis maps the key points of divergence between the two regimes, identifies where they interact, and sets out the practical steps a cross-border business should take before shipping encryption technology or licensing encryption software abroad.

What legal authority governs each regime, and why does that distinction matter?

BIS derives its authority over encryption exports from the Export Control Reform Act and exercises it through the EAR. OFAC derives its authority primarily from IEEPA – and, for certain programmes, from the Trading with the Enemy Act – exercised through programme-specific sanctions regulations. These are parallel statutory systems, not a hierarchy.

The practical consequence is that no licence or exception under one regime authorises conduct under the other. A BIS export licence for encryption software does not authorise a transaction that is otherwise blocked under an OFAC sanctions programme. Equally, an OFAC general licence permitting certain transactions with a sanctioned country does not remove the obligation to satisfy BIS classification and licensing requirements for the same shipment.

In our practice, we regularly encounter the misconception that a successful BIS Technology and Software – Unrestricted ("TSU") notification or an encryption licence exception under the EAR effectively clears the transaction for OFAC purposes. It does not. The two analyses must be run in parallel, not in sequence, and a clean result under one programme is irrelevant to the other.

This structural independence means that a cross-border technology business must maintain two separate analytical tracks – one oriented toward the classification of the item and the end-use controls under BIS, and one oriented toward the identity and location of the end-user and the destination under OFAC.

How does the BIS classification system apply to encryption products?

Under the EAR, encryption items are typically classified by reference to the Commerce Control List ("CCL," the BIS schedule of controlled items identified by Export Control Classification Numbers or ECCNs). Encryption products and software occupy a defined category on the CCL, and their classification determines what licence exceptions are available and what destinations or end-users require a licence.

The EAR provides for a review mechanism under which mass-market encryption products meeting specified parameters may be eligible for treatment as EAR99 (items not specifically listed on the CCL and subject to the least restrictive export controls) or for a licence exception rather than a formal licence application, following a self-classification review. Products with stronger or more specialised encryption capabilities attract tighter controls, and certain country destinations require a specific licence regardless of the product's classification.

BIS also applies the de minimis rule and the foreign-produced direct product rule ("FDPR"), which can extend US jurisdiction to foreign-made products that incorporate controlled US-origin encryption components or technology above specified thresholds. The FDPR has been expanded by BIS in successive regulatory actions, and its interaction with encryption-containing technology is now one of the most technically complex questions in US export-control practice.

What the BIS classification analysis does not address is the sanctioned-party dimension. BIS does consider destination and end-user through the Entity List (BIS's list of parties subject to enhanced export-licence requirements) and denied-persons controls. However, BIS controls are structured around the item and its technical characteristics; OFAC controls are structured around the identity of the counterparty and the destination country or territory.

Where does OFAC's sanctions analysis diverge from the BIS framework?

OFAC's prohibitions on encryption transfers are driven not by the technical characteristics of the product, but by the identity of the parties and the destination involved in the transaction. A transaction that involves a person on the SDN List (OFAC's list of Specially Designated Nationals and blocked persons), or that is directed to a comprehensively sanctioned destination, is prohibited irrespective of whether the encryption product would otherwise be licensable or excepted under the EAR.

Three dimensions of OFAC's analysis are particularly important for encryption exporters.

First, the 50 percent rule (OFAC's rule treating entities owned 50 percent or more, in the aggregate, by blocked persons as themselves blocked) can catch a technology distributor or reseller that does not itself appear on the SDN List. A software company licensing its encryption product to a foreign distribution partner must screen the distributor's ownership chain, not merely its name. In our experience, this is exactly where technology-sector screens fail – the direct counterparty is clean, but an intermediate holding company sits above a listed person.

Second, OFAC operates a web of country-based sanctions programmes. A comprehensive programme effectively prohibits virtually all transactions with the relevant destination, regardless of whether the item exported is encryption software, consumer hardware, or a commodity. BIS also restricts certain country destinations for encryption products, but the lists do not overlap perfectly. A destination that is moderately controlled under the EAR may be comprehensively blocked under an OFAC programme – and vice versa, a destination subject to a targeted (rather than comprehensive) OFAC programme may permit certain encryption transfers if the counterparty is not designated.

Third, OFAC applies a substance-over-form analysis. A transfer routed through a third country to reach a sanctioned end-user, or licensed ostensibly to a non-sanctioned reseller who then retransfers to a prohibited destination, engages OFAC's evasion provisions. The encryption technology's path to its ultimate destination is as relevant as its immediate recipient.

The position above covers the standard case. Your specific facts – the product's ECCN, the counterparty's ownership structure, the country of ultimate destination, and the programme in play – change the analysis materially.

For an assessment of your exposure under OFAC and the EAR, contact Calder & Vance at info@caldervance.com.

What is the interaction between EAR licence exceptions and OFAC general licences?

Both BIS and OFAC provide mechanisms that permit certain otherwise-controlled transactions without a case-by-case application. Under the EAR, these are licence exceptions (standing authorisations for defined categories of items, destinations, or end-users). Under OFAC, these are general licences (standing authorisations permitting a defined category of transactions without a separate application). The two instruments operate independently.

A BIS licence exception for encryption items – for example, an exception available for mass-market products following a self-classification review – does not constitute or imply an OFAC general licence. An OFAC general licence permitting transactions with certain categories of persons in a sanctioned destination – for example, one that carves out personal communications software – may or may not extend to encryption products of the type in question. The scope of each instrument must be read on its own terms.

In practice, the interplay creates gaps that neither regime explicitly addresses. Consider a software product that qualifies for an EAR licence exception following an encryption review. The same product, if supplied to a distributor in a jurisdiction subject to a targeted OFAC programme, requires its own OFAC analysis. If the end-user in that jurisdiction happens to be a non-designated state-owned enterprise, the OFAC analysis turns on whether any general licence extends to technology transfers with such entities – a question that depends on the specific programme's terms. BIS has no view on this question.

When the two regimes issue conflicting signals – a BIS licence exception available, an OFAC general licence absent or ambiguous – the more restrictive position governs. This is the cardinal rule of US export-control and sanctions compliance for dual-use items: where two controls apply, satisfy both.

How does secondary-sanctions risk interact with encryption export controls?

OFAC's secondary-sanctions provisions add a further dimension that BIS controls do not address. Secondary sanctions can reach non-US persons who engage in significant transactions with SDN-listed parties or with parties connected to certain programmes, even when no US-origin item, technology, or person is involved in the transaction. For an encryption technology company incorporated outside the United States, this creates exposure that is entirely absent from the BIS framework.

A non-US software company exporting encryption technology to a foreign customer may have no BIS obligation at all – if no US-origin components, no US persons, and no US-controlled technology are involved. But if that customer is connected to a party subject to OFAC's secondary-sanctions provisions, the non-US software company faces potential OFAC risk regardless. Does your compliance programme address the distinction between primary and secondary OFAC exposure? For many technology exporters, it does not.

The interaction is particularly acute for cloud-based encryption services and software-as-a-service products, where the physical location of the export is less clear and where customer onboarding may occur across multiple jurisdictions simultaneously. OFAC has confirmed, through enforcement guidance and published statements, that the prohibition on providing services to sanctioned parties applies to cloud and software subscription models in the same way as to traditional exports. BIS, by contrast, addresses cloud delivery of encryption-enabled software under its own distinct framework, with separate conditions and exceptions.

For businesses operating under multiple regimes, the practical implication is that the scope of OFAC secondary-sanctions risk should be assessed as a standalone question at the start of any market-entry or product-launch analysis – not treated as an afterthought to the BIS classification exercise.

We also advise clients on how the UK OFSI regime and EU sanctions programmes interact with US encryption controls. The analysis for those regimes is set out in companion pieces linked below.

How do the EU and UK encryption export-control regimes compare with OFAC and BIS?

For businesses operating outside the United States, the EU and UK regimes introduce a separate but structurally comparable dual-track system: export controls administered through the dual-use regulatory instrument (in the EU, Regulation 2021/821; in the UK, through the Export Control Order), and financial sanctions administered by the Council (EU) or OFSI (UK). As with the US system, a clean result under one track does not clear the other.

There are, however, important points of divergence from the US position.

Under the EU dual-use rules, encryption products are controlled by reference to the EU dual-use list, which broadly mirrors the Wassenaar Arrangement Munitions and Dual-Use Control List. The EU list and the US CCL are aligned at a high level but differ in their treatment of specific product categories, key-length thresholds, and mass-market exceptions. An encryption product that qualifies for a BIS licence exception may nonetheless require a case-by-case licence application under the applicable EU member state's export-control authority, or vice versa.

On the sanctions side, the EU and UK regimes use an ownership and control test (the test for whether a non-listed entity is caught through a listed person's ownership or control) that differs from OFAC's 50 percent rule. Under OFAC, the test is purely mathematical: aggregate ownership at or above 50 percent triggers the block. Under the EU and UK rules, the test includes a control dimension – a listed person who controls a company without owning a majority stake may still cause that company to be caught. For encryption technology businesses with complex distribution chains, this distinction changes the scope of the counterparty-screening exercise.

The UK adds a further consideration. Following the UK's departure from the EU single market, ECJU (the Export Control Joint Unit) administers a UK-specific export-control list that mirrors Wassenaar broadly but has diverged in certain areas. Post-2020 UK export authorisations do not automatically satisfy EU requirements, and a business that previously held a single EU authorisation for encryption exports to third-country destinations must now maintain separate UK and EU licences where both regimes apply.

If a transaction has already been flagged under one of these regimes, or a filing has been refused, an early review can preserve options that narrow with time. Contact Calder & Vance at info@caldervance.com.

What are the common risk flags in cross-border encryption export transactions?

In our cross-border practice, the same risk patterns recur across encryption export mandates, regardless of sector or product type. Identifying them early – before the transaction closes – substantially reduces the risk of a prohibited export, an enforcement referral, or a licence denial.

The first risk flag is inadequate ownership-chain screening. Many compliance programmes screen the direct counterparty against the SDN List and stop there. Where the direct counterparty is a distributor, reseller, or system integrator – common in the technology sector – the relevant screening must extend to the distributor's ultimate beneficial owners and any intermediate holding structures. A counterparty that is clean at the entity level may be caught by the 50 percent rule at the beneficial-owner level.

The second risk flag is miscategorisation of the product. Encryption items span a wide range of ECCNs, and the classification analysis requires a technical assessment of the algorithm, key length, access-control features, and intended use. A product that is internally described as "basic" encryption may carry a classification that triggers licence requirements for a significant number of destination countries. Relying on a vendor's stated classification without independent verification has led to enforcement action in a number of cases handled by practitioners in this space.

The third risk flag is the cloud and services assumption. Technology businesses frequently assume that software-as-a-service or cloud-hosted encryption products sit outside the export-control regime because no physical export occurs. Both BIS and OFAC have addressed this position, and the consensus in current enforcement practice is that cloud delivery does not exempt a transaction from either regime's requirements. The encryption-enabled product must be classified; the end-user must be screened.

A fourth, frequently overlooked risk is the deemed-export dimension. Under the EAR, a transfer of encryption technology to a foreign national within the United States is treated as an export to that person's country of nationality – the deemed export rule. A US-based technology company that employs foreign nationals and allows them access to source code or technical parameters for a controlled encryption product has, in regulatory terms, made a deemed export to their home country. This can trigger licence requirements for employees from certain countries, and it sits entirely outside the OFAC analysis.

  • Ownership-chain gaps: the 50 percent rule aggregates indirect holdings; screen to the ultimate beneficial owner.
  • Product miscategorisation: obtain an independent ECCN classification before relying on a vendor's or distributor's categorisation.
  • Cloud delivery: BIS and OFAC both apply to software-as-a-service encryption products; physical export is not the threshold.
  • Deemed-export exposure: access to controlled encryption technology by a foreign national in the US requires analysis as an export to their country of nationality.
  • Parallel-regime compliance gaps: a clean BIS classification does not substitute for OFAC screening, and vice versa.

The AUDIENCE_MYTH we encounter most consistently is the belief that free or open-source encryption software is categorically exempt from US export controls. This is incorrect. Open-source status is a factor that BIS considers in its classification analysis, and certain open-source encryption products are eligible for treatment under a licence exception following a self-classification review and notification. However, OFAC's analysis is entirely unaffected by the open-source character of the software. If the recipient is a designated party or the destination is a comprehensively sanctioned territory, the transfer is prohibited regardless of the software's licensing model. The open-source assumption is one of the most persistent myths in technology-sector compliance, and it has contributed to enforcement actions against companies that genuinely believed their products were freely distributable without restriction.

What should a cross-border business do before it ships or licenses encryption technology abroad?

A structured pre-transaction review under both BIS and OFAC is the minimum standard for any cross-border encryption export. The sequence below reflects how we approach these matters in practice; it does not guarantee any particular outcome or regulatory response.

  1. Classify the product independently. Obtain an ECCN classification based on the product's technical specifications – algorithm, key length, access controls, and use-case – rather than relying on a vendor's or third party's prior classification. Confirm whether the product qualifies for any EAR licence exception and whether a BIS notification has been or must be filed.
  2. Map the transaction's geographic footprint. Identify every country involved: the country of manufacture, any intermediate transit points, the immediate destination, and the country of ultimate end-use. Under the EAR, transit and re-export controls apply; under OFAC, the country of ultimate end-use is a primary factor.
  3. Screen to the beneficial-owner level. Run every party in the transaction chain – the buyer, the distributor, any reseller, and the identified end-user – against the SDN List, the Entity List, denied-persons lists, and the applicable consolidated lists of the EU, UK, and UN. Screen the full ownership chain for each entity to the ultimate beneficial owner, applying the 50 percent rule.
  4. Assess secondary-sanctions exposure. Determine whether any party in the chain has material connections to an OFAC programme that carries secondary-sanctions provisions. This step is independent of whether a US-origin item is involved.
  5. Check parallel jurisdictions. Confirm that no EU, UK, or other applicable export-control licence is required for the same transaction. A BIS licence exception or OFAC general licence does not satisfy parallel obligations under EU or UK law.
  6. Document the analysis and retain records. Record the classification rationale, the screening results, the programme review, and any licence exception relied upon. Under both the EAR and OFAC's enforcement guidance, contemporaneous documentation is a significant mitigating factor in any enforcement proceeding.
  7. Seek counsel where the analysis is inconclusive. If the ECCN classification is unclear, if the ownership chain reveals a potential SDN nexus, or if the destination falls under a programme with limited general-licence coverage for technology transfers, the matter should be referred to sanctions and export-control counsel before the transaction proceeds.

In a recent matter, a software business in the financial-technology sector sought to license encryption-enabled transaction-processing software to a distribution partner in a third-country market. The initial internal review confirmed that the product met the criteria for a BIS licence exception. A subsequent OFAC screen identified that the distribution partner's parent company was 50 percent owned by a party on the SDN List. We assessed the eligibility for an OFAC specific licence, prepared the application, and managed the regulatory dialogue. The matter proceeded to a result that allowed the transaction to be restructured on a lawful basis. No outcome of this type can be promised in any matter, but the lesson is consistent: OFAC and BIS analyses must run in parallel from the start.

Related practices

Frequently asked questions

Where do the regimes diverge on encryption export controls?
The central divergence is legal basis and analytical focus. BIS controls encryption by reference to the product's technical characteristics – classification under the Commerce Control List determines whether a licence or exception applies. OFAC controls encryption transfers by reference to the identity of the parties and the destination involved. A product that is freely exportable under the EAR can be prohibited under an OFAC programme if the counterparty is designated or the destination is comprehensively sanctioned. Secondary-sanctions risk under OFAC has no equivalent in the BIS framework, which adds a further layer of divergence for non-US businesses.
Which regime is stricter on encryption export controls?
Neither regime is categorically stricter; they address different risk dimensions. BIS imposes detailed technical controls – ECCN classification, licence conditions, and end-use certificate requirements – that OFAC does not. OFAC's prohibitions are absolute where a sanctions programme applies: no classification or exception under the EAR overrides an OFAC block. For a given transaction the more restrictive regime governs that dimension of the analysis, and both must be satisfied. In practice, the OFAC analysis is often the binding constraint for transactions involving destinations or counterparties with any connection to a US sanctions programme, while BIS controls are the binding constraint for technically complex encryption products destined for countries that are not sanctioned.
What should a cross-border business do about encryption export controls?
A cross-border business should conduct parallel reviews under BIS and OFAC before any encryption export or software licence. The BIS review should classify the product independently, confirm applicable exceptions, and check all destination and end-user controls. The OFAC review should screen every party in the transaction chain to the ultimate beneficial owner, assess the country programme in play, and evaluate secondary-sanctions exposure. Where either review is inconclusive, the transaction should be paused and counsel instructed. Contemporaneous documentation of both analyses is essential regardless of outcome; it is the first thing an enforcement team requests.

Talk to Caldervance

For a scoped view of your exposure, contact info@caldervance.com.

Discuss your matter

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@caldervance.com.