Two federal agencies received Authorization to Operate (ATO) packages for similar cloud-hosted applications in the same fiscal year. The first agency ran the standard process: System Security Plan (SSP) drafted over eight months, Information System Security Officer (ISSO) review, risk analysis, third-party assessment, authorizing official signature. Eighteen months from kickoff to authorization. The team celebrated. Then the reauthorization cycle began its three-year countdown before the ink dried.
The second agency had deployed the same application type six months earlier using a continuous Authorization to Operate (cATO) framework. Controls were validated in the Continuous Integration/Continuous Deployment (CI/CD) pipeline at every code push. Real-time dashboards fed the authorizing official automated evidence. When a new module shipped, the compliance posture updated within the sprint cycle. The ATO was not an event. It was a state the system maintained continuously.
These two paths now define federal authorization strategy. One treats the ATO as a gate to pass through every three years. The other treats authorization as an operating condition the system must maintain every day. The second path is where DoD, GSA, and CISA are pointing. The implementation details are what most teams get wrong.
Build a cATO capability in four phases: deploy a secure landing zone with pipeline security tooling (Phase 1), build the Open Security Controls Assessment Language (OSCAL) authorization package with control-to-tool mappings (Phase 2), operationalize continuous monitoring with automated dashboards (Phase 3), then present the live compliance posture to the authorizing official for ongoing authorization (Phase 4). The formal cATO authorization phase compresses to 90 days for organizations with the Development, Security, and Operations (DevSecOps) foundation already built. Total program buildout is 6-18 months (see FAQ #5).
cATO vs. Traditional ATO: What Actually Changes
The traditional ATO process follows the Risk Management Framework (RMF) as a sequential set of steps: Prepare, Categorize, Select controls, Implement, Assess, Authorize, Monitor. Organizations treat each step as a discrete project phase. The result is a compliance event that happens at authorization and then again at the conventional three-year reauthorization, with continuous monitoring in between that rarely feeds back into the authorization decision in real time.
The Structural Problem with Periodic Authorization
A system authorized under the traditional model is assessed as of a specific point in time. The moment the ATO is signed, the assessment begins aging. Infrastructure changes, software updates, and configuration drift accumulate in the gap between formal assessment cycles. The authorizing official holds a document describing the system as it existed at authorization, not as it exists today.
For high-velocity federal systems, this gap creates real risk. A system deployed on containers with weekly release cycles has a materially different attack surface 90 days after authorization than it did on day one. The traditional ConMon process, monthly vulnerability scans and quarterly reporting, is not designed to track that kind of change cadence. The monitoring produces data, but it rarely changes the authorization decision in real time.
How cATO Reframes the Authorization Decision
Continuous ATO redefines the authorization trigger. Under the traditional model, the question is: “Is this system secure enough to authorize?” Under cATO, the question is: “Is this system maintaining its approved security posture continuously?” The shift sounds semantic. The operational difference is significant.
cATO requires the authorizing official to have access to a real-time view of the system’s compliance state. Controls are validated programmatically at each code deployment. Security findings trigger automated alerts and workflow actions, not quarterly reports. The ATO document does not describe a snapshot; it describes a governance model the system is required to maintain. If the system falls out of the approved posture, the authorization is at risk in real time, not at the next scheduled review.
The audit fix. Audit your current authorization model before claiming cATO readiness. Answer these three questions: Are controls validated in your deployment pipeline or only during formal assessment periods? Does your AO have access to a real-time compliance dashboard, or do they receive periodic reports? Does your ConMon process trigger authorization decisions, or does it feed a monitoring archive? If the answer to any of these is “no” or “archive,” your cATO foundation work starts there.
DevSecOps Integration: Where the cATO Compliance Engine Lives
cATO does not function without DevSecOps infrastructure. The compliance controls that a traditional ISSO validates manually must be automated and integrated into the CI/CD pipeline to sustain continuous authorization. Platform One, the DoD DevSecOps platform that pioneered cATO for DoD applications, built this infrastructure at scale. For a deeper look at pipeline compliance architecture, see the federal DevSecOps compliance guide. Most federal agencies and contractors are building toward it from varying starting points.
Automated Security Scanning in the Pipeline
The CI/CD pipeline is where continuous control validation happens. Static Application Security Testing (SAST) scans source code at every commit. Software Composition Analysis (SCA) identifies vulnerabilities in third-party dependencies before they reach production. Container image scanning validates that every image deployed meets the approved security baseline. Infrastructure as code scanning checks configuration files for security misconfigurations before they provision.
Each of these scan types maps to specific RMF controls. SAST covers controls in the SA-11 family (Developer Testing and Evaluation). Container scanning covers CM-7 (Least Functionality) and SI-3 (Malicious Code Protection). IaC scanning covers CM-6 (Configuration Settings) and CM-8 (System Component Inventory). The mapping matters because scan findings must connect to control validation status in the compliance dashboard, not to a security findings queue alone.
Organizations that treat pipeline scanning as a security function separate from compliance miss the cATO value. The scan output is the compliance evidence. When a pipeline scan confirms that no critical vulnerabilities exist in the container image being deployed, that confirmation is an automated control validation event that updates the ATO posture in real time.
Real-Time Compliance Dashboards
The AO’s view of a cATO system is a dashboard, not a document. The dashboard aggregates control validation results from every automated scan, presents compliance posture by control family, tracks open findings by severity and age, and surfaces trend data showing whether the system is maintaining or degrading its security posture over time.
Tools like Anchore, StackArmor, and RegScale build this layer by ingesting scan data from pipeline tools and mapping it to RMF control families in real time. The authorizing official does not wait for the ISSO to compile a quarterly report. They query the dashboard. If the compliance posture crosses a defined threshold, automated alerts notify the AO and the system owner. The human authorization decision is informed by live data, not periodic summaries.
The audit fix. Map your current pipeline tools to RMF control families before deploying a compliance dashboard. Build a control validation matrix: list every control in scope, identify the automated tool that validates it (SAST, SCA, container scan, IaC scan, SIEM), and confirm the tool can produce machine-readable output the dashboard can ingest. Controls without an automated validation source are manual gaps that require separate evidence collection workflows. Address those gaps before claiming real-time compliance posture.
cATO does not replace the authorizing official’s judgment. It changes what that judgment is based on. An AO working from live dashboard data is making a better-informed decision than one working from a six-month-old assessment package. The governance model still requires human accountability; the evidence quality is what changes.
OSCAL-Ready Documentation: The Machine-Readable Foundation
cATO requires documentation the compliance engine can read and process, not documents a human reviewer interprets. OSCAL, the Open Security Controls Assessment Language developed by NIST, is the format. Without OSCAL-formatted system security plans, component definitions, and assessment results, the automated compliance pipeline cannot validate control status against the authorized baseline. The documentation is the machine’s instruction set.
What OSCAL Requires in Practice
An OSCAL-formatted SSP is not a Word document reformatted to JSON. It is a structured representation of every control implementation, every system component, every interconnection, and every piece of assessment evidence using defined schemas. A narrative that says “MFA is implemented using Azure Entra ID” becomes a machine-readable assertion with component identifiers, control mappings, implementation status fields, and links to validation artifacts.
For cATO, this structure enables the compliance pipeline to query the authorized baseline at any point. When a deployment pipeline scan confirms that MFA enforcement is active for all privileged accounts, that confirmation links to the OSCAL control assertion for AC-2 and updates its validation status. The authorization package stays current because the pipeline is continuously populating it with validated evidence, not because an ISSO is manually updating a Word document.
Building the OSCAL Package for cATO
Federal agencies moving to cATO should treat OSCAL package development as a parallel track to DevSecOps pipeline buildout, not a downstream task. The component definitions in the OSCAL package determine what the pipeline validates and how findings map to control status. Building the pipeline without the OSCAL package means the scan outputs have no structured home in the authorization record.
FedRAMP Rev5 and FedRAMP 20x both converge on machine-readable foundations, though through different programmatic paths. The FedRAMP Rev5 machine-readable milestone was originally scheduled for September 30, 2026 under RFC-0024, but FedRAMP Notice 0009 (March 25, 2026) established a staggered three-deadline schedule. Significant change notification and minimum assessment scope requirements begin January 1, 2027 for all Rev5 classes. New Rev5 Class D (High) submissions must provide comprehensive machine-readable data beginning May 1, 2027. Existing Rev5 Class D (High) certified cloud services must provide comprehensive machine-readable authorization data by November 1, 2027 (before or during their next annual assessment). Classes A (Pilot), B (Low), and C (Moderate) must provide semi-structured text authorization data by the same November 1, 2027 deadline. Notice 0009 references “machine-readable authorization data” generally rather than mandating OSCAL specifically, though OSCAL remains the industry-leading format. The CR26 (FedRAMP Consolidated Rules for 2026) binding rules will be published by end of June 2026. FedRAMP 20x runs on its own Key Security Indicator framework (RFC-0006) and is explicitly out of RFC-0024 scope. The DoD cATO framework and the FedRAMP Rev5 machine-readable requirements share the same technical prerequisite: structured documentation that the compliance pipeline can process.
The audit fix. Start the OSCAL package with component definitions. Inventory every software component, hardware component, and service in the system boundary. Define each component’s control contribution in OSCAL format before writing control implementation statements. This inverts the traditional SSP drafting process, but it builds a package the pipeline can actually use. The GSA fedramp-automation repository at github.com/GSA/fedramp-automation includes templates and validators that confirm schema compliance before you connect the package to a live compliance engine.
cATO Implementation Roadmap: The Four-Phase Buildout
Organizations that have achieved cATO authorization, including Platform One-hosted applications and early DoD cATO adopters, followed a recognizable build sequence. The phases are not perfectly linear, and teams with existing DevSecOps maturity can compress or overlap them. The sequence reflects the dependency order: each phase creates the foundation the next phase requires.
Phase 1: Secure Landing Zone and Pipeline Baseline
cATO requires a secure, accredited infrastructure environment before authorization work begins. The secure landing zone establishes the baseline configuration, network segmentation, and access controls that define the cATO operating environment. Platform One’s Iron Bank, a hardened container registry with pre-validated images, is the DoD model. Commercial implementations use comparable patterns: hardened Kubernetes clusters, immutable infrastructure, and pre-approved CI/CD toolchains.
Pipeline security tooling deploys in this phase. SAST, SCA, container scanning, and IaC scanning must be operational and producing structured output before OSCAL package work begins. The scan configurations should reflect the control set the system will be authorized against, so that scan findings map to specific RMF control families from day one.
Phase 2: OSCAL Package and Control Mapping
Phase 2 builds the OSCAL-formatted authorization package. System boundary definition, component inventory, and control selection happen here. Each control in scope maps to an automated validation source in the pipeline. Controls without automated validation sources get documented with manual evidence collection workflows. The control validation matrix from Phase 1 audit work becomes the blueprint for Phase 2 package structure.
This phase also establishes the risk tolerance thresholds that govern the ATO posture. How many open critical findings trigger an AO notification? What findings warrant a pause on production deployments? These thresholds translate into automated workflow rules in the compliance dashboard. The AO defines them during Phase 2; the system enforces them automatically in later phases.
Phase 3: Continuous Monitoring Automation
Phase 3 operationalizes the compliance engine. The compliance dashboard connects to pipeline scan outputs and begins tracking control validation status in real time. Automated alerts activate against the risk thresholds defined in Phase 2. The OSCAL package begins receiving automated evidence updates from pipeline runs.
The ConMon process transforms here. Monthly scan reports still exist, but they are generated automatically from dashboard data, not compiled manually by the ISSO. The human work shifts from data collection to exception management: reviewing automated findings, making remediation decisions on open risks, and maintaining the risk register. Gartner forecasts that by 2026, 70% of enterprises will have integrated compliance as code into their DevOps toolchains (Gartner Market Guide for DevOps Continuous Compliance Automation Tools). The operational discipline required to get there is what separates organizations that achieve cATO from those that produce cATO documentation without the underlying capability.
Phase 4: Authorization and Ongoing Posture Management
Phase 4 is the formal authorization under cATO governance. The AO reviews the compliance dashboard, the OSCAL package, the risk thresholds, and the continuous monitoring architecture. Authorization is granted not on a static package but on a demonstrated operating model. The ATO document describes the governance commitments the system owner is making: control validation cadence, finding remediation SLAs, AO notification thresholds, and the conditions under which authorization is suspended.
Post-authorization, the team’s compliance work is pipeline maintenance and exception management. New features trigger pipeline scans and update control validation status automatically. Significant architectural changes trigger a focused assessment of affected controls. The conventional reauthorization cycle does not apply in the same form; the AO reviews posture on a defined schedule, but authorization is not at risk unless the system falls out of its approved operating parameters.
The audit fix. Before Phase 4 authorization, conduct a dry-run AO briefing using only the compliance dashboard. If the AO cannot answer “what is the current control validation rate?”, “how many open critical findings exist?”, and “when was the last pipeline scan?” from the dashboard alone, the cATO infrastructure is not ready. The dashboard must speak for itself. Documentation supplements it; it does not replace it.
| Dimension | Traditional ATO | Continuous ATO (cATO) |
|---|---|---|
| Authorization timeline | 12-18 months from initiation to ATO signature | 90 days or less for the formal authorization phase, given mature DevSecOps infrastructure (total buildout is 6-18 months) |
| Reauthorization cycle | Conventionally every 3 years per agency policy, OMB A-130, or FedRAMP PMO guidance; or on significant change | Continuous; posture maintained at all times, no discrete reauthorization event |
| Control assessment method | Point-in-time assessment by an independent assessor (3PAO for FedRAMP systems; Security Control Assessor for DoD systems); manual evidence review | Automated pipeline validation at each deployment; real-time control status |
| AO visibility | Periodic reports (monthly ConMon, quarterly Plan of Action and Milestones / POA&M); no real-time view | Real-time compliance dashboard; automated alerts on threshold breaches |
| Documentation format | Narrative SSP, Word/PDF; human-readable | OSCAL-formatted package; machine-readable, continuously updated |
| Security finding response | POA&M entries; remediation tracked in next quarterly review | Automated alert and workflow trigger; SLA-governed remediation tracked in dashboard |
| Compliance posture age | Current as of last assessment; drift accumulates between cycles | Current as of last deployment pipeline run; drift is continuous monitoring output |
| ISSO role | Manual evidence collection, package maintenance, report compilation | Exception management, risk decision support, pipeline compliance configuration |
| Key enabling technology | GRC platforms for documentation management | OSCAL tooling, CI/CD pipeline security scanners, real-time compliance dashboard |
| Program alignment | NIST SP 800-37 Rev 2 (sequential RMF steps) | DoD CIO cATO governance (Feb 2022 Memo + Evaluation Criteria + April 2025 Implementation Guide), NIST SP 800-37 Rev 2 (continuous monitoring emphasis), FedRAMP continuous monitoring guidance |
cATO is not a shortcut through the RMF. It is a higher-discipline operating model that requires more engineering investment upfront than a traditional ATO, not less. The 90-day authorization phase advantage belongs to organizations that have already built the DevSecOps foundation, completed their OSCAL package, and configured automated control validation. Organizations that attempt cATO as a documentation exercise, without the pipeline infrastructure to sustain it, will fail their first AO review of the compliance dashboard. Build the engine before you schedule the authorization.
Frequently Asked Questions
What is a continuous ATO implementation guide and who needs one?
A continuous ATO implementation guide defines the DevSecOps infrastructure, OSCAL documentation, and automated monitoring architecture required to achieve and maintain ongoing federal system authorization without periodic reauthorization cycles. Federal agencies, DoD contractors, and FedRAMP cloud service providers managing high-velocity systems benefit most. Any organization with release cycles shorter than 90 days faces authorization drift risk under the traditional model.
How does cATO relate to the NIST Risk Management Framework?
cATO transforms the RMF Monitor step (Step 7 in NIST SP 800-37 Rev 2) through automated tooling rather than periodic manual review. The seven RMF steps still apply; cATO changes how Step 7 operates in practice. Automated pipeline scans replace point-in-time assessments for control validation. The authorizing official still makes the authorization decision; they make it based on real-time dashboard data instead of a static assessment package.
What is the DoD cATO framework and how does it differ from civilian agency practice?
The DoD CIO cATO framework is governed by three documents: the February 2022 cATO Memo signed by DoD CIO John Sherman, the cATO Evaluation Criteria (dodcio.defense.gov), and the DevSecOps Continuous Authorization Implementation Guide (April 2025, DoD CIO). The framework requires three competencies: continuous RMF control monitoring, active cyber defense, and use of an approved DevSecOps reference design. Platform One is the predominant DoD reference implementation but not the only approved path. Civilian agencies follow the same NIST SP 800-37 baseline but without DoD’s specific toolchain requirements. FedRAMP Rev5 under RFC-0024 is driving similar automation requirements for civilian cloud providers, while FedRAMP 20x runs on its own Key Security Indicator framework. For full details on the OSCAL standard, see the OSCAL compliance standard explained.
Can an organization achieve cATO without Platform One?
Platform One hosts cATO-enabled applications for DoD programs, but cATO is an authorization model, not a platform requirement. Organizations build equivalent infrastructure using commercial tools: hardened container registries, CI/CD pipeline security scanners from vendors including Anchore, compliance automation platforms from StackArmor or RegScale, and OSCAL tooling from NIST’s published resources. The technical requirements are the same whether the infrastructure is Platform One or a commercial equivalent with equivalent security controls.
How long does it actually take to implement cATO from scratch?
Organizations with no existing DevSecOps infrastructure should plan 12-18 months to build cATO capability before the first authorization attempt. Organizations with mature CI/CD pipelines, existing container security tooling, and partial OSCAL documentation complete the buildout in 6-9 months. The 90-day authorization timeline applies to the formal authorization phase, not the total implementation timeline. The pre-authorization investment is what makes the 90-day gate achievable.
What is OSCAL and why is it required for cATO?
OSCAL is the Open Security Controls Assessment Language, a set of machine-readable formats for security documentation published by NIST. cATO requires OSCAL because automated compliance pipelines cannot parse narrative Word documents. OSCAL-formatted system security plans, component definitions, and assessment results enable the compliance engine to query control implementation status, map pipeline scan findings to specific controls, and update authorization posture programmatically. Without OSCAL, there is no machine-readable foundation for continuous control validation.
What vendors support cATO implementation?
Anchore provides container security scanning and software bill of materials management that feeds cATO pipelines. StackArmor offers FedRAMP and DoD cATO acceleration services including compliance dashboard deployment and OSCAL package development. RegScale provides continuous compliance automation that maps pipeline findings to RMF control families in real time. Each vendor addresses specific layers of the cATO stack; most mature implementations combine multiple tools rather than relying on a single platform.
How does cATO connect to FedRAMP?
cATO and FedRAMP converge on automation and machine-readable documentation, but through distinct programmatic paths. The original FedRAMP Rev5 machine-readable milestone (September 30, 2026 under RFC-0024) was extended by FedRAMP Notice 0009 (March 25, 2026), which set a staggered three-deadline schedule: significant change notification and minimum assessment scope requirements begin January 1, 2027; new Rev5 Class D (High) submissions must provide comprehensive machine-readable data by May 1, 2027; and existing Rev5 Class D (High) certified services face a November 1, 2027 deadline. Classes A (Pilot), B (Low), and C (Moderate) face the same November 1, 2027 deadline for semi-structured text. CR26 binding rules are expected by end of June 2026. FedRAMP 20x runs on its own Key Security Indicator framework under RFC-0006 and is explicitly out of RFC-0024 scope. Organizations building toward DoD cATO and FedRAMP Rev5 authorization should develop a single OSCAL package that satisfies both, since the NIST SP 800-37 control baseline underlies both programs.
Subscribe to The Authority Brief for next week’s analysis.
