TLDRThis article explores why encryption has transformed export controls from a technical compliance issue into a senior-level strategic risk. We’ll examine how software, cloud services, and embedded cryptography are regulated, why missteps attract sharper enforcement protocols, the questions leadership teams must ask to safeguard market access and maintain trust, and how to integrate legal, engineering, and product functions into global trade governance. |
The practice of encryption – and how it materially changes the logic of export controls – is a reality trade regulators have been grappling with for the past decade.
Export controls were originally designed for visible, finite goods crossing physical borders – but the advance of technology, including digital encryption, has evolved that logic. It is intangible, embedded by default, continuously updated, and distributed globally, in real time.
Undeniably, encryption helps to protect data, intellectual property, and commercial trust. However, it also potentially removes state visibility over how information is secured, transferred, and accessed. That loss of visibility – more than the mere presence of “security features” – is what places encryption squarely in the sights of export control regimes worldwide.
Today, encryption is no longer confined to specialist products, as it sits inside widely-used enterprise software, cloud platforms, connected devices, development tools, and internal systems. Regulators in the UK, EU, US, and allied jurisdictions increasingly view encryption as strategic infrastructure; and it is that shift which explains why enforcement, licensing expectations, and disclosure obligations have tightened, even as digital trade accelerates.
Encryption export compliance now sits at the intersection of national security, data governance, market access, and trust in global digital trade. Organisations that understand this reality are better equipped to unearth exposure before a transaction, collaboration, or product launch triggers regulatory scrutiny.
Why this mattersNo longer a niche technical concern, encryption is a structural factor shaping global trade governance. Mismanaged or misclassified encryption can expose organisations to regulatory penalties, market restrictions, and reputational damage. Unlike tangible goods, software and embedded cryptography move instantaneously across borders, magnifying oversight gaps; leadership teams must understand where encryption resides in products, cloud services, and R&D collaborations, and ensure classification, licensing, and risk management processes keep pace with real-world usage. Treating encryption strategically – integrating legal, engineering, product, IT security, and trade compliance – transforms export compliance from a reactive obligation into a tool for market access, operational resilience, and trust in the digital supply chain. |
Seeking assistance with export controls compliance?
Contact the clearBorder team today →
What counts as encryption under export control rules
(It’s broader than you might think)
Encryption export compliance does not apply only to companies that “sell cryptography.”
Controls extend to any technology that performs encryption functions, regardless of how incidental they may appear to the commercial offering. This includes:
- Software
- Firmware
- Source code that encrypts data
- At rest or in transit
- Hardware products with embedded cryptographic modules
- Cloud-based services or APIs that provide:
- Secure communications
- Authentication
- Key management
Crucially, even partial or supporting elements of cryptography (that is, the technical practice of encoding information into an unreadable format) can fall within scope. For instance, key generation, key exchange, identity verification, and access-control mechanisms are all routinely assessed alongside core encryption functions. In practice, the assertion that “we don’t sell encryption!” is likely to collapse under regulatory scrutiny, once a product’s architecture is examined end-to-end. For trade leaders, the risk lies less in intent and more in capability.
Compliance grey zones | Open source, updates, configuration choices |
||
| Myth | Reality | Impact |
| “Open source is automatically exempt” | Open-source encryption can still be controlled, depending on functionality and distribution | False assumptions here can lead to uncontrolled releases or cross-border access |
| “Mass market means low risk” | Mass-market status reduces licensing friction, not compliance responsibility | Ongoing reporting and governance obligations remain |
| “Updates and patches are operational noise” | Technical updates can materially change encryption strength or scope | Classification can shift without commercial teams noticing |
| “Only enabled features matter” | Regulators assess what a product can do, not just what is switched on | Architecture decisions create export exposure upstream |
The key takeaway? Product architecture increasingly defines export compliance risk. Encryption decisions made by engineering or product teams can, quietly, reshape regulatory obligations long before legal or trade teams are consulted.
Encryption export compliance codes (without legalese)
ECCNs, dual-use codes, and what boardrooms need to know
Encryption export compliance can often become clouded by dense classification frameworks, but the commercial implications are relatively straightforward (in theory, at least).
In the United States, most encryption technologies fall under the Export Administration Regulations (EAR), typically within ECCNs such as 5A002 / 5D002 (more sensitive encryption) or 5A992 / 5D992 (mass-market encryption). That distinction determines where products can be sold, whether licences are required, and what disclosures must be made to regulators.
Across the EU, encryption is governed under the Dual-Use Regulation (EU) 2021/821, while in the UK it sits within the Export Control Order and Strategic Export Controls framework. While terminology and procedures may differ on certain points, the underlying logic is aligned, through widely-accepted prioritisation of nations’ security.
→ Ultimately, classification decisions shape market access: affecting licensing timelines, potentially restricting sales into certain jurisdictions or triggering reporting obligations, and influencing how products can be bundled, deployed, or updated.
Why “mass market” and licence exceptions still carry risk
Licence exceptions and “mass-market” classifications are often misunderstood as a green light for frictionless global distribution. In reality, they reduce licensing burden; they do not remove compliance responsibility.
Exceptions such as ENC in the US still require ongoing reporting, record-keeping, and internal controls, particularly when products evolve or encryption functionality changes.
Regulators are also shifting focus: instead of asking whether a company technically qualifies for an exception, enforcement increasingly examines whether the organisation operates a mature, repeatable export compliance programme. Weak change management, poor documentation, or lack of oversight around updates and releases can attract scrutiny even where legal eligibility exists.
Where compliance often breaks down
Cloud tech and SaaS at the border
In digital environments, exports don’t happen at the shipping terminal. Remote access to encrypted software, cloud platforms, or administrative interfaces can constitute an export at the moment an overseas user is granted access. Cross-border permissions, DevOps pipelines, support tools, and even monitoring dashboards increasingly fall within export control scope.
As a result, encryption compliance intersects directly with:
- Identity management
- Access management
- Cloud architecture
- Vendor permissions
Decisions made by IT and engineering teams (often for speed or resilience) can invisibly create regulated export events, without anyone labelling them as such.
R&D, collaboration, and the spread of controlled code
Encryption exposure can also expand through collaboration: joint ventures, academic partnerships, outsourced development, and distributed engineering teams may all routinely share source code, test builds, and technical documentation across borders. When that code includes controlled encryption functionality, even temporary access for “review” or “testing” can trigger deemed export or re-export obligations.
These risks are frequently overlooked because they sit outside traditional trade workflows. However, regulators increasingly expect organisations to be proactive, and to understand how controlled code moves within their ecosystems – not just how finished products are sold.
The strategic fallout: why regulators treat encryption failures differently
Invariably, encryption failures are not viewed by regulators as isolated hiccups, glitches, or contained technical errors. Rather, they are seen as more profound structural breakdowns in governance. When encryption is misclassified, shared without control, or deployed without oversight, for instance, the regulatory concern is a tangible loss of state visibility into how sensitive technologies move across borders (not simply “non-compliance.”)
From an enforcement perspective, poorly governed encryption can enable sanctions evasion, frustrate lawful interception, and amplify downstream risk across supply chains, platforms, and jurisdictions. A single lapse may scale globally in minutes, not in shipments. This is why penalties in encryption cases are often framed as governance failures rather than administrative mistakes.
There is also a deeper trust dimension. Encryption sits close to the heart of digital sovereignty and national security. Failures, therefore, erode confidence that organisations can be relied upon to self-govern powerful, often-opaque technologies. In that sense, encryption compliance breaches are treated more like breaches of institutional responsibility – which explains the sharper tone, higher penalties, and lower tolerance for “we didn’t realise” defences.
Questions for the boardroom
Encryption export compliance should not be delegated wholesale to technical or engineering teams. It directly affects governance, risk, and strategy – and therefore deserves boardroom-level visibility. Leadership teams should be asking:
- Where is encryption embedded across our products and services, including default, inherited, or third-party components?
- Who can access controlled code, keys, or administrative functions, and from which jurisdictions?
- How do product updates, patches, or configuration changes alter our export classification or licensing posture?
- Are acquisitions, partnerships, or joint ventures introducing new encryption exposure we have not mapped?
These are questions of accountability, market access, and regulatory resilience… and they become considerably harder to answer once enforcement begins.
Encryption: a new fault line in global trade governance
Code now moves faster than goods, updates outpace licensing cycles, and access permissions matter more than fact-of-ownership. As a result, encryption export compliance sits uniquely at the intersection of legal interpretation, engineering design, product strategy, IT security, and trade governance.
Organisations that are able to smoothly integrate these functions (rather than managing encryption in silos) are best-positioned to reduce operational friction, protect global market access, and move faster with confidence and capability.
Those that do not risk discovering – usually, too late – that software now carries significant geopolitical weight.
Safeguard your technological export control compliance with clearBorder →
