Why Open Systems and MOSA Matter in Modern Defense Procurement

Matt Hyatt
Jan 16
5 min read

Defense procurement is changing in a way that rewards architecture as much as (or more than) raw technical performance. The Department of Defense isn’t just buying “a product” anymore, it’s increasingly buying the ability to upgrade, swap, integrate, secure, and compete components over time. That’s the logic behind Open Systems and the Modular

Open Systems Approach (MOSA) and it’s now deeply embedded in DoD policy and law.

If you’re building or selling defense technology, especially software-defined capabilities, sensors, comms, EW, autonomy, or anything that must integrate into an existing stack, understanding MOSA is not optional. It affects how requirements are written, how solicitations evaluate solutions, what data rights matter, how primes structure teams, and how long your solution can survive in a program of record.

Open Systems vs. MOSA (and why the difference matters)

Open Systems (in practice) usually refers to designing systems around published interfaces and widely adopted standards, enabling interoperability and reducing “closed” proprietary lock-in.

MOSA is broader: it’s a technical and business strategy for designing affordable, adaptable systems through modularity and open interfaces, explicitly tied to acquisition strategy (competition, sustainment, upgrade paths, data rights).

In other words:

Open Systems is often how engineers talk about architecture and standards.
MOSA is how acquisition leaders talk about architecture + competition + lifecycle outcomes.

And DoD is pushing MOSA hard, both through formal acquisition policy and more recent “accelerate fielding” reform messaging.

The procurement reality MOSA is responding to

DoD programs historically get trapped by a predictable pattern:

A prime wins a major platform or mission system.
Interfaces become effectively proprietary (even if not intentionally).
Upgrades require the original vendor (or vendor-approved subs).
Cycle time slows, costs rise, and innovation insertion becomes painful.
The government pays a premium to change what should be routine.

MOSA is meant to change that trajectory by requiring programs to think early about:

Modular decomposition (what can be swapped)
Open interfaces (how modules connect)
Sustainment and upgrade strategy (how capability evolves)
Competition over the lifecycle (how new vendors enter later)
Intellectual property and data rights (what the government needs to avoid lock-in)

MOSA isn’t “nice to have” it’s becoming a gate

Two signals matter:

Policy and guidance: DoD acquisition policy for major capability acquisition explicitly calls out the use of MOSA to evolve capability and maintain interoperability, alongside core acquisition concerns like IP strategy and other program risks.
Stronger enterprise push: Recent DoD-level reform messaging emphasizes maximizing MOSA use to speed delivery of urgently needed capability, including obtaining delivery of critical interfaces.

Separately, the DoD community has published a MOSA implementation guidebook that describes statutory/policy requirements and best practices across the lifecycle, aimed directly at PMOs and lead systems engineers.

The net: even when a solicitation doesn’t scream “MOSA,” evaluation teams are increasingly looking for credible evidence that you understand how your solution will integrate, evolve, and compete within a modular architecture.

The business reason: MOSA is a competition strategy

MOSA’s “open” promise is not philosophical; it’s economic.

When interfaces are open and modules are separable:

Programs can compete upgrades later (new sensors, new algorithms, new radios).
The government can avoid “single-vendor hostage situations.”
Vendors can win smaller, more frequent opportunities over time (technology insertion, refreshes, software increments).

This is why MOSA is repeatedly framed as an approach to achieving competitive, affordable acquisition and sustainment over the lifecycle.

For smaller companies, this can be a good thing if you show up MOSA-ready. A modular ecosystem is one of the few ways a non-incumbent can break into a mature platform.

The technical reason: modern capability is composable

Most “decisive” capability now comes from systems-of-systems integration:

Sensor fusion and edge compute
Data transport and cross-domain flows
Software-defined radios and waveform agility
Autonomy stacks that must plug into mission systems
Cyber-hardening and supply chain controls that evolve continuously

In that environment, performance on your test bench matters less than:

How fast you can integrate
How safely you can integrate
Whether your interfaces are stable and well-governed
Whether the program can replace you if needed (yes, really)

MOSA is a way to formalize those integration realities in acquisition language.

The hidden battleground: data rights and interface control

Open interfaces don’t stay open by accident. They stay open because programs enforce:

Interface control governance (ICDs, versioning, conformance testing)
A technical data package/data rights strategy aligned with sustainment and competition

This is why MOSA is consistently linked with IP strategy in acquisition policy and in MOSA guidance.

A practical truth: in many programs, “openness” rises or falls on whether the government can actually use the interface information and software artifacts to bring in another vendor later.

What goes wrong with MOSA in the real world

MOSA is not magic. GAO reviews have found that programs report varying levels of MOSA implementation and cite barriers such as increased design costs and time, and other practical constraints.

Common failure modes:

“Open in slides only.” MOSA language appears in a strategy doc, but interfaces remain tightly controlled.
Too-late modularization. Retrofitting modularity after architecture hardens is expensive.
One-vendor “open.” Interfaces exist, but they’re so vendor-specific that no real competitor can conform without major rework.
Cyber and cert friction. Open interfaces expand integration points; without security engineering, approvals can slow.
No conformance culture. If nobody tests interface compliance, “open” becomes interpretive.

The takeaway: MOSA isn’t a buzzword; you claim it’s a set of engineering and acquisition behaviors you demonstrate.

What “MOSA-ready” looks like for vendors

If you want to be taken seriously by a DoD PMO, integrator, or prime team, you should be able to answer (clearly, without hand-waving):

What are your external interfaces? Provide ICDs, APIs, message schemas, timing constraints, and versioning approach.
What standards do you conform to (and why those)? Don’t list standards as decoration; show how they enable interoperability.
How modular is your solution really? What can be swapped without rewriting the world?
How do you handle integration and conformance testing? Offer test harnesses, simulators, reference implementations, and evidence of repeatable integration.
What’s your data rights posture? You don’t need to “give away IP,” but you must understand what a program needs to sustain and compete.
How do you secure your interfaces? Open surfaces increase the attack surface, address authentication/authorization, logging, SBOM posture, and lifecycle patching.

If you can’t answer these quickly, you’re not MOSA-ready; you’re still “demo-ready.”

Why this matters even more now

The Department is explicitly trying to accelerate delivery of urgently needed capability while pushing structural changes in acquisition processes, paired with a call to maximize MOSA use in development programs and deliver critical interfaces.

That combination matters because it creates a procurement climate where:

Programs want speed, but not at the cost of long-term lock-in.
They want upgrade agility without re-platforming.
They want competition beyond initial downselects.

MOSA is the mechanism that makes speed sustainable rather than a one-time surge.

Bottom line

Open Systems and MOSA matter because they are how DoD is trying to buy what it actually needs in 2026 and beyond:

Capability that can evolve
Systems that can integrate
Programs that can compete upgrades
Architectures that can survive vendor churn
Fielding velocity without permanent lock-in

If you’re writing, building, or marketing defense tech and you’re not framing your value in MOSA terms, interfaces, modularity, integration speed, conformance, and data-rights strategy, then you’re competing in yesterday’s language.