How to Get a DoD ATO: RMF Steps, eMASS, and Reciprocity

To get a DoD ATO, you run your information system through the seven steps of the Department of Defense’s Risk Management Framework under DoD Instruction 8510.01, build an authorization package around a System Security Plan, Security Assessment Report, and Plan of Action and Milestones, submit it through eMASS, and obtain a signed risk-acceptance decision from an Authorizing Official.¹ Nothing connects to a DoD network without that signature, and the process realistically takes anywhere from six months for a simple, well-prepared system to more than two years for a complex one.

What an ATO Is and Why You Need One

An Authority to Operate is the Authorizing Official’s formal acceptance that a system’s residual security risks are tolerable for the mission it supports. It is a documented risk decision, not a certification of perfect security: the AO has reviewed the evidence, weighed the vulnerabilities against operational need, and concluded the system can go live.²

DoDI 8510.01 requires every DoD information system to receive and maintain a valid authorization before beginning operations. The instruction implements the NIST Risk Management Framework and adapts it for the defense environment with DoD-specific roles, tools, and oversight.³ Operate without a valid ATO, or let one lapse, and the system faces immediate disconnection along with potential contract consequences.

The Seven RMF Steps You Have to Complete

DoDI 8510.01 organizes authorization into seven steps. Every system moves through all seven before the AO signs anything.

Prepare. Establish the context, define roles, and identify the resources needed before technical work begins.
Categorize. Determine the sensitivity of the data the system handles and assign an impact level based on the consequences of a breach.
Select. Choose the security controls from the NIST SP 800-53 catalog that match the system’s impact level and mission needs.
Implement. Build and configure those controls into the system.
Assess. Test whether the controls work through an independent evaluation.
Authorize. The AO reviews the assessment results and makes a risk-based decision.
Monitor. Continuously track the security posture after authorization and feed findings back into risk decisions.

In practice these steps overlap. Preparation and categorization run in parallel, and monitoring feeds back into assessment. But all seven have to be complete before an authorization decision issues.¹

Categorize the System and Select Controls

Categorization is where real work starts. Using NIST SP 800-60, the team evaluates the types of information the system handles and rates the damage a security incident would cause across three dimensions: confidentiality, integrity, and availability. Each dimension is rated low, moderate, or high, and the system’s overall categorization takes the highest of the three.⁴ A system handling controlled unclassified information that could compromise military operations if exposed will land at moderate or high, which directly increases the number of controls required.

Once categorized, the team selects controls from the NIST SP 800-53 catalog. These are the specific technical and administrative safeguards the system must implement: access controls, encryption standards, audit logging, incident response procedures, and dozens more. Selecting the right controls means matching the baseline for the system’s impact level and then tailoring based on the operating environment and threat profile.⁵ Get this wrong and you either over-engineer the system, burning time and budget, or under-protect it, guaranteeing findings during assessment.

The Three Documents the AO Actually Reads

The authorization package pulls together many artifacts, but three carry the decision.

System Security Plan

The System Security Plan (SSP) is the backbone. It describes how every selected control is implemented, maps the system’s architecture, defines the authorization boundary, and inventories all hardware and software components.⁶ The boundary matters more than most teams realize: a vague boundary, or one that pulls in components you cannot actually control, will get flagged and stall the package.

The SSP also details authentication, encryption, physical access protections, and audit logging. DoD templates exist, and deviating from them without good reason invites revisions. Reviewers expect specific model numbers and version information, not a hand-wave toward “standard government-furnished equipment.”

Security Assessment Report

Before testing, the Security Control Assessor develops a Security Assessment Plan that lays out scope, methodology, procedures, and timeline, and the AO reviews it before testing starts.⁷ After testing, results go into the Security Assessment Report (SAR), which documents every vulnerability discovered, rates findings by severity, and provides the assessor’s overall recommendation to the AO.⁸ A clean SAR accelerates authorization. A SAR full of critical vulnerabilities sends the team into remediation before the AO looks at it.

Plan of Action and Milestones

Any control that fails assessment generates an entry in the Plan of Action and Milestones (POA&M). Each entry identifies the deficiency, describes the fix, assigns responsibility, sets a target completion date, and estimates remediation cost.⁹ The POA&M demonstrates that known weaknesses have a documented path to resolution.

