The sentence that starts this
It usually arrives the same way. A program office likes the product, a pilot goes well, and then someone from the security side joins the call and says the system will need an ATO before it can hold real data. Sometimes the word is "authorization," sometimes "the RMF package," sometimes an impact level — IL5 — dropped into an email with no explanation. A commercial team hears a compliance chore belonging to a different department, and that reading is the expensive one. An authorization is not paperwork wrapped around a finished product. It is a set of constraints on the product's architecture, and every month spent treating it as documentation is a month of building things you will take back out.
This is written for the team on the other side of that call: a real product, real customers, and no prior contact with federal security requirements. It covers what an authorization is, who signs it, why almost nobody gets one from scratch, the design decisions that are cheap now and painful later, and what changes about a roadmap. Pricing federal work and getting on a contract vehicle are later problems.
An ATO is a signature, not a certificate
An Authorization to Operate is a decision by a federal official — the Authorizing Official, or AO — to accept the residual risk of running a particular system with particular data. NIST Special Publication 800-37 Revision 2, which defines the Risk Management Framework the federal government uses, is explicit that this acceptance of risk is the AO's responsibility and cannot be delegated. The AO is a senior person inside the agency. They are not a lab, not an auditor, and not for hire.
Three consequences follow, and all three surprise commercial teams. Your company cannot obtain an ATO: no application, no fee, no vendor who can sell you one. An ATO attaches to a system operated by a federal organization inside a defined boundary, not to software that travels between customers. And because the AO accepts risk on behalf of a mission, the decision is not purely technical — a system with known gaps can be authorized if the need is strong and the gaps are documented, while a technically excellent one can be refused because nobody could explain what it talks to.
The backdrop is statutory. FISMA requires agencies to secure the systems supporting their operations, and OMB Circular A-130 requires them to authorize a system before it operates and keep that authorization current rather than treating it as a one-time event. Your customer is not being difficult; they are executing a rule they cannot skip.
What is being authorized is the system, not your software
The most useful reframe: the AO is not evaluating your product. They are evaluating a system that happens to contain your product. That system's boundary — what is inside, what is outside, what crosses the line — is drawn before controls are chosen, and your component lands somewhere on that diagram.
The sequence that follows is mechanical. The system is categorized under FIPS 199 by the impact of losing confidentiality, integrity, or availability, and that rating selects a control baseline from NIST SP 800-53 Revision 5. The baseline is tailored — controls inherited from a provider, controls scoped out with written rationale, overlays added for privacy or controlled unclassified information. What remains needs an implementation narrative, a defined value wherever the control asks for one, and evidence that it is operating.
That is why the questions arrive in a shape that feels strange. Nobody asks whether your inference is fast. They ask where model weights are stored, what the service authenticates against, whether it makes outbound calls, what it writes to a log, and who can read that log. Each is really asking: does this component reduce or increase the number of things the government has to explain?
What each label actually authorizes
Labels get used loosely here, and the looseness costs money. What the common ones mean, and more usefully what they do not:
| Label | Who grants it | What it does not cover |
|---|---|---|
| FedRAMP authorization | A federal agency, under the government-wide program GSA runs. FedRAMP was codified by the FedRAMP Authorization Act in the FY2023 National Defense Authorization Act. | A specific cloud service offering with a specific boundary. It does not authorize an application a customer builds on top of that offering. |
| DISA provisional authorization | DISA, against the DoD Cloud Computing Security Requirements Guide, at an impact level. | The mission owner's system. A provisional authorization is a reusable assessment of the cloud service; the mission owner's AO still issues the ATO for what runs on it. |
| Agency ATO | That agency's Authorizing Official. | Other agencies. Reciprocity is encouraged and real reuse happens, but a second AO accepts risk on their own terms and may ask for more. |
| Continuous ATO (cATO) | The AO, where the program can demonstrate the required competencies. | The obligation to keep demonstrating them. The DoD CIO memorandum on continuous authorization, issued February 2022, names ongoing visibility into RMF control health, active cyber defense, and use of an approved DevSecOps reference design. |
| "Our product is FedRAMP / IL5" | Nobody. It is not a grantable status for a component. | Everything. Software does not carry an authorization between environments. Ask which offering was authorized, by whom, at what boundary, and on what date. |
Inheritance is the usual route, and it is partial
Almost nobody authorizes a federal system from bare metal. The normal path is to deploy inside an environment that already carries an authorization and inherit what it provides — physical security, hypervisor and network controls, much of the infrastructure layer. That is a real reduction in work, and it is why platform choice is an early architectural decision rather than a procurement detail.
It is also partial in a way that is easy to misread. Inherited infrastructure controls do not authorize your application, your data flows, your identity model, or your logging. Ask your platform or cloud provider for the customer responsibility matrix — the control-by-control statement of what the provider satisfies, what is shared, and what is left entirely to you. That document is the actual scope of your remaining work. The narratives, parameter values and system-generated evidence filling the customer side of it are the substance of ATO engineering, written with the engineers who built the control rather than assembled afterward from a template.
We will not tell you a component arrives pre-accredited, because nothing does. When we hand over a piece of a system, the honest deliverable is a list: which controls it satisfies, which it inherits and from where, which it leaves to you, and what evidence it emits. Less satisfying than a one-word claim, and the version that survives an assessor.
The impact level tells you where you are going to live
On the defense side, the DoD Cloud Computing Security Requirements Guide sorts data into impact levels: IL2 for public and non-critical information, IL4 for controlled unclassified information, IL5 for higher-sensitivity CUI and unclassified national security systems, and IL6 for classified information up to Secret, which lives on classified transport. The level is set by the mission owner based on the data, not negotiated by the vendor.
For a commercial product this is the number that determines your delivery model. At IL2 a normal multi-tenant service can often work. From IL4 upward, where infrastructure physically sits and how privileged administrators are screened are answered by the SRG rather than by your preferences, and a service existing only in your own commercial tenant stops being an option. At IL6 the assumption of any outbound connection to your systems disappears. If your product exists only as a SaaS you operate, an IL5 or IL6 requirement is not a configuration change; it is a different product shape. Companion pieces: what IL4, IL5 and IL6 change for a workload and how FedRAMP and impact levels relate.
Five decisions that get expensive if you make them wrong early
Each of these is cheap to decide at the beginning and structural to change afterward. None of them requires federal experience to get right — only knowing in advance that the question is coming.
Identity, and who owns the login. Your product will not own authentication. OMB Memorandum M-22-09, the federal zero trust strategy issued in January 2022, requires agencies to use phishing-resistant multi-factor authentication and names PIV credentials and FIDO2/WebAuthn as the acceptable mechanisms. In practice your application federates to the customer's identity provider over SAML or OIDC and maps their groups to your roles. A product with its own user table, password reset flow and SMS second factor on the critical path is carrying an unscheduled rewrite.
Cryptography, and where it comes from. "We use AES-256" is not an answer. Federal systems require cryptography from a module validated under the NIST Cryptographic Module Validation Program, which constrains your TLS stack, your at-rest encryption and sometimes your language runtime. This one is time-sensitive: every remaining FIPS 140-2 validation certificate moves to the CMVP historical list on September 21, 2026. CMVP's guidance is that agencies should not include historical modules in new systems, though they may still be procured for legacy ones — so a validation that is fine for a customer's existing deployment may not carry the new one you are being added to. If nobody can name the validated module underneath your crypto, find out first.
Audit output, treated as a product surface. Federal operators need your security-relevant events in their own tooling, with synchronized timestamps and enough structure to answer an investigator's question. OMB M-21-31 set the earlier expectations; OMB issued M-26-14 on May 22, 2026, rescinding M-21-31 in full and replacing its flat retention tiers with an outcome-based model — logs actively searchable for at least six months, and retrievable for at least one year. Read the current memorandum rather than any summary, including this one. The design consequence holds either way: emit structured events on a documented schema, let the customer ship them somewhere you do not control, and never let your own dashboard be the only place the record exists.
Where the software actually runs. The most consequential decision here. A product that only runs in the vendor's cloud is limited to customers whose data may go there. One delivered as an artifact and stood up inside an environment the customer controls — no outbound calls, no hosted endpoint on the critical path, no telemetry leaving the boundary — is eligible for far more missions. It is harder to build, mostly because of dependency handling with no package index and the discipline of never assuming a network. We wrote separately about shipping a component into a sandbox you cannot see, because it is the shape most first federal requirements end up needing.
Configuration and hardening. Your software will land on images built to DISA Security Technical Implementation Guides, which are far more opinionated than a default cloud image. Anything requiring root, its own kernel modules, hardcoded ports, writes outside its own directories, or dependency pulls at runtime will collide with that. Testing early against a hardened base image is cheap; discovering it during an assessment is not. See STIG compliance for containers and SBOM expectations.
What actually changes about the roadmap
Four things, in rough order of how much they annoy engineering teams.
You stop controlling your own patch calendar. Federal continuous monitoring sets maximum remediation windows for known vulnerabilities, enforced against the operator rather than your release schedule. FedRAMP's long-standing guidance set outer bounds of thirty days for high findings, ninety for moderate and one hundred eighty for low; the program's 2026 rules replace that flat mapping with a schedule weighing exploitability and network reachability. Check the current documentation for the version that applies to you. Either way, dependency updates become scheduled obligations rather than housekeeping.
Architecture changes get reviewed before they ship. A material change to the boundary, the data flows or the underlying services triggers review with the AO's staff, and refactors that would be routine commercially acquire lead times.
You will support versions longer than you want to. Federal customers upgrade on their own change-control cadence. Plan for a release living in production well past the point commercial customers have moved on.
How the software was built becomes a contract question, and the rule here just moved. OMB memoranda M-22-18 and M-23-16 required agencies to collect a self-attestation — signed by a company executive — that software was developed in conformance with the NIST Secure Software Development Framework, SP 800-218, on a common form CISA published. OMB rescinded both memoranda and the common-form mandate in M-26-05, issued January 23, 2026, replacing the government-wide requirement with a risk-based approach each agency tailors to its own circumstances. Agencies remain free to ask for a self-attestation or an SBOM; what changed is that the ask is now an individual agency's to make rather than government-wide. Ask your customer which they require rather than assuming either. The underlying exposure did not leave with the form: build integrity, provenance and dependency management get examined, and the answers run to your engineering practice rather than to a documentation team.
The sequence, and who owns each step
Where we fit, and where we do not
Precision Federal is an Iowa limited liability company — a small engineering firm with a few members, building production AI, machine learning, data and cloud systems that have to survive somebody else's review. On this problem we build the system, implement the controls, write control narratives with the engineers who wrote the code, trace organization-defined parameters to real values, and assemble the evidence package the Authorizing Official reads.
What we do not do is worth stating plainly, because a firm offering these is either misreading a rule or hoping you will not check it. We do not issue or grant ATOs — that signature belongs to a federal official and, under NIST SP 800-37 Rev. 2, cannot be delegated. We are not a C3PAO and cannot certify you for CMMC; under 32 CFR part 170 those certification assessments belong to third-party assessment organizations authorized through the Accreditation Body. We do not perform your independent assessment and then remediate our own findings; an assessment is worth only the independence behind it. We hold no facility clearance today and do not perform classified work on classified networks — under the NISPOM at 32 CFR part 117 a facility clearance is sponsored against a real requirement, not obtained on a company's own initiative. We are not a training vendor, and we do not write proposals for other firms. Full scope statement: what we build and what we decline.
What to bring to the next call with your federal customer
These six say more about the size of the job than any assessment of your own product will.
- Who is the Authorizing Official, and has anyone spoken to their staff yet?
- What system does our product become part of, and where is its boundary drawn today?
- What is the categorization or impact level, and what data drove it?
- Which authorized platform or environment is this expected to run inside?
- Can we see the customer responsibility matrix for that environment?
- Is there an existing authorization we are being added to, or is this a new one?
Common objections, answered
Our product is already SOC 2 Type II. Doesn't that count?
It helps and it does not substitute. A SOC 2 report is an attestation about your organization's controls against criteria you and your auditor scoped. A federal authorization is a government official accepting risk for a specific system against a specific NIST SP 800-53 baseline, with evidence assessed independently. Much of the underlying engineering carries over — access control, change management, monitoring — but the control mapping, the parameter values, and the evidence format all have to be redone in the federal shape.
Can we just get authorized once and sell to every agency?
Partly. A FedRAMP authorization for a cloud service offering is designed for reuse, which is the point of the program. But reuse is a receiving Authorizing Official's decision, and they accept risk on their own terms. Plan for reuse to shorten the conversation, not to remove it.
How long does this take?
Anyone who answers that without seeing your boundary is guessing. The honest version: the clock is driven far more by whether an AO and a sponsoring program are identified, whether you are inheriting from an authorized platform, and how long the assessment queue is, than by how fast your engineers work. The one lever you fully control is arriving with controls implemented and evidence the system generates on its own, rather than narratives written after the fact.
Can we defer all of this until after the contract is signed?
You can defer the documentation. You cannot defer the architecture. Identity federation, validated cryptography, exportable audit output and the ability to run inside somebody else's environment are structural. Retrofitting them means reopening decisions the rest of the product is built on, which is why deferring them tends to cost more than the documentation ever did.
How a first conversation goes
There is no retainer to talk. A first exchange is scoping: what the system is, where the data sits, who signs the risk, what is already fixed. If the work belongs somewhere else — an assessor, a platform provider, a firm with a clearance we do not have — we say so in the first reply and point at who is better positioned. Where it fits, the first piece of work is a bounded assessment against the real architecture, ending in a written recommendation you keep whether or not we do the build.
Frequently asked questions
It is a federal Authorizing Official's formal decision to accept the residual risk of operating a specific information system with specific data. NIST SP 800-37 Rev. 2 defines the role and states that the acceptance of risk cannot be delegated. Without it, the system does not process federal data in production.
No. An ATO belongs to a system operated by a federal organization, within a defined boundary. A cloud service offering can hold a FedRAMP authorization, and DISA issues provisional authorizations for cloud service offerings under the DoD Cloud Computing SRG — but a component that ships to customers is authorized as part of each system it joins, not on its own.
No. You inherit infrastructure controls with a documented reference to the provider's authorization, which is a real reduction in scope. Your application, data flows, identity model and logging still require their own implementation, evidence and risk decision. Ask the provider for its customer responsibility matrix to see the exact split.
Federate authentication to the customer's identity provider rather than owning the login; source cryptography from a validated module rather than naming an algorithm; emit structured audit events the customer can export to their own tooling; and make the product installable into an environment you do not operate. Those four decisions are cheap early and structural later.
It changes where the software can run and who can operate it. The DoD Cloud Computing SRG sets requirements at each level for the environment handling the data, including where infrastructure sits and how privileged administrators are screened. From IL4 upward, a service that exists only in a vendor-operated commercial tenant generally stops being viable, and a deployable artifact becomes the practical delivery model.