An engineering team at a software company ships an update to a customer in a third market. The update includes a new encryption module. Nobody checks the classification. Six months later, a customs review surfaces the export. Was a licence required? Does the annual self-classification report cover it? These questions have real consequences under the Export Administration Regulations.
Encryption items are subject to dedicated controls under the EAR (the Export Administration Regulations administered by the Bureau of Industry and Security, or BIS). Most commercial encryption products require either a licence, a licence exception, or a completed classification review before export – and many trigger a mandatory annual report even when no licence is needed. The controls apply to software, hardware, and technology, including items transferred electronically or shared with foreign nationals in the United States.
This guide walks through each stage of the compliance process: classification, the licence-or-exception decision, the review and reporting obligations, the cross-border complications that arise when other regimes also apply, and the risk flags that most commonly catch businesses unprepared. As of April 2026, the BIS encryption control regime remains one of the most actively administered areas of the EAR, and BIS continues to publish updated commodity classification determinations and policy guidance.
Step 1: Classify the item and understand what "encryption controls" actually cover
The first practical step is to determine whether your item – hardware, software, or technology – is subject to encryption controls under the EAR, and if so, at what level of control. Encryption controls under the EAR apply to a wide range of items beyond dedicated cryptographic products: items incorporating encryption as an incidental feature, proprietary protocols, and technology for the development of encryption functionality are all potentially in scope.
The ECCN (Export Control Classification Number under the US Commerce Control List) for an item determines the specific controls, licence requirements, and available exceptions. Encryption items cluster around a defined set of ECCNs on the Commerce Control List. The correct ECCN is determined by examining the item's encryption features, key length, the protocols it supports, and its intended end use. Items that do not fall on the Commerce Control List are classified as EAR99 – a designation that carries no specific licence requirement for most destinations, but that does not mean they are exempt from all EAR obligations.
In our experience, the most common classification error is treating an item as EAR99 based on a surface-level read of the product description, without working through the technical parameters that the Commerce Control List requires. A product marketed as "standard commercial software" may still incorporate a controlled encryption function that places it in a specific ECCN category. Where there is any doubt, a Commodity Classification request to BIS – or a formal Classification Determination – is the reliable route. Exporters that skip this step and later face an enforcement inquiry find they cannot reconstruct a classification rationale.
One further point: classification is not a one-time exercise. When a product is updated – new cipher suites, longer key lengths, new functionality – the classification position should be revisited. Software companies that release regular updates need a classification review cycle built into the product development process, not treated as a compliance afterthought.
Step 2: Determine whether a licence, a licence exception, or an annual report applies
Once classification is confirmed, the next step is to identify the specific authorisation route for the export, re-export, or deemed export at issue. BIS controls on encryption items create a tiered structure: some items require a specific licence for most destinations; others qualify for a licence exception subject to conditions; and many – particularly mass-market encryption items – are eligible for export without a specific licence but with a mandatory annual self-classification report.
The licence exception structure for encryption is more detailed than for most other EAR categories. The principal encryption-related exceptions permit exports of certain mass-market products, open-source encryption software, and encryption items to specific end-users or destinations, but each exception carries its own eligibility criteria and conditions. Meeting the exception is not simply a matter of asserting that the product is "widely available" – the EAR sets specific technical and commercial thresholds.
The annual self-classification report is a frequently overlooked obligation. Many exporters correctly identify that their product qualifies for a licence exception and proceed with the export – without submitting the annual report that the exception requires. BIS treats a missing annual report as a compliance gap, and it can affect the availability of voluntary self-disclosure credit if a problem surfaces later. We regularly advise on cleaning up accumulated reporting gaps as part of a broader compliance remediation programme.
For items that require a specific licence, the application process runs through BIS's electronic licensing system. The reviewing agency – and in some cases additional government departments with equities in encryption policy – may ask for detailed technical information. Processing times vary. Applications for encryption items can involve interagency review, which extends the timeline beyond the standard period for non-encryption licences.
Step 3: Apply the deemed-export analysis to transfers within the United States
A deemed export is the release of controlled technology or source code to a foreign national within the United States, treated as an export to the foreign national's home country under the EAR. This is one of the most consequential and frequently misunderstood aspects of BIS's encryption control regime. An encryption software company that employs foreign-national engineers must assess whether providing those engineers access to source code – or to controlled technical data – triggers a deemed-export obligation.
The analysis turns on the ECCN of the technology, the nationality of the employee or visitor, and the destination that nationality implies for the deemed-export test. Some nationalities carry a licence requirement for deemed exports of certain encryption technology; others do not. Employers often assume that a US work authorisation or a US permanent-residency status resolves the question. It does not: the deemed-export rule looks to the foreign national's most recent non-US citizenship, with limited exceptions.
In a recent matter, a technology company with a large internationally diverse engineering team discovered during a compliance review that access to its core encryption codebase had been granted to a number of foreign nationals from destinations with specific licence requirements. We mapped the technology, assessed the ECCN, and worked through the deemed-export analysis for each nationality group. The business then implemented an access-tier structure aligned to its licence position and submitted a voluntary self-disclosure covering the historic gap. The matter concluded without a finding of wilful violation.
For detailed guidance on the deemed-export framework as it applies to technology more broadly, see our dedicated analysis at Deemed Export: Technology Under BIS / EAR.
How does BIS / EAR encryption control differ from the EU and Canadian regimes?
For a business that exports encryption items from or through multiple jurisdictions, understanding the divergence between the BIS / EAR regime, the EU dual-use regime, and the Canadian export-control regime is not optional – it is a precondition to structuring a compliant global distribution model. The regimes share roots in the Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies, but their implementation and scope diverge in several material respects.
Under the EU dual-use regime, encryption controls apply to items on the EU dual-use list. The competent authority in each EU member state administers the licence and the authorisation system. There are EU-level general export authorisations for certain categories of encryption exports to specified destinations, and a Union General Export Authorisation for transfers to some low-risk countries. The EU regime has its own technical thresholds and its own annual report-equivalent obligations. Critically, the EU rules also apply to the provision of encryption-related technical assistance and brokering services – a dimension that some exporters who focus only on goods overlook.
Canada's export-control regime, administered by Global Affairs Canada, also controls encryption goods and technology. The Canada regime includes a permit-required category for certain encryption items and operates its own permit-exception structure. The thresholds and the mass-market treatment do not map exactly onto the BIS framework. A company that manufactures in the United States and distributes through a Canadian affiliate must ensure that both the BIS position and the Canadian permit position are addressed for each product.
The practical result: a company managing encryption exports across all three regimes needs a classification matrix that captures the relevant lists for each jurisdiction, an understanding of where the general authorisations or exceptions apply in each, and a reporting calendar that tracks the distinct annual-reporting obligations of each regime. For a comparison of how the EU handles this, see our guide at Encryption Export Controls: EU Guide. For the Canadian position, see Encryption Export Controls: Canada Guide.
There is also a secondary-sanctions dimension. Where encryption technology is exported to a destination that is subject to US OFAC sanctions – or to an end-user on a BIS restricted list such as the Entity List – the BIS classification analysis does not exhaust the compliance question. OFAC prohibitions are independent of BIS licence requirements. A BIS licence exception does not override an OFAC sanctions prohibition, and an OFAC general or specific licence does not satisfy BIS requirements. The two regimes run in parallel, and a clean answer under one does not deliver a clean answer under the other.
What are the risk flags that most commonly cause enforcement problems?
In our cross-border practice, five patterns account for the large majority of encryption-related BIS enforcement issues we encounter. None of them are exotic. Most arise from process gaps rather than deliberate circumvention.
The first is classification drift. An item is classified correctly at launch, but product updates – new encryption libraries, extended key support, an added VPN function – change the technical parameters without triggering a reclassification review. By the time an export compliance audit runs, the product that has been exported for three years under a specific ECCN may qualify under a different one.
The second is incomplete annual reporting. As noted above, many licence exceptions for encryption items require an annual self-classification report. Businesses that treat the licence-exception determination as the end of the compliance task – without building the reporting obligation into a calendar – accumulate missed reports. BIS identifies this pattern frequently in voluntary self-disclosures.
The third is the assumed-EAR99 problem. A product team launches a new tool. A junior compliance review notes "commercial encryption" and marks it EAR99. No one works through the ECCN criteria. Two years of shipments later, a proper review finds the item sits in a controlled ECCN. This scenario – which we have seen across technology, fintech, and industrial-software clients – is precisely what the BIS self-classification and Commodity Classification processes are designed to prevent.
The fourth is the channel-partner gap. A US exporter uses a foreign distributor to serve end markets. The distributor's compliance checks are weaker, or nonexistent. The exporter assumes the distributor handles classification and licensing. That assumption does not transfer US export-control responsibility. The exporter remains the US person making the export or the re-export, and BIS jurisdiction follows the item.
The fifth is the deemed-export blind spot described above. Engineering teams with foreign-national employees sharing source code repositories containing encryption technology are, in many cases, making deemed exports without knowing it. Have you mapped which of your employees have access to controlled encryption source code, and from which countries they hold citizenship?
Step 4: When to involve export-control counsel – and what a review covers
Export-control counsel should be involved early, not after a problem has crystallised. The cost of a pre-launch classification review is a fraction of the cost of a voluntary self-disclosure process or an enforcement defence. That is a straightforward cost-benefit calculation for any business planning a new product release, a new distribution arrangement, or a merger involving an encryption product line.
There are four specific triggers that should prompt immediate engagement with counsel. The first is any acquisition of a business with an encryption product portfolio, where the acquired entity's classification history and compliance records may be incomplete or unavailable. The second is a BIS inquiry, a request for information, or a notification of a possible violation – each of which has a defined, often short, response window. The third is the discovery of a historical compliance gap, where voluntary self-disclosure may be available but must be structured correctly and promptly to benefit from the credit BIS gives for timely, complete disclosures. The fourth is any planned export or re-export to a destination, end-user, or end-use that triggers heightened BIS scrutiny under the Entity List, the Unverified List, or the general prohibition on contributing to weapons development.
A structured review by Calder & Vance in this area covers classification of the encryption item against the Commerce Control List, analysis of the applicable licence exceptions and their conditions, identification of annual-reporting obligations, deemed-export mapping for the relevant workforce, a gap assessment against the BIS five-element compliance programme standard, and – where a historical gap has been identified – support for a VSD (voluntary self-disclosure to BIS), including drafting the disclosure letter and managing the regulator's follow-up questions.
The position above covers the standard case. Your facts – the product architecture, the distribution channel, the destinations in play, the nationalities of your engineering team – change the analysis materially. The BIS / EAR encryption regime is administered at the detail level, and a generalised read of the rules does not substitute for a fact-specific review.
For an assessment of your encryption classification position or a review of your deemed-export obligations, contact Calder & Vance at info@caldervance.com.
A common misconception: "our product is open-source, so the controls do not apply"
One of the most persistent myths in encryption compliance is that open-source encryption software sits entirely outside BIS control. It does not. The EAR contains specific provisions addressing open-source encryption: there are exceptions available for certain publicly available encryption source code, but those exceptions have conditions, and not every open-source product meets them. Encryption source code that is publicly available but subject to payment restrictions, access controls, or distribution conditions may not qualify for the relevant exception.
The open-source argument also does not resolve the deemed-export question. Foreign-national employees who access an open-source repository containing controlled encryption source code are still subject to the deemed-export analysis if the technology itself is controlled. The public availability of the code changes the licence requirement for some exports – it does not eliminate the need to work through the classification and exception analysis.
We have acted for technology companies that launched open-source encryption projects in the genuine belief that no BIS obligations applied, only to discover during a compliance review that their distribution model did not satisfy the conditions of the applicable exception. Correcting that position – including a retrospective classification review and in some cases a voluntary disclosure – took considerably more resource than the original pre-launch review would have required.
The myth also extends to a second misunderstanding: that a product qualifying for a BIS licence exception has no further compliance obligations. As this guide has set out, many exceptions require annual reporting, specific end-user conditions, or re-export authorisation. Meeting the exception is the beginning of a compliance task, not the end of it.
Related practices
- Deemed Export: Technology under BIS / EAR – analysis of the deemed-export obligations for controlled technology and source code
- Encryption Export Controls: EU Guide – how the EU dual-use regime applies to encryption goods and technology
- Encryption Export Controls: Canada Guide – the Canadian permit-and-exception framework compared to the BIS approach