A weak POA&M is one of the fastest ways to get an authorization denied. Vague timelines, missing cost estimates, and remediation dates pushed past what the AO considers reasonable all signal that vulnerabilities are not being taken seriously. The AO reads the POA&M alongside the SAR, and if the residual risk picture is too bleak, authorization gets conditions attached or gets denied.

Who Signs, Who Assesses, Who Runs the Package

Four roles carry the process.

The Authorizing Official (AO) is a senior official, typically a member of the Senior Executive Service or a flag-grade officer, who holds the authority to formally accept the risk of operating the system. The AO’s signature on the authorization letter is the binding act that allows the system onto the network, and the AO can also revoke that authorization if conditions change.¹⁰

The Security Control Assessor (SCA) conducts the independent evaluation. Independence matters: the SCA must be organizationally separate from the development team. The SCA reviews all documentation, runs tests, and produces the SAR with a recommendation to the AO.¹¹

The Information System Security Manager (ISSM) handles day-to-day security management. That covers maintaining the security documentation, keeping configurations within approved parameters, coordinating continuous monitoring, and serving as the primary security point of contact during authorization. When the assessor has questions about how a control is implemented, the ISSM usually answers.

The Program Manager (PM) owns budget, schedule, and performance. The PM does not make security decisions, but every security decision has cost and schedule impact. A PM who treats the ATO as an afterthought handled in the final weeks before deployment has a system that will not deploy on time. Effective programs build ATO milestones into the acquisition schedule from day one.

Submitting Through eMASS

The Enterprise Mission Assurance Support Service (eMASS) is the DoD’s web-based system of record for RMF authorization packages. The team uploads all documentation into eMASS, and the workflow routes it through the chain of review. eMASS automates compliance tracking, generates required reports, integrates with security scanning tools, and maintains the enterprise baseline for security controls.¹²

Review inside eMASS is not instantaneous. The AO or a designated representative examines the SSP, SAR, and POA&M, and may request additional clarification or evidence. This exchange typically takes several weeks. Once the AO reaches a decision, it is recorded in eMASS and the system receives its formal authorization status.

The Decision the AO Can Return

The AO does not simply say yes or no. Several outcomes are possible.

Authority to Operate (ATO): Full authorization. Under DoDI 8510.01, an ATO must specify an authorization termination date within three years of the authorization date, unless the system has a compliant continuous monitoring program in place.¹
ATO with Conditions: Authorization is granted with specific conditions, usually tied to POA&M items that must be resolved within a defined window. Miss those conditions and the authorization can be pulled.
Interim Authority to Test (IATT): A temporary, limited authorization allowing operation in a specified environment for testing only, under time constraints and conditions set by the AO.¹³
Denial of Authority to Operate (DATO): The AO finds the risks unacceptable. The system cannot connect to any DoD network until the deficiencies are corrected and a new authorization attempt succeeds.¹⁴

Faster Paths: Reciprocity, cATO, and Assess Only

Not every effort needs a fresh full authorization.

Reciprocity. DoD policy requires components to accept valid authorizations granted by other DoD organizations whenever possible, rather than forcing redundant testing. DoDI 8510.01 states that the DoD Information Enterprise “will use cybersecurity reciprocity to reduce redundant testing, assessing, documenting, and the associated costs in time and resources.”¹ A receiving organization may add conditions or require supplemental assessment for its specific environment, but the baseline expectation is that an existing ATO should carry weight across the enterprise.

Continuous ATO (cATO). This newer pathway replaces the time-boxed cycle with an ongoing authorization, letting mature teams deliver software updates without pausing for reauthorization. The February 2022 DoD CIO memo requires three competencies: continuous monitoring of RMF controls with real-time visibility, active cyber defense capabilities, and a secure software supply chain aligned with NIST SP 800-161. The system must operate on a DevSecOps platform meeting one of the DoD Enterprise DevSecOps Reference Designs, with automated security scanning embedded in the CI/CD pipeline.¹⁵ A prerequisite that catches teams off guard: the software factory must already hold a current ATO with no high or very high unmitigated findings before it can be evaluated for cATO. There is no shortcut around the traditional process.

Assess Only. Individual software applications, hardware components, and IT services that fall below the system level still undergo RMF assessment procedures but do not require their own ATO.² If you sell components that will be incorporated into a larger authorized system, you still demonstrate security compliance, but the overhead is significantly less than a full authorization.

Cloud Systems and DoD Impact Levels

