Export controls on dual-use defense software: what developers must know

Software crosses borders invisibly. A repository pushed to a cloud host, a demo delivered over video conference to a foreign partner, a contractor in another country granted read access to a build system -- each of these is a potential export transaction under US law. For defense software developers, the two regulatory regimes that govern these transactions are the Export Administration Regulations (EAR) and the International Traffic in Arms Regulations (ITAR). Getting the classification wrong does not merely create paperwork; it can result in criminal charges, denial of export privileges, and exclusion from future government contracting. This article walks through the core concepts that any engineer or product lead at a defense-adjacent software company needs to understand before the first international deal closes or the first foreign national joins the development team. References to ITAR-free defense software strategy appear throughout because classification decisions made at the architecture stage determine compliance costs for the product's entire commercial life.

What makes software dual-use under export regulations

The term "dual-use" describes a product, technology, or piece of software that has both commercial civilian applications and potential military or intelligence uses. Under US export law, dual-use items are governed by the EAR, administered by the Bureau of Industry and Security (BIS) within the Department of Commerce. The EAR does not control items based solely on what a developer intends them for -- it controls items based on their technical capabilities. A geolocation library that can track vehicles at 10-meter accuracy is controlled regardless of whether the developer's target market is logistics or battlefield management.

For software specifically, the triggering technical parameters vary by category. In the cryptography category (ECCN 5D002), the relevant parameter is key length: symmetric encryption above 56 bits and asymmetric encryption above 512 bits are controlled, which encompasses virtually every cryptographic library in production use today. In the navigation category (ECCN 7D004), the relevant parameter is whether the software processes inertial measurement data or GNSS signals in ways that exceed civilian accuracy thresholds. In the sensors and lasers category (ECCN 6D001, 6D003), the parameter is whether the software enables image or signal processing at resolutions or bandwidths that exceed specified civilian limits. The dual-use classification is therefore a technical determination, not a marketing one.

Software that falls below the thresholds for every controlled ECCN is classified as EAR99 -- the default classification for uncontrolled commercial items. EAR99 software generally requires no export license to ship to most destinations, but it is still subject to prohibitions against shipment to sanctioned countries and denied parties. The practical challenge for defense software companies is that a single product often contains modules at different ECCN levels: the core application logic may be EAR99, the embedded TLS stack is 5D002, and a signal processing module may be 7D004. The product's export classification is determined by the most controlled component.

EAR vs ITAR: which regime applies to your product

The boundary between EAR and ITAR is defined by the US Munitions List (USML), a list of defense articles and services published under ITAR at 22 CFR Part 121. If a software product was specifically designed or modified for military application and falls within a USML category, it is ITAR-controlled -- and the compliance burden is substantially higher than under EAR. ITAR requires registration with the Directorate of Defense Trade Controls (DDTC), a State Department license for virtually every foreign transfer, and detailed record-keeping on every disclosure. The penalties for ITAR violations are also more severe per transaction than EAR penalties.

Relevant USML categories for software developers include Category XI (military electronics, which covers electronic warfare, military radar, and military command and control software), Category XIII (auxilliary military equipment, which includes certain surveillance and intelligence-gathering software), and Category XV (spacecraft systems and related articles, which captures software for satellite command and control with military applications). If a product sits clearly within one of these categories, ITAR registration is not optional -- it is a prerequisite for any foreign disclosure, including showing the product to a foreign national in a US office.

The practical test that determines which regime governs is the "specifically designed or modified for military use" standard. A C2 system designed from the outset for military operations and marketed exclusively to defense agencies is likely ITAR-controlled. The same underlying mapping and communications technology packaged as a commercial product and sold to emergency services, logistics operators, and military customers alike is more likely EAR-controlled under a dual-use ECCN. This distinction is not purely academic: the strategic decision to build ITAR-free defense software is increasingly popular among non-US developers and companies that want to export to allied nations without the friction of DDTC licensing. A thorough USML review by export control counsel before product launch is the only reliable way to establish which regime applies.

Encryption export controls: EAR 740.17 and the 64-bit rule

