One provider, 91 agencies: the many-to-one problem in federal cloud

Microsoft maintains one FedRAMP package for Microsoft 365 Government Community Cloud. Ninety-one agencies hold an authorization on it. Microsoft writes its security story once, with a team that does nothing else, and sells it ninety-one times. Each of the ninety-one agencies writes its own system security plan for its own tenant, with a few people who also cover forty other systems, and nobody else can use what they write.

That is the many-to-one problem. It is not new, it is not FedRAMP's fault, and it is not going away. But the FedRAMP changes we wrote about in FedRAMP moved the risk to agencies make it worse, because they take away the few shared artifacts that let the ninety-one agencies start from the same place.

Key insights

• The provider side scales. The customer side does not. One provider, one package, one specialized team, repeated across every customer. Each agency has one instance of each offering, a bespoke integration, and a generalist team that must document it from scratch.
• The customer's half of the work is generically standard but specifically unique. Every agency must answer the same questions about identity, logging, data handling, and configuration. Every agency answers them for a different tenant, wired into different directories, different log pipelines, and different boundaries.
• Most offerings have almost no peers to collaborate with. On October 17, 2026, 216 of the 534 certified offerings had exactly one agency customer. The median offering has two. Only eight have more than fifty.
• Agencies' portfolios overlap less than you would think. The typical agency shares about a quarter of its cloud portfolio with its closest peer agency. Even the Department of Veterans Affairs, with 131 offerings, overlaps only 17 percent with its nearest match.
• The one place collaboration would pay off is the one place FedRAMP just removed the shared artifact. The 84 offerings with ten or more agency customers carry 64 percent of all agency authorizations. FedRAMP retired the Customer Responsibility Matrix in June 2026 and promised, without a date, to "separately work with agencies to create standardized baselines."
• The 2026 rules add agency-side work that is one-to-one by design. As the rules take effect, each agency must review each quarterly report, ingest machine-readable evidence into its own tools, file its own CISA incident reports, and track provider weaknesses in its own records. None of that is shareable.

The asymmetry

A cloud service provider has four advantages an agency customer cannot match.

Scale. The provider's compliance cost is spread across every customer. The agency's is spread across one tenant. If Microsoft spends a million dollars improving its FedRAMP package, the cost per customer is about eleven thousand dollars. When an agency spends a hundred thousand dollars documenting its tenant, the cost per customer is a hundred thousand dollars.

System knowledge. The provider built the service. Its engineers know which log goes where, which setting enforces which control, and what the architecture looks like under the marketing diagram. The agency knows what the admin console shows and what the Secure Configuration Guide says. Under Rev5 the Customer Responsibility Matrix was the provider telling the customer, control by control, "this part is yours." Under the 2026 rules there is no control-by-control document of that kind.

Repeatability. The provider answers the same question from ninety-one customers with one answer. The agency answers a different question for each of its forty providers, and the answers do not transfer. The identity integration for Microsoft 365 teaches you nothing about the identity integration for ServiceNow.

Profit motive. The provider's package is a revenue asset. It gets a budget line, a team, and executive attention, because a lapsed certification puts federal sales at risk. The agency's system security plan is a compliance cost. In our experience it gets whatever is left after operations.

None of this is a criticism of providers. They are doing what a well-run business does. The point is that the two sides of a FedRAMP relationship are built on opposite economics, and the program's recent changes assume the customer side can behave like the provider side.

The customer's work is standard in shape and unique in content

Here is what every agency must do for every certified offering it uses, with small differences by class. The agency decides whether to use the service, documents that decision, writes the agency portion of the system security plan, records which controls it implements and which it relies on the provider for, configures the service according to the Secure Configuration Guide, connects it to agency identity, agency logging, and agency monitoring, authorizes it, reviews the provider's quarterly reports, tracks the provider's open weaknesses, and reports its own incidents.

The shape of that list is identical for 246 agencies and 534 offerings. The content is unique every time, because the content is the integration, and the integration is the agency. Which directory issues the identities. Which SIEM takes the logs. Which network boundary the service sits inside. Which data types flow into it. Which agency policies govern the administrators. Two agencies with the same offering, the same class, and the same impact level will write different documents, correctly.

