Acquisition

What Is the DoD Software Acquisition Pathway (SWP)?

The Software Acquisition Pathway under DoDI 5000.87 enables continuous iterative delivery of defense software on commercial and embedded systems.

The software acquisition pathway is a Department of Defense (DoD) acquisition mechanism established to deliver secure military software through continuous, iterative releases instead of multi-year hardware schedules. Governed by Department of Defense Instruction (DoDI) 5000.87, issued on October 2, 2020, the pathway creates procedures tailored specifically for software development, integration, and operational fielding.

Before this pathway existed, the military bought software using the same milestone-gated processes created for battleships, tanks, and aircraft. Those linear processes required years of upfront requirements definition before developers wrote any operational code. The software acquisition pathway replaces that waterfall model with modern commercial practices, requiring programs to deliver working capabilities into operational environments within one year of obligating funds.

What the Software Acquisition Pathway Is

The software acquisition pathway is a tailored acquisition process governed by Department of Defense Instruction 5000.87 that enables the rapid development and continuous delivery of software to military operations. Issued by the Office of the Under Secretary of Defense for Acquisition and Sustainment on October 2, 2020, DoDI 5000.87 establishes policy, assigns responsibilities, and prescribes procedures to acquire, develop, integrate, and deliver secure software.

Traditional defense acquisition separated system development into discrete, linear milestones. A program spent years compiling rigid operational requirements, drafting technical specifications, conducting formal reviews, and building prototypes before fielding an initial capability. Software developed under that framework was often outdated before it reached service members.

DoDI 5000.87 eliminates those multi-year milestone gates for software systems. The instruction requires programs to adopt modern iterative development methodologies, such as agile or lean development. It also directs programs to establish automated development, security, and operations (DevSecOps) pipelines that allow automated testing, cybersecurity validation, and frequent operational deployment.

The policy applies across the military departments, combatant commands, and defense agencies. It covers both standalone business and mission applications and software embedded directly inside combat weapon systems.

Where the Pathway Fits in the Adaptive Acquisition Framework

The software acquisition pathway is one of six distinct acquisition pathways that make up the Adaptive Acquisition Framework (AAF). The Department of Defense established the AAF in January 2020 to dismantle the rigid, one-size-fits-all approach of legacy acquisition regulations.

The AAF tailors program oversight into six pathways to minimize unnecessary bureaucratic processes and actively manage risk based on the unique characteristics of the capability being acquired:

  • Urgent Capability Acquisition: Fields capabilities to fulfill urgent operational needs in under two years.
  • Middle Tier of Acquisition: Uses rapid prototyping and rapid fielding to demonstrate capabilities within five years, detailed further in our middle tier acquisition explainer.
  • Major Capability Acquisition: Acquires complex, hardware-intensive systems through traditional milestone phases and formal reviews.
  • Software Acquisition: Provides for rapid, iterative delivery of software capability directly to operational users.
  • Defense Business Systems: Modernizes commercial business systems, such as enterprise resource planning, financial, and logistics software.
  • Acquisition of Services: Procures contracted professional, technical, and operational services.

Program managers can combine pathways to match system requirements. For example, a major satellite program procuring space vehicles through Major Capability Acquisition can execute its ground station software or mission data processing through the software acquisition pathway. To accelerate early work, programs can also pair this pathway with flexible contracting tools, such as the mechanisms covered in our Other Transaction Authority guide.

The Section 809 Panel Recommendations

The software acquisition pathway originated from reform proposals produced by the Advisory Panel on Streamlining and Codifying Acquisition Regulations, known as the Section 809 Panel. Congress established the panel in Section 809 of the Fiscal Year 2016 National Defense Authorization Act (NDAA), Public Law 114-92.

The panel consisted of 16 recognized experts in defense acquisition and procurement policy. Congress charged them with delivering actionable recommendations to transform the defense acquisition system into an agile, modern enterprise capable of maintaining technological advantage.

The Section 809 Panel operated from August 2016 through July 2019. Over that three-year period, the panel published five comprehensive reports: an interim report, a final report delivered in three successive volumes, and a concluding roadmap. Across those five publications, the panel organized 98 distinct recommendations around four core founding principles.

