The Software Acquisition Pathway, established by DoD Instruction 5000.87 on October 2, 2020, is the Department of Defense's preferred route for buying software: minimum viable products delivered to users in months, continuous iteration thereafter, and no major capacity milestone gates in the middle. The instruction's stated goal is software that ships in cycles measured in weeks or months rather than the years a traditional Major Capability Acquisition consumes. cSTEM, the department's software tracking system, measures whether funded programs actually deliver, release by release.
For contractors and program offices alike, the pathway changes who holds authority, what gets funded, and what evidence of progress looks like. Here is how it works.
Why did the Pentagon need a separate software pathway?
The legacy acquisition system was built around hardware: a single big development, a production decision, decades of sustainment. Software economics run the other way. Requirements change faster than a two-year requirements freeze can hold, value arrives incrementally, and the highest-risk phase is often the first user touch, not the final test. Programs forced through hardware milestones produced software that was technically delivered and operationally stale.
DoDI 5000.87 formalized what experimental programs had already shown. Kessel Run, the Air Force software factory started in 2017, demonstrated that commercial-style product teams, DevSecOps pipelines and short release cycles could put new software in operators' hands in months, per Air Force reporting on its early deliveries to mobility aircrew. The pathway made that model the default rather than the exception.
What are the phases of the Software Acquisition Pathway?
Two. A planning phase aligns requirements, funding and users around a minimum viable product and a full-spectrum cyber test strategy. An execution phase then runs continuous iteration: design, build, test, ship, measure, repeat, with the product owner empowered to reprioritize the backlog between releases. There is no milestone B in the middle. Instead of a single production decision, the program proves value with each increment and the emphasis shifts to sustaining a cadence indefinitely.
The instruction directs programs to plan from day one for continuous deployment into operational environments, including classified and tactical networks, and to fund the software factory, the pipeline and the data rights accordingly. Pathway programs report delivery performance rather than schedule adherence to a baseline that software does not respect anyway.
What is cSTEM, and why does it matter?
cSTEM, the Continuous Science, Technology, Engineering and Mathematics acquisition tracking system, is the department's software-specific oversight tool. It records each program's funded capabilities, releases and delivery velocity, giving senior leaders a portfolio view of what software the department is actually shipping, in contrast to cost-and-schedule dashboards built for hardware programs.
Its importance is contractual as much as managerial. Because pathway programs avoid traditional milestone evidence, delivery data becomes the accountability record: a program that stops shipping shows up in cSTEM, and a program shipping frequently has a defensible case for continued funding. For vendors, being visible in the system with real release history is a currency of its own.
Who approves what under the pathway?
Authority shifts toward the people closest to the code. The pathway empowers a designated senior software leader or program manager to make most decisions that a milestone decision authority would otherwise own, including release decisions and backlog priority. Service acquisition executives retain validation of the pathway's use and oversee the portfolio, while component chief software officers carry day-to-day governance. The effect, intended by the 2020 instruction, is fewer large review boards and more continuous judgment by accountable individuals.
Contractors should note the corresponding expectations: true data rights for government-owned code where specified, access to pipeline metrics, and test evidence generated continuously rather than in a single qualification campaign. Contracts on the pathway increasingly reflect those terms.
Related stories: Digital Twins in Aircraft Programs: What They Actually Deliver to Sustainment · Loitering Munitions and Human Control: Where the Pentagon Draws Its Line.
How is the pathway actually being used?
Through the mid-2020s the pathway moved from experiment to standard practice. Department budget materials and reporting through 2025 describe dozens of programs across the services using the pathway, spanning mission planning, command and control, and sustainment software, while the department continued to press legacy software efforts to adopt its practices. The Air Force's Kessel Run and Space Force and Army software organizations provided the cadre of experienced product managers and developers that pathway programs draw on.
The open problems are cultural and budgetary, not procedural. Program elements written for hardware deliverables resist funding a standing software product line; security accreditation for continuous deployment on tactical networks remains slow; and finding career government product managers is a recognized shortage, per department testimony. The instruction gives permission. Organizations still have to change behavior.
What should a vendor do differently to win pathway work?
Three adjustments stand out. Sell outcomes and a delivery cadence, not a system specification: pathway contracts reward teams that can show shipped, used software every quarter. Be instrumented: pipeline metrics, release history and user telemetry are the evidence a pathway program lives on, and a vendor without them is invisible to cSTEM. Bring a product mindset: pathway programs expect a vendor that iterates on user feedback rather than one that builds to a frozen spec and negotiates change orders.
The firms that treat the pathway as paperwork will lose to those that treat it as a different product relationship with the government.
How does the pathway relate to the other acquisition pathways?
The department's system now runs on parallel tracks: the Software Acquisition Pathway, the Middle Tier of Acquisition for rapid prototyping and fielding, and the traditional Major Capability Acquisition pathway, each with its own instruction. The boundaries blur in practice. Many programs start in Middle Tier, use its flexible authorities to mature a capability, then transition software-heavy elements onto the software pathway for continuous delivery, a route the department formalized in guidance after 2020. Hybrid programs are common in reporting through 2025: a hardware platform on the traditional pathway with a software product line delivered iteratively alongside it. The decision criterion stated in department guidance is the dominant nature of the work: software-dominant efforts belong on the software pathway, and forcing them through hardware gates is what the 2020 instruction was written to stop. Program managers moving between tracks carry lessons both directions, and department reviews describe the pathways as a portfolio to choose deliberately, not a hierarchy to climb.
Frequently Asked Questions
What is DoDI 5000.87?
DoD Instruction 5000.87, signed October 2, 2020, is the instruction establishing the Software Acquisition Pathway. It directs the department to acquire software through continuous iteration: planning around a minimum viable product, executing in short development cycles, and deploying to users continuously. It is the department's stated preferred pathway for software-intensive systems.
Is the Software Acquisition Pathway mandatory for software programs?
It is the preferred pathway per department policy, and programs proposing another route for software-intensive work must justify why. In practice, most new software-dominant efforts enter through the pathway or adopt its practices, while legacy programs continue under earlier frameworks until transitioned.
What is a minimum viable product in defense software?
A minimum viable product is the smallest usable version of a capability that real users can operate and evaluate, delivered early enough to generate feedback that shapes subsequent releases. Pathway planning is organized around defining the MVP, funding it, and standing up the pipeline and test strategy to iterate on it continuously.
How does the pathway handle security and testing?
Through continuous, not terminal, verification. Programs are directed to build a full-spectrum cyber test strategy into each iteration, use DevSecOps pipelines with automated security checks, and pursue continuous authority to operate rather than a single accreditation event. The instruction treats security as an engineering property of the pipeline, verified release by release.