That is why there is no library of reusable agency SSP statements for Microsoft 365, even though 91 agencies have each written one. The statements are not interchangeable. The parts that would be interchangeable, the provider's responsibilities and the generic description of the service, were the parts the provider used to supply through the Customer Responsibility Matrix. The parts that remain for the agency are the parts that cannot be shared.

The numbers: most offerings have no peers, and most portfolios barely overlap

We computed these from the FedRAMP Marketplace data published on October 17, 2026.

Forty percent of certified offerings have exactly one agency customer. For those 216 services, there is no peer agency to compare notes with, no second SSP to read, and no shared interest in a customer-responsibility baseline. The agency is the market.

The top of the market looks like the opposite problem: here there are plenty of peers. Ninety-one agencies have an M365 tenant. If collaboration on customer-side artifacts were going to work anywhere, it would work here. We come back to that below.

Now look at it from the agency's side. The median agency uses six certified offerings. Nearly half use five or fewer. Those are mostly small agencies and components with no dedicated cloud security team. Their portfolios are not as concentrated as you might expect: only about 30 percent of the small agencies' authorizations are on the ten most-used offerings. The rest are on niche services where the small agency may be the only customer with a security team to ask.

The large agencies have the capacity and the opposite problem. We measured, for each agency, how much its cloud portfolio overlaps with its single closest peer agency, using the share of offerings the two have in common out of all the offerings either one uses. The median agency's best match overlaps 25 percent. The Department of Veterans Affairs, with 131 offerings, overlaps 17 percent with its closest match, the Department of Agriculture, and 46 of its offerings are used by no other agency at all. The Department of State, with 72 offerings, overlaps 29 percent with its closest match, the Department of Health and Human Services.

So the two halves of government face mirror-image versions of the problem. Small agencies have little capacity to collaborate and a mix of shared and orphan services. Large agencies have capacity but share only a quarter of their portfolios with anyone, and the integration content differs even where the offering is the same.

Why there is no standard way to collaborate

Three things would have to exist for agencies to share customer-side work, and none of them does.

A shared starting point. Under Rev5, that was the Customer Responsibility Matrix: the provider's control-by-control statement of what the customer owns. It was imperfect and often late, but it was the same document for all 91 M365 customers, and an agency's SSP could cite it. Notice NTC-0013 (June 16, 2026) replaced it with the Secure Configuration Guide, which covers administrative account settings; the provider rule for it maps to a single control, CM-7. FedRAMP said it "will separately work with agencies to create standardized baselines that clearly separate the responsibilities so they can engage in the RMF process correctly." As of October 17, 2026, there is no date, no request for comment, and no deliverable for that work.

A shared format. An agency's SSP lives in whatever GRC tool the agency bought: eMASS, CSAM, Xacta, Archer, ServiceNow, RegScale, JCAM, or a spreadsheet. The 2026 rules require agency tools to produce and ingest OSCAL and JSON (rule AGU-AGC-GRC), and FedRAMP states it does not endorse or fund agency tooling. The KSIs and rules are published as JSON with tags naming related 800-53 controls, which is useful, but a tag is not an inheritance statement: nothing in a 20x package says which of those controls the agency still owns. Two agencies that wanted to exchange control statements for the same offering would first have to agree on how to express them.

A shared forum. FedRAMP's 2026 Liaisons Program page gives no cadence, curriculum, or schedule. The agency ruleset is the only one of seventeen still marked "Placeholder." The FedRAMP community on GitHub is active, but most of the voices in it are providers and assessors. We know of no government-wide repository of agency authorization artifacts, and the artifacts contain system-specific detail that agencies do not share outside the agency.

Even if all three existed, the overlap data above sets the ceiling. For the 216 single-customer offerings, there is nobody to share with. For the long middle, a quarter-overlap portfolio means most of an agency's documents have no counterpart anywhere.

How the FedRAMP changes make this worse

The prior article scored sixteen changes and found twelve shifted risk toward agencies. Five of them land directly on the many-to-one problem.

The CRM is gone. Covered above. The one artifact that was written once by the provider and consumed by every customer is replaced by a configuration guide that tells administrators which switches to set, not which controls the agency owns.

KSIs replace the 800-53 baseline in the package. Provider evidence is now organized around 46 Key Security Indicators. Agency SSPs are still organized around 800-53 controls, because NIST SP 800-37 requires it and agency GRC tools are built that way. The KSIs carry 800-53 control tags, but a 20x package contains no statement of which controls the agency implements and which it inherits. That translation is the agency's job, 246 times over. Under Rev5 it was unnecessary; both sides spoke 800-53.

