For decades, defense software selection has been driven primarily by technical criteria: can the platform meet hard real-time requirements, does it carry a credible certification pedigree, can it support mixed-criticality workloads, and can the supplier sustain the product for the life of the platform? Those questions remain essential. But as defense systems become more software-defined, another question is moving to the center of program-risk discussions: who ultimately owns and controls the company behind the software?
That is not a question about corporate nationality, and it is not an argument that foreign-owned technology companies cannot serve U.S. defense customers. Many do and do it well. The point is narrower: ownership, control, governance, access, and long-term decision rights become material when a supplier underpins sensitive or classified programs. In that context, Foreign Ownership, Control, or Influence — FOCI — is not an abstract compliance topic. It shapes how a company is structured, how work is performed, what information can be accessed, and how government customers evaluate risk.
Why FOCI Matters
FOCI oversight exists because national security programs need confidence that protected information, sensitive technologies, and critical operational decisions are insulated from inappropriate foreign influence. The concern is not that a foreign parent is untrustworthy. It is that the government needs to understand where authority resides, how decisions are made, who can access sensitive information, and whether ownership could create pathways of influence inconsistent with national security requirements. This is formalized under the National Industrial Security Program (32 CFR Part 117, the former NISPOM), administered by the Defense Counterintelligence and Security Agency.
For a software supplier, those questions reach well beyond the handling of individual classified documents. They touch product roadmaps, engineering priorities, cybersecurity response, maintenance, intellectual property, staffing, infrastructure, and where investment flows. That matters because the software foundation of a mission system is rarely a short-term purchase — it can stay embedded in an aircraft, spacecraft, or weapon system for decades. A program office therefore must weigh not only what a product does today, but the organization that will maintain, secure, certify, and evolve it across the full lifecycle. Viewed that way, corporate structure becomes one component of technical and programmatic risk.
Software Is Now Strategic Infrastructure
This matters more each year because software itself has become strategic infrastructure. Modern platforms rely on software to enforce safety boundaries, isolate workloads, connect sensors and mission applications, manage cybersecurity domains, orchestrate heterogeneous compute, and increasingly run AI at the edge. The operating system, hypervisor, separation kernel, and their certification artifacts are no longer peripheral — they are the digital foundation on which mission capability is built.
That changes supplier selection. Choosing a foundational platform is not a feature comparison between real-time operating systems; it is a decision about the long-term partner behind the platform — the organization you depend on for vulnerability response, certification support, maintenance, security updates, product continuity, and architecture evolution. The deeper the software sits in the stack, the more consequential those dependencies become. The same scrutiny long applied to hardware provenance is now being applied to software: not just the code, but who maintains it, who controls the build infrastructure, and who makes long-term decisions — the thrust of recent secure-software-supply-chain policy, from SBOM requirements to CMMC.
FOCI Is Risk Management, Not a Binary Label
It is important not to treat FOCI as a simple line between “acceptable” and “unacceptable” suppliers. U.S. policy provides a ladder of mitigation measures scaled to the degree of foreign control — from board resolutions and Security Control Agreements to Special Security Agreements, and, for stronger control, proxy agreements and voting trusts that vest operational authority in cleared U.S. citizens. These structures are an established, effective part of the defense industrial base.
But a mitigation structure existing is not the same as a customer understanding how it works in practice. The useful move for acquisition leaders, chief engineers, program managers, and security teams is to ask a consistent set of questions:
These are not questions designed to exclude suppliers by nationality. They are questions designed to understand risk — and they apply to every supplier, domestic or foreign.
Control Is Also Architectural
There is a second meaning of “control” that belongs in the same conversation. Governance control determines who steers the company; architectural control determines whether your foundation can enforce — and prove — the separation your mission depends on. The two reinforce each other. A foundation built on a separation kernel, with static, immutable partitioning and a small, trusted computing base, lets a program demonstrate isolation between safety-, security-, and mission-critical workloads and constrain how data moves, independent of any single application or vendor stack. Governance answers “who decides”; architecture answers “what can be enforced and evidenced.” Programs that treat sovereignty as purely a corporate question, or purely a technical one, are solving only half of it.
Proxy
This is why lifecycle and organizational confidence increasingly sit beside technical excellence. Deterministic performance, strong isolation, certification evidence, cybersecurity, and modularity remain the first requirement. But programs also need evidence that the technology can be sustained, patched, recertified, and evolved without disruptive redesign — and clarity around ownership, operational independence, and supply-chain resilience. The most resilient programs evaluate these together rather than as separate engineering, acquisition, and security conversations.
Why This Matters To Lynx
For Lynx, this shift is a chance to broaden the conversation beyond RTOS feature comparisons. Lynx is a U.S.-owned and U.S.-operated company focused on mission-critical aerospace and defense systems, and its role is to provide a long-lived software foundation — one that must stay secure, certifiable, adaptable, and supportable across generations of hardware and mission capability. Domestic ownership does not replace technical excellence, rigorous security, or certification credibility. But for programs where classified work, long-term control, and supply-chain assurance matter, it can be a meaningful part of the overall risk equation — especially when paired with an architecture built to enforce separation and reduce certification scope.
The point is not that ownership should dominate every software decision. It is that corporate governance, operational control, and supply-chain resilience now belong in the same conversation as performance, safety, cybersecurity, and lifecycle cost.
Defense acquisition used to ask a narrow question: does this technology meet the program’s technical requirements? The more appropriate question today is broader: can this technology — and the organization behind it — be trusted to support the mission for the entire life of the platform? As defense becomes software-defined, the answer will depend on architecture, lifecycle strategy, governance, and the ability to maintain trusted control over critical software foundations. In that environment, FOCI is not merely a compliance topic. It is part of a larger conversation about strategic software sovereignty.