Many companies, particularly Software-as-a-Service ("SaaS") and start-up companies, continue to struggle with the concept of export control classification of items with encryption functionality. This ongoing confusion is understandable for a few reasons. First, many SaaS companies do not export their software in the traditional sense. Software purchasing has moved beyond the days of downloading and installing software onto a computer from, for example, a CD-ROM. (Most newer laptops no longer contain disc drives.) But these companies may still unknowingly be exporting software according to regulatory definitions.

Second, many SaaS providers and other software developers are shocked that export controls, primarily applicable to military and "dual-use" items, have any relevance to seemingly innocuous software programs. But there are many commercial software programs that are classified under Export Control Classification Number ("ECCN") 5D002 (or 5A002 for related hardware), which require export authorization (i.e., an export license or license exception) for export to nearly every country in the world.

Unsurprisingly, there are additional reasons why SaaS companies, and other companies involved in software production, make mistakes when it comes to encryption classification, or fail to classify at all. In this article, we describe some of these most common mistakes and hope to shed some light on an often-misunderstood portion of the Export Administration Regulations ("EAR").

  1. "We Do Not Export Our Software": Misunderstanding "Export" or Reasons for Classifying

The idea that a company does not export and thus does not require export classification could be a mistake for a couple of reasons. First, a company may incorrectly believe that a software export is only achieved through the physical shipping of software in hard copy outside the United States. To clarify, an export of software can take place when the software is downloaded in another country. In the case of a SaaS offering, which may not typically involve downloads abroad, exports may occur during the development stage if software is transferred to developers in other countries or, as discussed below, to non-U.S. persons in the United States.

Also, some companies offer both SaaS options and "on-premises" options for software deployment. The on-premises deployment of software typically provided as a SaaS offering could trigger an export. Additionally, under the EAR the release of software to a foreign person within the United States is deemed an export, and these "deemed exports" require appropriate authorization like any other export. "Deemed reexports" can also occur when a particular country would not require a license but a third party national in that country would e.g., a Mexican citizen in Canada.

Even if there truly is no export, confirming the export control classification of your software may be a prudent decision, especially if the software is from a startup or other company that may receive foreign investment in the future. Under the Committee on Foreign Investment in the United States ("CFIUS") regulations, CFIUS has jurisdiction to review "covered transactions." Certain jurisdictional triggers require an understanding of whether the U.S. business target of the investment produces, designs, tests, manufactures, fabricates, or develops one or more "critical technologies." The definition of "critical technologies" includes certain items controlled on the Commerce Control List ("CCL"), like encryption items classified under ECCNs 5D002 and 5A002.

As with any item potentially controlled under the export control regulations, it is generally a good idea to classify the product to confirm compliance with relevant requirements. Our clients frequently receive or provide requests to business partners to certify compliance with relevant export control and sanctions regulations, and these certifications often require confirmation of relevant export control classifications.

  1. Incorrectly Thinking the Software Has No Reason to Be Controlled

Many of our clients are understandably frustrated when their SaaS (or other software) offering, which contains or merely leverages standard cryptography, is assigned an ECCN subjecting the product to export controls. Many SaaS programs have sending, receiving, storing, or processing information as a primary function. If these items do not qualify for "mass market" treatment (more on that later), then the appropriate classification is often ECCN 5D002 for "information security" software, unless certain decontrols apply. Why? Because the Department of Commerce Bureau of Industry and Security ("BIS"), which administers the EAR, controls the encryption functionality, even when the encryption is widely available. For this reason, it may be helpful to think of encryption functionality, which is nearly ubiquitous in modern software, particularly SaaS, as "tainting" software that would ordinarily not be controlled.

Even if the software is export controlled, most export controlled software may be exported to most countries and end users around the world without the need for a license and with little regulatory burden. For this reason, some have described the use of export controls of encryption items as more of an exercise in information gathering than truly controlling exports.

  1. Mistaking the Effect of Using "Open Source" Encryption

Within the industry, open source often means software developed and maintained through open collaboration and made available for anyone to use, examine, alter, and redistribute however they like, typically at no cost.1 The EAR uses the similar, though not identical, concept of "publicly available." To be "publicly available," the EAR requires the software to be "published," meaning "when it has been made available to the public without restrictions upon its further dissemination."2 BIS provides two examples of publicly available encryption items that notably both involve free provision of software: free apps posted online or mass market software available as a free download.3

And now things get tricky. What if the software only uses open source, publicly available encryption software, e.g., OpenSSL? Unfortunately, in Note 2 to its "Encryption Items NOT Subject to the EAR" webpage, BIS states, "While open source code itself may be publicly available and not subject to the EAR, an item is not considered publicly available merely because it incorporates or calls to publicly available open source code. Rather, a new item with encryption functionality has been created which would need to be evaluated as a whole under the EAR."4 Therefore, software that incorporates publicly available encryption does not automatically receive the benefit of that encryption software's publicly available treatment. Instead, the "new item with encryption functionality" will likely not be publicly available per the definition, and it will potentially be subject to export control requirements. This is the case even though the publicly available encryption software is released from EAR controls if exported by itself.

  1. Incorrectly Claiming "Mass Market" Treatment

