"Weapon system as a composable platform" is a phrase that now turns up in acquisition strategies, industry days, and the architecture documents the Army posts for Next Generation Command and Control. It describes a real change. A weapon system stops being one thing delivered by one prime and becomes a platform that other things plug into: sensors, processing, applications, data services, from more than one vendor, each replaced on its own schedule.
The architecture diagram for that platform usually exists. The authorization diagram usually does not. That gap is where composable programs stall, and it lands on two groups of people who rarely talk to each other before it does.
If you run a program office, you have been told to make the system composable, and you own the ATO that has to survive it. If you are a commercial vendor, you want to be one of the modules, and nobody has told you what that costs beyond the interface specification. This post is for both.
What "composable" means, and what it does not
The word is doing three different jobs at the moment, and conflating them is the first mistake.
Modular hardware. MOSA in its original sense: swappable line-replaceable units behind published physical and electrical interfaces. SOSA-aligned cards, OMS-conformant mission systems. The unit of replacement is a box.
Composable software and data. The NGC2 sense. A common data layer, core services, and applications that ride on top of them, so a new application or sensor feed integrates without reworking the stack. The Army's NGC2 capability characteristics notice says the architecture "emphasizes the importance of a composable architecture and data layer design patterns" and aims at "a multi-vendor NGC2 ecosystem". The common data baseline the Army and industry aligned on as the program moved from prototyping to delivery is that architecture arriving. The unit of replacement is a container or a service.
Composable weapons. Raytheon's usage: seekers, airframes, actuators, software and test infrastructure reused across missile programs. The unit of replacement is a subsystem inside a munition.
What all three share is the definition the statute uses. 10 U.S.C. 4401 requires every major defense acquisition program with a Milestone A or B decision after 1 January 2019 to be designed, to the maximum extent practicable, with a modular open system approach: modular design, modular system interfaces between major components, and verification that those interfaces comply with widely supported standards. The FY2021 NDAA extended the requirement to every defense acquisition program.
Strip the vocabulary and composability is three properties. Components are severable. Interfaces are published. Replacement is independent. Everything that follows is a consequence of those three.
The part the guidance leaves out
The Office of the Under Secretary for Research and Engineering published an 84-page MOSA implementation guidebook in February 2025. It is a good document. It uses the word "interface" more than two hundred times. It does not use "RMF", "ATO", or "reciprocity" once. Cybersecurity gets one section of three paragraphs, which concedes that "software cybersecurity can be challenging in a MOSA solution" and points at DevSecOps toolchains and model-based engineering as the way through.
That is not a criticism of the guidebook. It is a systems engineering document and it does its job. But it means the authorization consequences of composability are nobody's assigned reading, and GAO found the planning gap runs deeper than that. Of 20 programs GAO reviewed in January 2025, none had done the cost-benefit analysis MOSA policy requires, and most had not addressed all of the planning elements in their acquisition documentation. Programs adopted the word before they adopted the plan.
The authorization boundary is the planning element that goes missing most often, because it belongs to a different office than the architecture does.
The boundary nobody redrew
Under RMF, an authorization boundary is drawn around a system as delivered. The authorizing official accepts risk for everything inside it, on the strength of a body of evidence that describes what is inside it.
Now make the system composable. Components inside that boundary are designed to change independently, from different vendors, on different schedules. That is the whole point.
Every one of those changes is a change to an authorized system. RMF handles change through security impact analysis: the ISSM determines whether the change is significant, and if it is, the affected controls are reassessed. On a monolithic boundary the analysis is against the whole system, because the boundary offers no smaller unit to analyze against.
So the program ends up in one of two places.
It freezes the composition. Module swaps queue up behind the next full reassessment, because that is the only time the authorization can absorb them. The architecture is composable on paper and static in practice. This is the quiet failure, and it is the common one.
It pays per swap. Each replacement gets its own impact analysis, its own reassessment, and its own wait for an assessor from the pool the whole portfolio shares. The program bought composability to move faster and now moves at the speed of the AO's calendar.
A third cost shows up in both cases. Under a single-prime model, the prime assembled the body of evidence. Under a multi-vendor composable model, each module arrives with its own scan results, its own image provenance, its own control narratives. Someone has to integrate those into one coherent package the AO can sign. That someone is the program office, and it is integration work that nobody scoped.
What a composable authorization looks like
The fix is to make the authorization model composable in the same way the architecture is. Four things do that. None of them is new. All of them have to be decided at design time rather than at the first module swap.
The substrate carries the infrastructure controls. Composability presumes a common runtime the modules share. If that runtime is an enterprise platform with its own authorization, the modules inherit the infrastructure controls and authorize only what they add. The second post in the weapon system series made the availability case for that platform. The composability case is stronger: you cannot compose across dedicated infrastructure that differs at every site, and you cannot inherit from a substrate that has no authorization to inherit from.
The interface specification is also the interconnect specification. MOSA already requires the program to publish its modular system interfaces. Add three attributes to each one: the classification of what crosses it, the direction, and the protection applied. That is the data flow an assessor needs, and it now exists as a by-product of the architecture rather than as a separate ISSE deliverable that lags it by a year. The interface control document and the interconnect agreement become the same artifact.
Change classes are defined before the first change. The authorization package should say, in advance, which swaps are routine and which are significant. A replacement module that implements the same published interface, handles the same data at the same classification, and runs on the same substrate under the same policy enforcement is a routine change. It is covered by continuous monitoring, not by reassessment. A module that adds an interface, changes a data flow, or requires a new privilege is significant, and everyone knew it would be before the vendor was selected. This is the mechanism the DoD CIO's 2022 continuous ATO memo is built on: continuous monitoring of controls, active cyber defense, and an approved DevSecOps reference design, in exchange for an authorization that moves with the software.
Evidence is a module deliverable. Each component ships with the evidence for what it implements: a hardened image, a software bill of materials, current scan results, and control narratives for the controls the module owns rather than inherits. The program integrates evidence packages the way it integrates modules, through a defined interface. DoD's reciprocity playbook, issued in January 2024, exists to make assessment results reusable across organizations. A module assessed once against a published interface on a known substrate should not be assessed again from zero because it moved to a sister program on the same substrate.
Do these four and a module swap becomes what the architecture promised: a change of component, not a change of system.
For the program office
Five decisions, all of which are cheaper before the architecture is baselined.
- Draw the authorization boundary at the same time as the architecture. Not after. The two diagrams should be reviewed together, and the boundary should say which modules inherit from the substrate and which carry their own controls.
- Choose the substrate first. The enterprise platform is the composition layer and the inheritance source. A composable architecture on bespoke infrastructure at each site is a contradiction, and the cost visibility work tells you what that contradiction currently costs.
- Put security attributes in the interface repository. Classification, direction, protection, on every modular system interface. It is the cheapest ISSE deliverable the program will ever produce, because the architects are already writing the rest of the document.
- Define change classes in the authorization package. Routine versus significant, with the criteria written down. Get the AO to sign the criteria, not just the system.
- Budget for evidence integration. Someone owns assembling multi-vendor evidence into one package. If it is not in the sustainment estimate, it becomes the IT team's problem on delivery day.
The same authorization study that scopes a hardware system with embedded software scopes a composable one. The difference is that the interconnects sit inside the platform rather than at its edge, and there are more of them.
For the vendor
You want to be a module. Here is what that asks of you beyond conforming to the interface.
You inherit only if you deploy the platform's way. The substrate's controls cover you when your container passes its admission policy, runs on a hardened base image, and uses the platform's identity and secrets. The first time a commercial application meets a hardened baseline it produces findings that were invisible from the Dockerfile. Find them in a lab before the program finds them in its pipeline.
Your evidence package is part of your product. The program office is going to integrate it. If it arrives as a spreadsheet of CVEs and a promise, that integration is expensive, and expense is what MOSA was adopted to compete away.
Your swap-in is a security impact analysis for the program. Every hour of an assessor's time your module consumes is an hour the program did not plan for. If you conform to the published interface exactly, handle exactly the declared data, and ship the evidence for what you own, you are a routine change. If you need one more port, one more privilege, or one undeclared data flow, you are a significant change, and you have just handed the program office a reason to pick the vendor who was not.
That last point is the one worth sitting with. MOSA's entire premise is that the program can replace you. In a composable platform with a composable authorization, the vendor who is easiest to authorize is the hardest to replace. That is a competitive position, and it is available to whoever does the deployment work first.
This is already the direction
The Army declared NGC2 ready to scale in July 2026 after Project Convergence Capstone 6, with I Corps headquarters fielding next. The Space Force is moving missile warning ground processing onto Enterprise Ground Services. Each of these programs is composing capability from multiple vendors on a shared substrate.
The question for a program office is not whether the weapon system becomes a composable platform. The statute and the service architectures have settled that. The question is whether the authorization gets redrawn with the architecture, or after the first module swap fails to get through.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for legacy weapon systems at the Air Force Lifecycle Management Center, maintaining authorizations through the component changes this post describes, and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO). He now deploys commercial software onto the hardened platforms those systems are moving to.
If your program is adopting a composable architecture and the authorization boundary has not been redrawn to match, or you are a vendor who wants to arrive as a routine change rather than a significant one, contact Millabs. Assessments for program offices are performed independently of any vendor relationship, through existing government contract vehicles.