As a Joint Terminal Attack Controller (JTAC), I could clear a danger-close airstrike, accepting the risk of dropping ordnance within meters of friendly troops, in seconds, under a ground commander's authorization.
A software change to the very system that runs that kill chain waits months for an authorization from someone who has never been downrange and will never meet the mission it governs.
BLUF: Authorization is a warfighting function — when a software update is a munition, the authorization queue is a rationed magazine — and we've handed it to the wrong people. The authority to operate (ATO) a mission system should sit with the commander of the mission thread, not a distant Authorizing Official (AO). Commanders already own mission risk; let them own the software pipeline and the rollback too, with the AO as their staff advisor instead of a disconnected gate. The mechanism to do this already exists. We just haven't treated it as a transfer of authority.
The gate is in the wrong hands
The Risk Management Framework (RMF) treats authorization as a paperwork gate, owned by an AO who sits outside the mission and measures success by the absence of findings. The result is the queue every operator and entrepreneur knows: a fix is ready, the threat is live, and the change sits for months waiting on a signature from someone with no stake in the outcome and no feel for the cost of waiting.
Think about what that says. We trust an O-5 to accept the risk of lethal force against human beings. We do not trust that same commander to accept the risk of a software update to their own system. The authority to kill is delegated to the edge; the authority to patch a memory leak is hoarded at a desk.
We trust a commander to authorize a strike. We won't trust them to authorize a software update.
That inversion isn't a safety measure. It's a bottleneck we've mistaken for one.
The mechanism already exists
This isn't a call to abolish controls. It's a call to move who holds them and to let them run at machine speed. The Department already built the tool: in 2022 it issued continuous authorization to operate (cATO) guidance that authorizes a pipeline and its monitoring once, rather than re-litigating every change.[1] The technology problem is solved. What's missing is the command decision to treat cATO as a transfer of authority, not a new compliance badge.
Make authorization a command responsibility:
- Move the ATO under the mission-thread commander. The person who owns the mission owns the authorization, the pipeline, and the rollback.
- Turn the role of the AO into a staff advisor. The expertise is real and valuable. It belongs on the commander's staff, informing the risk decision, not standing astride it as a gate.
- Express controls as code. National Institute of Standards and Technology (NIST) 800-53, Security Technical Implementation Guides (STIGs), and mission rules of engagement (ROE) become automated checks in the pipeline. Compliance is proven continuously, not narrated once a year.
- Let evidence be exhaust. The pipeline emits its own audit trail as a byproduct of running. The commander gets a live view of control status; nobody assembles a binder.
What "right" looks like
The reason a commander can trust this isn't a leap of faith; it's a different definition of safety. Safety isn't the absence of findings on a checklist — it's the presence of control. System-Theoretic Process Analysis (STPA) makes that the standard, and a once-a-year PDF proves neither.
"Control" isn't one tool for everything; the right form of assurance depends on what you're authorizing. Firmware in a guided bomb's seeker, built without a sprawling tree of external dependencies, is a job for automated certification of the code itself — the evidence-based approach the Defense Advanced Research Projects Agency (DARPA) built as Automated Rapid Certification of Software (ARCOS) — not a software bill of materials (SBOM) scan of libraries it doesn't have. Software headed into procurement should get STPA run up front by the plans shop (the J5/A5/G5/N5), so the control problem is engineered down before it ever reaches RMF. And anything delivered continuously — a software factory's government build or a commercial product alike — should run on continuous RMF (cRMF) and a cATO pipeline by default. Different contexts, one principle: prove control continuously, in the form the system actually takes.
So what the commander watches isn't a binder; it's the pipeline proving itself in real time — controls-as-code passing or failing against NIST 800-53 and the STIGs, an SBOM and provenance on every build, patch latency against a time-to-patch (T2P) objective, a rollback measured in minutes to a known-good state, and the share of controls inherited without re-auditing. That's a live view of risk, the way a JTAC watches a stack — and it means a fix ships, and rolls back, faster than an adversary can exploit the gap.
Be honest about the cost: none of this is easier for the program office. Continuous RMF and up-front STPA are more work for the program manager and the contracting officer than mailing in an annual package. They do it anyway, because it buys three things at once — software that's more secure, better tools in the warfighter's hands faster, and a lower bill for the taxpayer. Three wins are worth a harder job.
The objections, answered
"Commanders aren't cyber experts." They aren't weather experts or fires experts or legal experts either, and they still own those risks, advised by staff who are. Authorization is no different. The AO's knowledge moves onto the staff; the decision moves to the person accountable for the mission.
"This weakens security." The opposite. Controls expressed as code and checked continuously are stronger than a once-a-year review that produces a static document and a false sense of safety. A shiny PDF is not security. A fix that ships in hours shrinks the window an adversary gets to exploit actually is.
"The AO role exists for a reason." It does, and the expertise survives. What ends is an authority structure that separates the risk decision from the person who bears the mission consequence of getting it wrong, in either direction. An AO rarely sees the mission ramifications of sitting on a fielding decision. As a combat operator, I have, and some of the errors have been horrifying and cost actual lives.
The fix
Delegate the ATO to the mission-thread commander, make the AO a staff advisor, and run authorization through a cATO pipeline where controls are code and evidence is automatic. The guidance to do this has existed since 2022. What's required now is a decision to trust commanders with the authority to patch the systems we already trust them to employ.
What you can do Monday
- Unit commanders: Ask who holds the ATO for the systems you fight with, and how long your last change waited in the queue. Put the number on a slide.
- PEOs / PAEs: Stand up a cATO pipeline for one mission system and designate the mission-thread commander as the authorizing authority, with the AO advising.
- Contracting officers: Require delivery into a continuously authorized pipeline, with controls-as-code and automated evidence, as a condition of acceptance.
- Authorizing Officials: Move onto the commander's staff. Trade the gate for a seat at the risk decision, where the expertise actually helps.
- DIU and the service innovation organizations: Make a commander-owned cATO pipeline a default deliverable of the commercial systems you field, not a follow-on project — the on-ramp that lets a commercial vendor ship into a classified enclave without forking its codebase. For dual-use software, buy the commercial license and own the data, not the vendor's intellectual property.
- OSD: Reissue the cATO guidance as a command-authority policy: who owns the ATO, and the AO as advisor by default.
- Congress: No new authority needed. Ask the Department for the median time a software change waits for authorization, and why a commander trusted with lethal force isn't trusted with that decision.
The conversation happens on LinkedIn — come argue with me there.