The dual-use concept — technology that serves both civilian and military purposes from a common technical base — has been a feature of defence technology since the invention of radar. In software, the dual-use opportunity is particularly significant because the marginal cost of serving multiple markets from a common codebase is relatively low, while the strategic and commercial benefits are substantial. Despite this, most defence software companies define themselves as either "defence" or "commercial" and miss the structural advantages that a genuine dual-use positioning provides.
Understanding what dual-use means in practice — as distinct from the marketing assertion that any capable software can serve both markets — requires clarity about the architectural decisions, regulatory implications, and investor positioning that distinguish genuinely dual-use products from products with a dual-use veneer.
What Dual-Use Is and Why It Matters for Funding
The dual-use concept originated in export control regulation, where it describes goods and technologies that have significant applications in both civilian industries and military applications. The EU Dual-Use Regulation defines dual-use items as "items, including software and technology, which can be used for both civil and military purposes." This regulatory definition creates obligations — dual-use items are subject to export authorisation requirements — but also creates a category of technology that is explicitly recognised as serving both markets legitimately.
For funding purposes, dual-use positioning is increasingly a requirement rather than an advantage. The two most important sources of defence-relevant early-stage capital in Europe — the NATO Innovation Fund and the EU European Innovation Council (EIC) — both explicitly require or strongly prefer dual-use technology positioning. NIF's investment thesis is centred on dual-use deep technology, and the EIC's defence-relevant calls explicitly require that funded technologies have both civilian and military applications. Pure defence plays — technology with no credible civilian application — face significantly higher barriers to accessing these funding mechanisms.
Beyond these specific programmes, the general venture capital market for defence technology has shifted toward dual-use positioning over the past five years. Commercial VCs that were previously uncomfortable with defence exposure are increasingly willing to invest in dual-use companies, because the commercial market provides a near-term revenue story independent of the slow-moving defence procurement cycle. Companies that position purely as defence technology companies are still able to raise from defence-focused VCs, but the pool of available capital is smaller and the valuations achievable are lower.
Examples of Dual-Use in Software: Data Fusion, Edge AI, Cybersecurity
Data fusion platforms are perhaps the clearest example of dual-use software. A data fusion engine that ingests heterogeneous data streams, normalises them to a common format, and produces an integrated operational picture is valuable in defence (situational awareness, intelligence analysis) and in commercial contexts (emergency services coordination, logistics operations, critical infrastructure monitoring). The core technical capability — ingesting, normalising, correlating, and visualising multi-source data — is the same in both contexts. The domain-specific layers (military data formats, security classification handling, operational picture conventions in the defence case; civilian data sources and commercial visualisation in the commercial case) differ, but they can be implemented as configurable layers on a common technical base.
Edge AI is another inherently dual-use capability. The ability to run AI inference models on constrained hardware at the point of data collection — without requiring cloud connectivity — is valuable in defence (tactical edge computing, forward-deployed ISR), in industrial IoT (factory floor monitoring, predictive maintenance), in healthcare (medical device AI, remote diagnostics), and in autonomous vehicles (on-board perception and decision systems). Companies building edge AI infrastructure that can deploy and manage models across distributed fleets of edge devices are building dual-use technology whether or not they define themselves that way.
Cybersecurity is the category where dual-use is most explicitly recognised by the market. Intrusion detection, vulnerability management, identity and access management, and network monitoring tools serve both civilian enterprises and military networks, often with minimal modification. The primary difference is in the classification and certification requirements applied to military deployments — the underlying technical capabilities are the same. Companies that have built cybersecurity products for regulated commercial sectors (financial services, healthcare, critical infrastructure) have demonstrated technical capabilities and compliance readiness that translate directly to military cybersecurity requirements.
Architectural Decisions That Support Both Markets
Building genuinely dual-use software — not just claiming dual-use positioning — requires specific architectural decisions that enable the same technical base to serve both markets effectively. The most important are:
Security-level parameterisation. Military deployments require security features (encryption standards, access control, audit logging, data classification labelling) that are typically more stringent than commercial requirements. Building these features as parameterisable capabilities — configurable to the required level rather than hardcoded to either military or commercial standards — allows the same codebase to be deployed at the appropriate security level for each customer. A system hardcoded for military security requirements is over-engineered for commercial customers; a system hardcoded for commercial requirements is insufficient for military deployments. Parameterisation avoids both problems.
Offline-first architecture. Military deployments frequently require the ability to operate without network connectivity. Commercial deployments in industrial or remote environments often have the same requirement. Designing for offline-first from the outset — with a local data store that functions independently of network availability, and synchronisation logic that manages updates when connectivity is restored — serves both markets simultaneously without requiring separate code paths.
Multi-tenancy with isolation controls. Commercial SaaS deployments typically use multi-tenant architecture where multiple customer organisations share the same infrastructure. Military deployments may require dedicated infrastructure or at minimum strong logical isolation between different classification levels. Building multi-tenancy with configurable isolation controls — from full multi-tenancy to dedicated single-tenant deployment — allows the same codebase to be deployed appropriately for each market without a full re-architecture for each deployment model.
Key insight: The test of genuine dual-use positioning is not whether you can claim that your technology serves both markets — it is whether you have actually sold to customers in both markets. Investors, procurement organisations, and funding bodies have all become sophisticated about the difference between dual-use positioning and dual-use traction. The former is easy; the latter requires deliberate commercial strategy and execution.
Regulatory: Export Control and ITAR Implications for Dual-Use Products
Dual-use products occupy a specific regulatory position that requires proactive management. In the EU, products on the EU dual-use control list require export authorisation when exported outside the EU. The EU Dual-Use Regulation (2021/821) updated the control list and the procedures in 2021, with particular attention to cyber surveillance technologies and AI capabilities. Software vendors should obtain an export control legal opinion for their products early in the commercial development process — ideally before first export to a non-EU customer — to determine which EU dual-use control list entries apply and what authorisation procedures are required.
For the US market, EAR (Export Administration Regulations) rather than ITAR typically applies to dual-use software, unless the software contains specific military application modules that would bring it onto the US Munitions List. EAR's licence exception for encryption products (ENC) provides a relatively streamlined authorisation pathway for software that includes cryptographic functionality, which covers most modern security-relevant software. Companies planning significant US market development should obtain a US export control review early to determine whether EAR or ITAR applies and what the compliance requirements are.
The regulatory complexity of dual-use export control is manageable — hundreds of companies navigate it successfully every year — but it requires deliberate attention and qualified legal support. The consequences of inadvertent export control violations are serious: criminal liability, administrative penalties, and loss of export privileges. Building export control compliance into the commercial operations process from the outset is significantly cheaper than retrofitting it after an enforcement action.