This article is not legal advice. Nothing here constitutes a legal opinion or replaces consultation with a qualified ITAR/EAR counsel. Export control law is fact-specific; what applies to our hardware configuration may not apply to yours. Treat this as a practitioner's orientation to the terrain, not a compliance roadmap.
When we started building underground sensor-effector hardware, the export control question surfaced faster than we expected — not at the point of sale, but during the hiring process. One of our early engineering candidates held dual citizenship. That conversation forced us to think seriously about deemed export rules before we had a single completed prototype. If you're building in this space, you'll hit the same wall, probably sooner than you expect.
The core problem with underground threat detection hardware is that it lives in a regulatory grey zone. The technology is dual-use almost by definition: seismic sensors, ground-penetrating radar modules, and acoustic arrays all have commercial applications in geophysical surveying, mining, and civil infrastructure inspection. But when those same sensors are packaged for persistent autonomous deployment in security-critical environments, the classification question becomes genuinely ambiguous.
USML vs. CCL: The Threshold Question
The United States Munitions List (USML) governs items controlled under the International Traffic in Arms Regulations (ITAR), administered by the State Department's Directorate of Defense Trade Controls (DDTC). The Commerce Control List (CCL) governs items under the Export Administration Regulations (EAR), administered by the Bureau of Industry and Security (BIS). The two regimes overlap, conflict, and require separate registration frameworks.
For underground sensing hardware, the relevant USML category is Category XII — Fire Control, Range Finder, Optical and Guidance and Control Equipment. Specifically, USML XII(c) covers detection and countermeasure equipment, and XII(e) covers sensors designed for military application. The tricky language is "designed for" — because a geophone array designed and marketed for commercial seismic surveying is CCL-controlled (likely ECCN 6A002 or 6A003), but the same hardware reconfigured with military-grade timing, encrypted telemetry, and persistent autonomous deployment characteristics may cross into USML territory depending on how the end-use is framed.
The 2018-2020 Export Control Reform (ECR) initiative moved a significant number of items from USML to the CCL "600 series" entries (ECCNs ending in .a1, .b1, etc.), but the boundary for active sensing hardware remains contested. If your system includes components that appear on USML Category XII even as sub-assemblies — certain types of acoustic transducers designed for military application, specific inertial measurement units, or radar modules with pulse characteristics exceeding commercial bands — you may find yourself with a USML-controlled article even if the finished system was designed for law enforcement or border security rather than warfighting.
DDTC Registration and When It Triggers
If you manufacture or export USML-controlled defense articles, you are required to register with DDTC under 22 CFR Part 122 regardless of whether you have completed any transactions. Registration is not export authorization — it's the prerequisite. The annual registration fee for manufacturers and exporters is currently $2,250 for the first year of a new registration, and it commits you to maintaining certain recordkeeping and compliance obligations from day one.
The registration question matters even for early-stage companies because "manufacture" under ITAR is interpreted broadly. Designing a defense article, even without physical production, can constitute manufacturing under DDTC interpretation. We sought legal counsel before our first prototype build specifically to understand whether our design activities triggered registration obligations. We're not saying our answer is your answer — the facts of your system matter enormously here.
One specific trigger to watch: if you receive DoD funding — SBIR/STTR awards, AFWERX grants, or direct contract R&D — the contracting officer will typically require DDTC registration as a condition. This is frequently the first hard forcing function for early-stage defense tech companies. The administrative burden of maintaining ITAR registration while still doing prototype-level engineering should not be underestimated. DDTC audits are rare for small companies, but the recordkeeping requirements — technology control plans, training documentation, visitor logs — create ongoing overhead that your team needs to actually absorb.
Technology Control Plans for Multinational Teams
The deemed export rule under both ITAR and EAR is the provision most likely to catch small engineering teams off guard. A deemed export occurs when controlled technology is released to a foreign national within the United States — through disclosure, demonstration, or access to technical data. Under ITAR, releasing USML-controlled technical data to a foreign national requires either an export license or a license exemption, regardless of geography.
For a small team doing embedded systems work, this is not theoretical. Your engineers read datasheets, collaborate on system architecture documents, and access firmware repositories. If any of those activities involve USML-controlled technical data and any team member is a foreign national without the appropriate license or exemption, you have a potential deemed export violation.
The standard mechanism to manage this is a Technology Control Plan (TCP). A TCP defines which technical data in your organization is controlled, who is authorized to access it, physical and digital access controls, and training obligations. The State Department does not maintain a public template for a TCP — the content requirements derive from 22 CFR Part 120-130 and are interpreted through practice. A TCP for a five-person hardware team looks different from one for a fifty-person company, but both need to be functional documents, not paper exercises.
Practical elements we've found necessary in our own TCP development: clear data classification tiers mapped to USML/CCL categories, a repository access policy that separates controlled from non-controlled technical data, onboarding documentation that addresses foreign national status, and periodic training with sign-off. None of this is exotic — it's administrative infrastructure that takes real time to build and maintain.
EAR and the CCL Path for Dual-Use Hardware
If your hardware classification analysis concludes that your article is EAR-controlled rather than ITAR-controlled, you're working under a different (and generally less restrictive) framework. The EAR is administered by BIS under 15 CFR Parts 730-774. Items on the CCL are assigned an Export Control Classification Number (ECCN); items not specifically listed are classified as EAR99, which requires no license for most destinations but remains subject to end-use and end-user controls.
For underground sensing hardware, the likely CCL categories are 6A002 (acoustic and optical sensors not specifically designed for military use), 6A003 (cameras and imaging systems), and potentially 6E001/6E002 (technology for development or production of CCL-controlled sensing equipment). The 600 series ECCNs — 6A615, 6E615 — cover military-grade variants that escaped USML reform but remain tightly controlled for export.
The key practical difference between ITAR and EAR for a small company is that EAR does not have the same registration requirement structure. You don't need to register with BIS to manufacture EAR-controlled items the way you must register with DDTC for USML articles. This matters for early-stage operational simplicity. However, EAR still imposes license requirements for many country destinations, and the end-use certificate requirements for dual-use military items under EAR Part 748 are non-trivial.
A Realistic Compliance Timeline
Based on our experience building in this space, here is a rough sequence of when export control decisions become forcing functions for a hardware-focused startup:
- Pre-prototype design phase: Classify your core technical data. Determine whether you have USML-controlled articles at the design level. This requires legal counsel — not a commodity review, but a qualified practitioner who understands the hardware domain.
- First hire with foreign national status: Deemed export analysis is mandatory before that person accesses any controlled technical data. TCP development should be underway before the first onboarding.
- First government funding application (SBIR/STTR, AFWERX, etc.): DDTC registration is typically required. Budget 60-90 days for the registration process, more if your application has complexity.
- First engagement with non-US entities (potential customers, partners, distributors): Export license or exemption analysis required before any technical data exchange. "Just a capability overview" is not a safe category — any technical data about USML-controlled articles requires authorization.
- First international conference presentation: If your presentation includes USML-controlled technical data, the public domain exemption under 22 CFR 120.11 may apply — but you need to confirm this before submitting an abstract, not after.
We're not saying the ITAR compliance burden is a reason not to build in this space. It is a reason to engage legal counsel early and to treat export control infrastructure as part of your product development overhead rather than an afterthought. The companies that get into trouble are almost always the ones who delayed the classification question because the hardware wasn't "really" defense-focused yet.
What We Haven't Resolved
To be direct about our own situation: we have ongoing ambiguity around exactly where certain components of our sensor-effector integration sit on the USML/CCL boundary. The effector side of the system — the autonomous response architecture — introduces classification complexity that doesn't exist for a pure sensing product. We're working through that with counsel and do not claim to have a definitive answer. Anyone building hybrid sense-and-respond systems in this domain will face the same open question.
The right stance is not to wait for certainty before registering and building compliance infrastructure. The right stance is to engage the process early, document your reasoning, and build the administrative backbone that lets your engineers work without constant interruption from compliance questions they're not equipped to answer themselves.
Again: nothing in this article is legal advice. The classification of your specific hardware under ITAR/EAR is a legal and factual question that requires qualified counsel. This is a field notes entry, not a compliance guide.