Foreign Military Sales for software vendors: navigating FMS and Direct Commercial Sales

Defense software companies building situational awareness platforms, C2 tools, or ISR analytics increasingly find that their most qualified prospects are foreign military customers -- allied and partner nations that are modernizing their forces and are willing to pay for capability that exceeds what domestic defense industries can supply. Two legal channels connect US vendors to those customers: Foreign Military Sales (FMS), where the US government acts as an intermediary and sells on the vendor's behalf, and Direct Commercial Sales (DCS), where the vendor contracts directly with the foreign buyer under an export license. Choosing the right channel -- and understanding what each demands in terms of documentation, compliance obligations, and long-term support commitments -- is as technically demanding as the software itself. This article covers both channels in depth, with particular attention to the export control landscape that governs every defense software transaction.

FMS vs Direct Commercial Sales: which channel fits your product

The structural difference between FMS and DCS determines everything downstream: pricing flexibility, negotiation room, delivery timelines, liability exposure, and the degree to which the US government stands behind the transaction. Under FMS, the foreign government sends a Letter of Request (LOR) to the US Department of Defense, DoD evaluates the request against foreign policy and security criteria, and if approved, DoD issues a Letter of Offer and Acceptance (LOA) to the buying country. The vendor is then contracted by the relevant US military service -- Army, Navy, or Air Force -- not by the foreign customer directly. The US government is the legal seller of record, and the vendor is a subcontractor to that arrangement.

DCS removes the government intermediary. The vendor applies for an export license from the State Department (for ITAR-controlled software) or Commerce (for EAR-controlled software), and upon approval, negotiates and signs a commercial contract directly with the foreign defense ministry or its designated prime contractor. This gives the vendor far more control over pricing, intellectual property terms, and delivery schedules. However, the vendor also assumes the full legal risk of the transaction, including liability for end-use violations and the obligation to conduct its own pre-contract due diligence on the customer's legitimacy and intended use.

The practical decision depends on two factors: the sensitivity classification of your software and the buying country's relationship with US security cooperation programs. Software that is firmly on the US Munitions List (USML) and whose transfer requires Congressional notification above certain value thresholds will almost always travel through FMS -- State Department is reluctant to issue DCS licenses for Category XI (military electronics and software) items when the FMS channel exists and provides stronger government oversight. Newer dual-use platforms with a clear ECCN under the EAR are more viable DCS candidates, particularly for partner nations that have Blanket Purchase Orders or existing DCS frameworks with US vendors. For a software company that has not yet navigated either channel, FMS is the lower-risk entry point precisely because the US military service case manager carries much of the compliance burden.

The Letter of Offer and Acceptance: structure and software-specific clauses

The LOA is the legal instrument that defines what is being sold, at what price, under what conditions, and with what sustainment commitments. For a software product, the LOA structure differs meaningfully from a hardware-only transaction. Hardware lines describe physical end items and associated ammunition or spare parts. A software line must describe an intangible deliverable: a specific version or build baseline, its licensing model, the scope of use rights granted to the foreign customer, and the terms under which updates and patches will be provided during the offer period.

Software-specific LOA clauses that vendors frequently encounter in draft review cover four areas. First, version lock: the LOA will specify the software version being offered, and without an amendment, the foreign customer receives that version and its direct patch lineage -- not a future major release that may carry a different ECCN or require a new policy review. Vendors should negotiate for language that accommodates minor updates within the same version family without requiring a new LOA. Second, sustainment pricing structure: software sustainment is almost always priced as a separately recurring line, typically renewable annually, rather than embedded in the acquisition unit cost. This is operationally correct but requires the vendor to maintain pricing visibility over a five-to-ten-year horizon at the P and A stage. Third, source code access: US government policy uniformly prohibits providing source code access to foreign customers under FMS unless a specific Technology Assistance Agreement (TAA) is negotiated and approved. Vendors should verify that their LOA language explicitly states this restriction rather than leaving it ambiguous. Fourth, third-party license obligations: if your software includes open-source components with copyleft licenses or commercial third-party libraries, the LOA must account for how those licenses pass through to the foreign customer, who takes on the same usage restrictions that apply to any licensee.

