Epirus: Directed Energy Weapons and the Systems Engineering of New Physics Domains

When a kinetic weapon fails to defeat a target, the failure mode is usually legible. The projectile missed, or the warhead didn’t detonate, or the armor held. The physics are violent but interpretable, and decades of test infrastructure exist to characterize them. When a high-power microwave weapon fails to defeat a target, the failure mode might be that the target’s electronics were simply more hardened than expected, or the geometry was wrong, or atmospheric absorption was higher than modeled, or the dwell time was insufficient — and you may not know which. That ambiguity is not a gap in Epirus’s engineering. It is the foundational challenge of directed energy as a weapons category, and understanding it illuminates why Epirus’s approach to systems engineering is genuinely novel rather than conventionally incremental.

What Epirus Builds

Epirus, founded in 2018 and headquartered in Los Angeles, is the company behind Leonidas — a solid-state, high-power microwave (HPM) system designed for counter-unmanned aerial systems (C-UAS) applications. Leonidas uses a phased-array antenna to direct high-power microwave energy at drone targets, inducing effects on their electronics that range from temporary disruption to permanent damage. The system is designed to be mobile, palletized for ground vehicles, and capable of engaging multiple targets in a swarm without the per-shot cost constraint of kinetic interceptors.

Epirus has secured contracts with the U.S. Army and has positioned Leonidas as a scalable, software-defined platform — meaning beam parameters, waveform characteristics, and engagement protocols are substantially software-controlled rather than fixed in hardware. That design choice has significant systems engineering consequences: it extends the requirements problem into the software domain and raises questions about configuration management that don’t arise for a system whose physics are fully determined at manufacture.

The company’s engineering leadership has spoken publicly about the importance of software-definability as a path to rapid capability updates. In a domain where the threat envelope (drone swarms, electronic countermeasures on UAS platforms, varying target hardening levels) is evolving faster than traditional acquisition cycles, that flexibility has operational value. It also means the requirements baseline is perpetually in tension with the threat model it’s meant to address.

The Verification Problem No One Talks About Clearly

Every systems engineer working in defense knows the structure: the system shall achieve [effect] against [target] under [conditions]. The requirement is verifiable if you can design a test that produces a pass or fail outcome. For kinetic weapons, this structure works reasonably well. You test against a defined target set under defined conditions, and you have a probability of kill (Pk) metric against which acceptance criteria can be written.

For HPM weapons, the structure strains immediately. The effect on a target’s electronics depends on:

• The coupling efficiency between the HPM field and the target’s antenna apertures and cable harnesses — which varies by target design, orientation, and even manufacturing tolerance
• The susceptibility thresholds of the target’s electronic components — which are determined by the adversary’s procurement choices, component sourcing, and hardening decisions
• The path loss and atmospheric absorption between aperture and target — which is environmental and varies with range, humidity, and terrain
• The accumulated effect of prior engagements — a target that has received partial HPM exposure may have components degraded but not failed, altering susceptibility for subsequent pulses

Writing a verifiable requirement against this input space is not impossible, but it requires a level of conditional framing that conventional requirements tools and templates are not designed to support. A requirement of the form “the system shall disrupt UAS flight control within N seconds at range R” is only meaningful if the target characteristics are bounded — and in operational reality, they are not bounded in any way the system designer controls.

The honest engineering response is probabilistic requirements against a characterized threat set: “the system shall achieve disruption with probability ≥ P against targets within susceptibility class S under atmospheric conditions C.” That framing is more intellectually honest, but it immediately raises questions about how class S is defined, who authorizes changes to the threat set definition, and how you test against a probabilistic acceptance criterion without prohibitively large sample sizes.

This is the requirement structure problem that Epirus, and the directed energy community more broadly, is actively working through. It is not solved. It is being solved in parallel with deployment, which is itself an unusual engineering posture.

Beam Control: Requirements at Multiple Physics Levels

Setting aside effects on the target, beam control requirements for a phased-array HPM system must encode physics at several levels simultaneously, and the interactions between levels are non-trivial.

At the aperture level, the requirement is about forming and steering a beam with specified sidelobe characteristics and main-lobe gain. This is well-understood antenna engineering. Phased array design is mature, and the requirement structures inherited from radar and EW systems apply reasonably well here.

At the propagation level, the requirement must account for how the beam behaves between aperture and target. Free-space path loss is straightforward. Atmospheric effects — particularly at higher microwave frequencies — are more complex and operationally variable. The system must maintain adequate field strength at the target across the environmental envelope the operator will actually use it in. Writing that requirement means defining the environmental envelope, which in a deployed military system means something like “all conditions in which the system will be employed” — a specification that is operationally meaningful but technically unbounded.

At the engagement level, the requirement must specify how the system manages beam dwell, scan patterns for multi-target engagements, and handoff logic when target tracks merge or diverge. Drone swarm scenarios introduce combinatorial complexity here: the beam scheduling problem for a 20-drone swarm is qualitatively different from a single target engagement, and the requirement structure needs to reflect that the system’s effectiveness against individual targets degrades as swarm size increases.

Software-definability complicates all three levels. If beam parameters are software-configurable, then requirements on beam control are requirements on a software system as much as an RF system. The configuration space needs to be bounded in requirements — you cannot verify a system that can be configured to operate in arbitrarily different modes.

