Export Controls for Software Companies: EAR, ITAR and Federal Contracts
By Philip Luca — Founder of GovExpress; prior domain experience at Bloomberg Government and GovWin IQ.
Most software companies first meet export controls in the commercial market, when an overseas customer, a distributor or a payment processor asks for an ECCN. Federal work raises the same question from the other side. A Department of War (DoW) contract carries an export clause, a prime asks whether your engineers are US persons, or an agency hands you technical data marked as export controlled.
This guide covers the two US export regimes that matter to software companies, how software is classified, what changes for encryption, why foreign employees and cloud hosting deserve attention, and where export controls show up in federal contracts. The rules cited are from the Export Administration Regulations (EAR), 15 CFR Parts 730 to 774, and the International Traffic in Arms Regulations (ITAR), 22 CFR Parts 120 to 130.
Two regimes, two agencies
| EAR | ITAR | |
|---|---|---|
| Administered by | Department of Commerce, Bureau of Industry and Security (BIS) | Department of State, Directorate of Defense Trade Controls (DDTC) |
| What it covers | Commercial and dual-use items, including most commercial software | Defense articles, defense services and technical data on the US Munitions List |
| Control list | Commerce Control List, Supplement No. 1 to 15 CFR Part 774 | US Munitions List, 22 CFR 121.1 |
| Typical outcome for commercial software | Classified under an ECCN or as EAR99; often exportable without a license or under a license exception | Rare for commercial software, but applies to software specially designed for defense articles |
Jurisdiction comes first. If an item is on the US Munitions List, the ITAR governs and the EAR does not. Everything else that is subject to US export jurisdiction falls under the EAR. A company that is not sure which regime applies can ask DDTC for a commodity jurisdiction determination.
The ITAR has one rule that surprises software companies: a company in the United States that manufactures defense articles or furnishes defense services generally has to register with DDTC under 22 CFR Part 122, whether or not it ever exports. If you build software to a defense specification, check this before the contract starts.
How software is classified under the EAR
Under the EAR, each controlled item has an Export Control Classification Number (ECCN). The number tells you the category and product group, and the entry lists the reasons for control and which destinations need a license. Software has its own product group, the “D” entries, such as 5D002 for certain encryption software.
Items that are subject to the EAR but match no ECCN are designated EAR99. Many business applications land there. EAR99 does not mean uncontrolled: an EAR99 product still cannot go to an embargoed destination, a party on a restricted list or a prohibited end use without authorization.
Military items moved from the US Munitions List to the Commerce Control List sit in the 600 series ECCNs, which carry tighter controls than ordinary dual-use entries. Software developed for those items can carry the same classification.
A practical approach to classification:
- List what you actually ship: each product, version and major module, including on-premises builds, mobile apps and any hardware.
- Check for defense-specific design first. Software specially designed for a defense article may be on the US Munitions List.
- Match against the Commerce Control List, starting with Category 5 Part 2 for anything that uses encryption.
- Record the result and the reasoning, dated and signed, and revisit it when the product changes.
- Ask BIS for a commodity classification under 15 CFR 748.3 when the answer is genuinely unclear or a large customer needs certainty.
Encryption is where most software lands
Almost every modern software product uses encryption, so Category 5 Part 2 of the Commerce Control List is the entry most software companies have to read. Encryption software is classified under entries such as 5D002, and many mass-market products are classified 5D992.
Most commercial encryption products can be exported to most destinations under License Exception ENC, 15 CFR 740.17, or without a license once the conditions for their classification are met. Depending on the product, those conditions can include a classification request to BIS or an annual self-classification report. Read the current text of 740.17 for your product type rather than relying on a summary.
Publicly available source code is treated differently. Under 15 CFR 734.3(b)(3) and 734.7, published software and source code is generally not subject to the EAR, with a notification condition for certain encryption source code under 742.15(b). That covers open-source components you publish. It does not cover your proprietary product built on top of them.
Deemed exports and foreign employees
Under the EAR, releasing controlled technology or source code to a foreign person inside the United States is a deemed export to that person’s most recent country of citizenship or permanent residency (15 CFR 734.13(b)). The ITAR’s definition of export, at 22 CFR 120.50, likewise reaches releases of technical data to foreign persons in the United States.
For software companies, this shows up in three places:
- Engineering teams. A foreign-national engineer with access to controlled source code or technology may need a license, depending on the classification and the person’s nationality.
- Offshore development and support. Sending controlled code or technical data to a team abroad is an actual export.
- Contract data. Technical data an agency or prime gives you may be controlled even when your own product is EAR99. Who on your team can see it is the question that matters.
Lawful permanent residents and protected individuals are US persons for these purposes. Visa holders generally are not.
Cloud hosting and SaaS
Running software as a service does not, by itself, export the software to the people who use it. The questions that matter are where controlled technical data and source code are stored and who can access them.
Both regimes contain a carve-out for encrypted storage. Under 15 CFR 734.18(a)(5) and 22 CFR 120.54(a)(5), sending or storing unclassified technology or technical data that is protected by end-to-end encryption meeting the stated standards, and not deliberately stored in certain listed countries, is not an export. Read the conditions closely; the carve-out depends on who holds the keys and where the data sits unencrypted.
Some federal contracts and authorizations add their own requirements on top, such as US-only data locations or US-person support staff. Those are contract and security terms, not export rules, but they often arrive in the same conversation. If your offering is going through FedRAMP or an agency ATO, keep the two analyses separate.
Where export controls reach a federal contract
| Where | What you see |
|---|---|
| DoW contracts | DFARS 252.225-7048, Export-Controlled Items, which requires the contractor to comply with the export control laws, including in performance of the contract |
| Technical data from the government | Markings identifying export-controlled information, often handled as CUI under DFARS 252.204-7012 |
| Primes and teaming partners | Questions about classification, US-person status of staff and where work is performed, flowed down from their own obligations |
| SBIR and R&D work | Technology developed under the award may itself be controlled; see SBIR and STTR |
| International sales of the same product | Your ECCN, restricted-party screening and any license exception you rely on |
Restricted-party screening belongs in every sale, federal or commercial. The International Trade Administration publishes a Consolidated Screening List that brings together the export screening lists of Commerce, State and Treasury, including the BIS Entity List.
A classification is a company claim
Most export classifications are self-determined. Nobody at BIS reviews your ECCN before you ship. A prime or an agency that asks for it is relying on your answer. A commodity classification from BIS or a commodity jurisdiction determination from DDTC is different: it is a government ruling on your product.
Self-attested is not the same as verified, and federal buyers increasingly ask which one they are looking at. See verified vs. self-attested: what federal buyers actually check.
If you find a past export that should have been licensed, both regimes provide for voluntary self-disclosure (15 CFR 764.5 and 22 CFR 127.12). Get export counsel involved before you file.
What this means for a software company
- Classify every product before a buyer asks. An ECCN or EAR99 determination, with the reasoning written down, answers most questions from primes and resellers.
- Read Category 5 Part 2 if your product uses encryption, which it almost certainly does.
- Map who can access controlled code and data, including foreign-national employees and offshore teams.
- Check ITAR registration if any of your software is built to a defense specification.
- Screen customers and partners against the Consolidated Screening List.
- Read the current rule text. The EAR and ITAR are amended often, and the FAR is being rewritten under the Revolutionary FAR Overhaul. Confirm the provisions in your solicitation and the current eCFR text.
Where this fits
Export classification sits next to the other representations a federal buyer expects to be settled before an offer arrives: country of origin, the Section 889 telecom representation, secure software development attestation and license terms an agency can sign. For defense work it often comes up alongside a facility clearance and CMMC.
Score your company’s federal readiness to see how your compliance profile looks next to the other categories federal buyers review.
Related reading
- The Trade Agreements Act for Software Companies: Country of Origin, Explained
- Section 889 for Software Companies: The Telecom Representation Every Offer Makes
- Facility Security Clearances for Software Companies: How an FCL Works
- SBIR and STTR for Software Companies: Funded R&D as a Federal Entry Point
- Glossary: CUI · DFARS 252.204-7012 · FedRAMP
Frequently Asked Questions
Does selling software to a US federal agency count as an export?
Not by itself. A sale to a federal agency inside the United States is not an export. Export controls still matter because the same product may be sold abroad, because technical data and source code you receive or produce under a contract may be controlled, and because releasing controlled technology or source code to a foreign person in the United States can be a deemed export under the EAR or an export under the ITAR.
Who decides whether my software is controlled under the EAR or the ITAR?
In the first instance, you do. Most companies self-classify their products against the Commerce Control List. If you are unsure, you can ask the Bureau of Industry and Security for a commodity classification, and if it is unclear whether the ITAR applies at all, you can ask the State Department's Directorate of Defense Trade Controls for a commodity jurisdiction determination. A self-classification is a company claim; a classification or jurisdiction determination is a government ruling.
Is export-controlled information the same as CUI?
They overlap but are not the same. Export Controlled is one category in the CUI Registry, so export-controlled technical information an agency gives you under a contract is usually marked and handled as CUI. The export rules still apply on their own terms: protecting the data under NIST SP 800-171 does not license its release to a foreign person.
The CMMC brief
What the Phase 2 suspension changed and what it did not — the obligations that still bind, the assessment path a contract puts you on, the scoping decision that drives the cost, and the sequence that fits inside a pipeline. Sourced from the primary record.