A central conclusion of the panel’s work was that software cannot be acquired like physical hardware. Hardware production requires fixed blueprints, tooling, physical materials, and sequential assembly lines. Software is never truly complete; it evolves continuously in response to emerging operational threats, bug discoveries, and user feedback.

The panel recommended creating an acquisition approach dedicated entirely to dynamic software development. The Office of the Secretary of Defense incorporated this guidance directly when drafting the Adaptive Acquisition Framework and DoDI 5000.87.

The Applications Path and the Embedded Software Path

The software acquisition pathway divides software acquisitions into two specific execution tracks defined in DoDI 5000.87 §3.1.b. Program offices must identify whether their effort belongs on the Applications Path or the Embedded Software Path during early acquisition planning.

Pathway AttributeApplications PathEmbedded Software Path
Primary FocusSoftware running on commercial hardware and cloud infrastructureSoftware embedded inside weapons and military-unique hardware
Operational EnvironmentEnterprise networks, cloud data centers, command postsTactical platforms, combat vehicles, aircraft, munitions, sensors
Hardware CouplingDecoupled from proprietary physical systemsIntegrated with tactical computing units and specialized processors
Delivery MechanismOver-the-network software updates, cloud deploymentPlatform flashes, tactical data loaders, maintenance updates
Governing DefinitionDoDI 5000.87 §3.1.b.1DoDI 5000.87 §3.1.b.2

Applications Path

DoDI 5000.87 §3.1.b.1 defines the Applications Path as providing for the rapid development and deployment of software running on commercial hardware, including modified hardware, and cloud computing platforms.

This path covers software that operates independently of specialized tactical hardware. Common implementations include mission planning systems, command and control decision aids, intelligence analysis tools, logistics management applications, and cloud-hosted data pipelines. Programs on this track frequently deploy software onto commercial cloud infrastructure, such as the multi-vendor cloud services outlined in our Joint Warfighting Cloud Capability explainer. Because commercial computing platforms follow open standards, software updates on the Applications Path can be developed and pushed across networks rapidly.

Embedded Software Path

DoDI 5000.87 §3.1.b.2 defines the Embedded Software Path as providing for the rapid development, deployment, and insertion of upgrades and improvements to software embedded in weapon systems and other military-unique hardware systems.

Embedded software runs directly on the specialized processors inside radar systems, missile guidance computers, tactical radios, combat vehicle controllers, and aircraft mission computers. Deploying embedded software requires rigorous verification because failures can compromise platform safety, sensor integrity, or physical operation. The Embedded Software Path establishes rapid update cycles for these complex environments while maintaining necessary airworthiness, safety, and operational qualification standards.

Speed Requirements and Minimum Viable Capability Releases

The software acquisition pathway establishes strict, legally binding timelines for moving software from initial funding to operational deployment. These statutory rules prevent programs from drifting into prolonged development without delivering fieldable utility.

According to DoDI 5000.87 §1.2.e and guidance published by the Defense Acquisition University (DAU), programs on the pathway must meet two firm delivery criteria:

  1. Deploy a Minimum Viable Capability Release (MVCR) within one year: The program must demonstrate the viability and effectiveness of capabilities for operational use in an operational environment not later than one year after the date on which funds are first obligated.
  2. Deliver operational capability at least annually thereafter: Following the MVCR, the program must deliver new capabilities to operations at least annually, while more frequent updates and deliveries are explicitly encouraged where practical.

The Minimum Viable Capability Release represents the smallest software deployment that provides useful operational value to an active military user. It is not an experimental laboratory prototype; it is an accredited, secure software release delivered to real operational environments.

To maintain this deployment tempo, DoDI 5000.87 requires programs to employ modern iterative methodologies (agile or lean) alongside modern DevSecOps tools. DevSecOps integrates cybersecurity controls directly into automated build and testing pipelines.

Automated pipelines shorten accreditation timelines. For instance, the Department of Defense Chief Information Officer’s enterprise DevSecOps reference design notes that inheriting controls from underlying Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) configurations can satisfy approximately 40 percent of total security controls, which shortens the authorization timeline for mission software owners.

Named Defense Programs Executing the Pathway

Several high-visibility military programs have transitioned their acquisition strategies to the software acquisition pathway to accelerate delivery.

Kessel Run Air Domain DevSecOps Portfolio

