Close
Updated:

Compliance in 2020 – Key Takeaways from the ITAR Cloud Rule

On December 26, 2019, the Department of State published in the Federal Register an interim final rule amending the International Traffic in Arms Regulations (ITAR) to define “activities that are not exports, reexports, retransfers, or temporary imports,” and specifically to clarify that the electronic transmission and storage of properly secured unclassified technical data via foreign communications infrastructure does not constitute an export. The rule also defines “access information” and revises the definition of “release” to address the provision of access information to an unauthorized foreign person.

Interested parties have an opportunity to comment until January 25, 2020. The ITAR interim final rule will become effective on March 25, 2020.

While the rule makes progress in an important area of Export Control Reform left open by earlier rulemakings, there are important nuances. Below are some key takeaways.

Takeaway 1 – The ITAR interim final rule generally harmonizes with corresponding EAR definitions.

The ITAR interim final rule is structured similarly and harmonizes its definitions with the Export Administration Regulations (EAR). In particular, it harmonizes the end-to-end encryption carveout, which provides that it will not be an export, reexport, retransfer, or temporary import to send, take, or store ITAR technical data that meets all of the following conditions:

  • Unclassified;
  • Secured using end-to-end encryption; “end-to-end” encryption requires that the data be encrypted before crossing a national boundary and stay encrypted while being transmitted from one security boundary to another, so long as no third party has the ability to access the data;
  • Secured using cryptographic modules compliant with the Federal Information Processing Standards Publication 140–2 (FIPS 140–2) or its successors, or by other cryptographic means that provide security strength that is at least comparable to the minimum 128 bits of security strength achieved by the Advanced Encryption Standard (AES–128);
  • Not sent from, or intentionally sent to a person in or stored in a section 126.1 arms embargo country or Russia.

Provided the above criteria are met, the storage of properly encrypted technical data in a foreign country is not a controlled export. However, when properly encrypted technical data present in a foreign country becomes unencrypted and thus recognizable as technical data, then an export occurs, and appropriate authorizations are required.

Section 734.18(a)(5) of the EAR contains a similar carveout. Consequently, companies may now be able to use similar compliance procedures for cloud services with respect to both EAR and ITAR controlled content.

Takeaway 2 – The ITAR interim final rule creates a bright-line standard for encrypted transmissions using alternative security methods.

To satisfy the end-to-end encryption carveout, companies would be able to use third-party or internally developed cryptography that is not NIST certified, but the alternative must provide security strength that is at least comparable to the minimum 128 bits of security achieved by the Advanced Encryption Standard (AES-128).

Unlike the EAR, which more vaguely requires that an alternative security be equally or more effective than the Federal Information Processing Standards Publication 140-2, the ITAR interim final rule creates a bright-line standard (i.e., AES-128) for encrypted transmissions.

However, under both the EAR and ITAR, the onus remains on the sender to ensure that the security means used are effective in the context in which the company operates. Transmissions lacking adequate security could therefore be treated as exports with the associated liability.

Takeaway 3 – The ITAR interim final rule revises the definition of “export” and “release” to address the use or provision of “access information.”

The ITAR interim final rule provides that an ITAR 120.17 “export” can include a release through the use of “access information,” which can occur in either of two ways: (1) the use of access information causes or enables a foreign person to access, view, or possess unencrypted data; or (2) the use of access information causes technical data outside of the U.S. to be in unencrypted form. “Access information” is information that allows access to encrypted technical data in an unencrypted form; examples of “access information” include decryption keys, network access codes, and passwords. The treatment of “access information” differs from the EAR in two respects.

First, under the EAR, authorization is required to share access information only if there is “knowledge” (i.e., awareness of a high probability) “that such transfer would result in a release . . . without a required authorization.” New ITAR 120.50(b), however, would require neither knowledge nor actual access to the unencrypted data. Rather, the rule requires authorization to provide access information to a foreign person “if that access information can cause or enable access, viewing, or possession of the unencrypted technical data.” Thus, if a password can theoretically cause or enable a foreign person to view unencrypted data, then authorization for sending the technical data must be in place prior to providing the password to the foreign person, even if the password were provided inadvertently.

Second, under the EAR, merely decrypting technology so that it is viewable abroad by a U.S. person would not by itself be an export. The ITAR interim final rule, however, states that a “release” includes using access information to cause technical data to be in unencrypted form, even when such action is taken by U.S. persons abroad. For example, while it would not be an export to provide a password for a virtual private network (VPN) to a U.S. person traveling in Germany, the use by the U.S. person of the password to make the technical data viewable via the VPN would be an export. In this case, however, the exporter could potentially rely on the ITAR 125.4(b)(9) exemption, which authorizes the export, reexport, or retransfer of technical data to U.S. persons and authorized foreign persons traveling or on temporary assignment abroad, subject to sufficient safety precautions such as encryption or secure networks like VPNs.

Takeaway 4 – Clarification that certain exchanges between U.S. persons are not exports, reexports or transfers.

The rule and associated DDTC guidance published with the rule both indicate that an export, reexport, retransfer, or temporary import does not include “transmitting or transferring within the same foreign country technical data between or among only U.S. persons, so long as the transmission or transfer does not result in a release to a foreign person or transfer to a person prohibited from receiving the technical data [such as a debarred person].” This change was not included in the 2015 proposed rule and provides more clarity for U.S. persons abroad who need to review technical data but are not necessarily listed on an existing authorization, such as in the case of discussions or training sessions that take place outside the United States where only U.S. persons are present.

Takeaway 5 – Use of end-to-end encryption would not necessarily trigger registration requirements.

The ITAR 122.1 exporter registration requirements can be triggered by only one instance of exporting ITAR controlled technical data. Sending or taking the technical data outside the United States in a manner that meets the requirements of the encryption carveout would not be an export and therefore would not in itself trigger the registration requirement. This is of particular importance, for example, to commercial companies that may possess ITAR controlled technical data but are exempt from registration (e.g., because their pertinent business pertains only to the production of unclassified technical data) and wish to use cloud services. Note, however, that sending technical data from the U.S. to an employee outside the U.S. that is accessed by that person in unencrypted form would still require authorization (e.g., via the 125.4(b)(9) exemption) and accordingly would require registration on that basis.