The clock: Programs on the Software Acquisition Pathway must field a Minimum Viable Capability Release within one year of first obligating funds. Traditional certifications to field take anywhere between 12-18 months.

The burden: The current process for bringing commercial software into the DoD such as pathfinding, authorizing, deploying, and scaling, was simply not designed for commercial tech. Instead of a clear, direct highway from requirement to mass deployment, the lifecycle feels like a labyrinth of twists, turns, and moving goalposts. Every phase introduces friction that treats off-the-shelf innovation like a custom hardware build, turning what should be a sprint into a war of attrition.

The root cause: The real blocker isn’t a lack of policy; it’s a lack of trust. Reciprocity has been the official DoD policy for years, yet it remains rarely practiced. Without a common vocabulary for software authorization, risk owners can’t easily evaluate or trust a body of evidence produced by another organization. The result? Receiving risk owners routinely dismiss prior authorizations from sister organizations, forcing vendors and program offices to rebuild evidence from scratch and restart the entire accreditation process.

The “get well plan”: Achieving a rapid 90-day authorization isn’t about luck. It’s about momentum. True partnership isn’t just a signed agreement; it’s a shared dedication to clear hurdles collaboratively so mission-critical capabilities can reach the field at scale.

The processes were built for static things

DoD acquisition was designed to deliver hardware objects, but software is not an object. That fundamental mismatch is the origin of nearly every software fielding problem downstream.

I did not start my career with that macro view of the system; I started with a program in trouble.

When I took my first assignment as a program manager in 2008, “Information Assurance” was the buzzword, clouds were just things in the sky, and software deployment was an afterthought, a secondary component that helped the hardware do its job. My mandate was a turnaround: salvage the Web Content Filtering program that lacked a cohesive strategy tied to mission outcomes, and consequently lacked a funding profile capable of meeting its promised schedule and performance metrics.

Fixing that program meant learning the entire machine at once: requirements collection, contracting, funding, acquisition, testing, certification, deployment, and ultimately assessing whether the end-user had the operational processes to use what actually arrived.

That list is the acquisition problem in miniature. When you view software through a traditional linear lifecycle, every step becomes an obstacle because the processes were built for static, physical assets that take years to deliver. The ultimate lesson, one that took the Department years to realize, was that the real power of cloud computing wasn’t cost savings. It was the ability to achieve ubiquitous access to technology and deploy software at scale, securely, and at an extraordinarily rapid rate.

That foundational realization informed everything I built as my career progressed. As the Deputy DoD Chief Information Officer for the Information Enterprise, I oversaw the portfolio responsible for translating those lessons into systemic policy. I led the pivot from the legacy DoD Cloud Strategy to the DoD Software Modernization Strategy, drove Information Technology (IT) reform across Defense Agencies and Field Activities, and rapidly fielded the Department’s emergency pandemic collaboration tools before converting them into the enduring DoD365 cloud environment.

Later, as the Deputy CIO for the Office of the Secretary of Defense (OSD), I led the creation, resourcing, and management of the OSD IT Enterprise. The playbooks program offices rely on today for continuous authorization, accreditation, and reciprocity are, in a meaningful part, the very frameworks my team and I set out to build and put into practice.

Solving the DoD’s software problem required more than strategic theory. It demanded an understanding of the friction at the lowest level of execution, built from the ground up.

The clock does not care about the paperwork

On paper, the rules are clear: programs under the Software Acquisition Pathway must demonstrate operational capability within 12 months of obligating development funds, and deliver subsequent capabilities at least annually thereafter. DoD Instruction 5000.87 is explicit: the trigger is the money moving, not the vendor being ready.

Reviewing 25 of DoD’s major IT business programs in its 2023 IT Systems Annual Assessment, the U.S. General Accountability Office (GAO) found 16 programs reported cost or schedule changes since January 2021, including 12 with schedule delays running three to 33 months, a median of 24 months. In 2025, the GAO published the IT Systems Annual Assessment that looked at 24 programs and found 14 reporting cost or schedule changes since January 2023, seven of them with delays of three to 48 months, a median of 15 months.

These are major IT investments on the Federal IT Dashboard rather than a sample of Software Acquisition Pathway programs, so the comparison is directional. It is still instructive, though. A 15-24 month median delay is up to double the entire window the pathway allows for fielding anything at all.

The structural bottleneck is obvious: traditional authorization for a commercial cloud service takes 12 to 18 months, stretching to 24 or 36 months at higher Impact Levels. A program manager cannot field software in 12 months when the authorization process alone consumes 18.

