The sentence that ends a security review badly
A vendor tells a state buyer, "we run on a FedRAMP High platform, so we're covered." Nothing in the program works that way. FedRAMP certifies a cloud service offering, defined in FedRAMP's 2026 rules as "a specific, packaged cloud computing product or service supplied by a cloud service provider for use by customers, that is the subject of a FedRAMP Certification." The platform under you is one offering. The application you built on top of it is a different one. The platform's authorization is worth real money to you, it removes real work, and it does not transfer. It also never touches the layer the buyer is actually purchasing.
What follows is drawn from published shared-responsibility documentation, FedRAMP's own templates and rules, the statute that governs package reuse, and the state-program materials. Every claim here is checkable against the same public sources.
The stakes are practical. A state or county security questionnaire usually arrives after the technical evaluation, with a two-week turnaround and a reviewer who is carrying four other procurements. A vendor who can name exactly which controls the platform carries, which ones it shares, and which ones sit entirely in its own column answers that questionnaire in three days. A vendor who cannot answers it in three weeks, badly, and gets a follow-up round that pushes award past the fiscal year.
What "inherit" means once somebody writes it down
Amazon states the split in its own words. Security of the cloud belongs to AWS, which manages "the hardware, software, networking, and facilities that run AWS Cloud services." Security in the cloud belongs to the customer, and the extent of it depends on which services the customer picked. For an EC2 instance, AWS puts the guest operating system, its patches, the application software, and the configuration of the AWS-provided firewall squarely on the customer.
Amazon then sorts controls into three buckets, and the names matter because assessors use them. Inherited controls are those "which a customer fully inherits from AWS," and the example given is physical and environmental protection. Shared controls "apply to both the infrastructure layer and customer layers, but in completely separate contexts or perspectives," with patch management, configuration management, and awareness and training named as examples. Customer specific controls are "solely the responsibility of the customer based on the application they are deploying."
Read the middle bucket twice, because it is where deals go wrong. Shared does not mean split in half. It means the same control number appears in two different systems and each system has to satisfy it on its own evidence. The provider patches the hypervisor. Nobody patches your container image but you. Both of those facts live under the same control family, and an assessor will ask for both.
The artifact that settles which bucket a given control falls into has a name and a template number. In the legacy FedRAMP package it is System Security Plan Appendix J, the CIS and CRM Workbook, which FedRAMP describes as delineating control responsibilities of cloud service providers and agencies. CIS is the Control Implementation Summary; CRM is the Customer Responsibility Matrix. If you are building on an authorized platform and you have not read its workbook, you do not actually know what you own. Ask the provider for it. It is normally available under a non-disclosure agreement, and any buyer's reviewer worth the title already knows it exists.
Under all of it sits the control catalog itself: NIST Special Publication 800-53, Revision 5, currently at Release 5.2.0, issued August 27, 2025. When a workbook says a control is customer-responsible, that is the document defining what the control requires.
How much of a control family a platform authorization removes
Editorial weighting drawn from published shared-responsibility documentation and control-responsibility workbooks. An illustrative ranking of how much of a family the platform carries, not a measured statistic. Your own provider's workbook is the authority for your system.
The shape of that chart is the whole argument. At the top, the platform does essentially all of it and you write one sentence pointing at the provider's package. At the bottom, the platform does close to none of it, because no provider knows what a role in your application is allowed to do or what your audit record is supposed to contain. The families at the bottom are also the ones a buyer cares most about, because they are the ones that govern their data inside your product.
The split, family by family
A workbook runs to hundreds of rows. The pattern underneath it compresses into a handful of lines, and holding the pattern in your head is what lets you answer a questionnaire without opening a spreadsheet.
| Control area | What the platform authorization carries | What stays in your column |
|---|---|---|
| Physical and environmental | Data centers, power, cooling, media destruction, facility access. Named by AWS as fully inherited. | Your own offices and endpoints, if the buyer scopes them in. Many state contracts do. |
| Maintenance and flaw remediation | Hypervisor, host operating systems, managed-service internals, hardware lifecycle. | Your base images, your operating system packages, your language runtimes, your third-party libraries, your model dependencies. |
| Configuration management | The provider's own baselines for the service as authorized. | Every setting you chose. The platform authorized the service, not your configuration of it. |
| Access control | Identity for the platform console and platform APIs. | Roles, permissions, session handling and multi-factor enforcement inside your application, plus who on your team can reach production. |
| Audit and accountability | Platform-level logs of infrastructure and API events. | What your application records, whether the record survives, how long you keep it, and who reads it. This is what an auditor subpoenas. |
| Personnel security | Screening of the provider's own staff. | Screening of yours. No platform authorization has ever cleared a vendor's engineer. |
Two families deserve a separate note because vendors routinely assume they are covered. Incident response is shared in an awkward way: the provider will tell you when the platform has an incident, on the provider's schedule, but your notification clock to your customer runs from when your system is affected, and that clock is written into your contract, not into the provider's. Contingency planning is worse. The platform sells you regions, availability zones, and a backup service. It does not sell you a recovery time objective, and it has never tested your restore.
Inheritance stops at the service list
An authorization applies to an enumerated set of services in a named environment, and the enumeration is published. Microsoft maintains service-by-service tables for FedRAMP and Department of Defense impact levels across Azure, Azure Government, and Azure Government Secret, updated as recently as February 2026, with a legend that reads: a checkmark means "service is included in audit scope and has been authorized." Reach for a service without the checkmark and you have stepped outside the boundary you were counting on.
The environment matters as much as the service. Azure commercial regions in the United States hold a FedRAMP High provisional authorization to operate and a Department of Defense Impact Level 2 provisional authorization. Azure Government regions hold FedRAMP High plus Impact Levels 2, 4, and 5. Impact Level 6 lives in Azure Government Secret. Same product names, different tables, different answers. A vendor who tested in a commercial region and wrote the proposal against the Azure Government table has an inheritance claim that will not survive a careful read.
Amazon draws the same boundary with more room in it. AWS states that "if a service is not currently listed as in scope of the most recent assessment, it does not mean that you cannot use the service," and puts the burden on the customer to determine whether the service will process customer data and to work the question with an account team. That is a fair position and a genuine flexibility. It is also a burden. Using an out-of-scope service is a decision you have to make, document, and defend, not a gap you can quietly ignore.
The published tables carry warnings that are worth reading literally. Microsoft notes that some services in Azure Government regions "require extra configuration to meet DoD IL5 compute and storage isolation requirements." That is an authorization conditioned on work the customer performs. And for edge hardware such as Data Box, Azure Stack Edge and Azure Local, Microsoft states plainly that "you are wholly responsible for the authorization package that covers the physical devices." The service is authorized. The thing sitting in the county building is yours.
You cannot inherit an assurance level from something sitting below it
Inheritance has a ceiling, and the ceiling is the weakest authorized layer in your stack. Microsoft writes the rule out for one of its own products: before Azure Information Protection can be used for Defense workloads at a given impact level, "the corresponding Microsoft 365 services must be authorized at the same IL." The same arithmetic governs your product. An application aiming at FedRAMP High cannot rest on a component authorized only at Moderate and call the gap inherited. It is not inherited. It is an open finding with a nicer name.
This is the single most expensive mistake in the pattern, because it surfaces late. Architecture gets chosen in month one on the strength of a marketing page, and the mismatch appears in month nine when an assessor maps the boundary and finds a Moderate dependency inside a High system. Checking the level of every dependency against the level you are claiming is an afternoon of work at the start and a re-platforming at the end.
The platform holds an authorization. Your customer holds the risk.
Congress settled the reuse question in statute, and the two halves of the provision are equally important. Under 44 U.S.C. § 3613(e)(1), "the assessment of security controls and materials within the authorization package for a FedRAMP authorization shall be presumed adequate for use in an agency authorization to operate cloud computing products and services." That presumption is the reason a platform authorization is worth paying for.
Subsection (e)(2) then draws two lines that vendors skip. The presumption does not relieve an agency of its own compliance responsibilities under federal information security law, and it does not restrict an agency's authority to determine that "there is a demonstrable need for additional security requirements beyond the security requirements included in a FedRAMP authorization for a particular control implementation." In plain terms: reuse is the default, and additional requirements are lawful. The General Services Administration is separately directed under 44 U.S.C. § 3609 to build the processes for agency review, reuse and standardization, and to "provide a secure mechanism for storing and sharing necessary data, including FedRAMP authorization packages, to enable better reuse of such packages across agencies."
So the honest sentence for a proposal is not "we are covered." It is: the platform under our application holds this authorization at this level, here is the responsibility workbook, here are the controls it assigns to us, and here is how we implement each one. That sentence shortens a reviewer's work, which is the actual thing you are selling in a security review.
State and local buyers run the same mechanics under a different program
State agencies, counties and cities rarely issue a FedRAMP authorization of their own. They do two other things, and both change what inheritance buys you.
First, many of them now route cloud purchases through GovRAMP, the nonprofit membership organization that operates the state-and-local analogue of FedRAMP and that carried the StateRAMP name until recently. GovRAMP describes itself as bringing "governments and technology providers together to improve cybersecurity, protect public data, and enable trusted technology adoption," and it publishes a tiered ladder rather than a single gate: Security Snapshot, Progressing Security Snapshot, Core Verification, Ready Verification, and Authorized or Provisional Verification, the last of which the organization describes as a twelve-month status based on an independent third-party assessment of more than 300 NIST controls. Its published scale is over 1,200 member organizations, more than 70 government organizations engaged, and more than 330 products in the program.
The tiered ladder is the part worth planning around. A vendor who cannot fund a full assessment can still enter at a lower tier and be visible to buyers who filter by program status, which is a materially different position from having nothing to show. The relationship between the two programs is also moving: GovRAMP published a note on July 15, 2026 titled "FedRAMP Recognizes GovRAMP in Updated Class A Rules." The direction of travel is toward mutual recognition. The specifics are in flux, so confirm the current position with the buyer rather than quoting a blog post at them.
Second, state contracts add overlays that no platform authorization touches, because they attach to the agency's data rather than to anyone's infrastructure. Any engagement handling federal tax information carries IRS Publication 1075, currently at Revision 11-2021, whose stated purpose is to direct recipient agencies, their representatives and their service providers to implement safeguards protecting confidential federal tax information. Criminal justice data carries the FBI's CJIS Security Policy. Health and education programs carry their own. A FedRAMP High platform underneath you satisfies none of these on its own. They flow to you through the contract, and the contract terms in state procurement are usually a published attachment signed as-is.
Practically, this means a state security review asks a different first question than a federal one. Federal reviewers ask which authorization you hold. State reviewers, working from a smaller staff and a shorter clock, ask what they have to accept on faith. The responsibility workbook is the answer, and handing it over early is one of the cheapest trust-building moves available to a vendor.
What FedRAMP 20x changes, and what it does not
The federal program is mid-rebuild, and the vocabulary is changing under everyone's feet. FedRAMP 20x describes itself as moving "beyond traditional compliance to focus on the security decisions that matter most," built on five stated principles including automatic validation, with Key Security Indicators intended to demonstrate security posture in near real time rather than through a static annual assessment. The certification classes now in play are Class A for mature security programs entering the federal marketplace, Class B for small-scale and light-use services, and Class C for common enterprise services, with Class D under development for the high-impact pilot.
The phasing, as published: Phase 1 was a low-impact pilot with 26 submissions and 13 completed reviews. Phase 2 covered moderate impact with 14 qualifying submissions. Phase 3 is active, formalizing requirements with the submission pipeline opening across July to September 2026. Phase 4 targets the Class D high pilot in the first half of fiscal 2027, and Phase 5, estimated for the second half of fiscal 2027, is the end of life for legacy Revision 5 certifications. The marketplace currently lists 529 certified cloud services, of which 28 carry the 20x certification.
Here is the part to say plainly rather than paper over. The Consolidated Rules for 2026 define "cloud service offering" and "information resource," but the published definitions list does not define inheritance, customer responsibility, or the reuse of an underlying provider's authorization, even though the rules site does carry a shared-responsibilities section organized by stakeholder type. The CIS and CRM Workbook is a legacy Revision 5 artifact. Its successor under a 20x certification is not something to assume. If you are starting an authorization now, ask your assessor and your provider what the responsibility artifact will be called in the package you are actually going to submit.
None of that changes the engineering. Whatever the program calls the document, some entity patches the hypervisor and a different entity patches your container. Keep your own responsibility matrix, mapped to the current control catalog, owned by a named engineer, updated when you add a service. It will outlive three program vocabularies.
Reading a platform authorization before you answer the questionnaire
What quietly breaks inheritance after you ship
A new managed service arrives in a sprint. An engineer picks the obvious tool for a queue or a search index, it is not on the in-scope table for your environment, and your boundary diagram is now wrong. This is the most common failure and the easiest to catch, because it is a one-line check in a pull request template.
The environment drifts. Development in a commercial region, production in a government region, and a staging deployment that nobody re-pointed. The authorization tables are different documents for a reason.
The provider changes the list. Services move in and out of audit scope, and a provider's open remediation items are visible to your customer's reviewer even when they are invisible to you. Reading the provider's continuous monitoring output is part of your job, not part of theirs.
Configuration drifts. The platform authorized the service as configured to its own baseline. Your storage bucket, your key rotation interval, your network rule are yours. An authorized service configured badly is an unauthorized posture with a good pedigree.
Staffing changes. Personnel screening is never inherited. A new engineer with production access is a control event, and on a state contract carrying tax or criminal justice data it can be a contractual one.
What a reviewer will actually ask you for
- The provider's responsibility workbook for the exact offering, authorization level and environment you run in.
- Your service inventory checked against the published in-scope list, with any out-of-scope service named and justified rather than omitted.
- Your own responsibility matrix, listing each customer-assigned control, its implementation, and where the evidence lives.
- Named owners for account management, audit records, and vulnerability scanning of your own code, images and dependencies.
- An incident notification commitment in hours, written into the contract rather than described on a call.
- Personnel screening records for everyone with production access, current as of the review.
- A restore test date, not a backup policy. Reviewers have learned the difference.
- The advisory feed you monitor for provider service changes, and the name of the person who reads it.
Bottom line
Building on an authorized platform is the right call, and the savings are large and legitimate. What it buys is the bottom of the stack: the buildings, the hardware, the hypervisor, the managed-service internals, and a package your customer's assessor is entitled by statute to presume adequate. What it does not buy is your application, your configuration, your audit trail, your people, or your recovery. Those stay in your column no matter whose logo is on the region.
The vendors who win security reviews are the ones who can say which is which without hedging. That capability costs one careful read of a responsibility workbook and a matrix you maintain afterward. It is the cheapest credibility available in this market, and it is visible to a buyer in the first ten minutes of a conversation.
Frequently asked questions
No. FedRAMP certifies a specific packaged cloud service offering supplied by a provider. The platform is one offering; your application is another. You can rely on the platform's package for the controls its responsibility workbook assigns to the provider, and you must implement and evidence the rest yourself.
Ask the provider for the Control Implementation Summary and Customer Responsibility Matrix workbook covering the exact offering, level and environment you use. In the legacy FedRAMP package this is System Security Plan Appendix J, described as delineating control responsibilities between cloud service providers and agencies. It is normally shared under a non-disclosure agreement.
Sometimes, and it is a decision rather than an oversight. AWS states that a service not listed in scope of the most recent assessment does not mean you cannot use it, and puts the analysis on the customer. Determine whether the service will touch customer data, document the reasoning, and raise it with the buyer before the assessment rather than after.
It helps and it rarely finishes the job. Many state and local buyers work through GovRAMP, which runs its own tiered ladder from Security Snapshot up to Authorized or Provisional Verification. State contracts also add data-specific overlays, such as IRS Publication 1075 for federal tax information, that attach to the agency's data rather than to any platform.
It changes the paperwork and the vocabulary more than the engineering. The 2026 Consolidated Rules define a cloud service offering but do not define inheritance or customer responsibility in the published definitions list, and the CIS and CRM Workbook is a legacy Revision 5 artifact with legacy certifications slated to end late in fiscal 2027. Ask your provider and assessor what the responsibility artifact will be in the package you actually submit.