How should organisations decide whether ITAR or EAR applies to a technology?

How to determine the governing control regime

ITAR and EAR turn on different jurisdiction tests, so the first task is to classify the item, technical data, software, or service against the relevant control list rather than starting from business intent. In practice, that means looking at whether the technology is defense-oriented or instead falls under commercial export controls, then testing the exact facts that create jurisdiction.

The classification step matters because the same technology can sit in a different regime depending on what it is, how it is described, and what controlled performance it provides. Teams should separate product marketing language from the technical record, because the decision has to stand up to review, audit, and potential government scrutiny.

Why formal classification is better than an informal guess

Organisations should treat the jurisdiction call as a controlled compliance decision, not an engineering opinion. A rushed answer can lead to the wrong license path, missed restrictions on reexport or transfer, and inconsistent handling across engineering, legal, procurement, and operations.

When the item is not plainly listed, the right move is to use the formal jurisdiction or classification request process and preserve the rationale that was used. That is especially important for dual-use technology, integrated systems, controlled software, and technical data that may appear ordinary until the exact function, performance, or end use is tested against the lists.

What good decision-making looks like in practice

Good practice is to build a repeatable review process that starts with technical description, then moves to list screening, then to documented escalation when the result is uncertain. The best decisions are tied to version-controlled records, named reviewers, and an explicit owner for the final classification.

Teams should also verify that classification is done at the right level of granularity. A whole platform may not be controlled in the same way as a component, module, file, or service package, so the decision should distinguish what is actually being exported, shared, or transferred. NIST Cybersecurity Framework 2.0 is useful here as a governance anchor because the activity depends on clear ownership, repeatable processes, and documented decisions.

Risk and Threat Considerations

The main risk is misclassification, which can create unlawful transfer, licensing failure, delayed shipments, contractual breach, or an inability to prove why a control decision was made. In cross-border programs, the impact is magnified because one incorrect jurisdiction call can propagate into trade, engineering, and vendor workflows.

Failure mechanism: Teams infer the regime from broad product category, customer need, or the most restrictive interpretation they have seen before, instead of testing the actual item against the relevant control criteria. That often leads either to over-restriction, which slows legitimate work, or under-control, which exposes the organisation to compliance and enforcement risk.

Impact: The organisation can apply the wrong authorization path, fail to obtain required approvals, and lose confidence in downstream screening, licensing, and recordkeeping. EU NIS2 Directive and similar governance regimes are a reminder that documented control decisions and accountable ownership are central when regulated obligations depend on precise classification.

Practitioner Guidance

What to prioritise: Put the technical classification step ahead of licensing discussion, because license analysis is unreliable until the item, data, or service is correctly placed.

What to verify: Keep evidence for the item description, technical characteristics, the list checks performed, the reviewer, and the date of the decision. If the case is ambiguous, require a formal ruling path rather than an email consensus.

Decision rule: If the item clearly fits the relevant list, proceed on that basis; if not, do not force a conclusion from analogy. When facts are incomplete, treat uncertainty as a reason to escalate, not as a reason to guess.

Practitioner takeaway: The strongest control is not memorising the regimes, it is making the jurisdiction decision reproducible, reviewable, and tied to the exact technical facts that drive it.

Related resources from NHI Mgmt Group

• How should security and compliance teams decide whether a data flow falls under EAR or ITAR controls?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?