The DoD ATO process is how a system earns its Authority to Operate on a defense network: a senior government official, the Authorizing Official, formally accepts the risk of running the system after reviewing evidence that its security controls meet Department of Defense standards. The decision is governed by DoD Instruction 8510.01 and follows the Risk Management Framework defined in NIST Special Publication 800-37.1Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems2National Institute of Standards and Technology. SP 800-37 Rev 2 – Risk Management Framework for Information Systems and Organizations It takes months to complete for most systems, and it is not a one-time exercise: the authorization is time-bound, actively managed, and can be revoked.
The Seven Steps a System Moves Through
NIST SP 800-37 Rev 2 lays out the framework as seven sequential steps. The sequence matters because each step produces evidence the next one depends on.2National Institute of Standards and Technology. SP 800-37 Rev 2 – Risk Management Framework for Information Systems and Organizations
- Prepare. Set the context and define the authorization boundary — every piece of hardware, software, and network connection that belongs to the system.
- Categorize. Identify what information the system handles and the potential impact if it were compromised. This drives which control baseline applies.
- Select. Choose the appropriate security controls from NIST SP 800-53, which organizes protections into 20 families, and tailor them to the system.3National Institute of Standards and Technology. SP 800-53 Rev 5 – Security and Privacy Controls for Information Systems and Organizations
- Implement. Put the controls in place and document how each one works.
- Assess. Test the controls to see whether they actually do what the documentation says.
- Authorize. The AO reviews the assessment and makes the risk decision.
- Monitor. Track control effectiveness on an ongoing basis, respond to changes, and keep the risk documentation current.
Most of the workload lands in Implement and Assess. Skimping on documentation during those phases is the most common cause of delays later, because the AO and the assessor have to keep sending the package back for clarification.
Who Decides and Who Does the Work
DoDI 8510.01 assigns accountability to named roles, and the separation between them is deliberate.
The Authorizing Official holds final authority to grant, deny, or revoke an authorization. AOs must be government personnel and cannot be contractors under any circumstances. They are appointed from senior leadership in a business or mission owner organization and must have relevant expertise with the system’s technology.1Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems The authorization decision itself cannot be delegated, though other tasks can be handed to a formally appointed AO Designated Representative. The risk the AO accepts factors into their annual performance evaluation.
The Security Control Assessor provides an independent evaluation of whether the protections work as documented. The DoD Component Chief Information Security Officer serves as the default SCA and can formally delegate the role. Independence is the point: the person testing the controls should not be the person who built them.
The Information System Security Manager runs the day-to-day security posture and compliance. The Information System Owner is responsible for building and maintaining the system. In practice the ISSM and ISO work closely together to assemble the package, while the SCA and AO review it from outside.
What Goes in the Authorization Package
The package is the evidence that persuades the AO to accept risk. DoDI 8510.01 requires three core components: the System Security Plan, the Security Assessment Report, and all Plans of Action and Milestones.1Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems
The SSP is the central document. It describes how every selected control is implemented within the system, covering both technical configurations and administrative policies. A reviewer should be able to trace the connection between the system’s architecture, its data flows, and the specific protections in place. A vague SSP that describes controls in the abstract, without tying them to the actual system, gets sent back.
The Security Assessment Report captures whether the controls actually work. The SCA tests them, records findings, and identifies any vulnerabilities and the risk they pose to the mission. Weaknesses that cannot be fixed before the authorization decision go into a POA&M, which details what each vulnerability is, the planned remediation, the resources required, and the timeline. The AO tracks POA&M execution across the system’s lifecycle, so it is not a document you write and forget.
Inheritance Can Cut the Workload Significantly
Not every control has to be documented from scratch. When a system runs on a platform that already has an ATO, such as a pre-accredited cloud environment, many controls are inherited from the underlying provider. During the Select step, controls sort into three buckets: inherited (covered by the platform), system-specific (managed by the system owner), and hybrid (shared). Mapping inheritance properly can cut the compliance workload substantially, sometimes by more than half, because you avoid duplicating security evidence the platform has already provided.
Submitting Through eMASS
The completed package is uploaded into the Enterprise Mission Assurance Support Service, the DoD’s central platform for RMF workflows. All authorization packages must be submitted through eMASS rather than through older legacy systems.4Defense Counterintelligence and Security Agency. NISP eMASS Industry Operation Guide The ISSM typically initiates the workflow, which routes the package to the SCA for review and then to the AO for a decision.
SCA review can take several weeks, depending on system complexity and documentation quality. Expect requests for additional information or clarification on technical implementations. The cleaner the initial package, the fewer round trips. Once the SCA is satisfied, the package moves to the AO.
The Four Possible Decisions
DoDI 8510.01 identifies four authorization outcomes.1Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems
- Authority to Operate. Granted when residual risks are acceptable. A full ATO is typically valid for up to three years, after which the system must go through reauthorization.
- ATO with Conditions. The system meets most requirements but has open risks the AO will accept temporarily, subject to restrictions or remediation deadlines. It can operate, but only within the boundaries the AO sets.
- Interim Authority to Test. Allows limited operation for testing or evaluation when a system is not yet ready for a full decision. This is not production-ready status.
- Denial of Authorization to Operate. Risks are too high or documentation is insufficient. A DATO blocks the system from any defense network until the issues are resolved and a new package is submitted.
The AO can downgrade or revoke an existing authorization at any time if risk conditions change. An ATO is a time-bound, risk-informed permission the AO actively manages, not a permanent green light.
Keeping the Authorization After You Get It
Receiving an ATO starts an ongoing obligation. DoDI 8510.01 requires continuous monitoring aligned with NIST SP 800-137: ongoing testing and assessment of control effectiveness, analysis and response to monitoring outputs, and regular updates to risk documentation.1Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems
Periodic security reviews and testing must occur at least annually. Automated vulnerability scanning typically runs on a more frequent schedule, often weekly or monthly, to catch new vulnerabilities and configuration drift between formal assessments. Results feed back to the AO, who uses them to decide whether the system’s risk posture remains acceptable.
Certain changes trigger reauthorization before the original ATO expires. Major changes to hardware architecture, software code, or data handling processes usually require a fresh risk assessment. The POA&M must stay current; missing remediation deadlines can result in suspension. A lapsed or revoked ATO means the system comes off the network until the issues are resolved.
Continuous Authorization as an Alternative
The traditional model has a weakness: the security posture on the day of assessment may bear little resemblance to reality six months later. Continuous Authorization to Operate, or cATO, replaces the periodic document-based review with continuous risk assessment and monitoring. Rather than expiring after a set term, a cATO persists as long as the system maintains an acceptable risk posture.
The DoD CIO’s evaluation criteria set three foundational requirements for cATO eligibility: the system must be built and deployed through a DevSecOps platform meeting one of the DoD Enterprise DevSecOps Reference Designs; ongoing evaluation of the software factory team’s processes and skills; and implementation of continuous monitoring, active cyber defense, and NIST secure supply chain guidance.5Department of Defense Chief Information Officer. Continuous Authorization to Operate – Evaluation Criteria
Programs pursuing a cATO fall into two categories. In one, software is developed and deployed entirely within the same authorization boundary as the software factory. In the other, the software factory deploys code into a separate boundary, such as a weapon system, which requires formal agreements including a Memorandum of Understanding and an Interconnection Security Agreement between the two boundaries. The bar for cATO is higher than for a traditional ATO, but it eliminates the disruptive multi-year reauthorization cycle.
Cloud Systems and Impact Levels
When a DoD system runs in a cloud environment, it must operate at the correct DoD Impact Level for its data. The DoD Cloud Computing Security Requirements Guide defines four levels:6General Services Administration. Cloud Security – Cloud Information Center
- IL2. Public or non-critical mission information. Cloud offerings with a FedRAMP Moderate authorization qualify through reciprocity.
- IL4. Controlled Unclassified Information and non-critical mission data on non-national-security systems.
- IL5. Higher-sensitivity CUI, mission-critical information, and national security systems.
- IL6. Classified information up to SECRET. Requires dedicated cloud infrastructure in facilities approved for classified processing.
For cloud services at IL4 and above, the Defense Information Systems Agency issues a DoD Provisional Authorization after evaluating the offering against FedRAMP baselines supplemented with DoD-specific controls. Two paths exist: uplifting an existing FedRAMP Agency ATO, or a fresh assessment by an accredited third-party organization plus DISA validation.7Department of Defense Cyber Exchange. DoD Cloud Authorization Process Even with a Provisional Authorization for the platform, the mission owner still needs a separate ATO from their own DoD Component AO for the specific system and data placed into that cloud environment.
Reciprocity Between Components
Reciprocity is a longstanding DoD policy goal. The principle is straightforward: if one Component has already authorized a system, other Components should accept that authorization rather than force redundant testing.8DoD Inspector General. Audit of the DoDs Use of Cybersecurity Reciprocity Within the Risk Management Framework In practice it works best when the original documentation is complete and available in eMASS for other Components to review.
The DoD Cybersecurity Reciprocity Playbook describes the process as AOs leveraging previous security assessments to facilitate mission needs without redundant testing.9DoD Chief Information Officer. DoD Cybersecurity Reciprocity Playbook For cloud services, DoD maintains reciprocity with FedRAMP for all systems processing IL2 data that appear on the FedRAMP Marketplace. When reciprocity disputes arise between Components, the DoD CIO’s office arbitrates.
CMMC Is a Separate Track
Contractors who handle DoD information face a parallel framework, the Cybersecurity Maturity Model Certification, which took effect in November 2025.10DoD Chief Information Officer. About CMMC CMMC governs the cybersecurity posture of contractor environments that store Federal Contract Information and Controlled Unclassified Information. It does not replace the RMF or the ATO process for DoD-owned systems, and an ATO does not substitute for CMMC certification. Contractors should not assume one covers the other.