🔒 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
FedRAMPCryptographyCompliance

FedRAMP RFC-0035/0036 Discussion: Class G, and No Certification-Data Field for Class D Crypto Disclosure

On October 15, a FedRAMP maintainer opened a discussion thread with an explanation of why the thread had to exist at all:

Hey all - as a reminder, FedRAMP can't answer questions or generally participate directly in RFC threads to avoid influencing public comment. Sometimes this creates confusion because folks just want to talk about details of something proposed in an RFC to understand it better or learn more about it, so we create these side-threads at times for RFCs.

The two RFCs in question are RFC-0035, Cryptographic Module Use Rules Updates, open October 14 and closing November 17, 2026, and RFC-0036, FedRAMP 20x Class D Cloud-Hosted Pilot Requirements, open October 15 and closing November 19, 2026.

Before going further: none of what follows is in force. The Consolidated Rules for 2026 datafile at version 2026.10.13.01 contains no rule proposed by either RFC. If you are certified today or applying today, your obligations are unchanged. What makes the thread worth reading anyway is that the questions in it are better than the RFCs — the first one found a load-bearing term that cannot be resolved from any published document, and two later ones found the place where the proposed change stops being self-consistent.

A class nobody has seen

The first question came six hours later, from a provider reading RFC-0036's proposed rule text:

With regards to: FRC-CLD-CTP: "Providers seeking a FedRAMP 20x Class D Certification SHOULD limit the likely handling of federal customer data within the cloud service offering to third-party information resources that are included in a FedRAMP Class B, Class C, Class D, or Class G Certified offering."

What is a Class G Certified offering? I do not believe I have seen or heard references to that previously.

They had not seen it previously because it is not anywhere. grep the Consolidated Rules datafile for the string Class G and you get zero. The definition of Certification Class, FRD-CCL, enumerates the field explicitly — "increasing from minimal assurance at Class A to significant assurance at Class D; currently available categories are Class A, B, C, or D" — and FRD-CPF, Certification Profile, says the same thing a second time. On fedramp.gov, the letter G appears exactly once as a certification class, and it is in the sentence the provider quoted.

The maintainer's answer:

That is a tiny little spoiler hiding in there. :) In RFC-0032, we proposed a separate process for FedRAMP Certification of cloud service offerings that were provided by federal agencies - if approved by the FR Board later this month, that will be Class G to differentiate it from commercial classes.

RFC-0032, Offerings By Government, closed for comment on September 8. It proposes an OBG ruleset letting a cloud service run by a federal agency obtain a FedRAMP Certification through that agency's own authorization process, with FedRAMP relying on the agency authorizing official's work rather than applying rules written for private companies. Its page never uses the letter G. The naming decision surfaced for the first time in a draft rule inside a different RFC, and was explained for the first time in a side thread about that RFC.

Two things follow from that, and the second is the one worth keeping.

The small one: G is not a rung above D. FRD-CCL reads the classes as a ladder of increasing assurance, and the maintainer's wording — "to differentiate it from commercial classes" — says the new letter steps off the ladder rather than extending it. A reader who assumed alphabetical order meant higher assurance would have misread FRC-CLD-CTP in the direction of stricter.

The larger one: an open RFC's proposed rule text already depends on another open RFC's outcome. FRC-CLD-CTP is a SHOULD about which third parties a Class D applicant may rely on for federal customer data, and one of its four permitted answers does not exist and may never. If you are modelling what Phase 4 participation would cost you, that SHOULD has an unresolvable term in it right now, and nothing you can read tells you so. Comment periods are usually described as a chance to react to text. This one also requires reconstructing a dependency graph across RFCs at different stages, from a thread that is explicitly not the place where comment gets counted.

The rule that is getting weaker

RFC-0035 is unusual in a way that is easy to skim past: it proposes making a FedRAMP requirement less strict, and says so in its own summary — "the proposed updates remove a previously firm barrier at Class D but do not require currently operating cloud services to do anything differently."

The Cryptographic Module Use ruleset is small. Three rules, all in one subset, applying to Classes B through D on both the 20x and Rev5 tracks. The one in question is CMU-CSO-UVM, which today runs a ladder by class: Class A and Class B MAY use modules with active validations under the NIST Cryptographic Module Validation Program, Class C SHOULD, and Class D MUST.

RFC-0035 proposes dropping Class D from MUST to SHOULD, matching Class C. It also adds a definition, FRD-CVM ("CMVP-Validated Module"), to replace the longhand throughout, and adds a new rule, CMU-CSO-TSC, requiring providers to treat a move from a CMVP-validated module to a non-validated one as a transformative change — which FRD-TRF defines as the class of significant change that "introduces substantive potential security risks that are likely to affect existing risk determinations and must be assessed in depth."

FedRAMP's stated reason is worth quoting rather than paraphrasing, because the mechanism matters more than the direction:

Requiring Class D services to use only CMVP-validated modules can force providers to run separate cryptography for government customers. That cryptography can cost more, lag behind commercial security updates, and perform worse than alternative solutions that still provide sufficient protection for specific use cases.

