Category: Authorization & Accreditation

Authority to Use

Also known as: ATU, Authorization to Use

Simply put

An Authority to Use (ATU) is a formal decision by an agency official to allow that agency to use an information system, service, or application that has already been authorized by another party. Rather than performing a full authorization from scratch, the agency reviews and formally accepts an existing authorization so it can use the offering. This concept is commonly applied to cloud services, such as those handled through FedRAMP.

Formal definition

An Authority to Use (ATU) is an official management decision issued by an authorizing official to authorize the use of an information system, service, or application, as reflected in the NIST CSRC glossary definition of authorization to use. In practice, particularly within the FedRAMP context, an ATU functions as an agency-internal decision to formally accept and reuse an existing authorization for a cloud service offering rather than issuing an independent Authority to Operate (ATO). An ATU is distinct from an ATO: an ATO generally represents an authorizing official's own risk-based determination based on a review of a system's security posture, whereas an ATU generally leverages a prior authorization that the accepting agency reviews and accepts. Both are risk-based management decisions and, as authorizations, should not be treated as permanent; they remain subject to the terms of the underlying authorization and applicable continuous monitoring requirements. This entry does not address FedRAMP program mechanics, DoD-specific requirements, or the specific review obligations an agency must meet, which readers should confirm against current authoritative sources.

Why it matters

The Authority to Use (ATU) matters because it addresses one of the most persistent challenges in federal authorization work: avoiding duplicative, resource-intensive reviews of systems that another party has already authorized. When an agency can review and formally accept an existing authorization rather than issuing its own Authority to Operate (ATO) from scratch, it can adopt cloud services more efficiently. This is especially relevant in the FedRAMP context, where a cloud service offering may already carry an authorization that multiple agencies can leverage. Understanding the ATU concept helps authorizing officials, ISSMs, and compliance staff correctly frame what decision they are actually making and what responsibilities they retain.

A common and consequential mistake is treating an ATU as though it eliminates an agency's own risk responsibility. An ATU is still a risk-based management decision: the accepting agency reviews and formally accepts an existing authorization, and that acceptance carries obligations. FedRAMP guidance indicates that each agency issuing an ATO or ATU for a cloud offering has review responsibilities tied to the cloud service, so an ATU should not be understood as a rubber stamp that transfers all accountability elsewhere. Officials should also avoid conflating an ATU with an ATO, an ATO generally reflects the authorizing official's own determination based on a review of the system's security posture, while an ATU generally leverages a prior authorization that the accepting agency reviews and accepts.

Equally important, an ATU should not be treated as permanent. Like an ATO, it is a time-bound, risk-based decision that remains subject to the terms of the underlying authorization and to applicable continuous monitoring requirements. If the underlying authorization changes or lapses, the basis for the ATU can be affected. Officials who assume an ATU stands indefinitely, independent of the authorization it relies upon, risk operating on an outdated understanding of a system's risk posture.

Who it's relevant to

Authorizing Officials

Authorizing officials are the parties who issue an ATU as an official management decision. They should understand that accepting an existing authorization is still a risk-based determination and that an ATU, like an ATO, is not permanent and remains subject to the underlying authorization and applicable continuous monitoring requirements. They should confirm their specific review obligations against current authoritative sources.

Information System Security Managers and Compliance Officers

ISSMs and compliance staff supporting cloud adoption need to distinguish an ATU from an ATO and track what the ATU depends on. Because an ATU leverages a prior authorization that the agency reviews and accepts, these practitioners should monitor the status of the underlying authorization and ensure continuous monitoring expectations are met rather than assuming acceptance is a one-time, static event.

Government Contractors and Cloud Service Providers

Providers whose cloud service offerings may be adopted by multiple agencies through an ATU should recognize that each accepting agency makes its own management decision to reuse an existing authorization. The specific FedRAMP mechanics and any DoD-specific requirements are out of scope for this entry and should be verified against current authoritative sources.

Auditors and Assessors

Auditors reviewing agency authorization decisions should verify whether a system operates under an ATO or an ATU, since the two rest on different bases, an independent determination versus acceptance of a prior authorization. They should also confirm that the ATU is treated as time-bound and tied to the underlying authorization, and should not equate the existence of an ATU with a guarantee of security.

Inside ATU

Leveraged Authorization Basis

An ATU generally relies on an existing authorization decision made by another organization for a cloud service or system, allowing a subsequent agency to accept and use that system without issuing its own independent Authority to Operate (ATO). The reader should verify the specific reuse mechanism against current FedRAMP PMO or agency guidance.

Risk Acceptance by the Using Organization

The organization issuing an ATU typically accepts the residual risk documented in the underlying authorization package as-is, rather than conducting a full independent assessment. This acceptance is a formal decision that should be documented by the responsible authorizing official.

