Summary
  • A continuous ATO is not a product or a certificate. It is an authorizing official's decision to keep a system authorized while continuous monitoring shows its risk stays acceptable.
  • NIST calls the general model ongoing authorization. It is described in SP 800-37 Rev. 2 and depends on a continuous monitoring program built to SP 800-137.
  • The DoD memo of February 2, 2022 sets three requirements for a cATO: continuous monitoring of RMF controls, active cyber defense, and an approved DevSecOps reference design.
  • In DoD, the authorizing official and the component CISO present the request and its evidence to the DoD CISO. A tool cannot grant a cATO.
  • The work is evidence: current control state, a record of every change, a living POA&M, and a stated tolerance the system can be checked against.

What Is a Continuous ATO?

An Authorization to Operate (ATO) is the decision by an authorizing official to accept the risk of running a system. Under the Risk Management Framework, that decision has traditionally been made at a point in time, on the strength of a package, and revisited on a schedule that is commonly three years.

A continuous ATO, also written continuous authorization to operate, continuous authority to operate, or cATO, changes the timing of that decision and not who makes it. The system stays authorized for as long as continuous monitoring shows that its risk remains inside what the authorizing official accepted. Review happens when something changes, not when a calendar says so.

Two definitions are in use, and it helps to keep them apart:

  • Ongoing authorization is NIST's term. It is described in SP 800-37 Rev. 2 and is open to any federal system with a mature continuous monitoring program.
  • cATO is the Department of Defense's term. It was set out in a memo from the DoD Senior Information Security Officer dated February 2, 2022, with three specific requirements.

Neither one removes the authorizing official. Software does not grant an authorization, continuous or otherwise.


Continuous ATO Compared With a Traditional ATO

Traditional ATOContinuous ATO
The decisionMade at a point in timeStays in force while conditions hold
ReauthorizationDriven by time, commonly every three yearsDriven by events, when risk changes
EvidenceAssembled for the assessmentCollected continuously
What the official seesA packageCurrent posture against a stated tolerance
A significant changeCan trigger a new assessmentIs assessed as it ships
The failure modeThe package drifts away from the systemMonitoring gaps go unnoticed

The last row matters. A traditional ATO fails quietly when the documents stop matching the system. A continuous ATO fails quietly when a control stops being observed and nobody notices. Any serious continuous ATO program has to treat missing observation as a finding in its own right.


What NIST Says: Ongoing Authorization

NIST SP 800-37 Rev. 2 describes ongoing authorization as a time-driven or event-driven process. The authorizing official receives the security information needed to decide whether continued operation is acceptable, and receives it through continuous monitoring instead of through a periodic reassessment.

Two conditions come first:

  1. The system already holds an authorization. Ongoing authorization continues a decision. It does not replace the first one.
  2. A continuous monitoring program is in place. NIST SP 800-137 calls this information security continuous monitoring: a defined strategy that says which controls are monitored, how often, and by what method, and that reports the results to the people who decide.

Under ongoing authorization, reauthorization becomes mostly event-driven. New threat or vulnerability information, a rise in findings, or a change in mission can all prompt the official to look again. NIST's earlier paper on the subject, Ongoing Authorization: Transitioning to Near Real-Time Risk Management, was folded into Rev. 2 of SP 800-37.


What DoD Requires: The Three cATO Requirements

The DoD memo of February 2, 2022, signed by the DoD Senior Information Security Officer, says an authorizing official must be able to demonstrate three things for a system to move to cATO:

  1. Continuous monitoring of RMF controls. The memo asks for ongoing visibility of key cybersecurity activities inside the system boundary, with robust continuous monitoring of the controls.
  2. Active cyber defense. The ability to respond to cyber threats in real time.
  3. An approved DevSecOps reference design. Software is built and delivered through a pipeline the Department recognizes, with a secure software supply chain.

The approval path is set out in the same memo. The authorizing official and the component CISO present the request and the supporting body of evidence to the DoD CISO for consideration. A cATO approved this way has no expiration date, and it can be revoked if the real-time risk posture is not maintained.

The DoD CIO followed the memo with two documents that say how a program shows it meets the bar: the DevSecOps Continuous Authorization Implementation Guide (version 1.0, March 2024) and the cATO Evaluation Criteria (May 2024).


After 2025: The Cybersecurity Risk Management Construct

