.svg){kind=icon}
Learn
Continuous ATO (cATO) is a DoD authorization state in which a system maintains its authorization to operate through ongoing monitoring, active cyber defense, and a secure DevSecOps software supply chain instead of periodic re-authorization.
Why it matters to your mission. A traditional authorization expires, so every model update or code change risks dropping a capability out of compliance until it is re-authorized months later. Continuous ATO keeps the authorization current by monitoring risk in real time instead of re-certifying on a calendar. The outcome is mission software, including AI, that can be improved and re-deployed without losing the right to operate.
Continuous ATO (cATO) is a DoD authorization state in which a system maintains its authorization to operate through ongoing monitoring, active cyber defense, and a secure DevSecOps software supply chain instead of periodic re-authorization.
A traditional authorization to operate is a point-in-time decision that expires and has to be renewed on a cycle. For software that ships weekly, and for AI whose behavior changes every time a model is retrained, that cycle is the bottleneck: the system evolves faster than the paperwork that permits it to run. Continuous ATO addresses that gap directly by shifting the authorizing official from periodic snapshots to a continuously maintained, real-time view of the system's risk.
cATO is the specific DoD authorization state that operationalizes the broader discipline described in accredited AI deployment. That page covers the whole fielding path: the Risk Management Framework, impact levels, zero trust, and cross domain solutions. This page covers one element of it: what cATO requires, how it differs from a traditional ATO, and why it is the authorization model that lets defense AI keep pace with the mission.
Key takeaways
Continuous ATO is a formal DoD authorization state, not a faster way to earn a one-time ATO. In the DoD CIO's February 2022 memorandum Continuous Authorization To Operate (cATO), the DoD Senior Information Security Officer directs that a system can operate in a cATO state once its authorizing official can demonstrate real-time risk management across the system rather than assessing it only at authorization and renewal.
The memo is explicit that current Risk Management Framework practice stops at obtaining the initial authorization and falls short on continuously monitoring risk afterward. cATO closes that gap. A DoD CISO-approved cATO carries no expiration date and remains in effect as long as the required real-time risk posture is maintained, which is the structural difference from a traditional ATO that lapses on a schedule.
Two points keep cATO from being misread as a loophole. It does not lower the control baseline; the DoD CIO frames it as a raise-the-bar effort and a privilege, not a shortcut. And it does not replace the underlying ATO; it changes the requirements for re-authorizing the system, so the authorization itself still exists and can still be revoked.
To place a system in a cATO state, the DoD CIO memo requires the authorizing official to demonstrate three competencies. These are the load-bearing requirements, and a plan that is missing any one of them is not a cATO plan.
Together these three make authorization a running capability instead of a document: monitoring supplies the evidence, active defense supplies the response, and the secure pipeline supplies the controlled path by which new code, or a new model, enters production without leaving the authorization boundary.
The difference is not the rigor of the controls; it is the shape of the authorization over time. A traditional ATO proves a system was secure on the day it was assessed and sets an expiration by which it must be proven again. A cATO proves the system is secure continuously and removes the expiration in exchange for sustained, demonstrable real-time risk management.
| Dimension | Traditional ATO | Continuous ATO (cATO) |
|---|---|---|
| Authorization basis | Point-in-time assessment of controls | Continuously maintained, real-time risk posture |
| Expiration | Fixed term; must be re-authorized on a cycle | No expiration while the real-time posture is maintained |
| Risk visibility | Assessed at authorization and renewal | Monitored continuously via a system-level dashboard |
| Handling change | A significant change can trigger re-authorization | Change flows through an approved DevSecOps pipeline inside the boundary |
| Threat response | Defined in plans; reviewed periodically | Active cyber defense acting in real time |
| How it is lost | Lapses when the term expires | Can be revoked if the real-time posture degrades |
| Fit for AI | Poor; a retrained model outpaces the renewal cycle | Strong; a new model state is re-deployed through the pipeline |
cATO is not less work than a traditional ATO; it sustains the monitoring, defense, and pipeline maturity that a traditional ATO only samples. What the mission gets back is the ability to change the system continuously without each change becoming an authorization event.
Most defense software benefits from cATO. AI requires it. AI breaks the assumption a traditional ATO depends on, which is that the authorized system stays fixed between assessments.
When a model is retrained on new data, its behavior changes, and from a control-assessment standpoint it is a new system state. Under a traditional ATO, that retrain can trigger re-authorization, which means a model improvement waits on a paperwork cycle, or worse, the model is frozen at the state it was first accredited in so it does not disturb the authorization. Both outcomes defeat the point of fielding AI. cATO fixes this: the retrained model moves through the same approved DevSecOps pipeline, under the same continuous monitoring, so it can be re-deployed without dropping out of authorization.
This is also why the audit trail matters more for AI than for ordinary software. An authorizing official sustaining a cATO on an AI system has to see not only that the controls are green but why the system produced a given result. Traceability is not a reporting nicety here; it is part of the real-time risk picture the authorization rests on.
A cATO is granted through a defined approval chain and held only as long as the posture that earned it holds. The DoD CIO memo sets out the path and the conditions.
The authorizing official notifies the component CISO of the intent to move a system to a cATO state, and the two present the request with its supporting body of evidence to the DoD CISO for consideration. Approval is deliberate rather than automatic, which is consistent with cATO being treated as a privilege and a higher standard.
Keeping a cATO is conditional. The memo is clear that a cATO can be revoked for a poor cybersecurity posture identified through continuous monitoring or external assessment, a change in risk tolerance, or a cybersecurity incident stemming from poor adherence to practices. A system can temporarily lose its cATO privilege without losing its underlying ATO, so the consequence of a lapse is a return to conventional re-authorization, not an immediate shutdown. That design keeps the incentive on sustaining the real-time posture rather than passing a one-time test.
cATO is the DoD's operational expression of an idea already present in the Risk Management Framework. The framework, defined in the National Institute of Standards and Technology's NIST Special Publication 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations, promotes near real-time risk management and ongoing authorization through continuous monitoring, rather than treating authorization as a single event.
In other words, RMF supplies the doctrinal root, ongoing authorization and continuous monitoring, and the DoD CIO cATO memo supplies the specific DoD implementation: the three competencies, the approval chain through the DoD CISO, the no-expiration condition, and the revocation criteria. A team scoping a cATO is implementing RMF's continuous-monitoring intent, not departing from it.
Torch.AI builds government-owned reasoning infrastructure designed to deploy and sustain authorization in mission environments, and to complement existing systems of record rather than replace them. ORCUS is the government-owned data-availability layer that runs in accredited environments; NEXUS makes data meaningful; HALO makes relationships understandable. Every determination preserves an audit trail, the traceability an authorizing official needs to sustain real-time risk decisions on an AI system.
Because the infrastructure is government-owned and auditable, the authorizing official keeps the monitoring feeds, the control evidence, and the audit trail that a cATO depends on, rather than relying on a vendor to produce them on request. That ownership makes the continuous-monitoring competency credible: the evidence the authorizing official reasons over is theirs to inspect and govern. You can see how this is packaged as a capability on the Torch.AI software page.
A secure DevSecOps pipeline that produces consistently configured, continuously scanned builds lets a retrained model re-enter production through the approved path rather than as an authorization event. Paired with continuous monitoring at the data layer and a preserved audit trail, that pipeline keeps an AI capability inside its authorization boundary while it keeps improving. The result is AI that can be re-deployed as the model changes, not demonstrated once and frozen.
A credible cATO is designed in from the start, not retrofitted. Require these:
Scoping a cATO path for an AI capability? The seven requirements above are the backbone of a continuous-ATO evaluation. Bring them to a scoping call and we will walk each one against your environment and target authorization boundary: request a technical walkthrough.
Continuous ATO is a DoD authorization state in which a system maintains its authorization to operate through ongoing monitoring, active cyber defense, and a secure DevSecOps software supply chain instead of periodic re-authorization. Per the DoD CIO's 2022 memorandum, a DoD CISO-approved cATO carries no expiration and remains in effect as long as the required real-time risk posture is maintained.
The DoD CIO memo requires the authorizing official to demonstrate three competencies: continuous monitoring of the full set of security controls with real-time risk decisions, active cyber defense that responds to threats in real time, and a secure software supply chain aligned to an approved DoD DevSecOps reference design.
A traditional ATO is a point-in-time decision that expires and must be renewed on a cycle, whereas a cATO is sustained through continuous real-time risk management and carries no expiration while that posture holds. cATO is not less rigorous; it replaces periodic sampling with continuous monitoring, active defense, and a controlled DevSecOps pipeline.
Because a retrained model is effectively a new system state, a traditional ATO can force a model improvement to wait on a re-authorization cycle or freeze the model at its originally accredited state. cATO lets a retrained model re-enter production through the same approved pipeline and monitoring, so it is re-deployed without dropping out of authorization.
The authorizing official notifies the component CISO and presents the request with supporting evidence to the DoD CISO for approval. A cATO can be revoked for a poor cybersecurity posture found through monitoring or assessment, a change in risk tolerance, or an incident from poor practice, and a system can lose the cATO privilege without losing its underlying ATO.
cATO is the DoD's operational implementation of the ongoing authorization and continuous monitoring already described in NIST SP 800-37 Rev. 2. RMF supplies the doctrinal intent of near real-time risk management, and the DoD CIO cATO memo supplies the specific DoD requirements: the three competencies, the approval chain, the no-expiration condition, and the revocation criteria.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