Reliance on Existing Security Documentation

An ATU generally depends on the security artifacts produced for the original authorization, such as the security assessment results and continuous monitoring outputs, which the using organization reviews rather than regenerates.

Scope and Boundary Considerations

An ATU applies to the specific system boundary and impact level covered by the leveraged authorization. Whether that scope satisfies a particular agency's needs, including any CUI, DoD, or national security system requirements, must be confirmed against the applicable authoritative sources.

Common questions

Answers to the questions practitioners most commonly ask about ATU.

Is an Authority to Use (ATU) the same as an Authority to Operate (ATO)?

No. An ATU and an ATO are distinct authorization decisions, and treating them as interchangeable is a common mistake. An ATO is generally issued by an authorizing official who accepts risk based on a system's own security assessment and authorization package. An ATU, by contrast, generally allows an organization to leverage a cloud service or system that has already been authorized by another entity, relying on that existing authorization rather than performing a full independent authorization. Readers should confirm the specific meaning and requirements against current authoritative guidance, because usage and terminology can vary by agency and program.

Does obtaining an ATU mean the authorization is permanent and no further oversight is needed?

No. Like other authorization decisions, an ATU is not permanent. Authorization decisions are generally time-bound and subject to continuous monitoring, and the underlying authorization being leveraged may itself be reassessed, updated, or revoked. Relying on an ATU does not relieve an organization of its continuous monitoring responsibilities for the portion of the system within its scope. Confirm the applicable monitoring and reauthorization obligations against current official sources.

When would an organization pursue an ATU instead of issuing its own ATO?

An ATU is generally considered when an organization intends to use a service or system whose security has already been authorized by another party, allowing it to rely on that existing authorization rather than repeating a full independent assessment and authorization effort. The suitability of this approach depends on the specific program, the environment, and the authorizing official's risk determination. Confirm eligibility and the applicable process against current authoritative guidance before proceeding.

What responsibilities remain with an organization that leverages an ATU?

Leveraging an ATU generally does not transfer away all security responsibility. The organization typically remains accountable for the parts of the system within its own scope, for understanding any shared responsibility boundaries, and for continuous monitoring of its portion of the environment. It should also track the status of the underlying authorization being relied upon. Verify the precise allocation of responsibilities against current official documentation and any applicable agreements.

How should an organization document reliance on an ATU?

In most implementations, an organization documents which existing authorization it is relying upon, the scope and boundary of what the ATU covers, the shared responsibility allocation, and the continuous monitoring arrangements for its portion of the system. Because documentation expectations vary by agency and program and may change across revisions, confirm the specific artifacts and format required against current authoritative sources.

Does an ATU replace the need to confirm requirements against the governing authority?

No. An ATU does not substitute for verifying obligations against the applicable governing publications, regulations, and agency-specific guidance. Terminology, scope, and process for ATUs can vary and may evolve across revisions, and this entry does not cover implementation, contractual, or legal specifics. Readers should confirm the current authoritative text and any agency-specific interpretation before relying on an ATU.

Common misconceptions

An ATU is the same as an ATO.

They are distinct. An ATO reflects an organization's own authorization decision following its assessment, while an ATU generally reflects a decision to use and accept a system already authorized by another organization. Practitioners should confirm the precise distinction and requirements against current FedRAMP PMO and agency guidance.

Issuing or relying on an ATU eliminates the using organization's responsibility for risk.

An ATU generally involves accepting the residual risk documented in the leveraged authorization; it does not remove accountability. The using organization's authorizing official remains responsible for the risk acceptance decision, and continuous monitoring of the underlying authorization still applies.

An ATU based on a civilian or FedRAMP authorization automatically satisfies DoD or national security system requirements.

Reuse of an existing authorization does not automatically meet the requirements of a different scope, such as DoD systems under the RMF or systems handling CUI. Additional or different requirements may apply and should be verified against the governing authoritative text.

Best practices

Document the authorizing official's formal risk acceptance decision when issuing or relying on an ATU, rather than treating reuse as an automatic or implied acceptance.

Review the leveraged authorization's scope, system boundary, and impact level to confirm it aligns with your organization's use case before relying on an ATU.

Continue monitoring the continuous monitoring outputs of the underlying authorization, since the leveraged authorization remains time-bound and subject to ongoing conditions.

Verify that a leveraged civilian or FedRAMP authorization actually covers your applicable requirements before assuming it satisfies DoD, CUI, or national security system obligations.

Confirm the specific ATU reuse mechanism, terminology, and required artifacts against current FedRAMP PMO and agency guidance, as these may evolve across revisions.

Maintain clear records distinguishing the underlying authorization decision from your organization's decision to use the system, to avoid conflating assessment, authorization, and use.