Automation can generate evidence and enforce controls. It cannot define risk tolerance, assign responsibility, establish the authorization boundary, or accept risk.
For years, the Authorization to Operate process has been framed as a documentation problem. Teams spend too much time assembling evidence, updating control narratives, chasing screenshots, and preparing for assessments. Automation can remove much of that burden. It can collect evidence continuously, apply policies consistently, identify vulnerabilities earlier, and make the state of a system easier to understand.
Yet an ATO effort can still stall even when the pipeline is fast and the evidence is plentiful.
That is because authorization is not simply a technical output. It is a risk decision about a defined system, operating in a defined environment, for a defined mission. The Authorizing Official needs confidence that risks are understood, responsibilities are clear, controls are working, and unresolved findings are being managed deliberately.
To make those responsibilities concrete, this article uses several terms consistently. The system is the capability inside the authorization boundary. The program is the organization accountable for delivering and governing that system. The platform is the shared technical foundation that provides services such as identity, networking, logging, policy enforcement, and software distribution. The environment is the real operational setting in which the system runs, including its infrastructure, data, users, integrations, mission, and threat conditions. An agency, service, or command supplies the organizational authority and policy context around the program.
This distinction is consistent with current Department of War direction. The Department announced its Cybersecurity Risk Management Construct in September 2025 to move cybersecurity away from static assessments and toward continuous risk management. Automation is one of its tenets, alongside critical controls, continuous monitoring and ATO, DevSecOps, cyber survivability, training, inheritance, operationalization, reciprocity, and threat informed assessments. Automation matters, but it is one part of a broader operating model.
When those conditions are missing, more automation can produce more data without producing a decision. The following problems often sit beneath a delayed initial ATO or an unsuccessful move toward continuous authorization.
1. The authorization boundary keeps changing
Every authorization begins with a boundary. That boundary identifies what is inside the system, what sits outside it, what data crosses it, and which connections or services the system depends on.
In practice, the boundary can move throughout development. A team adds a managed service. A new data source appears. A hosting decision changes. An external identity provider becomes part of the architecture. A platform component that was assumed to be inherited turns out to require program action.
Each change can affect the system categorization, applicable controls, inherited protections, threat assumptions, evidence requirements, and residual risk. If the official boundary diagrams and system inventory do not keep pace, the assessment is performed against a system that no longer exists.
Continuous authorization does not eliminate this problem. Department of War guidance describes cATO as operating within a system authorization boundary and within established risk tolerances. A boundary that is unstable or poorly understood makes both conditions difficult to satisfy. See the cATO Evaluation Criteria.
A stronger approach is to treat the boundary as a governed, versioned artifact. Architecture diagrams, data flows, external connections, software inventories, and platform dependencies should change together. The program should also define which architectural changes require an updated risk review before deployment.
2. Control ownership between the platform, application, and program is unclear
Modern delivery environments divide responsibility across several groups. A platform team may operate Kubernetes, identity services, logging, and policy enforcement. An application team may own source code, dependencies, configuration, and mission workflows. A program office may own governance, operational procedures, personnel controls, and the final authorization package.
The control implementation can fail in the spaces between those groups.
A platform capability does not automatically satisfy every control for every application. An application can inherit protection from a common control, but someone still needs to confirm the scope of that inheritance, verify that the application uses the service correctly, and document any remaining responsibility. NIST defines control inheritance as receiving protection from controls that another entity implements, assesses, authorizes, and monitors. That definition makes ownership and accountability essential, not optional. See the NIST control inheritance glossary.
Teams need more than a control mapping. They need a responsibility model that names the control owner, the implementation owner, the evidence source, the assessor, the monitoring cadence, and the person responsible for correcting a failure. Hybrid controls deserve particular attention because responsibility is shared by design.
Without that clarity, the same control may be claimed twice, assumed by everyone, or owned by no one.
3. Evidence exists but is not mapped to the decisions an Authorizing Official must make
Security tools can produce an enormous amount of evidence. Scanners generate findings. Pipelines record test results. Registries track images. Software bills of materials list components. Policy engines record decisions. Monitoring systems collect logs and alerts.
More evidence does not necessarily create more confidence.
An Authorizing Official needs to understand what the evidence says about mission risk. That means connecting each artifact to the relevant control, system component, assessment result, threat, and remediation decision. The evidence also needs context. When was it collected? Which version of the system did it describe? Has the system changed since then? Who reviewed the result? What residual risk remains?
NIST SP 800 37 emphasizes responsibility for controls, ongoing assessment, continuous monitoring, and risk management throughout the system life cycle. Those practices turn evidence into information that can support an authorization decision. See NIST SP 800 37 Revision 2.
The goal should not be an evidence warehouse. It should be a living, traceable body of evidence that helps the Authorizing Official answer four questions: what changed, what risk changed with it, what was done about that risk, and who is accountable for what remains.
4. The Authorizing Official and assessor are engaged too late
Some teams build the system, assemble the package, and then ask the Authorizing Official and assessor to review the result. At that point, disagreements about the boundary, evidence quality, control implementation, or acceptable risk can force substantial rework.
Early engagement changes the relationship from final inspection to continuous risk alignment.
The program, application team, platform team, assessor, mission owner, and Authorizing Official should agree early on the authorization strategy. They should identify the risk tolerance, evidence expectations, review cadence, escalation triggers, and conditions that would prevent a release. The Department of War cATO Implementation Guide calls for a cybersecurity risk governance group that brings these perspectives together and establishes guardrails based on risk tolerance.
Start by mapping the real decision chain and the authority delegated at each level. In some Navy organizations, a decision may move from the system team to the system owner and Information System Security Manager, then through the program office, a functional Authorizing Official, and the Naval Authorizing Official. Other organizations use different titles, but the risk is the same. Delegation can speed routine decisions while creating ambiguity when a change falls outside delegated criteria. The senior approver may see only exceptional changes and may have the least context about how the system evolved.
Make that chain explicit. Define what each level may approve, which conditions require escalation, what evidence must travel with an escalation, how quickly a decision is expected, and where the decision is recorded. Schedule recurring risk reviews with the Authorizing Official or a delegated representative and the assessor so context is built before an unusual or high impact change requires a decision.
This does not mean the Authorizing Official approves every deployment. It means the delivery process reflects the conditions under which the Authorizing Official is prepared to accept risk. When those conditions are understood before implementation, teams can build the right controls and evidence into the system from the beginning. UDS can help keep technical evidence and system state current, but the program still has to define the decision chain, delegation rules, and review cadence.
5. Teams pursue continuous authorization before establishing a mature initial ATO and Monitor stage
Continuous authorization is sometimes treated as a shortcut around the initial authorization process. It is not.
The Department of War cATO Implementation Guide states that systems seeking continuous authorization must already have achieved an ATO and entered the Monitor stage of the Risk Management Framework. It also identifies three required competencies: continuous monitoring of controls, active cyber defense, and an approved DevSecOps reference design.
Those requirements describe an operational maturity state. A team needs a known baseline, functioning controls, reliable evidence, established monitoring, trained personnel, and repeatable risk governance. If the initial authorization package is incomplete or the Monitor stage is immature, continuous authorization has nothing stable to build on.
For a deeper look at what that operating model requires, read Continuous Authorization Requires More Than a Pipeline.
Before pursuing cATO, a program should be able to demonstrate that it understands its current risk posture, detects meaningful changes, responds to control failures, manages the software supply chain, and escalates risk when conditions exceed approved tolerances. Automation supports each of these capabilities, but automation cannot create the organizational maturity behind them.
6. Vulnerability exceptions and remediation plans lack clear owners and deadlines
Not every vulnerability can be corrected immediately. Mission needs, operational constraints, vendor dependencies, and technical complexity may require a temporary exception or a longer remediation plan.
The problem begins when a finding is accepted into a backlog without a named owner, a milestone, a compensating control, an expiration condition, or a clear risk decision. The exception then becomes permanent through inattention.
A useful Plan of Action and Milestones entry should identify the action that must occur, the organization responsible for it, the resources required, the target date, the interim protection, and the authority responsible for accepting any remaining risk. Current FedRAMP guidance makes the ownership principle especially clear: the POA&M belongs to the agency when the action belongs to the agency. See Managing POA&Ms.
The same logic applies within a program. Platform findings should not disappear into an application backlog. Application findings should not be assigned vaguely to security. Every exception needs an accountable owner and a date when the decision will be corrected, renewed, or escalated.
7. Pipeline automation is mistaken for active cyber defense
A secure delivery pipeline is essential, but it is not the same as active cyber defense.
Pipeline controls can scan source code, inspect dependencies, validate configurations, enforce policy, sign artifacts, and block known problems before deployment. These are powerful preventive and detective measures. They improve consistency and reduce avoidable risk.
Active cyber defense continues after deployment. It requires teams to observe the operating environment, identify suspicious behavior, use current threat intelligence, investigate incidents, support forensic analysis, test defenses, and respond when an adversary changes tactics. Department of War cATO guidance includes activities such as threat actor emulation, penetration testing, monitoring for unapproved behavior, and continuous reassessment of residual risk.
A green pipeline proves that a defined set of checks passed at a particular moment. It does not prove that the system is currently free from compromise, that a control remains effective in production, or that the team can contain an active threat.
Programs should connect pipeline evidence with operational telemetry, incident response, defensive operations, and governance. Continuous authorization depends on the whole feedback loop, not only the path from code commit to deployment.
8. Teams assume authorization automatically transfers across environments
Reusable infrastructure and portable software can make teams believe that an authorization decision is portable too. It is not that simple.
Evidence can be reused. Assessed common controls can be inherited. A hardened package can arrive with software supply chain information, test results, signatures, configuration, and known vulnerability data. These capabilities can significantly reduce duplicated work.
The receiving Authorizing Official still has to consider the actual use of the system. The mission, data, hosting environment, integrations, users, operational procedures, inherited controls, and local threat conditions can change the risk decision. FedRAMP makes the distinction clearly: reusable certification evidence supports the agency process, but each agency remains responsible for authorizing its own system and accepting risk for its specific use and configuration. See Using a Certified Cloud Service.
Portable evidence is not portable risk acceptance.
Programs should define a repeatable assessment for each destination environment. That assessment should identify what remains unchanged, what can be inherited, what differs, which controls need new evidence, and who has authority to accept the resulting risk.
What a healthier authorization effort looks like
The most effective programs use automation within a clear governance model. They establish a stable system boundary, assign control responsibility, and agree on risk tolerance before attempting to accelerate releases. They give the Authorizing Official and assessor evidence that is current, traceable, and connected to decisions. They manage exceptions as accountable work. They combine pipeline assurance with active defense in the operating environment. They reuse technical evidence without pretending that one risk decision applies everywhere.
This creates a practical division of labor.
Automation should collect evidence, enforce policy, test configurations, identify drift, track vulnerabilities, and make changes visible.
Program leadership should define the mission context, establish the authorization boundary, assign responsibility, fund remediation, set risk tolerance, and ensure the right people are involved.
The Authorizing Official should make the final risk decision using evidence that reflects the system as it actually operates.
Where UDS Enterprise helps, and where it cannot decide
UDS Enterprise helps teams turn technical security activity into evidence that is easier to review and govern. Its Compliance Assessment Tool brings together vulnerability assessments, compliance scans, software bills of materials, and supply chain attestations. It evaluates each build against security policies defined by the organization, giving security teams a structured way to review findings, document adjudications, and preserve an auditable record of authorization decisions.
Other UDS capabilities strengthen that evidence. ATO Compliance Artifacts provide control responses, architecture information, system inventories, information flows, and vulnerability results. UDS Registry provides package history, vulnerability visibility, access control, and rollback. Infrastructure as Code Modules make infrastructure configuration versioned and repeatable. UDS Core and Unicorn Images give applications a more consistent runtime and software supply chain baseline.
Together, these capabilities reduce manual work, expose change earlier, and make technical risk easier to understand. They can help a team show what changed, which policy applies, what finding remains, and how that finding was adjudicated.
They cannot establish the authorization boundary, assign control ownership, define acceptable risk, or replace the Authorizing Official. Exact control coverage and evidence sufficiency still depend on the impact level, architecture, mission data, integrations, operating environment, and intended use.
UDS Proving Ground applies the same distinction to commercial software. A vendor can package and validate its software, generate traceable evidence, and demonstrate the capability in a representative environment. That evidence can support a future assessment, but the receiving program still has to evaluate its mission use, data, integrations, inherited controls, and operating environment before authorization.
The goal is not to automate judgment. It is to give the people responsible for judgment better evidence, earlier feedback, and fewer preventable surprises.
Find the real source of delay
Before adding another tool, identify where the authorization effort is actually breaking. Is the boundary moving? Is ownership unclear? Is evidence disconnected from risk? Is operational monitoring immature? Are exceptions unmanaged? Is the receiving environment materially different?
Once the problem is visible, teams can separate the work that should be automated from the decisions that require leadership, security governance, and Authorizing Official alignment.
Talk to Defense Unicorns about building a more secure and repeatable path to authorization.
