The Authorization 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 Authorization to Operate (ATO). For software teams building for the Department of War (DOW), 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 ATO efforts still stall, and shows how continuous ATO changes the equation. Whether you are an Information System Security Officer preparing a package, an Authorizing Official weighing risk, or a program manager trying to get software to Mission Heroes faster, this guide is written for you.
ATO stands for Authorization 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 an output of the NIST Risk Management Framework, defined in NIST SP 800 37 Revision 2. 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 can take 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) can compress the time required to deliver subsequent releases by shifting from authorization at a single point in time to ongoing authorization backed by continuous monitoring, compliance evidence generation, active cyber defense, and DevSecOps practices. The initial authorization still requires rigorous assessment. Continuous authorization requires more than a pipeline, and each release must remain within the approved authorization boundary and risk tolerance.
What ATO Stands For and What It Means
Authorization 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 with the authority to accept risk on behalf of the organization. The AO does not rubber stamp a checklist. The AO evaluates 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 (Authorization to Operate): Full authorization that permits the system to operate in production, subject to the terms and duration set by the authorizing organization.
- 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 Department of War cATO Implementation Guide. It relies on continuous monitoring, active cyber defense, and an approved DevSecOps reference design to sustain authorization as software changes.
These authorization decisions operate within the broader NIST RMF. The controls that systems are assessed against come from NIST SP 800 53 Revision 5, which catalogs 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 system categorization 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. NIST acknowledges that organizations may execute these steps iteratively or in a modified sequence, but understanding the canonical flow is essential for any practitioner navigating the ATO process.
- 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.
- 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 DoW mission applications, carries significantly more control requirements than a Low system. Categorization drives every downstream decision, so getting it right is essential. This step typically takes one to three weeks when stakeholders are aligned.
- 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 DOW systems, selection also incorporates Security Technical Implementation Guides and any organization specific overlays. With clear guidance, control selection can be completed in a few weeks.
- 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, and encrypting data at rest and in transit. 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.
- 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. NIST SP 800 53A Revision 5 provides the methodology and procedures for assessing these controls. Assessment backlogs are one of the biggest contributors to ATO delays because qualified assessors are in short supply, and the queue for assessment can itself take months.
- 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.
- 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 continues for the duration of the authorization. Under continuous ATO, monitoring is part of the operating model that enables ongoing risk determination and authorization.
How Long Does the ATO Process Take?
Traditional ATO can take 6 to 18 months for 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 DOW environments, the biggest time sinks are:
- Manual control implementation and documentation. Writing and maintaining an SSP for a Moderate impact system can mean documenting hundreds of controls. When done manually in Word documents and spreadsheets, it is slow, prone to error, 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 Mission Heroes for a year or more. In a threat environment that evolves in days, that gap is a strategic risk. Continuous ATO can compress the timeline after the initial authorization, which still requires rigorous assessment. The key difference is that continuous monitoring and automated evidence generation replace parts of the manual assessment cycle. The system’s security posture is evaluated continuously, and risk decisions can be based on current evidence rather than stale documentation.
For teams weighing how to make that shift, the case study From Six Months to Two Days: Accelerating ATO for Navy and Beyond shows what that acceleration can look like in practice. The move toward continuous risk management also aligns with the Department of War Cybersecurity Risk Management Construct, which emphasizes automation, critical controls, continuous monitoring and ATO, DevSecOps, cyber survivability, inheritance, reciprocity, and threat informed assessments.
Continuous ATO with UDS
The shift from traditional ATO to continuous ATO is not simply a process change. It requires a different technical and operational foundation. This is where the Unified Defense Stack comes in. UDS helps programs implement and maintain applicable technical controls, generate compliance evidence, and operate across connected, disconnected, and airgapped environments. It supports the technical foundation for continuous authorization, while the authorization boundary, risk tolerance, governance model, and final risk decision remain the responsibility of the program and its Authorizing Official.
Automated Compliance Evidence Generation
Instead of manually documenting every control activity, UDS can produce and aggregate evidence as part of software delivery and operations. When a container image is scanned, a configuration is validated, or an access policy is enforced, the resulting evidence can be captured and made available for assessment. This reduces manual documentation and helps teams keep evidence current. It reflects the same principle behind Defense Unicorns’ compliance automation approach: make evidence a product of delivery rather than a separate workstream.
NIST 800 53 Control Automation
UDS addresses many applicable NIST SP 800 53 technical controls at the platform level. Controls related to access management, audit logging, configuration management, system integrity, and vulnerability scanning can be enforced consistently by platform services rather than implemented separately by every application team. Applications may inherit protection from these common controls, but exact coverage depends on the impact level, architecture, mission data, integrations, operating environment, and authorization boundary.
For enterprise cloud and on premises environments, UDS Enterprise provides infrastructure automation, software distribution, and cybersecurity evidence capabilities that can reduce the time and manual effort required to prepare for authorization.
Hardened Pipeline for Continuous Delivery
UDS supports secure software delivery pipelines that integrate security scanning, software bill of materials generation, container signing, and policy enforcement into the build and deployment process. Code moves from commit to production through automated gates that validate security posture at each stage. Security is embedded in the delivery process, but pipeline automation is only one part of the cATO model.
The initial ATO establishes the authorized baseline. Subsequent releases must remain within the approved system boundary and risk tolerance, flow through the approved delivery process, produce the expected evidence, and remain subject to continuous monitoring and active cyber defense. This is the operating model described by Department of War cATO guidance. It gives the Authorizing Official current information for ongoing risk decisions, but it does not transfer the authority to accept risk to the platform or pipeline.
Traditional ATO Versus Continuous ATO
| Dimension | Traditional ATO | Continuous ATO |
|---|---|---|
| Timeline | Initial authorization can take months, and major changes may require additional review | Initial ATO is still required, but approved changes can move faster when they stay within established guardrails |
| Cost | Manual documentation, assessment effort, and repeated reviews create recurring cost | Reusable evidence and inherited controls can reduce the effort required for each change |
| Security posture | Reviews may rely heavily on evidence collected at specific points in time | Continuous monitoring provides current visibility into control effectiveness, configuration state, and vulnerabilities |
| Update frequency | Major changes may trigger additional authorization activity, which can encourage teams to batch releases | Releases can move continuously when they satisfy the approved process, boundary, and risk conditions |
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 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, AO review, or documentation, and separate that delay from active engineering work.
- Audit your documentation process. If your SSP lives in a Word document and your POA&M is a spreadsheet emailed between stakeholders, evidence will be difficult to keep current. Look for opportunities to generate evidence from the systems themselves rather than writing it by hand.
- Evaluate your control inheritance. How many controls are being implemented from scratch by each application team? A mature environment provides a platform that satisfies applicable controls at the infrastructure layer, leaving application teams to address the controls unique to their system. Ownership and the scope of inheritance must still be explicit.
- Assess your monitoring maturity. If your continuous monitoring consists of quarterly vulnerability scans and annual control reviews, you are not positioned for continuous ATO. Mature continuous monitoring provides timely visibility into control effectiveness, configuration state, and vulnerability posture.
- Understand your AO’s risk appetite. Knowing what evidence the AO needs, which changes are permitted, and which conditions require escalation is essential before investing in a cATO approach.
What good looks like is a platform that provides reusable technical controls, a delivery process that generates compliance evidence, continuous monitoring that gives decision makers current posture information, and an AO who receives a living authorization package rather than a static binder. Teams operating in this model spend more time building mission software and less time recreating security documentation.
The goal is not to eliminate rigor. It is to make rigor repeatable. Every control still matters. Every risk decision still belongs to the AO. The machinery that produces evidence, enforces technical controls, and sustains the authorization should operate at the speed required by the mission. UDS is designed to support that foundation, while people remain responsible for defining the boundary, assigning ownership, governing risk, and making the authorization decision.