And, pointedly: "this RFC also does not change agency obligations under FIPS 140-3." That sentence is doing more work than it looks like. NIST's own position on the Cryptographic Module Validation Program is unambiguous — "if the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 or FIPS 140-3 is applicable. In essence, if cryptography is required, then it must be validated." The federal obligation does not move. What moves is who holds it, and where in the procurement it gets discovered.

So the honest summary of RFC-0035 is not "FedRAMP relaxed the crypto rules." It is that the assurance shifts from something the program guarantees by class to something the provider states and the agency evaluates. Which puts all the weight on the statement.

Both comments ask for the same field, and it has nowhere to live

That is exactly where the two substantive comments on RFC-0035 landed, from opposite sides of the table.

A provider-side commenter went first:

Today, a Class D designation tells us that a CSP offering uses FIPS-validated cryptographic modules. If the requirement becomes SHOULD, that assurance goes away. CSPs and agencies would no longer be able to tell whether a product uses FIPS-validated modules without access to the CSP's CR26 implementation details. [...] If it does change to SHOULD, please require CSPs to publicly disclose whether their offering uses FIPS-validated modules, so agencies and other CSPs don't need CR26 implementation details to find out.

A 3PAO assessor arrived at the same ask with a sharper specification:

If Class D moves to SHOULD, please add a public, machine-readable field in the certification data and on the Marketplace stating whether federal customer data is protected by CMVP-validated modules: all, some, or none. Applying it to every class would solve the Class C problem too.

FedRAMP's answer to "how would an agency find out" is already written, and it is CMU-CSO-CMD — the documentation rule, a MUST at every class, which RFC-0035 leans on by name as the thing that keeps agencies informed after the barrier comes down. The RFC's motivation says a potential agency customer "will always know where and how the cloud service offering uses cryptographic modules."

Check where that documentation goes. CMU-CSO-CMD's artifact is a list of cryptographic modules, and it lands in the FedRAMP Certification Package. Sharing the package is CDS-CSO-RPS, and CDS-CSO-RPS is a MAY — providers may responsibly share some or all of a package publicly if they determine it will not likely have an adverse effect. The provider-side commenter's phrase "without access to the CSP's CR26 implementation details" is not a worry about an edge case. It is the default.

The public obligation is a different rule, CDS-CSO-PUB, a MUST to publicly share up-to-date information in human-readable and JSON formats. It enumerates sixteen items — FedRAMP ID, service model, deployment model, business category, UEI number, sales and security contacts, product website, logo, service description, the public service list, secure configuration guidance link, documentation overview, trust center landing page, next Ongoing Certification Report date, and current independent assessment service. None of them is cryptographic.

The rule links its schema, so the absence is checkable rather than argued. In fedramp-certification-package-overview-schema-2026-06-24.json — the public, machine-readable face of a certification, the file an agency GRC tool actually consumes — the substrings crypt, FIPS, CMVP, module, algorithm and validated each appear zero times.

In the Security Decision Record schema, which is not required to be public, there is exactly one cryptography-shaped property in the entire document. It is called encryption, it hangs off a ports-and-protocols row, it is typed string, and its description reads: "Encryption method used by the service (e.g., TLS, SSL, None)." No module, no certificate number, no validation status, no approved-mode flag. A free-text field whose own example list offers SSL, which the IETF formally deprecated in 2015.

This is the same shape as the Security Decision Record having no field for the assessor: the rules describe an obligation the machine-readable artifact has no slot for. The difference is that here the gap is load-bearing for a change the program is actively proposing. Remove MUST from Class D, and the thing that replaces it is a disclosure. Today that disclosure has no public field, no schema, no enumerated value, and no MUST behind it. Both commenters noticed independently, which is usually the sign that a comment period is working.

The certificate that expires without you touching anything

The assessor's first point is the one with a date on it, and it is the most immediately actionable thing in either thread:

FRD-CVM says "active validation," and every FIPS 140-2 certificate moved to the CMVP Historical list on September 21, 2026. Plenty of packages still cite 140-2 certificates for OS-level modules the CSP never touched. Read literally, those providers just went from CMVP-validated to non-validated without making a change.

The date is correct. NIST's CMVP page states that modules validated to FIPS 140-2 could be accepted "through September 21, 2026. After that time CMVP will place the FIPS 140-2 validated modules on the Historical list, allowing agencies to continue using these modules for existing systems only."

Now put that against the proposed text. FRD-CVM defines a CMVP-validated module as one with an active validation. CMU-CSO-TSC makes a move from a CMVP-validated module to a non-validated one a transformative change. Neither says whether "move" means an action the provider took or a status the certificate lost. Read strictly, a package citing a 140-2 certificate crossed that line on September 21 while the provider was doing nothing at all, and a transformative change is not a paperwork event — it is the category that triggers an in-depth reassessment.