The LOA also typically includes a non-recurring engineering (NRE) line if any country-specific customization is required -- localization, interface adaptation for country-specific C2 systems, or integration with legacy infrastructure. Vendors should treat NRE as a separate negotiated item from sustainment, because NRE costs are one-time and their justification requires different documentation than recurring maintenance pricing.

End-use monitoring requirements for exported defense software

The US government maintains two parallel end-use check programs for exported defense items: Golden Scepter for FMS cases and Blue Lantern for DCS-licensed items. Both programs conduct post-shipment verification to confirm that transferred items -- including software -- are being used as authorized, have not been transferred to unauthorized third parties, and are accessible for inspection by US government representatives. For software vendors, these programs create ongoing compliance obligations that extend well beyond the delivery date and require internal record-keeping systems that most commercial software companies do not have by default.

Under Golden Scepter, the Defense Security Cooperation Agency (DSCA) coordinates with the Security Cooperation Office at the US embassy in the buying country to conduct periodic end-use verification. For software, verification typically involves confirmation that the software is installed only at authorized sites, is being used only by vetted personnel with the access level specified in the LOA, and that no unauthorized copies have been distributed. The vendor is expected to cooperate by providing deployment records: installation site addresses, user counts by role, version deployed, and patch delivery history. The frequency of checks is risk-scaled -- higher-sensitivity software in countries with less mature security cooperation histories receives more frequent attention. Vendors who cannot produce adequate records at the time of a check face potential remedial measures including license restrictions on future cases.

A practical complication for software vendors arises when the product uses telemetry, cloud-connected licensing enforcement, or automatic update mechanisms. These features, standard in commercial software, can create inadvertent data flows between the foreign customer's network and the vendor's infrastructure that were not disclosed in the LOA and may violate the buying country's information security policies or, in some cases, US restrictions on transferring data generated by foreign government systems. Before deploying any form of phone-home functionality to a foreign defense customer, vendors should obtain explicit approval from DSCA and from the buying country's security authority, and document the approved data flows in a supplement to the LOA or the Technical Assistance Agreement.

Technology transfer restrictions: what you can and cannot include in an FMS package

Technology transfer restrictions are the most technically consequential constraint that FMS and DCS impose on software vendors. The term "technology" in ITAR and the EAR covers not just source code but also technical data: design documents, architecture diagrams, training data for machine learning models, algorithm specifications detailed enough to allow replication, and operational parameters that characterize the software's performance envelope. Vendors frequently underestimate the breadth of what constitutes controlled technology and inadvertently create compliance exposure by providing detailed technical briefings to foreign customer technical teams without confirming that the briefing materials fall within the scope of the approved export.

For software sold under FMS, the default position is that the foreign customer receives object code (the deployable binary or container image) and user-level documentation only. Source code, training datasets for AI components, model weights for proprietary machine learning elements, and API specifications at the integration level all require separate technology release approvals. Vendors who want to provide these elements -- for example, to enable the foreign customer to develop country-specific integrations -- must request a Release of Technology through the DSCA case manager, who routes the request through the relevant US military service's technology security review process. This review evaluates whether the technology release could enable the recipient to replicate the capability domestically, transfer it to a third country, or derive performance data that would reveal US intelligence priorities.

Third-country transfer restrictions are a related concern. If the buying country deploys the software in a multinational operation where personnel from non-approved countries will have access -- common in coalition environments where allied nations share a common operating picture -- the vendor must verify that the LOA or DCS license covers that disclosure. An FMS case that was approved for Country A's national use does not automatically authorize exposure to Country B's personnel operating alongside Country A's forces. The DSCA case manager can add a third-country transfer provision to the LOA, but this must be requested before the exposure occurs, not after.

In-country support obligations and third-country transfer rules

FMS software cases almost always include a support element that requires the vendor to provide personnel in the buying country. This support takes several forms: initial installation and configuration support delivered at system fielding, operator and administrator training, and ongoing help desk or field service representative (FSR) coverage for the sustainment period. Each of these requires planning well before the LOA is signed, because in-country support personnel face their own compliance requirements that can affect hiring, travel, and security clearance timelines.