Safety Constraints: Invisible Boundaries

For a kinetic weapon, safety is largely geometric. The hazard exists at the point of impact and in the blast radius. The geometry is defined by physics. Engineers can draw a line on a map and say: inside this boundary, there is hazard; outside it, there is not.

For an HPM weapon, the hazard boundary is defined by the intersection of the beam pattern, the field strength at range, and the biological or electronic susceptibility thresholds of whatever is in the beam path. The beam is invisible. It propagates at the speed of light. It does not leave a visible signature that personnel can use as a cue for safe standoff distance.

This creates a safety requirements problem with no direct kinetic analog. The system must prevent engagement geometries that would expose friendly personnel or protected assets to harmful field levels — but the system itself is the only entity with the information needed to assess whether a given geometry is hazardous. Safety interlocks must be implemented in the same software-defined architecture that controls engagement parameters.

The personnel protection requirements for directed energy weapons draw on exposure limits developed in the RF safety community — IEEE C95.1 and related standards provide biologically-derived thresholds for continuous and pulsed RF exposure. But these standards were developed for occupational and general population exposure, not for the operational context of a deployed weapon system with dynamic geometry and mixed friendly/hostile populations in the engagement space. Applying them to a weapon system requires engineering judgment about how to translate population-level exposure standards into real-time engagement constraints, and that translation is not standardized.

Building Process Without Precedent

What makes Epirus’s engineering challenge distinctively difficult is the absence of institutional infrastructure. When a new aircraft enters development, the MIL-SPEC ecosystem provides tested requirement templates, qualification test procedures, failure mode libraries, and a community of practice that has worked similar problems. When a new directed energy weapon enters development, most of that infrastructure does not exist in mature form.

The effects characterization data needed to write verifiable requirements is classified, sparse, and not reproducible on commercial test ranges. The threat models needed to define the target susceptibility classes are intelligence products, not engineering documents. The test infrastructure for HPM effects is limited in the United States and largely unavailable to commercial contractors without specific facility access.

Epirus has navigated this by being explicit about the iterative nature of their engineering process. Their software-defined architecture is partly an RF design choice and partly an acknowledgment that the requirements will change as more effects data is generated and as the threat evolves. Build-measure-update cycles that are anathema to traditional defense acquisition are structurally necessary when the domain knowledge required to write stable requirements is still being accumulated.

This creates a tension with the contractual structures that govern defense acquisition, which are designed for requirements-driven development. Epirus has had to work within acquisition frameworks that assume requirements stability while operating in a domain where that stability is not achievable. How they have navigated that tension — through phased deliveries, capability thresholds and objectives framing, and close integration with operational test communities — reflects the kind of process engineering that doesn’t appear in technical papers but is where the real engineering work happens.

What This Means for the Directed Energy Field

Epirus is not the only company working directed energy, but Leonidas is the most visible ground-based HPM system in current U.S. military fielding discussions. The engineering challenges Epirus faces are not company-specific — they are domain-specific. Any organization developing HPM, high-energy laser, or other directed energy systems will encounter versions of the same problems: probabilistic effects against unknown targets, physics-level requirements at multiple coupled layers, invisible safety boundaries, and limited institutional precedent.

The directed energy community is building that institutional infrastructure now, partly through accumulated test data from systems like Leonidas, partly through evolving standards work in the defense standards community, and partly through operational experience from deployed systems. That process is slow relative to the pace at which the counter-drone threat is evolving, which creates pressure to deploy and learn rather than fully characterize and then deploy.

The requirement structure problem in particular is likely to push directed energy developers toward more explicit probabilistic and model-based requirements frameworks — approaches that treat system performance as a distribution over a threat space rather than a deterministic value against a fixed target. Tools and processes that can represent and manage that kind of requirement, trace it through design, and connect it to test results without collapsing the probabilistic framing into a false binary are not yet standard in the defense acquisition ecosystem. Developing them is the systems engineering work that will define the maturity of directed energy as a weapons category.

Honest Assessment

Epirus is doing technically serious work in a domain where the easy path — adopting conventional requirement structures and hoping the physics cooperates — would produce a system that looked verifiably compliant on paper and was operationally unpredictable in the field. Their willingness to build engineering process iteratively, to be explicit about the probabilistic nature of HPM effects, and to design software-definability into the platform as a hedge against requirement instability reflects sound engineering judgment.

The limitations are real. Leonidas operates in a threat environment where adversary drone hardening decisions can shift the effectiveness envelope faster than the acquisition cycle can respond. The safety interlock problem is genuinely unsolved at the standards level, which means every deployment involves engineering judgment in a domain where the consequences of a wrong judgment are severe. And the absence of institutional precedent means that engineering process built now will need to be rebuilt as the domain matures — the standards, test procedures, and requirement templates that Epirus is contributing to developing will eventually displace the ad hoc approaches that were necessary to get to first fielding.

That is not a criticism. That is what it looks like to engineer at the frontier of a new physics domain. The harder question — one that Epirus cannot answer alone — is whether the institutional infrastructure needed to mature directed energy as a weapon category is being built fast enough to keep pace with the operational need. The engineering of Leonidas is ahead of the engineering ecosystem it requires.