Agencies report provider incidents to CISA. Under the pilot-era 20x rules, the provider reported to CISA. Under NTC-0012, each affected agency reports, based on the impact to its own services. One provider's duty became up to 91 agency duties, each carried by a security operations center that did not detect the incident and learns about it when the provider's notice arrives: within an hour of the provider's decision for a Moderate (Class C) service, within six hours for Class B.

Each agency reviews each quarterly report and tracks the same weaknesses. Rule CCM-AGM-ROR requires every agency customer to review every Ongoing Certification Report. The agency vulnerability rules tell agencies to review overdue and accepted provider vulnerabilities and, where agency policy requires, track them in their own records. For a provider with 91 customers, that is 91 reviews of the same quarterly report and 91 decisions about the same accepted weaknesses. There is no mechanism for one agency's review to count for another.

FedRAMP stepped out of the middle. Package access now runs through provider trust centers, and FedRAMP "will no longer act as an intermediary." A provider "may deny an access request if it does not want to do business with an agency." Under Rev5, a reusing agency could request a Low or Moderate package and its monitoring data from the FedRAMP repository. Now each agency negotiates its own access, and the small agency with one seat has the same escalation path as the department with ten thousand.

Each of these replaces something done once, by FedRAMP or by the provider, with something done separately by every agency customer. That is the many-to-one problem, written into the rules.

What agencies can do

The honest answer is that no agency can fix this alone, and FedRAMP has not committed to fixing it. But some of the work can be made less bespoke.

• Separate the generic from the specific in your own SSP. Write the description of the service, the provider's responsibilities, and the class-to-impact-level rationale as a reusable block you can hand to another agency. Keep the identity, logging, and boundary detail in a separate section that stays yours. The first block is shareable today; nothing stops two agencies from trading them.
• Pick the services where peers exist and start there. The 84 offerings with ten or more agency customers carry nearly two-thirds of all agency authorizations. A customer-responsibility baseline for Microsoft 365, ServiceNow, and the hyperscalers would help nearly every agency in government. Ask FedRAMP, through the Liaisons Program and the community, when the "standardized baselines" promised in NTC-0013 will arrive, and which services they will start with.
• Push the one-to-many work back toward the provider through the contract. FedRAMP's responsibilities page allows contract terms that add to FedRAMP's rules, such as monthly rather than quarterly reports, though asking a certified provider for more than FedRAMP requires now takes an agency-head finding of demonstrable need and a notice to FedRAMP (rules AGU-AGC-NAR and AGU-AGC-NAI). A control-by-control customer-responsibility statement, mapped to 800-53, is a reasonable deliverable to ask for from a provider with 91 customers. It costs the provider once and saves the government 91 times, which is exactly the kind of case an agency head can make.
• Standardize your own side. If your agency uses forty offerings, write one identity integration pattern, one logging pattern, and one boundary pattern, and make every offering fit them. The integration will still be unique to your agency, but it will be the same unique across all forty.
• Use the data to find your peers. The Marketplace shows which agencies hold an authorization on each offering. For any service you are about to authorize, the list of agencies that already did is public. Call them.

We built FedXchange partly because of this problem. The tracker shows every offering's certification type and the agencies that use it, so an agency can find its peers before it starts. The document development process generates the agency-side policies and procedures from a shared, agency-neutral base and lets each agency fill in only the parts that are its own. That does not solve the many-to-one problem. It moves the line between generic and specific a little closer to where the economics say it should be.

Sources

• FedRAMP Marketplace data (GitHub), October 17, 2026
• FedRAMP NTC-0013: Rev5 updates, Secure Configuration Guide
• FedRAMP NTC-0012: Incident communication
• Consolidated Rules for 2026: Agency Use rules
• Consolidated Rules for 2026: Collaborative Continuous Monitoring agency rules
• Consolidated Rules for 2026: Vulnerability Evaluation and Reporting agency rules
• Consolidated Rules for 2026: Secure Configuration Guide ruleset
• Consolidated Rules for 2026: Certification Packages for agencies
• Consolidated Rules for 2026: Agency responsibilities
• Consolidated Rules for 2026: Liaisons Program
• Consolidated Rules for 2026: Complete rulesets and status
• FedXchange: FedRAMP moved the risk to agencies