Encryption export controls under EAR are one of the most frequently encountered compliance issues for defense software developers because every modern software product uses encryption. The relevant ECCN is 5D002, which covers software that implements, or is specifically designed to support, encryption algorithms with key lengths above specified thresholds. AES-128, AES-256, RSA-2048, ECDH with P-256 or P-384, TLS 1.2 and TLS 1.3 -- all are 5D002-controlled items. A SaaS product delivered entirely over HTTPS is exporting a 5D002 item every time a foreign user's browser establishes a TLS session.

License Exception ENC under EAR 740.17 provides a framework for exporting most commercial encryption without a transaction-by-transaction license. Mass-market encryption products -- software available for retail sale to the general public through standard commercial channels -- qualify for the most permissive tier of ENC (Section 740.17(b)(3)) without any prior BIS review. Custom or non-mass-market encryption products require a one-time review request submitted to BIS and the NSA before export, followed by annual sales reporting to certain destinations including Russia and China. Defense software companies that embed custom encryption implementations (rather than off-the-shelf TLS libraries) must classify those implementations separately and may face stricter ENC eligibility criteria.

The "64-bit rule" is an informal reference to a threshold in EAR Part 742.15 that distinguishes between publicly available encryption source code (which is not subject to EAR when properly published) and controlled software. The rule's practical implication is that open-source encryption libraries distributed without restriction are generally outside EAR jurisdiction, but the moment a defense software company forks one of those libraries and restricts distribution -- even for security hardening -- the restricted fork may re-enter EAR jurisdiction as a controlled 5D002 item. Development teams that maintain private forks of open-source cryptographic libraries should ensure those forks are reviewed as part of the product classification analysis.

ECCN codes that appear in defense technology software

Defense technology software clusters around a small number of ECCN codes, and understanding what each covers allows developers to identify controlled modules early in the design process. ECCN 5D002 (information security software) is by far the most common, covering encryption implementations of any kind above the minimum thresholds. ECCN 7D004 covers software for inertial navigation systems (INS) and GPS/GNSS receivers that operate beyond civilian accuracy limits -- relevant for any navigation software used in UAV flight control, precision targeting, or autonomous ground vehicle guidance. ECCN 4D001 covers software specifically designed for military intelligence gathering, signal exploitation, or electronic warfare support measures.

ECCN 0D521 is a control added under the EAR's emerging technology framework and covers software that enables surveillance, location tracking, or communications monitoring of individuals or groups at scale. This ECCN is increasingly relevant for defense software that incorporates RF detection, SIGINT-adjacent capabilities, or large-scale network traffic analysis. ECCN 3D001 covers software for the production of semiconductors and electronic components that are themselves controlled; it is relevant for defense software companies that develop embedded firmware at the hardware abstraction layer for controlled signal processing chips. ECCN 2D002 covers software for certain machine tool control systems used in weapons manufacturing -- less commonly encountered in pure software products but relevant for companies that sell software to defense industrial base manufacturers.

Software that contains modules across multiple ECCN categories requires a component-level analysis. The product's overall export license requirement is driven by the most controlled component, but each component may qualify for different license exceptions. A product with a 5D002 encryption module and a 7D004 navigation module cannot use ENC to license the 7D004 component -- each ECCN has its own set of applicable license exceptions listed in the Commerce Control List entry. For defense software entering formal procurement, the contracting authority will typically require a copy of the product's ECCN classification and applicable license exceptions as part of the technical documentation package.

Deemed export risk: foreign nationals on development teams

The deemed export rule, codified at 15 CFR 734.13(a)(2), treats the disclosure of EAR-controlled technology or source code to a foreign national in the United States as an export to that person's country of nationality. The rule applies to the release of controlled items by "visual inspection, oral exchanges, or the application to situations abroad of personal knowledge or technical experience acquired in the United States." In practical terms, this means that showing a foreign national engineer the architecture of a 5D002-controlled system, giving them read access to a controlled repository, or discussing the technical specifications in a design review is an export event -- one that may require a BIS license before it can legally occur.

The deemed export risk is most acute in development teams that include nationals of countries with restrictive license requirements: China, Russia, and countries subject to comprehensive sanctions are the highest-risk nationalities for EAR-controlled items. However, the deemed export rule applies to nationals of all foreign countries for ITAR-controlled items -- there is no allied-nation exception under ITAR for deemed exports, though there are license exceptions available for nationals of certain treaty allies. A defense software company that grants a British citizen engineer full access to an ITAR-controlled source repository without a DDTC license has committed a deemed export violation regardless of the UK's status as a close US ally.

