🔒 Closed beta: four products · 📉 Corrections record: AI mistakes, counted by class and fed back into the next run · 📢 New post: FedRAMP Release 2026.10.13.01 Added 279 Control Mappings and Has No Changelog Entry · 📝 Also fresh: Atlassian CVE-2026-21589 Added to KEV; CVE Record Rejected the Next Day · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 KSI Quick Check: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPComplianceGRC

FedRAMP Reciprocity Rule: No Reporting Path for Providers

On September 8, Johann Dettweiler — stackArmor's CISO — published a piece called FedRAMP 20x: Automation, Reciprocity & What Comes Next, and the first two-thirds of it is hard to argue with.

His read on the technical direction: everyone is on board. Automation, machine-readable security data, continuous validation instead of "periodic archaeology expeditions through 700-page System Security Plans," repeatable queries against actual system state instead of a screenshot pasted into Word. "That's not evidence collection," he writes of the old way. "That's compliance theater." Agreed, and we have said roughly the same thing about what 20x prep actually looks like.

Then he gets to the part that worries him, and it is not about whether 20x can authorize anything. It is about what happens on the day after.

A provider finishes the 20x process with Key Security Indicators, automated validation, the CR26 machine-readable formats, the lot. It walks into Agency A, which says that's nice, now send the traditional SSP, the POA&M, the control implementation statements, the agency-specific evidence workbook, and don't forget the 3PAO assessment. Agency B wants something slightly different. Agency C takes some of the FedRAMP artifacts and wants its own assessment of the rest. Agency D has a template it has been lovingly maintaining since approximately the Bush administration and somebody is going to fill it out.

"We haven't created reciprocity," he concludes. "We've created a really fast, overly complex, stupidly expensive way to reach the starting line." His ask is that FedRAMP, agencies, providers, and assessors converge on a shared definition of what a 20x certification actually conveys. He frames it as four questions: what security assertions an agency can reasonably inherit, what evidence has already been validated, what an agency should still be able to ask a provider to demonstrate again, and what is legitimately agency-specific because it concerns mission risk rather than the security of the underlying service.

It is a good piece and the scenario is recognizable. Our reading differs on one thing, and it is the thing the whole argument rests on: that definition is not missing. It is written down, it is written as a prohibition, and it has been in force since July.

There is a ruleset for agencies, and almost nobody reads it

The Consolidated Rules for 2026 have a stakeholder section per party, and one of those parties is federal agencies. Inside it sits the Agency Use ruleset — AGU — which carries Audience: Agencies, applies to both 20x and Rev5, and covers Class A through Class D. It describes itself as summarizing "the many demands made on agencies by the FedRAMP Authorization Act and OMB Memorandum M-24-15 in a simple, clear, easy-to-follow set of FedRAMP-style rules."

Agency D is already out of bounds. Here is AGU-AGC-NAR, titled No Additional Security Requirements, in full:

Agencies MUST NOT require additional information or materials from FedRAMP Certified cloud service offerings beyond those required by FedRAMP UNLESS the head of the agency or an authorized delegate determines there is a demonstrable need and notifies FedRAMP; this does not apply to seeking clarification or asking general questions about FedRAMP Certification Data.

Agency A's demand for a bespoke evidence workbook is not a grey area. It is a MUST NOT with a single escape hatch, and the hatch is deliberately expensive. The determination does not belong to the authorizing official who wants the workbook; it belongs to the head of the agency or an authorized delegate, who must find a demonstrable need and tell FedRAMP about it.

Its sibling AGU-AGC-TPP closes the other door, with the same head-of-agency gate: agencies MUST NOT require a service to obtain or maintain a particular FedRAMP Certification Type or Path. That is the rule that stops "we only accept agency-sponsored packages," which was the quiet way the old world enforced its preferences.

Then AGU-AGC-NAI requires an agency to notify FedRAMP after requesting any additional information or materials beyond what FedRAMP requires — a notification duty that exists independently of whether the request was justified. AGU-USE-AFR is nine words long and says agencies MUST allow certified offerings to follow FedRAMP rules. And AGU-USE-RCF requires an agency to collaborate with FedRAMP when its own security determinations conflict with the certification package, rather than resolving the conflict unilaterally by sending the provider a spreadsheet.

