Authority To Operate Explained

The Authority to Operate Process for Defense Software

Every information system that touches a federal or defense network must earn permission to operate, and that permission is called an Authority to Operate (ATO). For software teams building for the Department of Defense, the ATO process is often the single largest bottleneck between working code and mission impact. This guide breaks down what ATO actually means, walks through the seven steps of the Risk Management Framework that produce it, explains why traditional timelines stretch so long, and shows how continuous ATO fundamentally changes the equation. Whether you are an ISSO preparing a package, an Authorizing Official weighing risk, or a program manager trying to get software to warfighters faster, this guide is written for you.

ATO stands for Authority to Operate, a formal, risk-based authorization decision made by an Authorizing Official (AO) that permits an information system to operate on a government network at an accepted level of risk. It is the output of the NIST Risk Management Framework (RMF), defined in NIST SP 800-37. It is not a certification of perfect security. It is a judgment that the system’s controls are sufficient for its operational environment. How long does the ATO process take? Traditional ATO typically takes 6 to 18 months, with some complex systems exceeding two years. Delays come from manual control implementation, extensive documentation, assessment backlogs, and AO review queues. Continuous ATO (cATO) compresses subsequent releases to weeks, or even days, by shifting from point-in-time authorization to ongoing authorization backed by automated monitoring, automated compliance evidence generation, and DevSecOps pipelines. The initial authorization still requires rigorous assessment, but every release after that flows through a continuously monitored, continuously authorized path.

What ATO Stands For and What It Means

Authority to Operate is the formal declaration that a system has been assessed against applicable security and privacy requirements and that the risks of operating it have been reviewed and accepted. The decision belongs to the Authorizing Official, a senior leader (typically a general officer, SES, or their designated representative) with the authority to accept risk on behalf of the organization. The AO does not rubber-stamp a checklist. They evaluate the Security Assessment Report (SAR), the System Security Plan (SSP), and the Plan of Action and Milestones (POA&M) to make a risk-informed judgment. ATO sits within a broader family of authorization decisions:

• ATO (Authority to Operate): Full authorization, typically valid for up to three years, permitting the system to operate in production.
• IATT (Interim Authority to Test): A temporary, limited authorization that allows a system to operate in a controlled environment for testing purposes. It does not permit full operational deployment.
• Continuous ATO (cATO): An ongoing authorization model, described in the DoD CIO’s DevSecOps continuous authorization guidance, that replaces periodic reauthorization with continuous monitoring, active cyber defense, and DevSecOps practices to sustain authorization across every release.

All of these authorization types are products of the NIST RMF. The controls that systems are assessed against come from NIST SP 800-53, which catalogs hundreds of security and privacy controls organized into families such as Access Control (AC), Audit and Accountability (AU), and Configuration Management (CM). The RMF process itself is defined in NIST SP 800-37, and the system categorization methodology follows FIPS 199. Understanding where ATO sits in this standards ecosystem is critical: the RMF is the process, SP 800-53 provides the controls, and ATO is the authorization decision that results.

The Seven RMF Steps

The RMF is a structured but adaptable seven-step process. While NIST acknowledges that organizations may execute these steps iteratively or in a modified sequence, understanding the canonical flow is essential for any practitioner navigating the ATO process.

