Unmanned Vessel “Marketplace” Models: Contract Questions Defense Suppliers Should Prepare For
The Navy’s recent unmanned-vessel moves suggest a more modular, faster-moving buying environment than a classic single-platform program of record. NAVSEA said in July 2025 that the Modular Attack Surface Craft program would use modular design, commercial off-the-shelf technology, incremental development, and Other Transaction Agreements to support rapid deployment and cost-effectiveness. Navy fact sheets later described MASC as merging Medium and Large USV capabilities into one streamlined concept, while CRS said the FY2026 submission envisioned a prototyping phase with industry, modular payloads, and future integration under separate enabling-capabilities efforts. At the smaller end, the Navy’s sUSV work has already emphasized common modular enclosures, third-party software integration using open architectures and standardized interfaces, DIU prototype-to-production transitions, and follow-on production OTs. That combination points toward a more marketplace-like model in which hulls, autonomy stacks, payloads, control software, and sustainment elements may be sourced, upgraded, and competed more modularly than many defense suppliers are used to.
If the Navy buys unmanned vessels more like a family of swappable parts and services suppliers will be judged less on one prototype and more on how cleanly they fit a larger ecosystem
That shifts the contract conversation. The hard questions move away from simple hull performance alone and toward integration burden, software rights, payload interfaces, certification evidence, sustainment ownership, and how fast a vendor can plug into a modular fleet without forcing the government to rebuild everything around it.
1️⃣ Which part of the stack are you truly selling
In a marketplace-style model, the government may not be buying a vessel in the old all-in sense. It may be buying a hull, an autonomy stack, a payload-delivery layer, a common enclosure, a mission app, or a control-and-computing package. Suppliers should expect the Navy to press them on exactly which layer they own and which layers depend on others.
2️⃣ How open are your interfaces really
Once the Navy starts emphasizing modular payloads, third-party software, common enclosures, and standardized interfaces, suppliers should expect a much sharper question than “are you open architecture.” They should expect to show how another vendor’s payload, autonomy module, or comms package actually plugs in without a heroic custom rewrite.
3️⃣ Who owns the software updates and baseline drift
Software ownership becomes a contract question quickly once a fleet includes multiple prototypes, production baselines, autonomy revisions, and payload-specific updates. Suppliers should expect questions about how baseline changes are controlled, tested, fielded, and funded over time, especially if the Navy wants fast iteration without a fresh contract fight every cycle.
4️⃣ What technical data rights does the government really need
Suppliers should expect the data-rights question to become more pointed in a marketplace model because modular fleets lose flexibility if only one vendor can modify, sustain, or integrate a critical layer. The government may not need every design detail, but it will likely care deeply about the data necessary to maintain competition, insert payloads, and avoid total lock-in.
5️⃣ Who carries payload integration risk
Modular payload language sounds attractive until something does not mate cleanly with the hull, power package, computing environment, or control stack. Suppliers should expect the Navy to ask who owns integration risk across sensors, weapons, ISR packages, payload-delivery systems, and enabling electronics, especially if those items are being developed under different contracts.
6️⃣ How much test evidence is enough for fielding and production
The Navy has already used prototyping, experimentation, and OT pathways across several unmanned-vessel efforts. That means suppliers should expect more pointed questions about what evidence actually supports transition to production, fleet use, or wider deployment. Claims about autonomy, endurance, reliability, and collaborative behaviors will increasingly need a traceable test story behind them.
7️⃣ Who provides sustainment availability and fleet support
Unmanned vessels look cheaper until sustainment, remote support, reliability growth, and field-service ownership become blurred. Suppliers should expect sharp questions about who handles repairs, software refreshes, logistics, troubleshooting, fleet spares, and in-theater support once the system moves beyond a lab or detachment environment.
8️⃣ How will cybersecurity and autonomy assurance be handled contractually
Cybersecurity and autonomy assurance are likely to become some of the toughest contract questions because a modular USV ecosystem creates more software pathways, more interfaces, and more responsibility seams. Suppliers should expect questions about authority to operate, software assurance, cyber testing, patching ownership, remote update security, and how autonomy behavior is bounded and verified.
| Contract question | Why it appears | What it threatens | Best-prepared suppliers | Best commercial answer | Bottom-line impact |
|---|---|---|---|---|---|
Layer ownership Scope lane. |
Modular fleets split capability across many vendors. | Margin leakage and unclear scope. | Companies with precise boundary definitions. | Clear stack map and interface responsibilities. | Foundational |
Open interfaces Integration lane. |
Marketplace models depend on plug-and-play claims being real. | Custom-integration cost and schedule pain. | Vendors with genuine standards discipline. | Demonstrable third-party integration path. | Very high |
Software update ownership Lifecycle lane. |
Autonomy and mission software will keep changing. | Cost creep and baseline drift. | Firms with real configuration control and release plans. | Lifecycle software governance model. | Very high |
Data rights Competition lane. |
The Navy wants modularity without full vendor lock-in. | Future leverage on both sides. | Firms able to separate essential government rights from protected IP. | Targeted rights package, not vague openness. | Strategic |
Payload integration risk Mismatch lane. |
Different payloads may be developed under different efforts. | Unpriced engineering burden. | Suppliers with hard interface discipline. | Explicit limits and integration assumptions. | Very high |
Evidence threshold Transition lane. |
Prototype and OT pathways compress timelines. | Overclaim risk and production disappointment. | Firms with clear test provenance. | Honest maturity map. | High |
Sustainment ownership Availability lane. |
Prototype economics do not equal fleet economics. | Total lifecycle cost shock. | Suppliers with credible field support concepts. | Availability-based support logic. | Very high |
Cyber and autonomy assurance Trust lane. |
More modularity means more software seams and risk seams. | Delayed fielding and operational distrust. | Firms treating cyber and assurance as core deliverables. | Testable assurance package. | Strategic |
Marketplace models reward clean boundaries
The more modular the acquisition becomes, the less tolerance there is for vague ownership of software, payload fit, testing, or sustainment. Clear boundaries start to look like real capability.
Open architecture becomes a contract subject, not a marketing phrase
Suppliers will increasingly have to prove how third-party payloads, common enclosures, and government-directed updates can work in practice without custom integration every time.
Lifecycle answers may matter more than prototype answers
The vendor that explains sustainment, cyber patching, reliability growth, and software governance better may look stronger than the vendor that only explains top speed and range.
Move the sliders based on the contract environment you want to test. Higher modularity, faster software change, more third-party payload mixing, greater government insistence on competition, and stronger lifecycle support expectations will shift which questions matter most.
How to read the score
- Higher modularity usually makes interface-control discipline and scope boundaries the first major contract separator.
- Higher software churn usually makes configuration control, patch ownership, and update funding more important than many hardware suppliers expect.
- Higher lifecycle expectations usually raise sustainment, cyber, and autonomy-assurance questions because prototype economics stop being enough.
The strongest contract lesson is that suppliers should prepare for a buying environment that looks less like one monolithic ship competition and more like a managed ecosystem of hulls, autonomy, payloads, enclosures, control software, and support services. In that kind of model, the companies that look easiest to integrate, govern, update, and sustain may have an advantage over companies that only pitch standalone technical performance.
We welcome your feedback, suggestions, corrections, and ideas for enhancements. Please click here to get in touch.