License Exception ENC and the Complications Around Encryption

Hardware and software that incorporates encryption is a much larger category of exports than most people realize. That’s because just about anything that contains some sort of encryption capability – even if it’s ancillary to the item’s primary function – needs to be considered for export controls that may apply.

When you look at the main export control regulations, the EAR and the ITAR, most items that are classified as encryption look like they’re highly controlled, so working with exports that involve cryptography can appear daunting.

The good news is that many products with these capabilities are not actually captured on the control lists – and most of those which are controlled by the EAR are eligible for relatively broad export authorizations including License Exception ENC (for “Encryption commodities, software, and technology). In fact, more than half of all exports made under license exception are authorized by License Exception ENC.

But License Exception ENC has about as many twists and turns as can be found anywhere in the Export Administration Regulations (EAR), and before you even try to untangle it, there are two other steps to take first when classifying any potential export item that contains cryptographic capabilities.

Step 1: Subject to the ITAR

It’s a common misconception that the International Traffic in Arms Regulations (ITAR) controls commercial cryptography. That was largely the case until 1996, but the rules have been updated numerous times since. Today the ITAR applies only to narrow areas of encryption identified in Category XIII(b) of the U.S. Munitions List, which includes cryptography that falls into five buckets of military or intelligence cryptographic (including key management) systems and related technology:

…capable of maintaining secrecy or confidentiality of information or information systems, including equipment or software for tracking, telemetry, and control (TT&C) encryption and decryption;
… capable of generating spreading or hopping codes for spread spectrum systems or equipment;
… cryptanalytic systems, equipment, assemblies, modules, integrated circuits, components and software;
… authorized to control access to or transfer data between different security domains as listed on the Unified Cross Domain Management Office (UCDMO) Control List (UCL);
… ancillary equipment specially designed for the articles identified above.

If an item doesn’t fall into any of these areas, it’s going to be subject to the EAR – if it’s subject to any U.S. export controls at all.

Step 2: Not subject to the EAR

Software that’s been published is generally not subject to the EAR. Some of the most popular consumer software applications are, in the parlance of regulations, publicly available mass market encryption software which does not come under the EAR (after classification or, more commonly, self-classification). Think of common web browsers and messaging apps.

Also outside the scope of the EAR is open-source software, though the regulations don’t specifically use that term. If software can be downloaded online without any special access, and no activation key is required to deploy it, then that software can generally be considered to be publicly available source code. If it’s published, it’s not subject to the EAR. But there’s a catch. The EAR does say that, in limited cases involving “non-standard cryptography”, encryption source code isn’t technically considered to be published – even if it’s open source and readily available – unless an email notification has been provided to the BIS and NSA with the source code’s location (or a copy of the code). Once software has been published and any required notification has been made, the source code and any corresponding object code are not subject to the EAR.

However, this applies only to software – not hardware. Also, it doesn’t apply when published encryption software is incorporated into proprietary products; those still need to be evaluated as encryption under the EAR to determine how they’re controlled.

It seems like a strange rule; the people who use 3^rd party published encryption may not even understand how it works, and a lot of software engineers are incredulous that their implementation of widely used published encryption software – such common types as OpenSSL and OpenSSH – can change the status of an otherwise uncontrolled product.

If you’re confused, you’re not alone – and there are other complications to wade through. The Bureau of Information Security (BIS) provides some helpful policy guidance for understanding when encryption items are not subject to the EAR.

Also, the Export Compliance Training Institute offers on-demand seminars about navigating the rules around encryption and cryptography.

Step 3: Subject to the EAR

Normally in the EAR, one classifies an item based on its overall function and capabilities, then you’re most of the way to knowing whether an export license is required. But if an item involves any kind of encryption, be sure to consider Category 5, Part 2 of the CCL – the section that deals with cryptography and other information security – to see if it applies.

The EAR defines cryptography as “The discipline that embodies principles, means and methods for the transformation of data in order to hide its information content, prevent its undetected modification or prevent its unauthorized use. ‘Cryptography’ is limited to the transformation of information using one or more ‘secret parameters’ (e.g., crypto variables) and/or associated key management.” The definition encompasses decryption but does not include fixed data compression or coding techniques that may help to keep information secure.

