The sentence that starts this
Almost nobody goes looking for FedRAMP. FedRAMP arrives in an email. A federal agency — or a prime selling into one — tells a commercial software team that the product cannot be purchased until it is FedRAMP authorized, and a company that has spent years building something good suddenly owns a compliance program it has never run, on a schedule set by somebody else's procurement calendar. The first instinct is usually to treat it as a documentation exercise: hire a writer, produce a binder, receive a stamp. That instinct is what makes first attempts expensive.
FedRAMP is not a document review. It is an independent assessment of a running system against a published set of requirements, followed by a government decision to accept whatever risk is left over. The documents are an output of that process, not the substance of it. Most of the cost, and nearly all of the schedule risk, sits in the gap between how your system works today and how it will have to work to survive an assessment by someone who is paid to be skeptical.
There is a second complication for anyone reading up on this in 2026: the program changed materially in June, so much of the guidance circulating online describes a version of FedRAMP that is being retired. What follows is the current shape, with sources you can check.
What FedRAMP is, in law
FedRAMP began as policy, not statute. The Federal CIO issued a memorandum on December 8, 2011 establishing the program; Congress later codified it in the FedRAMP Authorization Act, enacted as part of Title LIX of the James M. Inhofe National Defense Authorization Act for Fiscal Year 2023 (Pub. L. 117-263). That Act established FedRAMP within the General Services Administration and created a FedRAMP Board to provide input and recommendations to the GSA Administrator. OMB then issued Memorandum M-24-15, Modernizing the Federal Risk and Authorization Management Program, on July 25, 2024, which rescinded the 2011 memorandum and replaced it with an updated vision, scope, and governance structure. The Joint Authorization Board that used to grant provisional authorizations on behalf of the whole government was retired in that transition, its governance role passing to the FedRAMP Board.
The economic reason the program exists is written into the statute. Under 44 U.S.C. § 3613, the assessment of security controls and materials in a FedRAMP authorization package is presumed adequate for an agency's own authorization, and agencies are directed to reuse those existing assessments to the extent practicable. That is the entire value proposition: assess once, let many agencies rely on it.
Presumed adequate, not automatically accepted
The statute presumes a FedRAMP assessment adequate for agency reuse, but expressly preserves "the authority of the head of any agency to make a determination that there is a demonstrable need for additional security requirements beyond the security requirements included in a FedRAMP authorization for a particular control implementation." Read plainly: FedRAMP gets you believed. It does not get you excused. An agency can still ask you for more.
The 2026 rules changed the shape of the problem
On June 25, 2026 FedRAMP published its Consolidated Rules for 2026, which replace the familiar Low / Moderate / High framing with Certification Classes A through D. FedRAMP's own explanation of the classes is worth quoting because it is the single most misread thing in the new model: the classes describe "the level of assurance information a cloud service provider supplies through FedRAMP for a cloud service offering" — the depth, frequency, and quality of the data an agency gets, not how secure the service is. Impact level is still a property of the agency's system. Class is a property of your commitment.
| Class | FedRAMP's stated adequacy | What it means for a first-timer |
|---|---|---|
| Class A | "Adequate for use in pilots, during configuration and testing, or for extremely low or negligible risk use cases such as processing public information or getting started with very few users." | The entry ramp. Lowest assurance commitment, fastest to reach. |
| Class B | "Adequate for use in most Low impact agency information systems and some Moderate or High impact agency information systems with appropriate compensating controls." | Roughly where the old Low baseline sat. |
| Class C | "Adequate for use in most Low or Moderate impact agency information systems and some High impact agency information systems with appropriate compensating controls." | The practical target when a customer will handle CUI or non-public federal data. |
| Class D | "Adequate for use in most agency information systems regardless of the impact level, especially when deployed with appropriate compensating controls." | Highest assurance commitment, highest ongoing cost. |
Class descriptions quoted from FedRAMP, FedRAMP Certification Classes, Consolidated Rules for 2026 (fedramp.gov/2026/agencies/use/classes/).
The transition dates matter if you are planning a budget. FedRAMP has published that the Class A pipeline opens August 3, 2026 and the Class B and Class C pipelines on August 31, 2026; that the new rules take effect for all stakeholders on January 1, 2027; and that no new applications under the legacy Rev5 rules will be accepted after June 11, 2027. Existing Rev5-certified systems are told to begin adopting the new rules immediately. Check fedramp.gov before you commit a plan to these — published program timelines are the kind of thing that moves.
The sponsor problem
For most of FedRAMP's history the hardest gate was not technical. It was finding a federal agency willing to sponsor you — to put its authorizing official's name on the risk decision, and to spend its own staff's hours reviewing your package. That produced a genuine circular trap for commercial companies: agencies would not sponsor a product they had not bought, and they could not buy a product that was not authorized. Companies with a strong existing federal customer got through it. Companies trying to enter the market frequently did not, no matter how good the software was.
The 2026 rules are explicitly aimed at that trap. FedRAMP's own guidance to providers now says that if you are new, "Class A is the simplest way to get FedRAMP Certified to obtain a customer" — that is, get listed at a low assurance class first and use the listing to win the customer who will justify a higher class later. The same guidance warns in the other direction: providers "generally should not go straight to FedRAMP Class C or Class D Certification unless they have an existing contract with a government agency that requires this level of commitment."
Do not over-read this as "the agency no longer matters." Agencies still authorize their own systems, and § 3613 still lets an agency head demand more. What changed is that you can get on the board before an agency commits rather than after. If you have a real sponsor, take the class they need. If you do not, enter low, get listed, and let a customer pull you up.
What an independent assessor does — and what it cannot do
The organization that performs your assessment used to be called a Third-Party Assessment Organization, or 3PAO. Under the 2026 rules FedRAMP calls them independent assessment services, and the rules are blunt about who counts: FedRAMP must not accept verification, validation, or other attestations from independent assessors that are not FedRAMP Recognized. Recognized assessors are listed in the FedRAMP Marketplace, and you pay them — the initial independent assessment is a provider expense, not a government service. FedRAMP itself can stand in for a Recognized service on the yearly ongoing verification, but not on the fresh initial assessment that Classes B through D require.
For Classes B through D, providers "MUST supply a fresh initial FedRAMP independent assessment that was completed by a FedRAMP Recognized independent assessment service within the previous 3 months." Independent verification is optional at Class A and required above it. That freshness window is a real scheduling constraint: an assessment that goes stale while you are still fixing findings is one you may have to buy again.
Here is what an assessor cannot do, and this is where first-timers lose months. An assessor cannot authorize you — that decision belongs to the government. An assessor cannot design your controls, build your evidence pipeline, and then independently assess the thing it built; the independence is the product, and a firm that sells you both is selling you a conflict. An assessor cannot make an incomplete system complete: if logging is not centralized when they arrive, they will write that down, not fix it. And an assessor cannot inherit your accountability. FedRAMP's rules put it on you — providers "MUST maintain responsibility and accountability for the accuracy and completeness of all information in the FedRAMP Certification Package."
Scope is the decision that sets the price
Scope determines how much of your system gets assessed, and therefore what the assessment costs. FedRAMP's Minimum Assessment Scope rules require a provider to identify "all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering," and to "clearly identify, document, and explain information flows and security categories for ALL information resources or sets of information resources in the cloud service offering." Third-party dependencies do not fall outside that: the rules require you to address their potential impact on federal customer data through documented usage and configuration, a justification for use, and mitigating or compensating measures.
Two things follow. First, every convenience SaaS your engineers wired in — error tracker, analytics pixel, support chat widget, CI runner, feature-flag service, notification vendor, LLM API — is now a scope decision with a documentation cost attached. Each one either earns its place in the assessed scope or comes out of the architecture before the assessor arrives. Second, your scope is not the agency's authorization boundary. FedRAMP's guidance to agencies draws that line: the cloud service "may be one service within that boundary," and it "does not automatically become a separate agency information system." You scope your offering; the agency scopes its system around you.
- Which components can touch federal customer data, even transiently in a log line or an error payload?
- Which third-party services are load-bearing, and which are conveniences you can remove faster than you can document?
- Where does telemetry go, who can read it, and does any of it leave the assessed environment?
- Which of your own internal tools reach into production, and under whose identity?
- What do you inherit from the underlying cloud, and can you show the inheritance rather than assert it?
- Can a support engineer reach customer data from a laptop, and is that path in scope?
The engineering work that dominates the effort
The 2026 rules push hard toward evidence that a machine can read. FedRAMP 20x is built around Key Security Indicators — named, measurable security outcomes reported as structured data — and requires providers to identify a target certification profile and apply the relevant FedRAMP practices to the offering, with an ongoing report that reflects current posture rather than an annual snapshot. That is a different demand than "write a narrative describing your access control policy": the system has to emit proof of its own behavior, continuously, without a human assembling screenshots.
In practice the work concentrates in a few places, and none of them are writing. Identity, because federated authentication, phishing-resistant multi-factor, and automated account lifecycle are often absent in products that grew up on passwords and a manual offboarding checklist. Logging, because evidence you cannot query is evidence you do not have. Configuration management, because you must state what the baseline is and prove drift gets caught. Vulnerability management, because scan cadence and remediation timelines are commitments, not aspirations. Change management, because a system that changes faster than its documentation fails on accuracy alone. And the decisive one: an evidence pipeline that regenerates on every deploy, so the package is a byproduct of running the system rather than a project someone does twice a year.
The other large lever is inheritance. Building on a cloud foundation that already carries a federal authorization — AWS GovCloud, Azure Government, GCP Assured Workloads — lets a meaningful share of the underlying requirements be satisfied by the platform rather than by you, provided you can document the split honestly rather than gesture at it. That architectural decision, made early, changes the size of the remaining work more than any tooling choice will. This is the substance of our FedRAMP engineering practice: boundary and inventory work, control implementation in the infrastructure itself, machine-readable package generation, pre-assessment preparation, and continuous monitoring that regenerates evidence instead of re-collecting it.
What FedRAMP does not get you
FedRAMP is not FISMA, though they share a control vocabulary — FedRAMP governs cloud offerings sold to agencies, while FISMA governs the agency's own systems, and the two questions come up at different moments (we have written separately on which applies when). FedRAMP is also not a DoD impact level. Provisional authorizations at IL4, IL5, and IL6 are issued by DISA under the DoD Cloud Computing Security Requirements Guide, which builds on a FedRAMP baseline and layers DoD-specific requirements on top; if your customer said "IL5," a commercial FedRAMP certification is a prerequisite step, not the answer (the plain-language comparison is here). FedRAMP is not CMMC, which governs contractor handling of controlled unclassified information in your own environment. And FedRAMP is not a substitute for the agency's own risk decision, per § 3613.
One more, because vendors blur it constantly: no component you buy arrives pre-accredited. A FedRAMP-authorized dependency can carry real inheritance into your package, but the assembled system is yours and the assessment is of the assembly. Anyone claiming their library, model, or container "is FedRAMP certified" in a way that transfers to your product is describing something that does not exist.
Where we stop
Precision Federal builds authorization-ready systems. We are not a FedRAMP Recognized independent assessment service, and we do not want to be — we will not assess work we built, because independence is the entire point of an assessment and selling both sides of it is worth less to you than it looks. We do not issue ATOs; only a government authorizing official does that. We are not a C3PAO and cannot certify you for CMMC. We hold no facility clearance today and do not perform classified work on classified networks. We are not a training vendor, and we do not write proposals for other firms. We will not tell you a component arrives pre-accredited, because nothing does.
What we will do is the engineering: define the assessed scope and defend it, implement controls in infrastructure rather than in prose, build the evidence pipeline that makes the package a byproduct of operating the system, prepare you for the assessor's questions before the assessor asks them, and run continuous monitoring afterward. If your problem is a headless model or a bespoke small model that has to deploy into a customer-controlled environment rather than your own, that is a related but distinct architecture question — we have written about it here — and it interacts with scope in ways worth working through before you pick a class.
How an engagement starts
It starts with a scoping conversation, not a proposal. What is the offering, who is the customer pushing you, what class do they actually need, what is already built, and what does the data flow look like today. That is usually enough to tell whether the honest answer is "this is a substantial engineering program," "this is smaller than you think — start at Class A," or "you do not need FedRAMP at all; your customer needs something else and used the word FedRAMP because it is the word they know." We say the third one when it is true, and we are public about what we turn down.
Can we start before we have an agency customer?
Under the 2026 rules, yes — FedRAMP's provider guidance points new entrants at Class A specifically as a way to get certified in order to obtain a customer. Whether that is the right spend depends on how close your pipeline is. A listing with no buyer behind it is an expense; a listing that unblocks a named opportunity is an investment.
Our product is single-tenant and installs in the customer's own cloud. Does FedRAMP apply?
Frequently it does not, or not in the form you were told. If the software runs inside a boundary the agency already owns and authorizes, the agency's own authorization process governs it, and your obligation is to be documentable and assessable inside their boundary rather than separately certified. This is worth resolving before spending anything, because the two paths cost very different amounts.
How much of this can be automated?
Evidence generation, drift detection, inventory, and the machine-readable reporting the 2026 rules are built around — a great deal. Judgment calls about scope, inheritance, and how to describe a partially-implemented control honestly — very little. Tools that promise to generate a defensible package from a questionnaire are automating the wrong half.
What is the single most common reason a first attempt stalls?
Scope decided late. Teams write documentation against an architecture that has not been pinned down, discover during assessment that three vendor dependencies are in scope, and restart. Deciding scope first is unglamorous and saves more time than any other single choice.
Frequently asked questions
The sponsor requirement was the traditional bottleneck, and the Consolidated Rules for 2026 are designed to reduce it — FedRAMP's guidance describes Class A as a path to certification that helps a provider obtain a customer, rather than requiring one first. Agencies still make their own authorization decisions for their own systems, and under 44 U.S.C. § 3613 an agency head may still require more than FedRAMP did.
Certification Classes A through D, published in FedRAMP's Consolidated Rules for 2026. FedRAMP is explicit that a class describes the level of assurance information a provider commits to supplying, not the level of security a service provides — agencies still categorize their own systems by impact level and evaluate a provider's package against that.
It should not. FedRAMP only accepts assessments from FedRAMP Recognized independent assessment services, and independence is what the assessment is buying. A builder assessing its own work produces a document, not an assurance. Separate the two, on purpose.
No. DoD provisional authorizations at IL4 through IL6 are issued by DISA under the DoD Cloud Computing Security Requirements Guide, which builds on a FedRAMP baseline and adds DoD-specific requirements including personnel and connectivity conditions. FedRAMP is the foundation for that path, not a replacement for it.
Honest answer: it depends almost entirely on how far your current architecture sits from the requirements, and anyone quoting a duration before seeing your data flows is guessing. The assessment window itself is bounded — Classes B through D require an independent assessment completed within the previous three months — but the remediation work ahead of it is the variable, and it is the part that is engineering.