The Army's MSD IDIQ Is Really About Continuous ATO

The dollar ceiling on a multiple-award IDIQ is the least interesting number in the announcement. Ceilings are not spending, and a vehicle with a large ceiling and no task orders is a promise.

The interesting part of the Army's Modern Software Delivery IDIQ is the obligation it places on the winner. The Army has been building a continuous authorization process to replace the periodic reauthorization cycle, and its approach was informed by two pilot programs (opens in a new tab). Put that together with a software delivery vehicle and the contract stops being about shipping a system. It becomes about keeping one authorized.

That is a different business, and most contractors are still bidding the old one.

What continuous authorization actually changes

An authority to operate has historically been a document with an expiry date. You assemble the package, you get the signature, and you have three years. The three years are the problem: the system drifts, the controls decay, and everybody discovers the drift at the next review.

Continuous authorization replaces the event with a process. Controls are assessed on a schedule, evidence is generated by the system rather than assembled by a person before a review, and the authorization is maintained rather than renewed.

Two consequences follow immediately.

First, the evidence has to come from the pipeline. A control that is attested in a spreadsheet is a control you re-verify by hand every cycle. A control that reads a configuration from the deployed environment is a control that can be checked on Tuesday afternoon without a meeting.

Second, somebody has to own the evidence. Not the deliverable, the evidence. In most programs that is nobody's full-time job until the review is three weeks away, which is exactly the failure mode continuous authorization exists to fix.

A continuous authorization is a data product. If nobody owns the data, you have a periodic authorization with better branding.

Why the vehicle matters as much as the policy

A multiple-award IDIQ with task orders changes the unit of competition. You are not bidding a five-year transformation. You are bidding an increment, and then the next one, against companies that are also on the vehicle.

That structure rewards a specific capability: the ability to show a working, authorized increment quickly and then keep showing it. It punishes the program-management skill of promising a big delivery at the end, because the end keeps moving and the customer can see the increments that did not arrive.

For an incumbent, this is the uncomfortable part. The old model let a contractor recover a slow start with a strong finish. The new model is a running scoreboard, and a slow start is visible in month four.

What a bid has to prove now

If authorization is continuous, the proposal has to answer questions that most teams treat as post-award work.

1. Where does the evidence come from? Name the systems. Configuration management, the CI pipeline, the vulnerability scanner, the access control system. If the answer is "the ISSO collects it," you have described a person, not a process.
2. What is automated, and what is not? Be specific about the control families you can instrument and the ones that stay manual. A credible bid admits the manual ones and says who does them.
3. Who signs when something drifts? Continuous authorization requires a decision path for a failed control that does not wait for a board meeting. Name the role and the response time.
4. What happens at a significant change? New data, new boundary, new dependency. The process has to say which changes trigger a re-assessment and which do not, or every change becomes an argument.
5. How does the government read the evidence without you? This is the one contractors skip. If the evidence lives in your tooling and your dashboard, the government cannot verify it and cannot transition it. That is a rejection risk disguised as a convenience.

None of these are engineering novelties. They are the ordinary work of running a system in a way that produces proof. The difference is that the contract now pays for the proof, and the absence of it is a finding rather than an inconvenience.

Where contractors get this wrong

The common mistake is to treat continuous authorization as a documentation deliverable and staff it with the proposal team. That produces a beautiful control matrix and no instrumentation.

The second mistake is to defer automation to a later phase. There is no later phase. The first task order is where the pattern gets set, and a manual process installed at the start does not get automated during a period of performance that is already behind.

The third mistake is organizational. Continuous authorization needs an engineer who owns the evidence pipeline and has the standing to block a release when a control fails. Most contractors give that responsibility to a compliance lead with no authority over the deployment, which produces a report that is accurate and ignored.

The honest read

The Army is not buying software. It is buying a delivery capability that stays authorized, and it has designed a vehicle to buy that capability in increments from more than one company.

Contractors who can show an authorized increment with machine-generated evidence will do well on this vehicle, because that is the thing being scored whether or not the evaluation criteria say so plainly. Contractors who bid a schedule and a staffing plan are bidding the previous decade.

The work is not glamorous. It is logging, control mapping, and a release gate that actually blocks. That is also the work that survives an audit, which is the only test that matters after the award.