The pace of the Authorization to Operate (ATO) process has long been a source of frustration and lost productivity. Technology can only make a difference if it is deployed. Yet, the pace is rarely the fault of a single stakeholder. Instead, the pace reflects systemic complexity, entrenched policy processes, evolving security requirements, and a vendor and government program/project manager ecosystem often unprepared to meet government compliance expectations. While government agencies bear responsibility for clarifying shifting frameworks and implementing automation, contractors must improve their readiness, code quality, and documentation to contribute meaningfully to secure, timely authorizations.
Authorization to Operate (ATO): Policy vs. Process vs. Risk
Federal ATOs are legally mandated and structured by formal frameworks. While they are perceived to be compliance-oriented, their ultimate goal is to manage real security risk balancing risks against the utility a system yields. Legislation, such as the Federal Information Systems Management Act (FISMA), and policy, as outlined in OMB memoranda and other directives, stipulate all government information systems must undergo security authorization (ATO) before operation.[1] These policies explicitly link ATO to approved risk-management processes. For instance, DoD Instruction 8510.01 stipulates the RMF “adopts the NIST RMF to comply with FISMA requirements”[2] Similarly, FedRAMP was established by OMB to centralize cloud authorization using a standardized and centralized process.[3]
ATO: Policy, Then Process, Then Security
It is vital to align processes and security with well-defined, adaptive policy if automated ATO workflows are to be able to deliver speed and assurance.
Before ATO can be understood as a matter of process or security, it must be recognized as a policy-driven construct. Policy defines the intent, while the process defines the roles instantiating the intent. While policy does not equate to law, it provides a framework for the interpretation and implementation of legal mandates within government systems, including those found in FISMA, the Privacy Act and other relevant statutes. Policies issued by the Office of Management and Budget (OMB), such as A-130, and standards from the National Institute of Standards and Technology (NIST) translate legal authority into concrete measurable requirements for control implementation, risk acceptance, and documentation. These frameworks structure how agencies define security boundaries, assess risk, and ultimately authorize systems.[4] Inconsistencies in policy interpretation or outdated guidance can often create bottlenecks that are more disruptive than technical shortfalls. It is vital to align processes and security with well-defined, adaptive policy if automated ATO workflows are to be able to deliver speed and assurance. Therefore, policy must be the starting point for efficient authorization.
Process Frameworks (NIST, FedRAMP, DoD RMF)
The structured process of an ATO is derived from frameworks which translates policy into action. Chief among these is the NIST RMF (SP800 37), a seven-step lifecycle for selecting, assessing, measuring, implementing, and authorizing security controls.[5] [6] ATO packages are built on NIST SP 800-53 control baselines, a catalogue of safeguards “derived from mission and business needs, laws, executive orders, regulations, policies, standards, and guidelines.”[7] This means the controls cover both the policy requirements and the operational requirements of the system. FedRAMP extends NIST standards to the cloud.
The FedRAMP process defines specific control baselines, assessment templates, and reuse rules to enable a single ATO to cover multiple agencies. The Department of Defense’s (DoD) Risk Management Framework (RMF) aligns with the National Institute of Standards and Technology (NIST) RMF, but adds DoD-specific rigor. The frameworks are intended to be aligned.
Security and Risk Focus
Despite the compliance procedures, the purpose of an ATO is fundamentally security-driven: it formally accepts residual risk. In other words, an Authorizing Official (AO) only signs off on an ATO when the remaining vulnerabilities are understood and the mission benefit outweighs the risk.[8] NIST guidance makes clear that no system can be 100% secure, so “the best practice is to take a risk-based approach to system security.”[9] The RMF explicitly focuses on continuous risk management, from initial categorization through control implementation and ongoing monitoring.[10] Industry commentary echoes this: the ATO is not merely the completion of a ‘bureaucratic checklist’, but rather a ‘dynamic and ongoing commitment to ensuring that information systems operate securely, upholding federal and national defense priorities, and defending against adversaries’ [11] In practice, this means tailoring controls and authorization conditions to the system’s mission-criticality and threat context.
Interaction
In practice, the policy, frameworks, and security elements interact continuously. Software is dynamic; it evolves and so must the measures to safeguard it. Policy mandates establish the scope of authorizations to operate (ATO). Frameworks (NIST RMF, FedRAMP, and DoD RMF) define the steps, measures, and checks required to comply with the policy. Security objectives (such as risk mitigation and mission assurance) underpin the entire process. Historically, many agencies have viewed the ATO process as compliance-driven and ‘procedural’, sometimes at the expense of operational security insight.[12]
In practice, policy and prescribed frameworks have come to dominate the ATO process. Agencies must first follow the law and detailed process guidance; meeting every control requirement is non-negotiable. Compliance gates (e.g., documentation and third-party assessments) largely dictate timelines and workloads.[13] However, the intent behind these mandates is to reduce risk to a known and acceptable level, a level driven by mission requirements.
The formal ATO decision itself is an action that accepts risk,[14] and should be driven by real measurable security outcomes, not just checkboxes. Thus, while policy sets the minimum standard and frameworks provide the process, risk management should ultimately be the guiding influence.[15]
The Authorizing Official (AO)
At the core of the ATO process is the AO. The AO is the individual legally empowered to accept risk on behalf of an agency. The AO’s signature is not just procedural. The signature affirms that the residual risk of operating a system is understood, evaluated, and deemed acceptable within the mission context. This is a critical trust decision with operational consequences.[16]
To make an informed, timely, and risk-appropriate decision, the AO depends heavily on comprehensive, clear, and current information from multiple stakeholders. It is the responsibility of U.S. Government (USG) program managers to ensure internal system documentation (e.g., Site Security Plans (SSP), POA&Ms), operational contexts, and mission requirements are clearly defined. Meanwhile, commercial providers must supply precise, high-quality, and continuously updated evidence about their systems’ security postures — including inherited controls, vulnerability status, and implementation of secure-by-design practices.
The mission requirement and operational context are often not actually accurately planned, funded, and implemented, thus leaving many security issues unresolved. As a consequence (and often a result from contract law issues) vendors do not (or can avoid) providing the continuing level of security protection for their product.
When information is incomplete or roles are not aligned, the AO faces challenges. For instance, when vendors provide inadequate documentation, when system boundary descriptions are out of date, when new risk scenarios from emerging technologies are being evaluated, or when the system has undergone material changes, the AO will be forced to delay the process, demand rework, or approve a system based on incomplete insight. It is therefore essential to improve the flow of actionable, fully transparent, technically accurate, and risk-informed data to AOs if the ATO lifecycle is to be accelerated while ensuring mission assurance. Ideally, there is a balance to be found.
The ATO Bottleneck: From Paper to Practice
Achieving an ATO, the formal risk-acceptance decision by a senior official, has long been a landmark for U.S. federal IT deployments. In accordance with FISMA and NIST RMF guidance, an ATO is the document attesting that a system “meets required security and privacy standards and that its risk is acceptable.” While seemingly straightforward, in practice, the ATO process has become lengthy, documentation-heavy, and reactive.
The results are the consequence of innovation speed: the process of creating ATO packages can produce static artifacts that are outdated by the time they are reviewed. This can lead to delays, duplicated effort, and ‘compliance on paper’ that may not accurately reflect reality. Often, the ATO cycle could take months, sometimes years. The majority of that time is spent on manual evidence gathering and paperwork in addition to layers of subordinate bureaucratic review. Such redundant processes can hinder the deployment of mission-critical systems in a timely manner, especially in fast moving technologies like Artificial Intelligence (AI).
As the Government Accountability Office (GAO) observes, conventional compliance models frequently impede operational readiness and generate retrofit security gaps.
These lags compromise both security and agility. When providers and agencies wait until the tail end of the development process to gather control evidence, they risk costly rework and the introduction of security gaps. As the Government Accountability Office (GAO) observes, conventional compliance models frequently impede operational readiness and generate retrofit security gaps.[17] The previous model treats the ATO as an afterthought, a hurdle to be cleared rather than an integral part of sound engineering.
Why is this the case?
The ATO process is often complex and slow due to a combination of knowledge gaps, evolving requirements, and shifting interpretations—but also because of how these interact with legacy bureaucracy and risk-averse culture. Significant causes include:
1. Knowledge Gaps and Skill Shortages
- RMF complexity: Many practitioners lack a deep understanding of the NIST Risk Management Framework (RMF) or how to map technical configurations to security controls.
- Documentation overload: The ATO requires extensive, structured documentation, including system security plans (SSPs), POA&Ms, and continuous monitoring reports, which few staff are fully trained to produce. In addition, duplicate bureaucratic requirements often create multiple copies and versions from other interested parties.
- Role confusion: Confusion about responsibilities amongst system owners, ISSOs, security engineers, and authorizing officials creates coordination bottlenecks.
- Third-party reliance: FedRAMP and DoD processes often depend on 3PAOs or external assessors, introducing additional handoffs and scheduling delays.
2. Shifting or Inconsistent Interpretations
- Control interpretation variability: Agencies and assessors interpret NIST 800-53 controls differently, leading to rework. What’s “adequate” encryption or access control at one agency may fail at another.
- Inconsistent interpretations: AOs must exercise discretion when evaluating risk, yet inconsistent interpretations and insufficient vendor evidence complicate this. Providing clear, comprehensive packages up front helps reduce reliance on subjective judgments.
- FedRAMP overlays: Cloud providers may pass one agency’s authorization, only to be asked to “tweak” their package for another due to slightly different threat postures or interpretations.
3. Changing Requirements
- Continuous updates to NIST guidance: New revisions (e.g., SP 800-53 Rev. 5, SP 800-37 Rev. 2) introduce new families, such as supply chain risk and privacy, that systems weren’t designed to cover.
- Emerging mandates: Executive Orders (e.g., EO 14028), OMB memos (e.g., M-22-09 on zero trust), and new frameworks (e.g., CISA’s SCuBA) mean the “target” moves throughout a system’s lifecycle.
- System evolution: By the time an ATO is nearly complete, the system itself may have changed significantly (e.g., shifted to containers, integrated AI models), invalidating prior assessments.
4. Manual, Siloed Workflows
- Static documents: Most packages are created as Word/PDF documents, leading to version-control issues, limited reuse, and difficulty maintaining the current state.
- Spreadsheet-driven mapping: Control mapping, vulnerability tracking, and asset inventories are often tracked manually, which is error-prone and not easily updatable.
- Siloed toolchains: The security stack (SIEM, scanner, CMDB) is not integrated with ATO tooling, so live status is rarely reflected in the ATO package unless pulled manually.
5. Compliance-Centric Culture
- Checklist mentality: Organizations often focus on producing “good-looking packages” rather than meaningfully reducing risk, creating a time-consuming compliance theater.
- Risk aversion: Security and legal teams often err on the side of “do everything” rather than tailoring controls to realistic threats, slowing down the process.
- Fear of failure audits: Agencies fear being found noncompliant in OIG or GAO audits, so they tend to overcompensate by adopting conservative interpretations and generating more paperwork. Additionally, it has been seen that GAO auditors may have a limited view and knowledge of RMF implementations and measures, focusing on financial audit measures rather than NIST security or process measures
6. Lack of Automation or Tooling
- Few standardized APIs: Unlike DevOps, there is no widely adopted API layer for generating compliance artifacts. Tools like RapidFort exist but are not widely used.
- No shared source of truth: There’s often no central, real-time source of data about system configurations, vulnerabilities, and POA&Ms tied into the RMF flow.
- FedRAMP’s backlog: For SaaS providers, the FedRAMP JAB PMO backlog is a limiting factor, due to limited slots and government-side resourcing.
7. Legacy Systems and Architectures
- Hard-to-secure platforms: Many systems being authorized are based on legacy or hybrid architectures that don’t natively support segmentation, logging, or encryption.
- Undocumented systems: Older systems often lack clear diagrams, inventories, or ownership records, making them nearly impossible to assess accurately.
- Government agencies often have to navigate a maze of legacy processes, compliance mandates, and resource constraints. However, these bottlenecks are exacerbated by vendor submissions that are incomplete, inconsistent, or not aligned with control requirements. To overcome delays, there must be a collaborative rethinking of roles and expectations. PEOs/PMs need to follow CIO/CISO direction in ensuring measurable security standards are included in contracts for the vendors. There must be consequences for failure to meet these standards.
The Case for Automation
The current ATO processes are not without shortcomings. Periodic audits and checklist-driven reviews are not adequate for today’s rapidly changing, AI-driven IT environments, where the only constant is change. Manual control review of spreadsheets, screenshots, and logs to demonstrate that the implementation of each control is slower and more error-prone than the mission demands. Security teams often focus on meeting minimum compliance requirements instead of implementing comprehensive security measures through a forward-looking lens.
Automation offers a straightforward remedy. Tools that integrate with modern DevSecOps pipelines can generate and validate evidence as part of the standard workflow. For example, platforms like RapidFort continuously scan running systems, container images, and infrastructure, automapping findings to NIST SP 800-53 controls. They maintain live compliance dashboards that show which controls are satisfied and where issues remain. Likewise, configuration-as-code tools (Terraform, Ansible, Chef InSpec, etc.) can codify hardening rules.
These automation approaches directly address the ATO bottleneck. Rather than spending months chasing static evidence, teams can verify controls on demand. For instance, the fastest phase of a manual ATO — evidence generation — is dramatically accelerated. Automated tools can attest to controls like AC-6 (Least Privilege) by inspecting IAM roles, or SC-28 (Encryption at Rest) by checking cryptographic settings. The outcome is verifiable, timestamped, and reproducible evidence produced by machines. Integrated automation can cut ATO cycles by an estimated 40–60% range.
Secure by Design (SbD) transforms the ATO from a retrospective checklist into a living, evidence-driven process aligned with DevSecOps workflows.
When systems are built with codified, testable security measures, automation tools can continuously verify compliance without manual rework. Secure by Design (SbD) transforms the ATO from a retrospective checklist into a living, evidence-driven process aligned with DevSecOps workflows. SbD is the architectural bedrock that enables ATO automation by embedding security controls directly into system code and infrastructure from the outset
Secure-by-Design: Embedding Security from Day One
Security by Design (SbD) is an engineering mindset and a set of principles that treat security as built-in rather than bolted on. The intent is to anticipate threats in architecture, codify controls in code, and continuously validate outcomes. According to Carnegie Mellon’s Software Engineering Institute, SbD involves a seven-phase lifecycle (Plan, Design, Build, Test, Deploy, Monitor, Evolve), where each phase “integrates security tasks into normal engineering workflows.”[18] SbD principles can be distilled into a few core ideas:
- Early Threat Modeling: Identify potential attackers, assets, and data flows from the start. For example, during the system “Categorize” (RMF Step 1), teams build data flow diagrams and analyze mission impact to select appropriate controls, rather than guessing later.
- Least-Privilege and Defense-in-Depth: Architect systems with minimal privileges and multiple overlapping safeguards. Embedding these patterns into the design and build phases ensures that control baselines (NIST SP 800-53 families like Access Control, Logging, Configuration Management, etc.) are reflected in the system configuration from the outset.
- Automate Controls Implementation: Express security rules as code. For instance, Infrastructure as Code (IaC) templates can enforce encryption, logging, or authentication settings uniformly across all environments. Using Security Technical Implementation Guides (STIGs) or Center for Internet Security (CIS) benchmarks as code allows immediate, automated hardening.
- Continuous Validation: Build scanning and testing into the CI/CD pipeline. Every code commit or build triggers automated assessments and tooling (e.g., SAST, dependency checks, vulnerability scans) that map results back to control objectives. This real-time feedback provides on-the-fly evidence (logs, Software Bill of Materials (SBOM) records, scan reports) so controls can be demonstrated instantaneously.
These SbD steps align naturally with the NIST RMF phases. For example, “Plan”/”Design” corresponds to Categorize and Select Controls: we clarify the security boundary and then choose accurate baselines. “Build”/”Test” then Implement the selected controls via code and automated scripts, generating built-in compliance. “Deploy”/Assess leverages CI pipelines so that each deployment assess itself. By the time of “Authorize,” all the evidence has been collected in the dashboards.[19]
This SbD pipeline transforms the ATO into a compliance-by-construction process. One way to think of it is that every commit, or container automatically carries with it evidence of compliance: if a build passes its built-in checks, those passing results are tagged as control evidence. Rather than firefighting at approval time, security is baked into the system. As OMB notes, embedding these practices means “the evidence necessary for ATO is produced automatically as part of normal engineering operations.”
Continuous ATO (cATO): Making Authorization an Ongoing Service
To realize the full benefits of automation, the federal cybersecurity community is moving toward a continuous ATO (cATO) model—where authorization is no longer a static event but an ongoing, evidence-driven service. An acceptable baseline is established and must be met even as the code evolves. Automated ATO, SbD, and cATO align with DevSecOps practices. In tandem, the four leverage secure build pipelines, runtime monitoring, and continuous control validation to deliver near real-time visibility to the AOs. Rather than relying on static documentation and manual snapshots, systems under automated ATOs that use SbD principles and cATOs generate telemetry that directly maps to NIST RMF controls, enabling continuous compliance assessment.
This approach requires changes across the ecosystem: vendors must generate machine-readable artifacts and security attestations, program managers must ensure evidence is available and mapped to system boundaries, and AOs must be equipped to interpret dashboards instead of binders. cATO does not eliminate oversight—it makes it faster, smarter, and more defensible. In this model, ATO is no longer a gate—it becomes a feedback loop. And with this shift, the role of the AO also evolves: from a once-per-year or every third year approver to a partner in live system oversight, empowered by dashboards instead of document binders.
Tools of the Trade: Orchestration and Automation Platforms
Implementing SbD requires the proper toolchain. Platforms like the MITRE’s Security Automation Framework[20] and others exemplify how automation can bridge engineering and compliance. For instance, SAF integrates with DevSecOps workflows (CI servers, container registries, infrastructure pipelines) to enable continuous compliance. Its key features include continuous control verification against NIST SP 800-53, CIS benchmarks, FedRAMP baselines, and other standards, with real-time dashboards. It can automatically generate SSP and SAR content (e.g., control narrative statements) and output machine-readable artifacts (OSCAL and JSON) to streamline audits. Platforms like RapidFort and similar tools, which focus on the vulnerability element, act as a “compliance co-pilot,” translating technical scan results into authorization-ready reports.
Orchestration platforms can embed compliance. For example, SteelCloud and Chef have tools that allow teams to ingest DISA STIGs or CIS controls into code, continuously scan systems, and remediate deviations on the fly. Policy-as-code framework tools, such as Open Policy Agent and Terraform Sentinel, can enforce guardrails at deployment time. Vulnerability management tools can integrate with issue trackers to auto-open tickets for findings. The common theme is orchestrating compliance end-to-end: from code commit through to monitoring and governance.
In practice, a robust automated ATO toolchain might look like this diagram. Developers commit code to a CI pipeline, which builds and hardens artifacts. The automated tools (SAST, SCA, config scanners) analyze the code/infrastructure against control baselines. The generated security results (pass/fail) are auto-linked to specific RMF/NIST control IDs, while the compliance platform aggregates this evidence and signals any gaps back to engineers. At deploy time, runtime scans (e.g., container image scanners, cloud configuration checks) feed continuous-monitoring platforms. The Authorizing Official (AO) and assessors then view a unified dashboard of live control status instead of static reports.
Automation doesn't remove human judgment; it frees security professionals to think strategically by handling the routine work allowing the AOs to focus their attention on the changes not on the starting baselines.
This orchestration greatly eases the evidence burden. Instead of assembling screenshots and PDFs, engineers deliver data feeds. Compliance teams can spend more time addressing real risks rather than translating tech findings into narratives. The goal is for the AO to focus on risk instead of paperwork. Automation doesn’t remove human judgment; it frees security professionals to think strategically by handling the routine work allowing the AOs to focus their attention on the changes not on the starting baselines.
Shared Responsibility: Government and Providers
ATOs often occur in cloud or mixed environments, so a shared responsibility model applies. Under frameworks such as FedRAMP and DoD Cloud (IL requirements), cloud service providers (CSPs) assume many infrastructure-level controls, while agencies cover application- and data-level controls. Early architecture mapping is crucial here. SbD teaches teams to catalog which controls are inherited from the cloud (e.g., FedRAMP moderate controls for VPC security and host OS hardening) and which must be implemented in the tenant.
In this model, cloud providers and software vendors also have roles in automation. Many CSPs now publish Machine-Readable Authorization (MRA) artifacts or OSCAL-formatted SSPs to speed customer compliance. These can be consumed to create automated dashboards calling out exceptions. Some even provide APIs to export compliance evidence (e.g., AWS Audit Manager and Azure Policy data). Vendors of common software (such as Kubernetes distributions) increasingly provide CIS or STIG-hardened images and built-in logging mechanisms. Agencies should leverage these offerings: vendor-supplied automation can handle controls for layers they own, while the agency’s SbD pipeline covers the rest.
Importantly, responsibility-sharing also means co-developing solutions. For example, a CSP might integrate its continuous monitoring outputs (e.g., control compliance status) into the agency’s compliance dashboards. Likewise, custom applications (or COTS software) should embed monitoring hooks so that their patch status and configuration can be automatically asserted. Joint “dev/co-dev” initiatives (such as cloud.gov for government agencies) demonstrate this: when a platform inherits FedRAMP status, the remaining customer ATO steps can be streamlined.
Training Tomorrow’s ATO Professionals
None of these innovations matters if people aren’t prepared. Recognizing this, the USG should sponsor ATO-focused education programs for government and provider cybersecurity professionals. These courses teach not only the technical RMF fundamentals but also the risk management strategy and automation. An executive-level course on the ATO process would cover FISMA requirements, RMF fundamentals, FedRAMP and ISO frameworks, threat modeling, NIST SP 800-53 control selection, SSP writing, assessment, incident response, and continuous monitoring. Participants learn to view ATO as a risk decision (“acceptable risk” per FISMA) and to align internal policies with external mandates (DoDI 8510.01, FedRAMP, NIST). Activities simulate real projects: students draft control baselines, write SSP statements, run mock assessments, and even prepare brief executive summaries for AOs.
Similarly, an ATO course for contractors and startups could provide hands-on RMF training with a DevSecOps emphasis. From “ATO 101” and FISMA basics to DoD 8570 workforce roles and technical controls, this training targets the skillset needed to accelerate authorizations. It explicitly covers implementing controls via STIGs and Infrastructure-as-Code, using automated scanning tools (Nessus/ACAS, container scanners), and transitioning to continuous authorization. By including syllabus components such as DevSecOps practices, early threat modeling in design, and continuous ATO concepts, these programs prepare professionals to apply SbD and automation on the job.
The next generation of ATO-focused cyber professionals needs to be trained to speak both “policy” and “pipeline.” They learn the formal steps (categorization, SSP/SAR/POA&M drafting, AO decision, etc.) as well as modern best practices (automation orchestration, SBOM usage, FedRAMP inheritance). For example, participants learn to make the upfront effort of embedding a STIG in code means less writing later. They also discuss workforce certifications (DoD 8570 IAM/IAT categories) to ensure teams have qualified personnel for roles like ISSO, ISSM, and Security Control Assessor. Courses emphasize collaboration between developers, assessors, and managers, echoing the cultural shift needed for true SbD.
Emerging Threats: AI and Quantum & the ATO
ATO documentation and design controls must now also account for emerging tech risks. Two critical areas are specifically artificial intelligence (AI) and quantum computing. On the surface these technologies introduce a different class of risks, but these risks are often merely different manifestations of the fundamental risks covered by policy, and if posed in that light, the existing policy frameworks could be modified to handle these. For example, AI risk is largely around data exposure, already covered in the frameworks.
AI considerations
As agencies increasingly use AI (and face AI-enabled adversaries), ATO packages should include assurances of AI trustworthiness. The NIST AI Risk Management Framework (AI RMF 1.0, 2023) provides a starting point. It encourages organizations to document the design of AI systems, data provenance, model validation, bias mitigation, and decision transparency. For example, if a system incorporates machine learning components, the SSP must note the training data governance, update frequency, and security of the model pipeline. Threat modeling must explicitly consider adversarial AI scenarios (e.g., model poisoning or deepfake attacks) and the defenses against them. Controls might include robust input validation, model audit logs, or human-in-the-loop checkpoints. Recent literature highlights how adversaries can weaponize AI for automated reconnaissance, realistic deepfakes, and self-mutating malware.[21] In response, ATO processes must require ML-based tools in defense roles have traceable development histories aligned to the specific function the tool is expected to execute and provide continuous monitoring for anomalous behavior. More broadly, agencies may start referencing NIST’s AI RMF in new guidance; e.g., NIST (2023) recognizes that trustworthiness attributes (safety, security, privacy) should be risk-managed like any other. In practice, this could mean tagging AI-relevant sections in the SSP and applying existing controls (e.g., SI-3 Malicious Code Protection) to AI modules.
Quantum resilience
Threat modeling must assume that adversaries could someday record encrypted traffic now to decrypt later.
Post-quantum cryptography (PQC) is no longer futuristic: NIST has finalized quantum-resistant algorithms and urges immediate transition planning.[22] ATO documentation should reflect quantum readiness for sensitive data. This means (1) inventorying where vulnerable public-key crypto (RSA, ECC) is used; (2) including PQC migration plans in SSPs; and (3) incorporating new controls from EO 14028 (Software Supply Chain) that track cryptographic agility. For example, an ATO might require that any new key exchange be implemented in a “crypto-agile” manner or that post-quantum schemes (such as CRYSTALS-Kyber) be adopted in accordance with NIST guidance. Threat modeling must assume that adversaries could someday record encrypted traffic now to decrypt later. As one expert warns, AI-driven attacks combined with quantum decryption could represent a “catastrophic” threat if left unaddressed.[23] Thus, controls such as SC-13 (Cryptographic Protection) should be interpreted to cover quantum-resistant algorithms where available, and SSPs should annotate any legacy crypto in use. Even if full PQC is a phased effort, ATOs must demonstrate plans for it.
SBOMs and pipelines must now account for AI/quantum. An SbD-secured system might, for instance, maintain an AI model inventory in its SBOM or flag deprecated crypto libraries. Automated dependency checks should include the detection of known vulnerable algorithms. Documentation needs an explicit section on “Emerging Tech Risks,” noting that controls will evolve (e.g., NIST SP 800-208 on PQC, NIST SP 800-207 on Zero Trust architecture, including AI). By integrating these considerations into the risk assessment and control selection steps, future ATO packages will be better aligned with agencies’ “quantum-proof” and “trustworthy AI” roadmaps.
Continuous Updates: Evolving Software Supply Chains
Finally, supply chain reviews must become continuous. The speed of innovation is increasing, and the ATO frameworks and processes must keep pace. It is simply a fact: software supply chains change daily as new library versions, container images, and third-party components are released. The static checklists are obsolete as soon as the next build is released.
Automated SBOM tools should scan code repositories to detect vulnerabilities in new dependencies. Each SBOM update can trigger a compliance revalidation step. Compliance automation platforms then regenerate any affected SSP/SAR entries on demand. In effect, the authorization package lives alongside the software, not in a filing cabinet.
Modern SbD guidance specifically highlights this need, “Automated SBOMs and dependency checks mitigate third-party risk”, and contracts can even require providers to supply automated compliance evidence.[24] By continuously syncing the evidence repository with the evolving software, agencies avoid “ATO decay,” where a once-authorized system drifts out of compliance. In fact, some advanced programs treat the ATO not as a static certificate but as a living assurance framework. Every deployment or change “inherits pre-validated templates” so that new instances start in a known-good state. The AO can then extend or revoke the ATO fluidly based on these feeds, rather than waiting years for a renewal audit.
Going forward
Improving the ATO process requires a shared commitment from policymakers, government assessors, and private sector vendors. While automation and Secure-by-Design practices offer the technical foundation, aligning policy, practice, and expectations is essential for sustainable transformation. In addition to the urgent need to provide training to both USG and providers, the following table outlines additional concrete recommendations across three domains—policy, U.S. Government practice, and vendor behavior to streamline and modernize the ATO process.
Conclusion: Toward Data-Driven Trust
In an age of hybrid clouds and rapid releases, the old ATO paperwork model is no longer fit for purpose. By contrast, a Secure-by-Design, automation-driven approach redefines the ATO as a continuous process of trust. Security controls become embedded in engineering, evidence is generated in real time, and live dashboards and data streams replace the manual slog. Agencies and providers share responsibility: vendors harden their components, while systems engineers integrate inherited controls and run continuous scans. New training programs ensure that cyber professionals understand not just policy, but how to implement it in code and pipelines. Emerging challenges like AI adversaries and quantum threats are addressed through updated threat models and forward-looking controls. And through automation and SBOM-driven processes, the package stays up to date with the software supply chain.
ATO practices are mandated by policy and structured by frameworks, but they are supposed to be grounded in actual security/risk needs. Policy (FISMA, OMB, DoD directives) is the primary driver of requiring ATOs, and NIST-based processes (RMF, FedRAMP) prescribe how to implement them. The dominant day-to-day influence has been those policies and procedures. However, there is an explicit (and growing) push to ensure that ATO decisions are driven by real-world risk and mission impact.
The ATO has to evolve from a bureaucratic gatekeeper into a dynamic trust mechanism—actively enabling mission assurance by continuously validating resilience, integrity, and compliance in an ever-changing threat environment.
The ATO process can become more efficient, transparent, and meaningful. Compliance becomes a byproduct of sound engineering, not an after-the-fact checkbox. In this vision, agencies can deploy mission-critical systems confidently, knowing that authorization is maintained dynamically. The ATO has to evolve from a bureaucratic gatekeeper into a dynamic trust mechanism—actively enabling mission assurance by continuously validating resilience, integrity, and compliance in an ever-changing threat environment. 
[1] (Team, 2025)
[2] (Office of the DoD Chief Information Officer, 2022)
[3] (Office of Management and Budget (OMB), 2024)
[4] (SecondFront, 2025)
[5] (National Institute for Standards and Technology (NIST), 2020)
[6] (Team, 2025)
[7] (National Institute for Standards and Technology (NIST), 2020)
[8] (SecondFront, 2025)
[9] (Team, 2025)
[10][10] (National Institute for Standards and Technology (NIST), 2020) (Team, 2025)
[11] (Clomera, 2023 )
[12] (Clomera, 2023 ) (KPMG, 2025)
[13] (Team, 2025)
[14] (SecondFront, 2025)
[15] (KPMG, 2025) (Office of Management and Budget (OMB), 2024)
[16] (National Institute of Standards and Technology , 2018)
[17] (Government Accountability Office (GAO), 2025.)
[18] (Touhill, 2023)
[19] (Touhill, 2023)
[20] (MITRE, 2025)
[21] (Gupta, 2025)
[22] (Gupta, 2025)
[23] (Gupta, 2025)
[24] (Pentecost, 2025)
Henry J. Sienkiewicz
Dr. Ray Letteer
References
Clomera, A. (2023 , October 17). From Risk to Authorization: Understanding What ATO Means in Cybersecurity. Retrieved from ipkeys.com: https://ipkeys.com/blog/ato-cybersecurity/
Government Accountability Office (GAO). (2025., July 30). Cybersecurity Regulations: Industry Perspectives on the Impact, Progress, Challenges, and Opportunities of Harmonization. Retrieved from gao.gov: https://www.gao.gov/products/gao-25-108436
Gupta, A. (2025, July 2). Quantum-Resilient AI Security: Defending National Critical Infrastructure in a Post-Quantum Era. Retrieved from https://www.cyberdefensemagazine.com/quantum-resilient-ai-security-defending-national-critical-infrastructure-in-a-post-quantum-era/
KPMG. (2025). Accelerating ATOs with the new cybersecurity risk management construct. Retrieved from kpmg.com: https://kpmg.com/us/en/articles/2025/accelerating-ato-ai-burden-to-battlefield.html
MITRE. (2025). MITRE Security Automation Framework . Retrieved from https://saf.mitre.org/
National Institute for Standards and Technology (NIST). (2020, September ). NIST SP 800-53B Control Baselines for Information Systems and Organizations. Retrieved from https://csrc.nist.gov/pubs/sp/800/53/b/upd1/final
National Institute of Standards and Technology . (2018, December). NIST SP 800-37 Rev. 2 Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. Retrieved from https://csrc.nist.gov/pubs/sp/800/37/r2/final
Office of Management and Budget (OMB). (2024, July 25). M-24-15 Modernizing the Federal Risk and Authorization Management Program (FedRAMP) . Retrieved from https://bidenwhitehouse.archives.gov/omb/management/ofcio/m-24-15-modernizing-the-federal-risk-and-authorization-management-program-fedramp
Office of the DoD Chief Information Officer. (2022, July 19). DoD Instruction 8510.01, “Risk Management Framework (RMF) for DoD. Retrieved from https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/851001p.pdf#
Pentecost, W. S. (2025, October). Comply-to-Contract: Operational Security and Fraud Prevention in the Trucking Industry. The Transportation Lawyer, 27(2), 17-23.
SecondFront. (2025, September 30). DoD Authority to Operate (ATO) explained. Retrieved from secondfront.com: https://www.secondfront.com/resources/blog/dod-ato-explained
Team, I. P. (2025, June 3). Authorization to Operate (ATO). Retrieved from cms.gov: https://security.cms.gov/learn/authorization-operate-ato
Touhill, G. (2023, October 9). Secure by Design at CERT. Retrieved from https://www.sei.cmu.edu/blog/secure-by-design-at-cert/
Leave a Comment