The Air Force’s software development unit, Kessel Run, completed a major portfolio restructuring under the pathway in 2022. On April 13, 2022, the program executive office approved Kessel Run’s formal acquisition strategy under DoDI 5000.87, as reported by the Defense Visual Information Distribution Service.

The approved strategy consolidated 21 separate software development efforts into a unified Air Domain DevSecOps Portfolio. This consolidation established five distinct software acquisition pathway programs of record. By bringing those efforts under a single acquisition framework, Kessel Run replaced fragmented contract management with standardized DevSecOps delivery for operational air command and control units.

Army Enterprise Software Programs

The United States Army has prepared major information systems to enter the software acquisition pathway. As reported by the U.S. Army in March 2025, two major initiatives prepared execution-phase transitions:

  • Operational Medicine Information Systems, Army (OMIS-A): OMIS-A provides medical surveillance, treatment records, and patient tracking for operational field units. Its execution-phase decision point meeting was scheduled for April 29, 2025.
  • Integrated Personnel and Pay System, Army Increment II (IPPS-A Inc II): IPPS-A Inc II modernizes human resources and pay records for active, National Guard, and Reserve soldiers. Its execution-phase approval review was scheduled for December 2025.

Transitioning large enterprise records systems like IPPS-A Inc II to the software acquisition pathway allows military project offices to deliver functional modules incrementally to active service members instead of waiting for a completed multi-year software build.

Agencies focused on rapid fielding also use the pathway to deliver advanced applications. Defense Innovation Unit Director Doug Beck noted in March 2025 that the software acquisition pathway enables the department to adopt commercial technology with operational focus and speed. Through organizations like the Space Development Agency, accelerated software delivery also links directly into low-Earth orbit tracking and battle management architectures.

Government Accountability Office Findings on Implementation

The Government Accountability Office (GAO) has published multiple oversight audits reviewing the Department of Defense’s implementation of the software acquisition pathway. These reviews identify measurable progress alongside persistent organizational and technical hurdles.

GAO-21-105298: Baseline Data and Delivery Cycles

In September 2021, the GAO published its first major assessment of the framework, GAO-21-105298, titled DOD Software Acquisition: Status of and Challenges Related to Reform Efforts.

The review found that although the department established the software pathway in 2020, it lacked an overarching data collection strategy to evaluate program outcomes across the military services. GAO recommended that the department automate its data collection processes to monitor pathway performance accurately.

GAO also analyzed delivery cadence across 36 weapon programs attempting to use agile methodologies. The report revealed that only six of those 36 weapon programs delivered working software to users within three-month cycles. This fell far short of commercial industry standards, which recommend continuous software releases every two weeks. Additionally, over half of the evaluated weapon programs and nearly all major business IT efforts reported persistent workforce shortages in qualified software personnel.

GAO-23-105611: Workforce Gaps and Modernization Recommendations

In April 2023, the GAO issued GAO-23-105611, examining progress on software modernization initiatives. The audit reviewed 17 recommendations previously made by the Defense Science Board and the Defense Innovation Board.

The GAO found that while the DoD had partially or fully addressed all 17 recommendations, 13 of them still required additional action to achieve full execution. The report also noted that the department had yet to establish a dedicated, professional cadre of military and civilian software developers. Without an internal software workforce, defense programs remain dependent on external system contractors for basic engineering tasks.

GAO-23-105867: Pathway Disparities in Weapon Systems

In July 2023, the GAO published GAO-23-105867, evaluating software requirements within major weapon acquisitions.

The report highlighted a structural divide across the department. While programs officially registered on the software acquisition pathway are required to use flexible requirements processes tailored for agile development, weapon programs acquiring software through other acquisition pathways (such as Major Capability Acquisition) generally lacked those supportive requirements processes. They also lacked modern software engineering tools, which created schedule delays whenever platforms attempted to integrate new digital subsystems.

Department-Wide Mandate Under the March 2025 Hegseth Memorandum

On March 6, 2025, Secretary of Defense Pete Hegseth issued a memorandum establishing the Software Acquisition Pathway as the preferred procurement route across the Department of Defense (DoD). The directive, titled “Directing Modern Software Acquisition to Maximize Lethality”, applies across all defense components. It directs military programs to use the pathway as the default method for the software elements of both business systems and major weapon system programs. The memo does not replace or rewrite DoDI 5000.87; it directs adoption of the existing instruction.