That brutal arithmetic dictates which commercial vendors survive in this market. It’s easy to look at those numbers, throw up your hands, and declare the system is broken beyond repair. That frustration is understandable. But if we step back and examine the full picture, we can pinpoint exactly where—and how—to drive meaningful progress step by step.

The vocabulary problem underneath everything 

Here is where the gap between the designed system and the operating system is widest.

The mechanism for fielding software quickly and at scale was supposed to be reuse: one organization assesses a product, generates a body of evidence, and other Authorizing Officials (AOs) draw on that evidence to inform their own risk decisions rather than starting over. The policy exists. The U.S. Office for Management and Budget (OMB) reinforced it with a “presumption of adequacy,” directing agencies to reuse existing certifications to the maximum extent. The DoD CIO issued playbooks for continuous accreditation built on the exact same logic. The National Defense Authorization Act (NDAA) FY2025 defined “presumptive reciprocity” and NDAA FY2026 articulated the reporting metrics for the Department to use to show progress. Despite the policy, the practice of reciprocity is minimal at best.

When I was in government, my focus was building those pathways, issuing playbooks for continuous accreditation so different organizations could leverage a single body of evidence and reuse it based on need. The mission outcome was to mirror authorization decisions to match how modern software is actually deployed: dynamically, at scale, and at a high operational tempo. The thesis remains sound, and progress has been made, but there remains an overwhelming disconnect in authorizing software quickly and consistently. 

That is the reality every program officer and vendor must sit with: the primary tool designed to solve the software fielding problem is widely available, yet largely unused.

Which raises the question of why. The answer isn’t what most vendors assume.

Reciprocity fails for a reason both mundane and decisive: practitioners across the Department do not use the same words to mean the same things. We are talking past each other.

This may be the root cause of why enterprise-at-scale capabilities are nearly impossible to deliver: we don’t use the same language to describe who is doing what. If DoD teams are talking past each other on simple terms, imagine the challenge of accepting a body of evidence from a different organization to inform your risk decision. Without a shared vocabulary, there is a feeling of not trusting external data sources. Risk decision-makers default to starting over because they feel compelled to personally understand and articulate every element of risk.

Follow that causal chain; it explains behavior that might otherwise look like pure bureaucratic inertia or turf protection:

1. A risk owner is personally accountable for an authorization decision.
2. To accept risk, they must be able to articulate it clearly to their leadership.
3. To articulate it, they must fully understand what the incoming body of evidence actually asserts.
4. When terminology drifts between organizations, that evidence becomes unreadable in a specific and disqualifying way.

Fixing this vocabulary gap is worth more to software fielding speed than any single policy memo; it is the absolute prerequisite for every reuse mechanism already on the books. Until that enterprise baseline is established, the only practical lever is to sidestep the translation problem entirely: place software inside an authorized boundary the receiving organization already trusts, backed by a body of evidence they already recognize.

The ISV “Get Well Plan”

For a commercial software vendor, the strategic reality comes down to a single metric: time. The program manager wants your capability today, but cannot afford a year-long detour to navigate authorization. Every month cut from that accreditation timeline directly translates to mission impact in the field. Whether you realize it or not, time-to-authorization is your primary competitive advantage.

The critical misstep usually happens during the initial discovery call. Vendors routinely underestimate the sheer level of effort required to achieve DoD compliance. Companies entering highly restricted defense environments for the first time often arrive with nascent security controls. Closing those regulatory gaps requires substantial, focused work that someone must execute.

Unless you’ve been through the gauntlet, there is no way of knowing how to navigate it. Second Front exists to bridge this gap, partnering with commercial innovators whose technology the DoD desperately needs, but who lack the specialized roadmap and/or talent to clear security hurdles.

The vendors who succeed in achieving a 90-day authorization alongside its partnership with Second Front match our intensity. They burn down findings, clear hurdles, and execute the tasks needed to graduate to the next phase of delivery. Rapid deployment at scale requires a true partnership, one built on shared goals, transparent collaboration, and momentum.

Connect with our team to learn how Second Front’s Game Warden platform accelerates commercial software through IL2–IL6 and Top Secret environments, delivering trusted, field-ready capabilities at mission speed and scale.

Frequently asked questions

About the author

Danielle Metz

Chief Policy Officer, Second Front

Danielle Metz serves as the Chief Policy Officer for Second Front Systems. She spearheads engagement efforts to advocate for new policies that enhance the deployment of software applications critical to national security missions.

More from this author