What IBCS changed in air and missile defense
Legacy U.S. Army air and missile defense operated through direct, point-to-point connections. A Patriot battery's command-and-launch element could only receive tracks from its own radar and could only task its own interceptors. Bringing in a second radar required a separate coordination step, which introduced latency and friction under a compressed engagement timeline. Integrating fires across battery and brigade boundaries required coordination above and beyond what a single node could automate.
IBCS replaced that architecture with a software-defined Integrated Fire Control Network (IFCN). Under IBCS, a fire control node can receive track contributions from networked sensors—Patriot and Sentinel radars, and in testing joint sensors such as the Marine Corps TPS-59 and Air Force F-35s (Army.mil, Dec 2019)—and can task the most appropriate available effector. The Army reported that in a 2019 flight test, multiple sensors from the Army, Air Force and Marine Corps contributed to a composite target track and the targets were intercepted (Army.mil, Dec 2019), which single-sensor fire units could not do. The Army describes IBCS as integrating sensors and effectors across the Integrated Fire Control Network (Army.mil, April 2026).
IBCS is managed by the Integrated Fires Mission Command Project Office under the Army's Portfolio Acquisition Executive Fires (previously PEO Missiles and Space) in Huntsville, Alabama (Army.mil). The prime contractor is Northrop Grumman (GAO-22-105230). The path to production ran through a failed 2016 limited user test, in which IBCS software performance was rated unsatisfactory; a December 2017 program restructure after cost growth exceeded the acquisition baseline; a second limited user test in 2020 that also exposed hardware transport deficiencies and led to a truck-based platform; a January 2021 production decision; and full-rate production approval in April 2023 (DefenseScoop, May 2023, GAO-19-336SP, GAO-21-222, GAO-22-105230).
The ATO problem for live-updating software
A structural challenge that every software-intensive fire control program faces, and that IBCS's record illustrates, is keeping certification in step with software that has to change continuously to stay effective.
DoD Instruction 8510.01 established the Risk Management Framework (RMF) and requires DoD systems, including weapons systems, to receive and maintain a valid authorization (DoDI 8510.01, July 2022). In September 2025 the Department of War announced the Cybersecurity Risk Management Construct (CSRMC). It describes RMF as "the previous Risk Management Framework" and replaces "snapshot in time" assessments with continuous, automated risk management. Its tenets include continuous monitoring and ATO, and DevSecOps. Programs designing today should map their authorization approach to CSRMC's design, build, test, onboard and operations phases and confirm with their authorizing official which issuance governs. The traditional model evaluates a defined software configuration, issues an ATO for that configuration, and requires reassessment when the configuration changes materially. For a traditional fixed-configuration system—a radar firmware release, a missile seeker software load—that model is workable. A new firmware release triggers a new evaluation; the pace of change is slow enough that the process can absorb it.
IBCS's IFCN software is built to change. In 2021 the program moved its software onto DoD's Software Acquisition Pathway and planned quarterly software increments for user evaluation (GAO-22-105230). The Army describes it as the first ACAT I-D Army program to use Agile DevSecOps (Army.mil, April 2026). Even so, GAO reported in 2023 that the program expected a "continuous cycle" of the process used to ensure the system is safe and suitable for the warfighter, a process GAO called "lengthy and complex," for each of its software and hardware releases (GAO-23-106059). Fast development does not by itself produce fast fielding. Certification has to be engineered to the same cadence.
GAO's Weapon Systems Annual Assessments tracked IBCS software risk across the development years. The 2016 limited user test found "unsatisfactory performance" of the IBCS software, which forced a second limited user test in 2020 (GAO-20-439, IAMD assessment). GAO also reported that hardware design changes required additional software development and raised software costs. By 2021 program officials said all software issues from the first test were resolved (GAO-21-222). In January 2022 Army leadership split initial operational testing into two phases so software updates could be inserted between them (GAO-23-106059). That record shows a program whose test schedule was repeatedly shaped by software maturity. Any program that ties certification to a fixed configuration should expect the same pressure. For any IFCN-style system, each such iteration plausibly requires retesting not just the changed component but the relevant inter-system interactions, which compounds cycle time.
Continuous ATO (cATO) establishes monitoring, automated testing, and risk-informed update authorization rather than full re-evaluation for each increment. The Department's own direction is now continuous authorization; the design work is making a program able to use it. The Department's November 2023 Data, Analytics, and Artificial Intelligence Adoption Strategy called for an agile, continuous delivery approach to AI and said shared infrastructure should automate DoD technology policies such as Continuous Authorization to Operate. The January 2026 Artificial Intelligence Strategy for the Department of War goes further. It directs the Department to "eliminate blockers" including Authorizations to Operate and to pursue rapid ATO reciprocity. The critical operational point: cATO requires deliberate design. It cannot be retrofitted as an afterthought after the system is built. The authorization pathway, monitoring architecture, and update testing framework must appear in the initial acquisition strategy and system design.
Programs that assume they can resolve this problem during integration test will find themselves either delaying deployment to complete evaluations or fielding systems they cannot improve on the timelines that operational requirements demand.
Sensor data quality: what exercises typically hide
The second structural challenge IBCS surfaced is less visible in development testing but matters acutely in realistic operational environments: heterogeneous sensors contributing to the same fire control node do not produce equivalent track data.
When Patriot, Sentinel, and a joint sensor such as the Marine Corps TPS-59 each independently detect the same airborne object, the resulting track reports may disagree on position, velocity, heading, and classification—not because any sensor is malfunctioning, but because each platform is optimized for a different detection geometry and fidelity trade-off. Radar types are generally optimized for different roles, such as engagement-quality fire control, longer-range surveillance, or forward-area air defense, each with its own resolution and sensitivity profile. Their track outputs cannot be treated as interchangeable.
IBCS's fire control software must correlate those tracks into a single combined air picture under the latency constraints of an actual engagement timeline. The correlation software—the same kind of automated fusion function that AI-enabled successors will extend—makes association decisions under uncertainty: is track A from Patriot the same object as track B from another sensor, or two different objects? In exercises, this question is usually straightforward because scenarios are designed with known objects on predictable paths. In a contested environment with electronic attack, spoofed or degraded sensor inputs, and multiple simultaneous threats, the hard correlation cases accumulate precisely when the engagement timeline is most compressed.
The practical implication for program offices and contractors: the sensor data quality characterization of each contributing platform is a necessary design input, not a post-delivery concern. Understanding the track error envelope of each sensor—its position uncertainty, its classification confidence range, its behavior under EW—is prerequisite knowledge for designing reliable correlation logic. That characterization typically does not appear in any single sensor's system specification because each sensor was procured separately. Acquiring it requires deliberate multi-sensor integration testing planned and funded as a distinct line item. Programs that skip this step will encounter it during operational evaluation, where the cost is measured in schedule months rather than testing weeks.
What IBCS integration surfaces about JADC2 requirements
IBCS is not just an air defense story. It is the Army's most operationally deployed reference implementation of what JADC2 requires at the unit level: software-defined networking between sensors and effectors, with automated fire control mediating the connection, a function AI-enabled systems will extend. DoD's Summary of the JADC2 Strategy (March 2022) sets out the enterprise framework and notes a supporting Implementation Plan, which DoD described as classified (DoD release, March 17, 2022); IBCS provides a fielded example of what realizing that framework in a specific mission area required. DefenseScoop described IBCS as a key enabler for the Army's contribution to JADC2 (DefenseScoop, May 2023).
Three architecture requirements that IBCS surfaced have applicability beyond air defense:
Latency is mission-function specific. The acceptable latency for passing an intelligence update to a commander differs from the latency acceptable for commanding an interceptor away from a target. Systems that use a single data transport layer across all message types—a simplifying assumption that is common in early architecture design—will discover that some functions are degraded at network conditions where others perform acceptably. Mission-specific Quality of Service design must be part of the initial architecture, not a performance optimization after fielding.
Resilient operation is a baseline requirement, not a feature. IBCS must function—at reduced capability—when communications links are degraded. In contested environments, the assumption of reliable connectivity is a known adversary target. Systems that behave reasonably under normal conditions but fail hard under degraded connectivity have limited value in the environments where integrated fire control matters most. The design requirement is graceful degradation: the system must identify which functions it can continue to perform on the available network capacity and maintain those, rather than requiring the full designed capacity to operate at all.
The human-machine interface for correlation uncertainty is an operational design problem. When the track fusion engine's confidence in a correlation decision falls below a threshold, an operator must make or confirm the decision. What the system presents to that operator—which information is available, how confidence is communicated, what options are actionable, how the decision is recorded—determines whether the system makes the operator more accurate under stress or more confused. This interface is not a UX addition. It is a determinant of whether the system delivers its claimed operational value. It requires deliberate design, realistic test scenarios, and training that includes the degraded cases, not just the nominal ones.
Decisions program offices and contractors face today
The IBCS experience produces four specific design choices that affect schedule, cost, and operational outcome for any similar program.
Establish the cATO pathway before writing the SOW. The authorization process for a live-updating AI system is a program architecture decision. If the acquisition strategy does not include a DevSecOps framework and a defined cATO approach from the start, the program will encounter the certification-cadence problem IBCS's record illustrates when software maturity demands updates. The January 2026 DoW AI Strategy and the 2025 Cybersecurity Risk Management Construct provide the policy basis; the program office must translate that into executable contract language.
Budget sensor characterization as an independent line item. The cost of understanding each contributing sensor's track error envelope under realistic conditions is knowable in advance and modest compared to the cost of discovering it during operational evaluation. A deliberate integration test plan that characterizes sensor agreement and disagreement across the relevant engagement geometries is a recoverable investment. Discovering the same information during operational test is not.
Define degraded-mode behavior before building the high-performance case. Programs under schedule and cost pressure tend to prioritize demonstrating peak performance in the designed scenario and defer resilience design to later increments. For a system whose operational value depends on functioning in contested conditions, this sequence is backward. Define, for example, what the system must do at a hypothetical 60 percent of designed network capacity, with one contributing sensor offline, under active electronic attack. Those requirements will drive architecture decisions that are difficult to retrofit after the core system is built.
Treat operator interfaces for uncertainty as requirements, not design options. The interface through which an operator interacts with the system's confidence outputs—what they see, what they can act on, what is recorded—is a documented requirement that the system must meet. If it is treated as a design option left to the contractor's discretion, the delivered interface will optimize for nominal operation rather than the degraded cases where operator judgment matters most.
What would change the analysis
These recommendations apply to the baseline case for any AI-enabled multi-sensor command node. Three conditions would change the weight or applicability of specific items.
If a program operates only in fully permissive environments with reliable communications and no electromagnetic threat, the resilience requirements simplify substantially. The question is whether that operational profile is realistic for the intended deployment context.
If a program connects a single sensor type to a single effector type, the track correlation problem disappears. The ATO and cATO requirements still apply to the software integration layer, but the multi-sensor data quality problem is not relevant.
If the AI component operates in read-only advisory mode—providing decision support to an operator who retains full manual override—rather than taking automated fire control action, the ATO requirements for live-updating software are somewhat less stringent than for systems that act without operator confirmation. This is a deliberate architecture choice with significant schedule implications in either direction.
Sources and further reading
- DefenseScoop, IBCS reaches initial operational capability (May 2023) — reporting on the IOC announcement
- GAO-19-336SP, GAO-20-439, GAO-21-222, GAO-22-105230 and GAO-23-106059 — Weapon Systems Annual Assessments, IBCS and IAMD program pages
- Army.mil, IBCS and the future of offensive and defensive integrated fires (April 2026) — program office, IFCN, Agile DevSecOps
- Army.mil, IBCS intercepts test targets (December 2019) — multi-sensor composite track test
- Data, Analytics, and Artificial Intelligence Adoption Strategy (November 2023)
- Artificial Intelligence Strategy for the Department of War (January 2026)
- DoD Instruction 8510.01, Risk Management Framework for DoD Systems (July 19, 2022) — see the September 2025 CSRMC announcement for the successor construct
- Summary of the JADC2 Strategy (March 2022)
Spartan X works on the AI integration problems IBCS-class programs now face at the edge: multi-model verification that surfaces disagreement and confidence before an AI output reaches an operator, DDIL-ready AI infrastructure where resilience is a baseline requirement, and governance and audit trails that give authorizing officials evidence about how fielded AI is behaving. The structural constraints IBCS surfaced are the same ones edge AI and C2 infrastructure must resolve across domains.