None of this is new drafting invented for 20x. It is a restatement of the statutory presumption of adequacy, which M-24-15 states plainly: if a service holds a FedRAMP authorization at a given FIPS 199 impact level, the Act requires that agencies must presume the security assessment in that package is adequate for issuing an ATO at or below that level. An agency can overcome the presumption — FISMA still makes the agency head responsible for their own security needs — but only on a "demonstrable need" for requirements beyond the package, or a finding that the package is "wholly or substantially deficient for the purposes of performing an authorization."

And the memo says what happens next, which is the part worth sitting with:

If a new authorization is issued following additional work, the agency that performed the additional authorization work must document in the resulting authorization package the reasons that it found the previous FedRAMP package deficient. The agency will inform the FedRAMP PMO of the deficiency.

So the shared definition of "done" that the stackArmor piece asks the ecosystem to go negotiate has already been negotiated, in law, in a memo, and in a ruleset. An agency that wants more than the package must name a demonstrable need, write down why the package fell short, and tell the program office.

Where our reading differs: the gap is evidentiary, not definitional

Having a rule and having a record that the rule was followed are separate problems, and 20x is otherwise very good at knowing the difference. That is the whole premise of the thing — stop asserting that a capability exists and let the assessor verify it directly. Hold the agency rules to that standard and they come up short in three specific, checkable ways.

First: the Agency Use ruleset contains no clocks. It carries five notification requirements. Count the Timeframe: fields attached to them and you get zero. Compare that to the provider side of the same relationship — CDS-UTC-AAD gives a provider 5 business days to notify FedRAMP after denying an agency's request for certification data. A provider who stalls an agency has a deadline. An agency that demands the Bush-era workbook must notify FedRAMP "after requesting," and "after" is not a date.

Second: nothing on the agency side is published. The word "publicly" appears zero times in the Agency Use ruleset. It appears four times in Certification Data Sharing, the ruleset governing the provider's half of reciprocity, where CDS-CSO-PUB requires providers to publicly share offering information in both human-readable and JSON formats, CDS-CSO-SVC requires a public service list detailed enough that a customer can work out what is in the Minimum Assessment Scope without asking anyone, and CDS-TRC-PAC requires trust centers to offer documented programmatic access to all of it. The provider's side of 20x is a public API. The agency's side is a web form filed with the program office.

Which means the provider in Dettweiler's scenario — the one being handed the workbook — has no way to find out whether the head of that agency ever determined a demonstrable need, whether the notification was filed, or whether anyone looked at it. The one document that would answer the question is an agency ATO package, and the provider is not a reader of agency ATO packages.

Third: the consequence named for breaking a MUST NOT cannot reach an agency. On September 13 — five days after the stackArmor post — FedRAMP added force-of-rule definitions to its definitions reference. FRD-MNT, the definition of MUST NOT, reads:

The rule is an absolute prohibition. Parties MUST meet such rules and address them in their security documentation. Failure to follow the rule is a vulnerability likely requiring corrective action and/or the denial of initial or ongoing FedRAMP Certification.

An agency does not hold a FedRAMP Certification. Half of that sentence is inapplicable to the party AGU-AGC-NAR binds, and the surviving half — document it in your security documentation — lands back in the package nobody outside the agency reads. The definition is written for providers because nearly every MUST NOT in CR26 is aimed at providers. It just happens to be the definition that governs the two rules carrying the entire weight of reciprocity.

The program is not confused about this, which is the interesting part

It would be easy to read the above as oversight. The changelog argues otherwise.

On June 25, 2026 — one day after CR26 launched — FedRAMP removed four rules, CCM-AGM-NAR, CCM-AGM-NFA, VER-AGM-DRE, and VER-AGM-NFR, with the stated reason that they "are addressed by AGU-AGC-NAI and AGU-AGC-NAR already." Agency constraints that had been scattered across the continuous-monitoring and vulnerability-reporting rulesets were deliberately consolidated into those two rules. They are not a leftover. They are the program's considered single answer to "may an agency ask for more?"

On September 13, 2026, FedRAMP ran a sweep adding structured timeframe metadata to rules that had a deadline stated only in prose — MKT-CAS-RFR, MKT-IIP-DLA, VDR-TFR-NMV, CCM-OCR-AVL, CCM-QTR-SAR, IVV-CSF-MCA. Not one AGU rule is in that list, and the sweep was prompted by a community question asking whether five specific rules should carry timeframe fields at all. The same release edited two Agency Use rules to fix broken reference URLs, so the file was open. The agency notifications have no clock because they were never given one, not because nobody has looked at them lately.