The memorandum also establishes standard contracting vehicles for acquisitions using the pathway. Under the directive, Commercial Solutions Openings (CSOs) and Other Transactions (OTAs) serve as the default solicitation and award mechanisms for acquiring software capabilities. The memo makes CSOs and OTAs the required competition and award method for software offices.

To align component practices with the mandate, the memorandum set a tight timeline for operational guidance. It directed the Under Secretary of Defense for Acquisition and Sustainment to release a formal implementation plan by April 5, 2025.

The Operational Reality of Defense Software Acquisition

The software acquisition pathway establishes modern commercial engineering practices as formal Department of Defense policy. By mandating a Minimum Viable Capability Release within one year and continuous operational updates annually thereafter, DoDI 5000.87 breaks the cycle of multi-decade hardware procurement timelines dictating digital tool delivery.

However, oversight data from the Government Accountability Office confirms that changing acquisition policy does not automatically resolve underlying engineering deficits. Defense programs still face serious shortages of organic software engineering talent, inconsistent automated testing infrastructure, and cultural resistance to continuous operational deployment.

For defense contractors, program managers, and military technologists, navigating the software acquisition pathway requires moving away from static contract deliverables and embracing continuous code deployment. Organizations preparing to field applications through the pathway should review the specific procedural requirements in DoDI 5000.87 to ensure their development infrastructure meets automated delivery and cybersecurity accreditation standards.

Frequently asked questions

What is the DoD software acquisition pathway (SWP)?

The Department of Defense (DoD) software acquisition pathway (SWP) is a dedicated acquisition route established under DoD Instruction (DoDI) 5000.87 in October 2020. It provides policy and procedures for the rapid, iterative delivery of secure software capabilities to operational military users. Instead of using traditional multi-year hardware milestones, the pathway mandates modern iterative development methods like agile and lean, continuous integration tools, and rapid operational fielding.

What are the two paths in the software acquisition pathway?

The software acquisition pathway contains two distinct paths: the Applications Path and the Embedded Software Path. The Applications Path provides for the rapid development and deployment of software running on commercial hardware, modified hardware, and cloud computing platforms. The Embedded Software Path provides for the rapid development, deployment, and insertion of upgrades and improvements to software embedded in weapon systems and military-unique hardware.

What is the primary objective of the DoD software acquisition pathway?

The primary objective of the DoD software acquisition pathway is rapid and iterative delivery of software capability to the user. Programs must deploy a Minimum Viable Capability Release (MVCR) to an operational environment within one year of first obligating funds. After this initial operational release, programs are required to deliver new capabilities to operations at least annually, with more frequent deliveries encouraged.

How many pathways does the DoD's Adaptive Acquisition Framework have?

The Adaptive Acquisition Framework (AAF) contains six distinct acquisition pathways designed to tailor oversight to specific capability types. These pathways are Urgent Capability Acquisition, Middle Tier of Acquisition, Major Capability Acquisition, Software Acquisition, Defense Business Systems, and Acquisition of Services. Each pathway uses different documentation requirements, oversight thresholds, and review milestones to manage risk based on the specific capability being purchased.

Why does the software acquisition pathway have no sustainment phase?

The software acquisition pathway omits a traditional sustainment phase because it is structured around continuous iterative delivery rather than a sequential build-then-field lifecycle. In conventional acquisition models, sustainment begins only after full deployment is complete. Under the software acquisition pathway, operations, continuous development, cybersecurity hardening, and regular capability updates occur simultaneously, meaning each incremental release serves as both capability growth and ongoing software maintenance.

What did Secretary Hegseth's 2025 memo change about the software acquisition pathway?

On March 6, 2025, Secretary of Defense Pete Hegseth issued a memorandum on defense software acquisition. It directs Department of Defense (DoD) components to make the Software Acquisition Pathway the default acquisition method for software in business systems and weapon programs. It also establishes Commercial Solutions Openings (CSOs) and Other Transactions (OTAs) as the default solicitation and award approach under the pathway. The memo directs adoption of the existing pathway under DoDI 5000.87 without replacing or rewriting that instruction.