What is the difference between ITAR and EAR for defense related products and software?

ITAR covers defense articles, services, technical data, and software that appear on the United States Munitions List. EAR covers commercial and dual use items that may have civilian and military applications but are not USML covered. The distinction matters because it determines jurisdiction, licensing expectations, and which agency oversees export control compliance.

How ITAR and EAR Split Defense and Dual-Use Export Controls

ITAR is the tighter regime for items that are specifically defense-related and listed on the United States Munitions List, while EAR governs commercial and dual-use products and software that have both civilian and military potential but are not USML-listed. The practical effect is that the item’s classification determines jurisdiction, licensing path, and the level of export-control scrutiny.

That distinction is not just legal paperwork. It changes how teams classify software, technical data, source code, and services, and it affects whether a release can move under a relatively flexible export-control process or requires defense-export handling with stricter restrictions and fewer assumptions.

Why the Classification Boundary Matters for Software and Technical Data

For software, the boundary is often more important than the code itself. A commercial product may fall under EAR even if it is used in a defense workflow, but software that is specially designed, developed, configured, adapted, or modified for a defense article can fall under ITAR. The same logic extends to technical data, documentation, and support that can export controlled know-how even when no hardware ships.

That is why classification has to happen before packaging, publication, and release. If a team treats all controlled material as a generic export issue, it can over-restrict ordinary commercial software or, worse, under-control defense-specific data. Good export-control practice starts with item classification, then maps that classification to distribution rules, licensing review, and access controls.

For practitioners managing related engineering, supply-chain, or security obligations, the EU Cyber Resilience Act is a useful reminder that software governance increasingly includes lifecycle obligations, documentation discipline, and secure-by-design expectations even outside export-control law.

Jurisdiction, Licensing, and Compliance Workflow Differences

ITAR and EAR differ most sharply in who oversees compliance and what kind of authorization is expected. ITAR is administered by the State Department and is generally more restrictive, especially for defense articles and associated technical data. EAR is administered by the Commerce Department and is built around item classification, control reasons, destination, and end use, which gives it broader coverage but typically more flexibility for commercial and dual-use items.

In practice, that means the compliance workflow is not the same. Teams need a reliable classification record, a review path for borderline items, and a process for determining whether a transfer is an export, reexport, or deemed export. For software and source code, distribution method matters as much as content, because cloud hosting, collaboration platforms, customer access, and contractor access can all create controlled transfer questions.

The control environment should support traceability. NIST SP 800-53 Rev. 5 is a useful reference point for access control, system integrity, auditability, and configuration management because export-controlled material must be discoverable, protected, and reviewable rather than simply “known to be sensitive.”

For stronger identity and access discipline around controlled technical material, NIST SP 800-53 Rev 5 Security and Privacy Controls is the most directly relevant control catalog in the supplied set, and NIST Cybersecurity Framework 2.0 is helpful where teams need a broader governance structure for identifying and protecting sensitive exports.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Export-controlled data needs tightly limited access and reviewable handling.
	AU-2 — Event Logging	Classification and export handling need auditable records of access and release actions.
Recommendation — Restrict access to controlled technical data and source code to the minimum authorized set. Log classification, access, and release events for controlled items.
ISO/IEC 27001:2022	A.5.15 — Access control	Export-controlled material needs access rules tied to classification and handling constraints.
Recommendation — Apply access rules that match the item's export-control classification.
NIST CSF 2.0	GV.RM-01 — Risk Management Roles, Responsibilities, and Authorities	ITAR/EAR decisions require clear ownership for export-control risk decisions.
	PR.AA-05 — Identity Management, Authentication, and Access Control	Controlled software and technical data must be protected through governed access.
Recommendation — Assign clear ownership for export-control classification and escalation decisions. Enforce authenticated, role-based access for controlled export material.

Practitioner Guidance

What to verify: Classify the item first, then verify whether the controlled element is the hardware, embedded software, source code, technical data, or a service relationship. The common mistake is assuming “defense customer” automatically means ITAR, or assuming “commercial software” automatically means EAR.

Implementation sequence: Start with a written classification record, then connect that decision to release approval, access restrictions, customer screening, and retention of export review evidence. If the item can be shared through code repositories, ticketing tools, or collaboration platforms, treat those channels as compliance surfaces, not just convenience tools.

Decision rule: If a product is specifically designed or adapted for a defense article or contains controlled technical data, elevate the review and apply the stricter handling path. If it is genuinely commercial or dual-use and not USML-covered, EAR usually becomes the governing framework, but destination and end-use still matter.

Practitioner takeaway: The real control point is not the label on the product, it is whether the item’s design, data, and distribution path place it under the defense-export regime or the broader dual-use regime.