Field service representatives working on FMS cases in foreign countries must hold US security clearances at the level required by the system's classification. If the software runs on a classified network in the buying country, the FSR may also require a personnel security determination from the buying country's security authority -- a process that can take three to twelve months and is not guaranteed to succeed. Vendors should identify FSR candidates early and initiate clearance processing in parallel with LOA negotiation rather than waiting for the LOA to be signed. A signed LOA that cannot be executed because the vendor lacks cleared in-country support personnel is a program failure that generates significant relationship damage with both the DSCA case manager and the foreign customer.

Third-country transfer rules also affect in-country support. If the vendor's FSR is a dual national, holds a passport from a country with restrictions in the buying country's security framework, or was born in a country that the LOA designates as a restricted nationality for access to the system, additional approvals are required before that individual can work on the program. These rules are not always documented in the LOA itself -- they are derived from the combination of the buying country's security requirements, the US government's technology release policy for the specific software, and the classification of the network the software runs on. Vendors should request a nationality review from the DSCA case manager as part of pre-deployment planning, not as a last-minute check.

Price and availability requests: how to respond without committing

A Price and Availability (P and A) request arrives from a US military service case manager when a foreign government has submitted a Letter of Request for your software. The P and A response is the basis on which DoD drafts the LOA, which means the numbers you provide at this stage will appear -- often verbatim -- in the legally binding offer to the foreign government. The procedural trap for vendors unfamiliar with FMS is treating the P and A response as a commercial quote subject to negotiation. It is not. Once the LOA is issued to the foreign government based on your P and A data, you are contractually bound to deliver at those terms if the customer accepts.

The correct approach to a P and A response is to provide your best estimate of costs with explicit assumptions documented in the response -- software version, licensing model, user count, training scope, sustainment period, and any country-specific customization scope. If any cost element depends on a requirement that has not yet been defined (for example, the number of installation sites), flag that dependency explicitly and provide a range or a per-unit rate rather than a total. DSCA case managers understand that software pricing has variable components and will incorporate your assumptions into the LOA as footnotes that qualify the pricing. This protects you if the actual deployment scope differs from the P and A assumptions.

Vendors should also address software sustainment pricing for a minimum five-year horizon in the P and A response, even if the initial request covers only a two-year period. Foreign customers routinely extend sustainment cases, and DSCA case managers prefer to structure the initial LOA with renewal options rather than process separate amendment cases each year. Providing a structured sustainment pricing schedule -- with defined escalation rates and clear definitions of what is included at each tier -- makes your product easier to manage through the FMS system and reduces the administrative burden that discourages repeat business through the channel.

Building relationships with the in-country program office and the US country team

The FMS process is formally government-to-government, but the outcomes -- which products get written into Letters of Request, which vendors are included in P and A cycles, and which sustainment cases get funded -- are shaped by relationships built well before any formal process begins. The two key relationship nodes for a software vendor are the foreign country's program office and the US Security Cooperation Office (SCO) at the American embassy in the buying country.

The in-country program office is the technical authority that defines requirements, evaluates competing solutions, and advocates internally for funding to execute an FMS case. For defense software, the program office typically sits within the defense ministry's J6 (communications and information systems) or equivalent directorate, or within a specialized capability directorate for ISR, logistics, or C2. Vendors who have demonstrated capability to the program office before the LOR is submitted -- through demonstration events, assessments funded by the US government's Building Partner Capacity programs, or participation in bilateral exercises -- have a significant advantage in shaping the requirement document to match their product's architecture. This is not manipulation of the process; it is the standard way that capable vendors establish technical credibility with foreign customers in advance of a formal acquisition.

The SCO is the US government's link between the buying country and the DoD FMS system. SCO officers are typically Army, Navy, or Air Force personnel assigned to the embassy for two-to-three-year tours. They coordinate Letters of Request, facilitate P and A cycles, and manage the relationship between the foreign ministry and the DSCA case manager in Washington. Building a productive working relationship with the SCO means keeping them informed of your product roadmap, flagging capability updates that might address emerging customer requirements, and providing technical support for assessments that the SCO facilitates. Vendors who treat the SCO as an administrative relay rather than a substantive partner miss the opportunity to shape how their product is positioned within the country's broader security cooperation portfolio. For a software company pursuing multiple FMS cases across several countries, the SCO network is a distribution channel as much as it is a compliance interface -- and investing in those relationships is one of the highest-return activities available to a defense software company working its way through the procurement cycle.