1. Prepare. This foundational step establishes the organizational context for risk management. Teams identify key roles: the AO, the Information System Security Officer (ISSO), the System Owner, and the Security Control Assessor (SCA). They define the organization’s risk tolerance, develop a risk management strategy, and identify common controls that can be inherited across systems. Preparation also includes standing up the monitoring strategy that will be used in Step 7. In practice, this is where many programs underinvest, leading to rework later. Thorough preparation can take weeks to a few months but pays dividends across every subsequent step.
2. Categorize. The system and the information it processes, stores, and transmits are categorized based on potential impact to confidentiality, integrity, and availability. Using FIPS 199, teams assign a Low, Moderate, or High impact level. A Moderate system, the most common categorization for DoD mission applications, carries significantly more control requirements than a Low system. Categorization drives every downstream decision, so getting it right is non-negotiable. This step typically takes one to three weeks when stakeholders are aligned.
3. Select. Based on the categorization, teams select a baseline set of security controls from NIST SP 800-53. They then tailor that baseline, adding supplemental controls to address specific risks or applying compensating controls where a standard control cannot be implemented as written. For DoD systems, selection also incorporates STIGs (Security Technical Implementation Guides) and any organization-specific overlays. With clear guidance, control selection can be completed in a few weeks.
4. Implement. This is where the engineering work happens. Teams implement the selected controls across the system: configuring access controls, enabling audit logging, hardening operating systems, encrypting data at rest and in transit, and much more. Critically, every control implementation must be documented, and the SSP captures how each control is satisfied. For complex systems, implementation can take three to six months or longer, and it is often the most labor-intensive step in the entire process.
5. Assess. An independent assessor (or assessment team) evaluates whether the implemented controls are functioning as intended and effectively mitigating risk. This includes reviewing documentation, interviewing personnel, testing controls through vulnerability scanning and penetration testing, and validating that the system’s actual configuration matches what the SSP describes. Assessment backlogs are one of the biggest contributors to ATO delays: qualified assessors are in short supply, and the queue for assessment can itself take months.
6. Authorize. The assessment results are compiled into an authorization package that includes the SSP, the SAR, and the POA&M. This package is presented to the Authorizing Official, who reviews the residual risk and makes the authorization decision. If the risk is acceptable, the AO issues the ATO. If not, the AO may issue a denial or request remediation. The AO review itself can take weeks, depending on the complexity of the findings and the AO’s availability.
7. Monitor. After authorization, the system enters continuous monitoring: ongoing assessment of a subset of controls, regular vulnerability scanning, configuration management, incident response, and reporting. Monitoring is not optional. It is the mechanism that sustains the authorization. Under a traditional ATO, monitoring runs until the authorization expires (typically three years), at which point the entire process restarts. Under continuous ATO, monitoring is the engine that enables ongoing authorization without periodic reauthorization.

How Long Does the ATO Process Take?

The honest answer: traditional ATO takes 6 to 18 months for most defense software systems, and some programs have experienced timelines exceeding two years. The variance depends on system complexity, organizational readiness, assessor availability, and AO capacity. Where does the time actually go? In Defense Unicorns’ experience delivering software to DoD environments, the biggest time sinks are:

• Manual control implementation and documentation. Writing and maintaining an SSP for a Moderate-impact system can mean documenting 300+ controls. When done manually, in Word documents and spreadsheets, it is slow, error-prone, and difficult to keep current.
• Assessment backlogs. Qualified Security Control Assessors are a scarce resource. Programs frequently wait months just to get on an assessor’s calendar.
• AO review queues. Authorizing Officials are senior leaders with broad portfolios. Authorization packages can sit in queue for weeks or months awaiting review.
• Reauthorization for changes. Under traditional ATO, major updates can trigger partial or full reauthorization, restarting significant portions of the process.

The cumulative effect is that software capable of delivering mission value today may not reach operators for a year or more. In a threat environment that evolves in days, that gap is a strategic risk. Continuous ATO compresses the timeline dramatically. After the initial authorization, which still requires rigorous assessment, subsequent releases can be authorized in weeks or even days. The key difference is that continuous monitoring and automated evidence generation replace the manual, point-in-time assessment cycle. The system’s security posture is evaluated continuously, not periodically, and the authorization decision becomes an ongoing one rather than a recurring event. For teams weighing how to make that shift, our case study on accelerating ATO from six months to two days for the Navy and beyond shows what that acceleration looks like in practice.

Continuous ATO with UDS

The shift from traditional ATO to continuous ATO is not simply a process change. It requires a fundamentally different technical foundation. This is where the Unified Defense Stack (UDS) comes in. UDS automates NIST 800-53 controls and supports continuous ATO across disconnected and air-gapped environments. UDS is a hardened software delivery platform built specifically for defense and national security environments, including air-gapped and disconnected networks. It provides the infrastructure and tooling that make continuous ATO operationally viable by addressing three critical requirements.

Automated Compliance Evidence Generation

Instead of manually documenting how each NIST 800-53 control is satisfied, UDS generates compliance evidence automatically as part of the software delivery pipeline. When a container image is scanned, a configuration is validated, or an access policy is enforced, the evidence is captured, timestamped, and mapped to the relevant control. This eliminates the months of manual documentation that characterize traditional ATO and ensures the evidence is always current, not a snapshot from six months ago. This is the same principle behind Defense Unicorns’ compliance automation approach: turn evidence into a byproduct of delivery rather than a separate workstream.