Mitigating deemed export risk requires a structured access control framework rather than informal assumptions about team members' backgrounds. The framework should identify every controlled item in the development environment, categorize team members by nationality and immigration status, and match access permissions to the license requirements for each item. Foreign nationals who require access to controlled items for legitimate engineering work can be authorized through a BIS deemed export license (formally an "EAR license for release of technology to foreign nationals") or, for lower-level EAR-controlled items, through a license exception such as Technology and Software Unrestricted (TSU) where applicable. The critical failure mode to avoid is retroactive discovery -- learning about deemed export violations during a government audit rather than proactively managing access before the fact.

Building an export control compliance program for a small team

A compliance program does not need to be a large bureaucratic system to be effective. For a software company with fewer than 50 engineers, the core compliance infrastructure consists of four elements: a product classification record, a denied party screening procedure, an access control policy for controlled items, and an annual training requirement. Each of these can be maintained by a single designated export control officer -- typically a senior engineer or general counsel with export control training -- rather than a dedicated compliance department.

The product classification record is the foundation. It documents the ECCN for each software module, the basis for the classification, applicable license exceptions, and the date of the last review. It should be updated whenever a new module is added or an existing module's technical parameters change. A module that starts as EAR99 can become 5D002-controlled the moment a developer adds an AES encryption layer -- and the classification record is the mechanism that captures that change before a sales or partnerships team unknowingly exports the newly controlled item without a license. Becoming a NATO subcontractor as a software vendor typically requires submitting the product's classification record to the prime contractor as part of the supply chain compliance process.

The denied party screening procedure should run automatically for every new customer, partner, and distribution channel. BIS, OFAC, and DDTC maintain separate screening lists; commercial screening tools aggregate all of them into a single API-accessible database. Screening should occur at the point of account creation for SaaS products, at contract signature for on-premise deployments, and at the time of any code or technical documentation transfer to a third party. Records of each screening result should be retained for five years. The access control policy for controlled items in the development environment is the internal-facing counterpart to denied party screening -- it maps controlled items to the personnel authorized to access them, and it should be reviewed whenever a new team member joins or an existing member's immigration status changes.

Consequences of non-compliance and how audits are triggered

BIS conducts export compliance audits through its Office of Export Enforcement (OEE). Audits can be triggered by a tip from a competitor, a suspicious financial transaction flagged by a bank's compliance system, a customs record that does not match an export license, or a review of public records such as patent filings or conference presentations that reveal controlled technical information was released to foreign nationals. The OEE also conducts outreach audits -- voluntary compliance reviews with no finding of wrongdoing -- as part of its education program, and companies that participate proactively in outreach reviews are seen more favorably in subsequent enforcement actions.

EAR civil penalties are assessed per violation and have been adjusted upward under the Federal Civil Penalties Inflation Adjustment Act to exceed $350,000 per transaction as of 2025. For a company that has been making weekly cloud deployments of a 5D002 product to foreign users without an ENC classification for two years, the per-transaction penalty applied to every deployment could produce a theoretical liability that dwarfs the company's total revenue. In practice, BIS negotiates settlements that account for the company's size, good faith compliance efforts, and cooperation with the investigation -- but the theoretical liability figure drives settlement negotiations and can be existential for a startup. Criminal penalties for willful ITAR or EAR violations reach $1 million per violation and 20 years imprisonment, and can be applied to individual executives in addition to the corporate entity.

Voluntary self-disclosure (VSD) is the most powerful tool available to a company that discovers a past violation. BIS's export enforcement guidelines give VSD treatment as a major mitigating factor, and resolved VSDs typically result in no penalty or a substantially discounted civil penalty compared to the penalty for the same violation discovered through enforcement action. The procedure for VSD requires submitting an initial notification to OEE within five days of discovering the potential violation, followed by a complete written report within 60 days. Defense software companies that conduct periodic internal compliance audits and have a documented VSD procedure in place are significantly better positioned to survive a discovered violation than companies that have no compliance infrastructure and no audit trail showing the violation was self-identified rather than caught externally.