Table of contents
If you are involved with building software for use by hardware teams working in aerospace or defense, there is a good chance that ITAR compliance has come up.
When we founded Cofactr, we knew early on that we would eventually want to become ITAR compliant, but we found it very difficult to find clear information on what would actually be involved in that process. Ultimately, customer demand pushed us to prioritize ITAR compliance and, with the help of some friendly experts, we were able to complete the process of becoming ITAR registered and compliant in just a couple of months.
My goal with this post is to share some of what we learned through that process and provide some clear, simple, guidance on what is actually involved in becoming ITAR compliant if you are building software for use by hardware teams.
What is ITAR?
ITAR stands for International Traffic In Arms Regulations and specifically refers to a United States Department of State regulatory regime and related laws. When we talk about ITAR, we are often using this term as a catch-all for multiple related US regulatory programs including ITAR, the Arms Export Control Act (AECA), the United States Munitions List (USML), and Export Administration Regulations (EAR).
Fundamentally, all of these laws are related to global trade and exports. The US government’s goal is to restrict and regulate exports from the United States of defense-related technologies. Other countries have similar laws (for example CGP in Canada), but those are outside the scope of this discussion.
It’s important to remember that technical data related to physical items regulated under ITAR is also, by extension, regulated under ITAR in much the same way as the physical item itself. For example, if the USML includes a rocket, not only are we restricted from exporting that rocket from the United States, but we are also restricted from exporting data that could help someone build that rocket themselves such as a technical drawing or bill of materials.
Does ITAR apply to me?
If you are building hardware in aerospace or defense, there is a very good chance that ITAR applies to you, but this article probably won’t cover the information that you need to know.
If you are building software, particularly cloud software, that could be used by teams building hardware in aerospace or defense, there is ALSO a very good chance that ITAR applies to you, and this article will cover some information that you need to know.
Why does ITAR apply to my software product?
When a user uploads technical data that is related to an export-controlled item to your software product, you have a responsibility to prevent intentional or unintentional export of that technical data.
Thanks to the movies, exporting defense technical data might bring to mind images of a USB key in a titanium attache case, but in practice, it’s much easier and more boring to run afoul of these laws. All it takes is an individual who is not a US-person viewing a file and, bam!, it’s been illegally exported. For example, if a member of your team who is not a US person opens up an export-controlled customer file to help troubleshoot a software bug, that file has just been illegally exported.
What’s this US-person thing?
These various export controls are all about preventing non-US-persons from accessing defense data, so it helps to know what a US person even is. In classic legalese form, a US person does not have to be a US citizen, and they don’t even have to be a person.
They do have to be a lawful permanent resident of the United States or any corporation, business association, partnership, society, trust, or any other entity, organization or group that is incorporated to do business in the United States. It also includes any governmental (federal, state or local) entity.
Okay, I want to become ITAR certified. What do I do?
Let me stop you right there. Unlike audit-driven certifications like ISO9001 or SOC2, ITAR is not a certification so you can’t become ITAR certified.
You can (and must) become ITAR registered, which involves filling out some paperwork with the U.S. Department of State, Directorate of Defense Trade Controls (DDTC), and paying an annual fee that is currently $2,250 or a bit more depending on some specifics of your business.
You also will need to become ITAR compliant, which is a matter of putting in place the staff training, technical controls, and internal procedures required to ensure that you actually are following the relevant laws.
There is no process for the government or a 3rd party to come to check that you are actually following the rules, but if you get caught not following the rules, the consequences can be very severe (think massive fines and possible jail time), so this isn’t a good area to move fast and break things.
Practically, for a software business, you’ll need to worry about implementing the required procedural and training programs and ensuring that your software technology meets the relevant data security requirements.
For your procedural and training programs, it is very unlikely that you will be able to figure that stuff out yourself unless you’ve done this before (in which case you shouldn’t be wasting your time with this article) so you will need to hire a consultant to help you out. This will look pretty similar for every business so your consultant will be able to give you some fairly out-of-the-box solutions like pre-made training materials and then they will tweak them as needed for the specifics of your situation. Expect to spend somewhere in the neighborhood of $15-30k and receive a bunch of slide shows that you can use for employee training and guidance on any areas where you will need to tighten things up within your operations. If you need recommendations for a consultant, you can reach out to me on LinkedIn, and I will introduce you to the one that we worked with.
Additionally, you will need to implement some administrative programs like Restricted/Denied Party Screening to make sure your staff, office visitors, vendors, customers, etc aren’t on terrorist watchlists and such. This will cost you a few thousand dollars per year for access to the relevant software from a company like Descartes or Thompson Reuters.
Ensuring your software itself is compliant is the hardest topic to get clear guidance on but, in practice, likely won’t prove to be super difficult. The key requirement is that you are ensuring that only US-persons have access to export controlled data.
You will need some basic protections like end-to-end encryption compliant with Federal Information Processing Standards Publication 140-2 (FIPS 140-2) but, in all likelihood, you already have this if you are using a modern web development stack.
At Cofactr, we have a pretty common stack with a React/TS frontend and a Django/Postgres backend, and we didn’t have to change anything about our core application to meet the end-to-end encryption requirement.
You will also need to use cloud hosting providers that are authorized by the Federal Risk and Authorization Management Program (FedRAMP) for portions of your application that process or store export-controlled data. In our case, this meant switching from a normal AWS region to an AWS GovCloud region. If you use one of the major cloud providers, you should be able to make the switch to the FedRAMP version of their service unless your application relies on their more esoteric or recently introduced services. In our experience, customers who need ITAR seem to prefer that we host with AWS GovCloud or Azure FedRAMP, but that’s mostly anecdotal.
The hardest part is ensuring that technical data can’t be exposed to any related services that you may use as part of your tech stack such as log monitoring, product analytics, customer support software, etc. If you determine that technical data could be exposed to one of those tools, you have three options:
- Migrate to an on-prem/private-cloud version of the product that is hosted in a FedRAMP cloud
- Disable that tool for customers with export-controlled data
- Engineer some sort of data obscuration into your application to prevent controlled data from being exposed to that tool
At Cofactr, we have employed all three strategies. We have migrated some products we use to on-prem in the same AWS GovCloud region we use for our own application, we have disabled some product analytics entirely for the ITAR-compliant version of our product, and we have engineered other parts of our system to insulate export-controlled technical data from SaaS products that cannot legally handle that data.
Is there any way around this?
The only way to avoid having to comply with ITAR is to prevent customers from using your product with export-controlled technical data. This will cut off your ability to serve customers in defense and much of aerospace, but only you can determine whether you will get enough business from these industries to justify the cost and effort required to comply with ITAR. At Cofactr, we love working with aerospace startups, so it was an easy decision for us to become ITAR compliant.
Important Legal Disclaimer
I am very much not a lawyer. Sadly, I haven't even played one on TV. This article reflects our experience with the process of becoming ITAR compliant, and there may be all sorts of specifics of your business that are different than ours. This information is provided for informational purposes only, and should not be construed as legal advice on any subject matter. You should not act on the basis of this content without consulting your own relevant lawyers and experts first.