RMFInsider

Assess Only vs full ATO is a question that comes up constantly once a system touches AI, cloud-hosted services, or shared infrastructure — because the two constructs answer different questions and route through different processes in eMASS. Confusing them is one of the fastest ways to stall a package, because the AO can’t authorize something that was never built to be authorized in the first place.

Here’s the distinction in practitioner terms, when each applies, and why the newest driver of this question — DoD AI systems — makes getting it right more important than ever.

The Core Difference

A full ATO (Authorization to Operate) is a risk decision made by an AO for an entire system operating in a specific environment. It covers the system’s full boundary — the infrastructure, the software, the data flows, the people and processes around it — and it results in the AO formally accepting risk to let that system operate.

Assess Only is different. It’s a security assessment of a component — often a piece of software, a model, or a capability — that does not, by itself, operate as a standalone system. The component gets assessed against applicable controls, but no AO issues an operational authorization for it, because it isn’t standing up its own operating environment. Instead, the assessment results become part of the body of evidence for whatever system eventually hosts or integrates that component.

	Full ATO	Assess Only
What’s being evaluated	A complete system within a defined boundary	A component, capability, or model — not a standalone operating system
Who issues a decision	An AO issues a formal authorization	No operational authorization is issued; results feed into a hosting system’s ATO
What it enables	The system to operate in its environment	The component to be integrated into an authorized system
Typical use case	A network, application, or platform with its own boundary	Software components, reusable services, and AI models assessed independent of a specific deployment

Why This Distinction Exists

Not everything that needs a security assessment operates as its own system. A reusable component — think a shared library, a platform service, or an AI model — might get integrated into dozens of different systems, each with its own boundary, mission, and risk posture. Assessing it once under Assess Only and letting hosting systems inherit that assessment is far more efficient than re-assessing the same component from scratch every time it gets integrated somewhere new.

The tradeoff is that Assess Only doesn’t grant operational authority on its own. The component still needs to land inside a system that holds its own ATO — one where the AO has accepted risk for the complete environment, including how that assessed component is actually being used.

Decision Criteria: Which One Applies

Ask these questions when you’re trying to figure out which construct fits what you’re working on:

• Does this have its own defined system boundary, with infrastructure, users, and data flows that belong to it specifically? If yes, you’re likely looking at a full ATO.
• Is this a component that will be deployed inside other systems’ boundaries, potentially multiple times, in different contexts? That’s an Assess Only candidate.
• Will an AO be accepting risk for operating this thing directly, or will the risk acceptance happen one level up, at the hosting system? Direct risk acceptance means full ATO; inherited risk acceptance means Assess Only.
• Is the body of evidence going to stand alone, or does it need to be combined with a separate infrastructure assessment before anyone can authorize operational use? If it needs to be combined, you’re building toward Assess Only plus a hosting ATO, not a single full ATO.

Getting this wrong in either direction causes real delays. Trying to push a component through a full ATO process when it has no independent operating boundary leaves the AO with nothing coherent to authorize. Trying to treat a complete system as Assess Only leaves it with a body of evidence but no actual authorization to operate — which means it can’t go live no matter how clean the assessment looks.

A useful sanity check: if you can point to a specific user population, a specific network segment, and a specific set of data flows that belong exclusively to what you’re assessing, you’re almost certainly looking at a full ATO. If instead you’re describing something that gets dropped into other systems’ environments and inherits its operating context from wherever it lands, Assess Only is the right lane. When you genuinely can’t tell which one applies, that’s usually a sign the boundary hasn’t been scoped clearly enough yet — and that scoping conversation needs to happen before any control mapping starts, not after.

Where AI Systems Fit: The Assess Only Model Split

This is where the distinction has gotten sharper over the past year. DoD’s framework for AI systems explicitly separates the assessment of the AI model itself from the authorization of the infrastructure hosting it. Models route through the Assess Only construct under the DoD AI Cybersecurity Risk Management Tailoring Guide, while the hosting infrastructure — the servers, the network, the surrounding platform — receives its own standalone ATO through the traditional RMF or cATO path.

In practice, that means an AI model doesn’t get its own ATO. It gets assessed, and that assessment becomes part of a combined body of evidence that spans both the model’s performance characteristics and the infrastructure’s security controls. The AO authorizing the hosting system is the one making the actual risk decision, informed by both halves of that evidence.

This split matters for how you scope the work. If you’re standing up an AI capability, you’re not managing one package — you’re coordinating two parallel efforts that converge into a single authorization decision at the hosting system level. Missing that structure early is a common reason AI-related ATO efforts stall: someone tries to build a single unified package when the framework expects two distinct evidence streams.

For a full walkthrough of how that model-versus-infrastructure split works end to end, see how to get an ATO for an AI system in DoD — it goes deeper into the mechanics of coordinating the Assess Only model assessment against the hosting infrastructure’s separate authorization.

What This Looks Like in eMASS

Practically, this means your eMASS workflow branches depending on which construct you’re in. A full ATO package builds out a complete system record — boundary, controls, artifacts, test results, POA&Ms — all tied to one system record that an AO ultimately approves.

An Assess Only effort produces an assessment record for the component, but that record doesn’t stand alone as an operational authorization. It gets referenced by, or attached to, the hosting system’s package as supporting evidence. If you’re the ISSO on the hosting system side, you need to know whether the component you’re integrating already has a current Assess Only record you can inherit, or whether you’re commissioning a new assessment as part of your own package timeline.

This is the same logic behind traditional control inheritance in RMF — a hosting system doesn’t re-prove every control from scratch if a shared service already has current evidence. Assess Only extends that same inheritance model to components and AI models specifically. If you need a refresher on how the standard ATO build-out works before layering an Assess Only component into it, how to get an ATO step by step covers the full RMF process an ISSO manages for a complete system package.

Reauthorization Timing Differs Too

Full ATOs have their own reauthorization cycle tied to the hosting system’s authorization period, continuous monitoring status, and any significant changes to the system boundary. Assess Only records need their own currency tracking too — a component assessment doesn’t stay valid indefinitely, and a hosting system inheriting a stale Assess Only record is taking on the same kind of risk as inheriting any other outdated piece of evidence.

If you’re not already tracking what happens when a hosting system’s ATO comes up for renewal, ATO reauthorization: what changes when your ATO expires walks through that cycle — the same principle applies to keeping any inherited Assess Only evidence current within that cycle.

The Practical Takeaway

When you’re scoping a new effort, ask whether what you’re building has its own independent operating boundary or whether it’s a component destined for integration elsewhere. That single question determines whether you’re heading toward a full ATO package or an Assess Only assessment feeding into someone else’s package.

For AI specifically, expect the two-track pattern to be the norm going forward: the model gets assessed under Assess Only, the infrastructure gets its own ATO, and the AO’s authorization decision draws on both. Scoping your package around that structure from day one saves you from restructuring a combined effort into two tracks midstream — which is a far more expensive fix than planning for the split up front.

If you’re navigating an Assess Only versus full ATO decision on a live system and want a second set of eyes on how to scope it, that’s exactly the kind of question coaching is built for — working through your specific system boundary with someone who’s built these packages before beats guessing at the structure alone.