A software firm operating across three continents had classified its product as mass-market encryption and shipped globally for two years without incident. Then a customs query in a transit country surfaced. The product carried an encryption key length that, under a re-examination of the applicable Commerce Control List classification, placed it outside the mass-market exception. Two years of shipments. Multiple destination countries. A potential reporting failure to the regulator.
Encryption export controls under the Export Administration Regulations (the EAR – the US Commerce Department's rules governing dual-use goods, software, and technology) are among the most technically demanding areas of export-control practice. The classification turns on cryptographic parameters, end-use context, and the destination, not merely on whether the product is commercially available. Where a US-origin or US-controlled encryption product moves through a cross-border supply chain, the EAR's extraterritorial reach follows it – and parallel obligations under the UK's Export Control Order and EU dual-use rules may also apply.
This case comment sets out how the matter unfolded, what the cross-regime analysis revealed, and the practical lessons for businesses that develop, license, or distribute encryption products across multiple markets.
The situation: a software firm, a mass-market assumption, and a classification gap
The firm had made a common, understandable assumption: if a product is sold to the public through standard commercial channels at a non-specialist price point, it falls within the mass-market encryption exception under the EAR. That assumption is not wrong in principle. It was wrong on the specific facts.
The product in question had been updated eighteen months into the distribution cycle. The update increased the supported key length and added a mode of operation that introduced functionality not present in the original version. No one re-ran the classification. The updated product continued to ship under the original determination, which had been correct at the time it was made but had not been revisited when the code base changed.
When the customs query arrived, the compliance team commissioned an internal review. The review surfaced two distinct problems. First, the updated product did not, in all configurations, satisfy the conditions for the mass-market exception as the EAR defines them. Second, and more significantly, the firm had distributed the product to a distributor who had sub-distributed it to end users in a country subject to a US-administered country-level export restriction. That destination was not on the firm's original restricted-party list for this product, because the original classification had not generated a licence requirement for that market. The updated classification did.
In our experience, this is the pattern most frequently seen in technology companies: a clean initial classification, a product evolution that is not flagged to the export-control function, and a distribution channel that moves faster than the compliance review cycle.
What the cross-regime analysis revealed
An encryption product with a US-origin or US-technology content triggers the EAR regardless of where the exporter is located. That is the reach of the de minimis rule and the foreign-direct product rules under the EAR. A European firm exporting a product that incorporates US-origin encryption software above the applicable threshold is exporting a US-controlled item and must comply with the EAR as well as with its own national regime.
In this matter, the firm was incorporated in the European Union. Its product embedded a US-origin cryptographic library. The cross-regime analysis therefore had to address three bodies of rules simultaneously.
Under the EAR, the classification question turned on whether the product met the criteria for the mass-market exception or whether a licence exception for encryption items applied. Neither did, in the updated configuration for the destination in question. That meant a licence was required, and none had been obtained.
Under EU dual-use rules – the Council Regulation on controls for dual-use items, which implements the Wassenaar Arrangement categories in EU law – encryption software above a defined strength is a listed dual-use item. The EU rules include a general authorisation covering exports to certain low-risk destinations, but the destination in this matter fell outside that authorisation. The EU-competent authority had not been notified. No EU individual export authorisation had been applied for.
Under the UK Export Control Order – which, following the end of the Brexit transition, operates as a standalone regime administered by the Export Control Joint Unit (ECJU) – a separate export licence would have been required for any supply from a UK entity or any re-export from the UK. The firm had a UK affiliate that had facilitated one tranche of deliveries. That affiliate had no licence. It had assumed, incorrectly, that the EU parent's compliance position covered it.
Three regimes. Three separate licence requirements. One mis-classification that went undetected through a product update. The cross-border dimension had compounded a technical compliance error into a multi-jurisdictional exposure.
How does the mass-market encryption exception actually work – and where does it fail?
The mass-market encryption exception under the EAR is a conditional carve-out, not a blanket permission for commercially sold software. It requires that the product meets specific criteria relating to availability, pricing, and the absence of special features that would restrict it to a defined class of professional users. Critically, it requires that the product, as actually deployed, does not provide the user with direct control over the cryptographic implementation in a way that the rules treat as adding functionality beyond the mass-market threshold.
Where do firms most commonly go wrong? Four patterns recur in our practice.
- Version drift. The original product meets the exception. An update adds key management, a longer supported key length, or an API that exposes cryptographic parameters. The exception no longer applies, but the classification is not revisited.
- Configuration dependency. The product meets the exception in its default consumer configuration but not in an enterprise or developer configuration. Both are shipped. Only the consumer configuration has been classified.
- Bundled functionality. An encryption module that qualifies on its own is bundled with authentication or signing capabilities. The bundle may no longer qualify as mass-market because the combined functionality changes the control-list analysis.
- Destination blindness. The firm assumes the exception is destination-agnostic. It is not. Certain country restrictions apply regardless of whether a product would otherwise qualify for the mass-market treatment.
The EU dual-use rules apply a structurally similar analysis, though the thresholds and the list of qualifying destinations differ in detail from the EAR. The practical consequence is that a product classified under the EAR as requiring no licence for most destinations may still require an individual EU export authorisation for the same shipment, because the EU list entry for the category applies to it and no general authorisation covers that destination.
Is your export-control team re-running the classification every time the product team ships a new version? In many firms the answer is no.
The legal question: apparent violation, voluntary disclosure, and the multi-regime response
Once the review confirmed that licences had been required and not obtained, the firm faced the decision that arises in every apparent-violation situation: do nothing and hope the exposure is not discovered, self-report to one or more regulators, or take some intermediate remedial step?
Doing nothing was not a realistic option in this matter. The customs query had created a documented record. A regulator exercising audit powers could trace the same chain the internal review had traced. The potential for a future enforcement action, compounded by the failure to disclose a known apparent violation, was a worse outcome than the disclosure itself.
A voluntary self-disclosure (VSD – a proactive report to the regulator of an apparent violation, made before enforcement action is commenced) was assessed for each of the three regimes.
Under the EAR, the BIS enforcement programme has a VSD mechanism. A timely, complete, and well-structured VSD is treated as a significant mitigating factor in the penalty calculation. The absence of a VSD where one could have been made is itself an aggravating factor. The decision to disclose and the scope of the disclosure need to be handled with precision: the submission must be accurate, must not overstate the violation, and must not inadvertently acknowledge a broader breach than the facts support.
Under EU dual-use rules, the enforcement mechanism is national – each member state's competent authority – and the treatment of voluntary disclosure varies between member states. In this matter, the relevant national authority had a process for voluntary notification, and the firm's advisers engaged with it before any formal inquiry was raised.
Under the UK Export Control Order, ECJU has a disclosure process. The timing of engagement with ECJU, and the coordination of that engagement with the parallel BIS and EU processes, required careful sequencing. Disclosures to different regulators should not contradict each other. The factual narrative prepared for one filing had to be consistent with the others, even though the legal frameworks and the specific licence requirements differed.
If a transaction has already been flagged, or a filing has been refused, an early review can preserve options that narrow with time. For a confidential review of a potential breach, contact us at info@caldervance.com.
Risk flags that practitioners and compliance teams should recognise
This matter surfaced five risk flags that appear, in various combinations, in most encryption export-control matters we handle.
Lack of a version-control trigger in the export-control process. The product team was releasing updates on a commercial cycle. The export-control review was an onboarding step, not a recurring one. There was no documented procedure requiring the export-control team to be notified when a product update changed the cryptographic specification. Establishing a technical trigger – a field in the product-release checklist, a review gate in the development pipeline – is the structural fix.
Distributor responsibility is a second recurring issue. Distribution agreements in this sector frequently pass export-control obligations to the distributor in general terms. What they rarely do is specify which classification applies to which product version, require the distributor to re-classify before sub-distributing a new version, or create a reporting obligation back to the originating firm when a sub-distribution occurs to a destination that was not contemplated in the original agreement.
A third flag is the assumption that US-origin content is irrelevant once the product leaves the United States. The de minimis and foreign-direct product rules operate without regard to where the exporting entity is incorporated. A European manufacturer distributing a product that incorporates a US-origin cryptographic library above the relevant threshold is subject to the EAR for that distribution. Many compliance programmes in European firms do not address this adequately.
Fourth: the absence of a documented, dated classification opinion. When a regulator investigates, the firm's ability to demonstrate good-faith reliance on a contemporaneous written classification is one of the most important mitigating factors available. An oral determination, or one reconstructed after the fact, does not carry the same weight. The opinion needs to be written, dated, signed, and updated whenever the product changes materially.
Fifth, and sometimes overlooked: record-keeping. Export-control rules across the major regimes require records relating to exports to be kept for a defined period. Those records should include not just shipping documentation but also the classification basis, any licence or licence-exception documentation, and end-use certificates where applicable. If the records do not exist, the firm cannot demonstrate compliance even where compliance was, in substance, achieved.
What is the lesson for businesses distributing encryption products cross-border?
The central lesson is procedural, not technical: classification is not a one-time event. It is a recurring obligation that must be integrated into the product-development and commercial cycle, not treated as a gate at the point of first market entry.
Three structural changes address most of the risk in this pattern of case.
First, embed a classification review trigger in the software development lifecycle. Any product update that changes cryptographic specification, adds a new operational mode, or changes the intended user base should automatically require a re-classification before the updated version is distributed. This is a procedural fix, not a technical one. It requires the product team and the export-control team to communicate, which in many firms means establishing a cross-functional review gate where none currently exists.
Second, review distribution agreements for specificity. A general export-control clause that requires the distributor to comply with applicable law does not protect the originating firm from liability for its own classification error. The agreement should identify the applicable classification for each product version, require the distributor to notify the originating firm before distributing to destinations not specified in the original commercial terms, and include a return-of-information obligation so the originating firm can track the actual distribution path.
Third, address the multi-regime dimension explicitly. A compliance programme designed around the EAR alone is inadequate for a firm that has a UK affiliate, an EU entity, or a distribution chain that runs through EU or UK territory. Each regime has its own licence requirements, its own exceptions, and its own enforcement posture. The programmes need to be mapped against each other, the points of divergence identified, and the procedures calibrated to the strictest applicable requirement – because where the regimes diverge, the stricter prohibition governs.
In a recent matter, a technology business in the EU had designed its compliance programme around one regime's classification categories. When the cross-border footprint expanded to include a UK affiliate and a US-origin component, the programme was not re-scoped. We mapped the overlapping obligations across all three regimes, identified the classification gap on the updated product, prepared the written classification opinions, and supported the voluntary disclosure process across the relevant authorities. The matter proceeded with the regulators in a disclosure posture rather than an enforcement posture, which materially affected the firm's options going forward.
The position above covers the structural case. Your facts – the specific product, the key length, the end-use, the destination, the corporate structure, and the applicable version history – change the analysis. To discuss a cross-border encryption export-control matter, contact Calder & Vance at info@caldervance.com.
A common misconception: "If it is commercially available, controls do not apply"
A recurring assumption in this practice area is that commercial availability – the fact that encryption software can be downloaded by anyone, purchased without identity verification, or found bundled in standard operating systems – means export controls do not reach it. This is not accurate.
Commercial availability is a relevant factor in the mass-market analysis, but it is a necessary condition, not a sufficient one. The product must also meet all the other criteria the applicable rules set out for the exception to apply. And even where the mass-market exception applies for most destinations, it does not apply universally: certain country-level restrictions operate as overrides.
A related assumption is that open-source encryption software is not controlled. Under the EAR, publicly available software that is in the public domain in the manner the rules define may be outside EAR jurisdiction for certain purposes. But that carve-out has conditions. If the software has been modified, if the version in question includes capabilities not present in the publicly available version, or if the firm is distributing it in a manner that takes it outside the public-domain definition, the EAR may still apply.
EU dual-use rules contain comparable provisions on publicly available technology, but the conditions differ from the US position. UK rules diverge further in some respects. Relying on a public-domain or open-source characterisation without a documented legal analysis is a risk that has generated enforcement attention in more than one jurisdiction.
We regularly advise firms that have adopted commercial-availability or open-source assumptions without a documented legal basis. The pattern is common. The correction – a written classification opinion that addresses each element of the applicable exception – is straightforward if done early. It becomes considerably more complicated after a distribution cycle has run.
Related practices
- Deemed export and technology controls under the EAR – BIS classification, deemed-export analysis, and licence applications for technology transfers
- Encryption export controls: OFSI matter – parallel financial-sanctions and export-control exposure in UK-connected transactions
- End-use and end-user controls – managing end-use certificate requirements and post-shipment verification obligations