NIST 800-53 Control Automation

UDS automates the implementation of a significant portion of NIST 800-53 controls at the platform level. Controls related to access management, audit logging, configuration management, system integrity, and vulnerability scanning are enforced by the platform itself rather than implemented ad hoc by each application team. This means applications deployed on UDS inherit a substantial control baseline from day one, reducing the per-application authorization burden and ensuring consistent enforcement.

Hardened Pipeline for Continuous Delivery

UDS includes a secure software factory pipeline that integrates security scanning, SBOM generation, container signing, and policy enforcement into every build. Code moves from commit to production through automated gates that validate security posture at each stage. This is not security as an afterthought. It is security embedded in the delivery process, which is exactly what DoD’s cATO criteria require. The net effect is a shift from point-in-time authorization to ongoing authorization. The initial ATO establishes the baseline. After that, every release flows through the same hardened pipeline, generates the same automated evidence, and is subject to the same continuous monitoring. The AO maintains visibility into the system’s real-time security posture and can make ongoing risk decisions based on current data rather than stale documentation. This is what DoD’s cATO guidance envisions: continuous monitoring of security controls, active cyber defense measures, and adoption of DevSecOps practices, all sustained by a platform purpose-built for the mission.

Traditional ATO vs. Continuous ATO

Dimension	Traditional ATO	Continuous ATO
Timeline	6 to 18 months for initial authorization, and weeks to months for reauthorization on major changes	Weeks for initial authorization (with platform-inherited controls), then days for subsequent releases
Cost	High, with extensive manual documentation, dedicated assessment teams, and repeated reauthorization cycles	Lower per-release, because automated evidence generation and inherited controls reduce the marginal cost of each authorization decision
Security Posture	Point-in-time snapshot. Posture degrades between assessments as configurations drift and new vulnerabilities emerge	Continuously validated. Real-time monitoring detects drift and vulnerabilities as they occur
Update Frequency	Infrequent. Major updates may trigger reauthorization, creating incentives to batch changes and delay releases	Continuous. Every release flows through the authorized pipeline, enabling rapid delivery of patches and features

Practical Guidance:

If your team is struggling with ATO timelines, the first step is not to shop for a vendor. It is to understand where your process is actually breaking down. Here is what to assess:

• Map your current timeline. Break your most recent ATO effort into the seven RMF steps and measure how long each one took. Identify the steps where time was lost to waiting (for assessors, for AO review, for documentation to be completed) versus active work.
• Audit your documentation process. If your SSP lives in a Word document and your POA&M is a spreadsheet emailed between stakeholders, you have a documentation problem that no amount of process improvement will fix. Look for opportunities to generate evidence from the systems themselves rather than writing it by hand.
• Evaluate your control inheritance. How many of your 300+ controls are being implemented from scratch by each application team? A mature environment provides a platform that satisfies a significant portion of controls at the infrastructure layer, leaving application teams to address only the controls unique to their system.
• Assess your monitoring maturity. If your “continuous monitoring” consists of quarterly vulnerability scans and annual control reviews, you are not positioned for continuous ATO. Real continuous monitoring means automated, near-real-time visibility into control effectiveness, configuration state, and vulnerability posture.
• Understand your AO’s risk appetite. Some AOs are open to ongoing authorization models, and others are not. Knowing where your AO stands, and what evidence they need to feel confident in a continuous authorization decision, is essential before investing in a cATO approach.

What “good” looks like: a platform that inherits the majority of 800-53 controls, a pipeline that generates compliance evidence automatically with every build, continuous monitoring that provides real-time posture visibility, and an AO who receives a living authorization package rather than a static binder. Teams operating in this model spend their time building mission software, not writing security documentation. The authorization process becomes a byproduct of good engineering practice rather than a separate, adversarial workstream. The goal is not to eliminate rigor. It is to automate it. Every control still matters. Every risk decision still belongs to the AO. But the machinery that produces the evidence, enforces the controls, and sustains the authorization should run at the speed of software delivery, not the speed of paperwork. Platforms such as UDS are designed to fulfill these criteria.