For some software classified as "information security" software, there is still the possibility of avoiding most export controls. Specifically, if the software meets the criteria of the "Cryptography Note," commonly referred to as the Mass Market Note, in the EAR's Commerce Control List ("CCL"), then the software will be controlled as 5D992, or 5A992 for hardware, releasing it from the controls of 5D002 or 5A002 classification. The Mass Market criteria is:

Items meeting all of the following:

1. Generally available to the public by being sold, without restriction, from stock at retail selling points by means of any of the following:

a. Over-the-counter transactions;

b. Mail order transactions;

c. Electronic transactions; or

d. Telephone call transactions;

2. The cryptographic functionality cannot be easily changed by the user;

3. Designed for installation by the user without further substantial support by the supplier; and

4. When necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter's country in order to ascertain compliance with conditions described in paragraphs a.1 through a.3 of this Note.

It quickly becomes clear that these criteria have not been updated for some time. When was the last time you ordered software in a mail order transaction? However, the outdated language of the Mass Market Note can create some problems of interpretation. For example, a SaaS product likely does not require any installation, so how does one apply section 3 regarding installation without further substantial support? BIS does not explicitly provide much helpful guidance. On its Mass Market webpage, BIS explains, "Mass market products are typically consumer products sold at retail stores or internet locations, but products sold only to businesses can also qualify for mass market. BIS takes into account a range of factors when determining whether something qualifies for mass market including quantity of the item sold, price, technical skill required to use the product, existing sales channels, typical customer, and any exclusionary practices of the supplier."5

Taking the above at face value, a product targeting individual consumers has a greater chance of being mass market than a business-to-business item. Further, BIS explains the factors it considers but not how the factors are weighted or reviewed. For these reasons, companies should be careful when classifying a product as mass market without having adequate support for such classification.

Claiming License Exception ENC Without Conducting Full ENC Analysis

Software classified as ECCN 5D002 is controlled for National Security ("NS") and Encryption Items ("EI") reasons, and BIS requires a license or other authorization (i.e., license exception) for exports of 5D002 software to all destinations, except Canada. Fortunately, the EAR provides a license exception for encryption commodities, software, and technology ("ENC"). License Exception ENC is applicable to most exports of encryption items, removing the need for an export license. However, determining the applicability of License Exception ENC requires further analysis because various subparagraphs (i.e., (a), (b)(1), (b)(2), and (b)(3)) of the exception authorize different types of transactions and products, often requiring a self-classification report or classification request to BIS.

Many companies do the work of self-classifying their encryption item yet stumble at the finish line by not determining the appropriate license exception ENC subparagraph. This oversight may impact the requirements for using the license exception if the exception is even available. For example, for items described in ENC paragraphs (b)(2) or (b)(3), self-classification is not sufficient. Instead, those ENC subparagraphs require submission of a classification request to BIS. On the other hand, if a company self-classifies and determines that (b)(1) is the appropriate ENC subparagraph, the license exception requires annual reporting related to exports of the self-classified item. (Tip: If a company with an ENC (b)(1) item opts to submit a classification request to BIS, the item is no longer subject to an annual self-classification report requirement.)

***

Many commercial software products are subject to export controls from incorporated or leveraged encryption functionality, so software companies should classify their products under the EAR, if applicable. In many cases, a decontrol note will operate to remove the item from a controlled classification like ECCN 5D002 so that no authorization is required for export. However, even if the item requires authorization, nearly all encryption items are eligible to be exported, reexported, or transferred (in-country) without licenses by using License Exception ENC. It is important to conduct a License Exception ENC analysis to determine 1) additional requirements to use the exception, or 2) whether the product or transaction is a rare example for which ENC is not available and an export license is required.

The attorneys at Torres Trade Law have significant experience with classifying encryption items, both for exports and in preparation for potential investment. Additionally, the Torres team can assist with License Exception ENC analysis and requirements, and, when advisable, assist in the voluntary self-disclosure to BIS of any potential violations related to administrative or significant violations from unauthorized exports.

Footnotes

1. What Is Open Source Software?, IBM, https://www.ibm.com/topics/open-source (last visited Apr. 11, 2024).

2. 15 C.F.R. § 734.7(a) (2024).

3. Encryption Items NOT Subject to the EAR, Department of Commerce, Bureau of Industry and Security, https://www.bis.doc.gov/index.php/policy-guidance/encryption/1-encryption-items-not-subject-to-the-ear (last visited Apr. 11, 2024).

4. Id.

5. Mass Market (Section 740.17), Department of Commerce, Bureau of Industry and Security, https://www.bis.doc.gov/index.php/policy-guidance/encryption/3-license-exception-enc-and-mass-market/a-mass-market (last visited Apr. 11, 2024).

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.