If an item doesn’t fit this description, or does but qualifies for one of several carve-outs, then the item isn’t controlled as encryption and you can move ahead with the usual process of classifying the item to determine whether it is controlled elsewhere in the EAR for any other reason (see related post: Subject to the EAR – What It Means and How to Approach It

Step 4: Subject to the EAR and controlled for encryption

If an item does, in fact, fit the definition the EAR provides for cryptography, there are four ECCNs likely to apply in its classification:

5A002 and 5D002 for non-mass market encryption hardware and software, respectively;
5A992 and 5D992 for mass market encryption hardware and software, respectively.

Mass market or not? While specific export controls apply to all four of these ECCNs, the controls for mass-market items are generally less restrictive. So that’s the next determination to be made in classification.

This is where the navigation gets tricky and likely requires training and expertise.

The definition of mass market is detailed in Note 3 to Category 5 Part 2, and includes characteristics such as being sold at retail and having cryptography functions that aren’t meant to be modified by the user. This is generally hardware and software intended for use at home by consumers and by small businesses. If the item is deemed mass market, it will fall under ECCN 5A992 or 5D992, and will generally be eligible for export No License Required (NLR) (except to embargoed destinations or in other special circumstances). However, in some cases a classification request or self-classification reporting is required.

License Exception ENC: Paragraph (a), (b)(1), (b)(2), or (b)(3)? If you get to this stage, and determine that the item is not mass market, it will likely be classified in ECCNs 5A002 or 5D002. Again, a classification request or self-classification report may be required. Because Category 5, Part 2 pulls a wide range of items under control as encryption, ECCNs 5A002/5D002 cover a broad spectrum of items which are eligible for export NLR to Canada only. Despite having the same ECCN, they’re effectively not all controlled at the same level because License Exception ENC consists of multiple provisions, each of which authorizes a different scope of transactions, and applies to specific types of products.

In other words, it is not sufficient to know the ECCN when it comes exporting encryption items classified 5A002/5D002. The exporter must also obtain (or ascertain) the specific applicable provision of License Exception ENC. It takes careful analysis to determine not only which paragraph of ENC applies to an item, but also how it applies based on the item’s destination and characteristics.

Manufacturers and developers of encryption items classified as 5A002/5D002 generally characterize their products as being eligible for License Exception ENC subparagraphs (b)(1), (b)(2), or (b)(3).

Subparagraph (b)(2), otherwise known as the “restricted” provision of License Exception ENC, applies to several categories of relatively more sensitive items, including network infrastructure, source code, technology, quantum cryptography, and items customized for government use. While these items are still broadly exportable under the exception to non-government end users, exports to government end-users in countries not listed in Supplement No. 3 to Part 740 are limited.

Subparagraph (b)(3) items are broadly exportable under License Exception ENC, but only after a mandatory classification request is submitted to BIS. Non-mass-market chips, development kits, cryptographic libraries, and digital forensics are among the items identified by (b)(3).

Items not described in subparagraphs (b)(2) or (b)(3) are covered by subparagraph (b)(1), sometimes referred to as the “unrestricted” provision, which is the most common, and provides for the broadest authorization under License Exception ENC, worldwide except to embargoed destinations, and without unique end user limitations.

This overview should not be seen as a comprehensive guide for exporting items that contain encryption technology; the topic is too nuanced to be covered in depth in a blog post. Rather, it’s intended to offer a survey of the complexities that surround cryptography, and why it’s the first step in managing export compliance for any item that contains encryption functionality.

Resources

Many software developers also provide information on how their own encryption technology is classified. Here are a few examples:

Do you have questions about License Exception ENC? Visit hr4.hongjiuchina.com to learn about our company, our faculty, our staff and our esteemed Export Compliance Professional (ECoP®) certification program. To find upcoming e-seminars, live seminars and live webinars and browse our catalog of 80-plus on-demand webinars, visit our ECTI Academy. You can also call the Export Compliance Training Institute at 540-433-3977 for more information.

Scott Gearity is President of ECTI, Inc.