The ATO is a queue.
The package is the ticket.
Defense software doesn’t die in the field. It dies in the authorization queue, while a customer who already loves the prototype waits for someone to prove the software is what it says it is. This page is what an Authority to Operate actually asks for, why it takes months, what the Department changed in 2025 and 2026, and what it means to build software so the package is a byproduct of the build, not a project after it.
Last checked September 12, 2026 · sources in the footnotes · not acquisition or legal advice
Prove the system is what you say it is.
Then prove it again after every change.
Under the Risk Management Framework a system is categorized, its controls selected and implemented, assessed by someone independent, authorized by an authorizing official, and then monitored. The authorization rests on a package: the system security plan (what the system is and how each control is met), the security assessment report (what the assessor found), and the plan of action and milestones (what is still open). Under Software Fast Track, add the software bill of materials for sandbox and production, certified by a third party.
Every one of those documents describes a record: how the software was built, from what, changed by whom, checked against what, approved by whom. For most systems that record does not exist. It is reconstructed, by people, after the fact, and reconstructed again when the software changes. That reconstruction is the queue.
The Department has written down
what it wants instead.
Four signals, each from the Department itself, each asking for the same thing: evidence that exists when the assessor asks, reusable across components.
Software Fast Track.
The “Accelerating Secure Software” memo established SWFT: vendors supply a third-party-certified SBOM from production and sandbox, uploaded to eMASS, with independent assessment, so an authorization can be validated once and reused. A pilot in 2025; the Department’s stated path since.
The traditional ATO still slows fielding.
Six years after the SWAP study recommended ATO reciprocity between programs, Services, and agencies, the Board reported that manual reviews and after-the-fact documentation still delay critical software.
Rapid ATO reciprocity, named as mission-critical.
The strategy directs the Chief Digital and AI Office to work with the CIO to accelerate AI capability delivery, including rapid ATO reciprocity. AI features are the software that dies hardest in the queue, because the assessor has to ask what the model did.
Continuous ATO, approved in production.
The Army reported its first approved continuous-ATO platforms. A cATO rests on continuous monitoring of controls, active defense, and an approved DevSecOps pipeline: the system proves itself as it runs and changes, not once every three years.
Nobody sells the build layer that produces this. That is the gap.
Build the software so the package
is a byproduct.
On Haltere a change cannot reach production without passing four stations, and each station writes the record the assessor will ask for. Nothing is assembled later, because nothing can run without it.
The submission is an export. The reconstruction never happens.
Ten things to have on hand.
If any of these is a project rather than a query, that is where your ATO clock goes. Score yourself honestly.
A current diagram of the system boundary that matches what is deployed.
Every service and dependency in the build, with versions, as of the last release.
An SBOM for sandbox and production, reproducible from the exact commit.
Every change since the last assessment, with who proposed, reviewed, and approved it.
For any code an agent wrote: the model, the prompt, the checks, the approver.
Who can do what, enforced by your identity provider, and the record of every grant.
Append-only, queryable, correlated end to end, including the async hops.
For AI features: any decision from last month, reconstructed in one query.
The changes that failed policy and never merged, with the reason.
A package another program’s assessor could read without calling your engineers.
Seven or more as queries: you are close to continuous. Fewer than four: the build layer is the problem, not the assessor. How the governed production build closes the gap
What we do,
and what we don’t claim.
Haltere does not grant authorizations, assess systems, or hold impact-level authorizations on your behalf. Authorizing officials and assessors do that work, and your ISSM owns the package. What we do is build and operate software inside your boundary so that every artifact the package needs already exists, generated by the work itself, when they ask. Understood, controlled, traceable, correct: by construction, not by memo.
What a program will want to know.
How long does an ATO take?
Months, and often more than a year, for a system that has to assemble its evidence after the fact. The Defense Innovation Board said in 2019 that the process needed reciprocity and said again in January 2025 that the traditional process still slows fielding. The time is not the assessment. It is the reconstruction: producing, for a system that already exists, the record of how it was built, changed, and controlled.
What is Software Fast Track (SWFT)?
The DoD CIO’s initiative, established by the “Accelerating Secure Software” memo of April 24, 2025, to speed software authorization. Its mechanism is evidence a vendor supplies up front: a software bill of materials from both sandbox and production, certified by a third party and uploaded to eMASS, plus independent assessment, so an authorization can be reused across the Department instead of repeated by every component.
What is a continuous ATO?
An authorization that stays valid because the system proves itself continuously instead of once every three years. The Department’s 2022 cATO guidance rests on continuous monitoring of controls, active defense, and an approved DevSecOps pipeline. In April 2026 the Army reported its first approved cATO platforms. A cATO is only possible if evidence is generated by the system as it runs and changes. That is the design requirement this page is about.
Does Haltere grant ATOs or assess systems?
No. Authorizing officials authorize; assessors assess. Haltere builds and operates software so that the evidence they ask for exists the moment they ask: the SBOM at the frozen commit, the change record with names on it, the control evidence, the decision record for AI features. The submission becomes an export.
We are a small company with a Phase II award and no compliance staff. Is this for us?
Yes, precisely. AFWERX’s own guidance says it is not structured to pay for ATO services on SBIR/STTR efforts, so the package is your problem, with your award clock running. The governed production build takes the prototype your customer already loves onto a line where the package is a byproduct of the build.
Bring us the prototype your customer loves.
Tell us the award, the customer, and where the authorization stands. Fifteen minutes: you tell us what the ISSM has asked for, we tell you straight whether a governed production build makes the package a byproduct. No is a fine answer.
No newsletter. No drip sequence. Every request gets a real reply within one business day, from someone who can answer it.