The assessor's proposed fix is narrower and better than the problem: keep TSC for provider-initiated swaps, and handle certificate-status changes through a documentation-update window under CMU-CSO-CMD with a target date for moving to an active 140-3 module. Whether or not FedRAMP takes it, the underlying inventory question is yours either way. The distinction between we use a validated module and we use a module whose certificate is currently active is one most module inventories cannot answer, because they were built by recording a certificate number once.

The same comment lists what that inventory is missing, from the findings this assessor writes most often: certificates cited for modules not running in approved mode, modules outside the tested operating environment, and versions the certificate does not cover. Those are not exotic. They are what you get when a certificate number is copied into a document instead of checked against a running system.

What the hybrid note actually permits

The most recent comment in the side thread, posted today, is about a note rather than a rule:

The Notes in the rules are undefeated. My favorite is the one in CMU-CSO-TSC: "Adding a non-validated algorithm while a CMVP-validated module still protects federal customer data, such as hybrid implementation, is not such a change." Allows a CSP to add a PQC-approved algo. as an option to the algo that was validated as part of the module without going through a transformative.

That reading holds, and the hinge is a preposition. CMU-CSO-TSC's note draws the line between an algorithm used in place of a validated one, which is a transformative change, and a non-validated algorithm added while a CMVP-validated module still protects the data, which is not. Post-quantum deployments are overwhelmingly hybrid by design — a classical algorithm and a post-quantum one run together so that breaking the construction requires breaking both. The note means that shape of deployment does not drag you into a reassessment.

It is worth noticing what that unlocks in combination with the other RFC, because the two were written to fit together and neither says so loudly. RFC-0036 proposes CMU-CSO-PQS, a new Class D rule requiring providers to document the post-quantum status of digital key establishment and digital signatures protecting federal customer data — for each algorithm, whether it is post-quantum, part of a hybrid implementation, or neither, plus the target date to transition it. Its note says the rule is deliberately held out of RFC-0035 because it belongs to the Phase 4 pilot and the Consolidated Rules for 2027.

So RFC-0035 takes the brake off hybrid deployment, and RFC-0036 adds the odometer. We wrote in June about Executive Order 14412 and the cryptographic bill of materials — that the 2030 and 2031 deadlines were distant but the inventory work was not, because you cannot migrate cryptography you have never enumerated. CMU-CSO-PQS is that inventory, at per-algorithm granularity, with a date attached to each row, proposed as a Class D certification requirement. The EO set the destination. This is the first FedRAMP rule that asks you to publish your position on the route.

What the work is before November 17

For a provider at Class C or above, the practical list is short and none of it is contingent on the RFCs passing.

  • Take the module inventory down to the certificate, not the claim. CMU-CSO-CMD is already a MUST at every class and it is the rule RFC-0035 shifts weight onto. The version that survives an assessor is a certificate number, a module version, approved-mode status, the operating environment it was tested in, and the data flow it protects. "We use FIPS-validated crypto" is a sentence, not an artifact.
  • Record certificate status as a value that changes, not a fact you captured once. September 21 moved every 140-2 certificate to Historical with no action by anyone holding one. Whatever FedRAMP concludes about CMU-CSO-TSC, an inventory that cannot tell you which of your cited certificates are currently active cannot answer the question an agency will ask.
  • Decide now what your public answer is: all, some, or none. No rule requires you to publish it and no schema has a field for it. But the assessor asked for that exact field and the provider-side commenter asked for the same thing in looser words, so agencies will start asking for it in procurement whether or not it lands in CR26. Knowing your own answer is free. Discovering it during a negotiation is not.
  • If hybrid post-quantum is on your roadmap, write the per-algorithm table now. CMU-CSO-PQS as drafted wants the status and the target date for every key-establishment and signature algorithm you use. That table takes weeks to assemble honestly and an afternoon to maintain once it exists.
  • Comment in the RFC thread, not the side thread. The maintainer said it plainly: "don't forget to add public comment with feedback either way!" The side thread is where the questions got answered. It is not where the record is made.

This is the part where our own bias shows, so we will name it: the reason we build the audit engine to answer from live system state rather than to store finished documents is that every item above is a query, not a document. Whether a cited certificate is currently active has a true answer at this instant and a different true answer next quarter, and a package that captured the answer once is wrong by a schedule nobody controls. A certificate moving to Historical is a change in the world, not a change in your system, and a document set has no way to notice it.

The question worth carrying

The thing the two commenters were really defending is that a class letter used to be a compressed answer. "Class D" meant validated cryptography, and an agency or a downstream provider could read one letter and stop. RFC-0035 would take that compression away — correctly, probably, because the compression was hiding real cases where validated modules cost more and lagged behind on security updates, and because FedRAMP's classes were never meant to be a bigger control set at each rung so much as a different clock and a different depth of assurance.

But a compressed answer that goes away has to be replaced by an uncompressed one that is actually reachable. Right now the uncompressed answer lives in a package a provider MAY share, described by a schema with no word for cryptography in it.

So: if an agency had to determine today, from public data alone, whether your service protects their data with a module that holds an active validation — what would they find, and how long would it take them?

Reference