If the system runs in the cloud, additional requirements layer on top of RMF. The DoD Cloud Computing Security Requirements Guide defines four Impact Levels:

IL2 covers public or non-critical mission information. Cloud offerings with a FedRAMP Moderate authorization qualify for IL2 through reciprocity.¹⁶
IL4 covers Controlled Unclassified Information and non-critical mission data for non-national security systems.
IL5 covers higher-sensitivity CUI, mission-critical information, and national security systems.
IL6 covers classified information at the SECRET level for national security systems.

For contractors storing or processing covered defense information in the cloud, DFARS 252.204-7012 requires the cloud service provider to meet security requirements equivalent to the FedRAMP Moderate baseline. A December 2023 DoD memo clarified that “equivalent” means 100% compliance with all FedRAMP Moderate controls, validated by a FedRAMP-recognized Third Party Assessment Organization.¹⁷ If your provider cannot produce 3PAO assessment documentation, expect that gap to surface during your own ATO process.

How Long It Takes and What Slows It Down

Realistic timelines for a first-time ATO run from about six months for a well-prepared, low-complexity system to more than two years for large, complex systems with multiple interconnections. Common delays come from incomplete documentation (especially the SSP), slow stakeholder coordination, limited assessor availability, and discovering significant vulnerabilities late in assessment that require architectural changes rather than simple fixes.

Teams that treat the authorization as a parallel workstream from the start of development finish faster than teams that build first and bolt on security documentation afterward. If the SSP is not taking shape alongside the system architecture, the schedule is already slipping.

Keeping the ATO After You Get It

Authorization is not the finish line. DoDI 8510.01 treats the Monitor step as an ongoing obligation running for the life of the system. Continuous monitoring aligns with NIST SP 800-137 and includes periodic reassessment of controls, tracking changes to the system and its operating environment, updating risk assessments, and reporting the security posture to the AO.¹

Any significant change to the system has to be reported. Adding new network interfaces, migrating to a different cloud provider, modifying authentication methods, or deploying major software updates all qualify, and each may trigger partial reassessment. Failing to report significant changes is one of the fastest ways to lose an active ATO, because the AO’s risk acceptance was based on a system that no longer exists.

What a Denial Costs You

A DATO carries consequences well beyond the technical team. On the contract side, outcomes depend on the contract type. Under a firm-fixed-price contract, a DATO can lead to a cure notice, and if the contractor cannot resolve the deficiencies, the government may terminate for default and hold the contractor liable for the cost of bringing in another firm. Under cost-plus arrangements, the government may decrement the fee or pursue incompetence claims.

Operationally, a DATO disconnects the system from DoD networks immediately, and funding for the affected work typically stops. The team can address the AO’s concerns and resubmit, but the resubmission runs through the same full review, and the AO who denied the first attempt will scrutinize the second more closely. For programs on tight deployment timelines, a DATO can effectively end the effort. Even short of a DATO, operating without a valid authorization, or letting one lapse, exposes the program to administrative penalties and disconnection at any time.

1
Department of Defense. DoD Instruction 8510.01 – Risk Management Framework for DoD Systems
2
Department of Defense Chief Information Officer. ATO 101 for Small Businesses
3
Computer Security Resource Center. NIST Risk Management Framework
4
National Institute of Standards and Technology. NIST Special Publication 800-60 Volume I Revision 1 – Guide for Mapping Types of Information and Information Systems to Security Categories
5
Computer Security Resource Center. NIST SP 800-53 Rev. 5 – Security and Privacy Controls for Information Systems and Organizations
6
Computer Security Resource Center. Computer Security Resource Center – System Security Plan
7
FedRAMP. Security Assessment Plan
8
FedRAMP. Security Assessment Report
9
FedRAMP. Plan of Action and Milestones
10
Computer Security Resource Center. NIST Glossary – Authorizing Official
11
Cybersecurity and Infrastructure Security Agency. Security Control Assessor
12
Center for Development of Security Excellence. Enterprise Mission Assurance Support Service (eMASS) DISA-100.06
13
Computer Security Resource Center. Computer Security Resource Center – Interim Authorization to Test
14
Center for Development of Security Excellence. Introduction to the NISP RMF A&A Process Student Guide
15
Department of Defense Chief Information Officer. Continuous Authorization to Operate (cATO) Evaluation Criteria
16
Cloud Information Center – GSA. Cloud Security
17
Department of Defense Chief Information Officer. FedRAMP Authorization and Equivalency