In September 2025 the Department announced the Cybersecurity Risk Management Construct. It describes a lifecycle of five phases (design, build, test, onboard, and operations) built around automation and continuous monitoring, and it is intended to replace point-in-time reviews inside the Department.

For a program, the practical effect is the same pressure a cATO already applied, with more weight behind it: current, machine-collected evidence instead of documents assembled for a review. Confirm with your component which guidance governs your system today. For civilian agencies, the Risk Management Framework in SP 800-37 remains the governing process.


What a Continuous ATO Takes in Practice

Whichever definition applies to you, the same seven things have to exist before an authorizing official can reasonably keep a system authorized without a periodic reassessment.

1. A boundary and a baseline

The system boundary is defined, the SP 800-53 Rev. 5 baseline for its impact level is selected, and inherited controls are identified with their source.

2. A monitoring strategy

A written strategy says which controls are monitored, at what frequency, and by what means. Controls a cloud control plane can show, such as configuration, access, and logging settings, can be checked many times a day. Controls that rest on policy, people, or facilities are reviewed on a schedule.

3. Evidence with a time on it

Every observation carries the time it was taken and where it came from. An assessor or official should be able to ask what was true on a given date and get an answer that does not depend on anyone's memory.

4. A record of change

Every change inside the boundary has an actor, an authority, and a before and after state. A change nobody can explain is a finding.

5. A living POA&M

Findings open when they occur and close when they are fixed, with the evidence of the fix. The Plan of Action and Milestones is never rebuilt from scratch for a review.

6. A stated tolerance

The authorizing official says what is acceptable: for example, how long a high finding may stay open, or which control families may not regress. The system is then checked against that statement, and the official is told when it falls outside it.

7. Declared gaps

When a collector fails or a control stops being observed, that is recorded as a gap. A dashboard that stays green because nothing is being measured is the most dangerous outcome in continuous monitoring.


Common Misreadings

"A tool gives you a continuous ATO." No. The authorizing official decides, and in DoD the request goes to the DoD CISO with its evidence. A tool can produce the evidence the decision rests on.

"A continuous ATO means no more assessments." Assessment does not stop. It becomes continuous, and independent assessors still test controls.

"It only applies to software factories." The DoD memo is written around DevSecOps. NIST's ongoing authorization applies to any federal system with a mature monitoring program.

"Continuous monitoring is vulnerability scanning." Scanning is one input. Continuous monitoring covers whether controls remain effective, what changed, and whether the risk is still inside the official's tolerance.


Where PolicyCortex Fits

PolicyCortex is built for the evidence side of this work. It runs inside your own boundary and keeps three records: Proof of State for what was true on any date, Proof of Change for what changed and who approved it, and Proof of Agency for what automation was allowed to do.

For authorization, it records each authorizing official's decision with the frozen package it rested on, checks authorized systems every hour against the official's tolerance, and generates the SSP, SAR, and POA&M from one implementation record. Every exported package carries an evidence chain an assessor can verify offline, with no PolicyCortex account.

It does not grant an authorization. The authorizing official decides what operates.


Questions

Is cATO the same as ongoing authorization?

They describe the same idea from two sources. Ongoing authorization is NIST's general model in SP 800-37 Rev. 2. cATO is the DoD term, with three requirements set in the DoD memo of February 2, 2022.

Who approves a continuous ATO?

The authorizing official. In DoD, the authorizing official and the component CISO present the request and its evidence to the DoD CISO.

Does a continuous ATO expire?

A cATO approved by the DoD CISO has no expiration date. It can be revoked if the real-time risk posture is not maintained.

What controls are monitored?

The controls in the system's SP 800-53 baseline, at the frequency the monitoring strategy sets for each one.

What is the first step?

Hold a current authorization, define the boundary, and write the monitoring strategy. Automation comes after the strategy, not before it.


Sources

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages, the architecture page, and the two pages on authorization.

proof.state
Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change
Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency
Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture
Architecture. How the chain is built and where the evidence is stored in each delivery mode.
authorization
Continuous ATO. How an authorizing official's decision is recorded with its package, and how the authorized system is checked against it every hour.
baseline
NIST SP 800-53. The Low, Moderate and High baselines as evidence, with the SSP, SAR and POA&M generated from one record.

Read the guide. Then inspect the record it describes.

Published
Last updated
Unchanged since publication
Author
PolicyCortex Team