And one agency obligation already has a date, which has passed. AGU-AGC-GRC requires agency GRC, compliance, and inventory tools to produce and ingest machine-readable artifacts in at least OSCAL and JSON. That is the CR26 restatement of M-24-15's twenty-four-month milestone, and the memo's own footnote puts the deadline at July 25, 2026 — forty-five days before the stackArmor piece ran, and eighty-three before this one. The Agency Use ruleset's grace period ended July 4, 2026, with the optional-adoption, obtain, and maintain dates all set to the same day; no staged rollout, no "on the first assessment started after." The provider-facing Certification Data Sharing rules, by contrast, do not have to be maintained until January 1, 2027.

The agency rules bound first. The agency rules have no clock and no publication duty. Both of those are true at once, and the second is why the first is invisible.

So who does find out?

FedRAMP answers this itself, on the agency landing page, without being asked:

FedRAMP is not an oversight or enforcement body, it exists to be the primary point of connection between agencies and commercial services to enable adoption.

Followed immediately by the part that actually has teeth:

Failure to follow processes outlined by FedRAMP, in alignment with the law and policy, will expose agency officials to audit by the Office of Management and Budget, Inspectors General, and the Government Accountability Office. FedRAMP has participated in multiple audits by each of these bodies that has resulted in findings against agencies for following legacy processes or failing to properly adopt FedRAMP processes.

That is the real answer, and it is a better one than "nothing happens." The enforcement of reciprocity is an IG finding, not a FedRAMP action — and the page cites a March 2026 Council of the Inspectors General report on cloud computing best practices that, in FedRAMP's own words, "highlights many failures by agencies to meet their responsibilities for the use of cloud services." Agency officials who insist on the legacy workbook are not at risk from the program office. They are at risk from their own IG, on a timeline measured in audit cycles.

The asymmetry shows up one last time in how the two parties are told to escalate. Agencies get a documented path for a non-compliant provider: escalate to the vendor, then notify your contracting officer, then email FedRAMP, after which "FedRAMP will follow up with the provider and, if necessary, request corrective action in addition to notifying other agencies." There is no mirrored page in the provider section. A provider's recourse against an over-asking agency is the contract and the agency's own IG, and the same page draws the line explicitly: "FedRAMP's authority is limited to FedRAMP defined requirements."

What that means for a provider this quarter

If you are in the 20x pipeline, the practical consequence of all this is narrower than the debate suggests — and it does not involve waiting for the ecosystem to converge.

  • When an agency asks for materials outside the package, answer in writing, cite the rule, and keep the exchange. AGU-AGC-NAR exists, it is short, and most of the people sending the workbook have never read the agency section of CR26. The rule's own carve-out protects the reasonable case — clarification and general questions about certification data are explicitly not covered — so citing it is not obstruction. It is a request that the escape hatch be used properly: a demonstrable need, determined at the level the rule names. Then log who asked for what and when, because nobody else is keeping a log you can read. The agency files its notification with FedRAMP and you never see it, so if the pattern matters later — to a contracting officer, or to an IG — the only record in a form you control is the one you wrote down at the time.
  • Make answering cheap instead of making it rare. This is the part the stackArmor piece gets exactly right, and it is the same conclusion we reached writing about the Security Decision Record: if the underlying system state is queryable, then a 20x package, a 3PAO assessment, an agency risk review, and continuous monitoring are all projections of one dataset. An agency-specific workbook stops being an emergency and becomes a formatting job. That does not make the ask legitimate, but it does make it survivable while the enforcement question works itself out over several audit cycles.

That last point is most of why the engine we build renders evidence from live system state rather than storing finished documents. The record is a byproduct of the work, not a deliverable produced for a reviewer, which means an unanticipated question is a new query rather than a new project. We did not choose that shape to defeat Agency D's template. It just turns out that the architecture which satisfies a machine-readable program is also the one that absorbs a party who has not modernized yet.

The question worth carrying

The most useful thing in Dettweiler's piece is the sentence about why ambiguity is expensive: "Nobody gets fired for requesting another document."

He is right, and the rules now say otherwise — an agency that requests another document owes a determination at the head-of-agency level and a notification to FedRAMP. What the rules do not do is put that determination anywhere the market can see it. So the question is not whether we need a shared definition of done. We have one.

The question is whether a MUST NOT becomes a norm when the only party who can tell it was broken is the party who broke it.

Reference