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

FedRAMP RFC-0036: Class D Requires Six Months at Class C First

On October 15 FedRAMP opened RFC-0036, the full proposed requirements for the FedRAMP 20x Class D Cloud-Hosted Pilot. Comment closes November 19. The RFC's own summary of itself is accurate, which is worth saying because it is checkable: two new definitions, edits across six rulesets, ten new Key Security Indicators. Count them in the thread and the arithmetic holds.

It opens with an unusually direct piece of expectation-setting:

Additional rules and Key Security Indicators may be added during or after the Phase 4 pilot, and the existing rules and indicators are likely to change based on direct feedback during the pilot. FedRAMP understands that it would be convenient to know exactly what the rules are likely to be a year in advance, but that is not a realistic approach to developing a new process that is responsive to real world impacts.

So the rules in RFC-0036 are a draft of a draft. The thing in it that is already firm, and that decides whether any of the rest is your problem, is a sequencing rule — and it is the one that got the least attention.

The requirement that isn't about security at all

FRC-CLD-PCD, Progressive Certification to Class D:

Providers seeking a FedRAMP 20x Class D Certification MUST maintain a 20x Class C Certification without corrective action for at least 6 months OR receive a special exemption from FedRAMP to apply directly for a 20x Class D Certification due to an urgent critical need; such exemptions may include cloud services prioritized by the FedRAMP Board and limited pilots.

For the pilot itself the dwell time is waived and the prerequisite is not:

For the purposes of the FedRAMP 20x Phase 4 Pilot, a full non-pilot 20x Class C Certification is necessary to qualify for participation but six months without corrective action is not required.

Pair that with the calendar FedRAMP set in RFC-0033, which closed on October 9, and the practical picture resolves. The single stated requirement to apply for the Phase 4 pilot is a CR26-compliant 20x Class C Certification received before December 1, 2026. The application window is December 1 through 4. Participation is capped at a firm maximum of ten. Providers who were in the Phase 2 pilot, including the AI-prioritized ones, get no credit for it — the same Class C certification by the same date applies to them too.

Class C submissions opened on August 31. That gives the eligible population a three-month window that is already two-thirds spent, and FedRAMP added a human step for anyone cutting it close: if you apply for Class C before November 13 and intend to join the pilot, email the FedRAMP Director a notice of intent once your Class C application is in.

The rest of the pilot calendar, from RFC-0033: final Class D pilot requirements published November 18, initial discussions December 7 through 18, a mandatory draft package on February 17, 2027, and the final pilot package due March 17, 2027.

Two of those dates are worth holding next to each other. The final requirements land on November 18. Comment on RFC-0036 closes November 19. FedRAMP is explicit about why the pipeline is compressed — RFC-0033 closed in thirty days "due to the urgent need to finalize and open the FedRAMP 20x Phase 4 pilot" — but it does mean the comment window is a sprint, not a deliberation, and the people best placed to run it are the handful already holding a Class C certification.

Until now, a class was a declaration

This is the part that changes the shape of the program rather than the volume of work in it.

Nothing in the Consolidated Rules for 2026 as published conditions one Certification Class on holding another. Moving between classes is handled as a change, not an application: FRD-CCL defines a Certification Class Change as "a type of significant change that is likely to change the FedRAMP Certification class for the entire cloud service offering (e.g. from Class B to Class C or from Class D to Class C)." Note the direction of the second example. The current rules treat class as a property you notify FedRAMP about, revisable in either direction, and the phrase "without corrective action" does not appear anywhere in the datafile.

The Certification ruleset does carry one class-specific subset today — FRC-CLA, six rules for Class A — but those describe what Class A accepts as evidence, including assessments from approved alternative frameworks. They are not a gate on anything below.

FRC-CLD-PCD would be the first rule in FedRAMP's current corpus that makes a class something you queue for, and FedRAMP explains the reasoning in the rule's own notes rather than leaving it to be inferred:

FedRAMP is a government program that is not funded by fees or services. Program certification for Class D is very complicated and requires considerable investment and commitment from FedRAMP - traditional sponsorship for Class D (High) often took many years. This breaks up investment and review by expecting a cloud service to demonstrate a progressive level of assurance over time instead of starting at the highest level.

That is a staffing argument stated plainly, and it has a consequence for providers already carrying a Rev5 High authorization: existing Rev5 Class D holders keep it, but "transitions from Rev5 Class D will still be expected to move through 20x Class C first." If you are High today and want to be 20x Class D, the route goes down a level before it goes up.

Two requirements got smaller in six days

RFC-0036 flags its own lineage — the Certification section "includes proposed formal language for some rules that were mentioned in RFC-0033, and the proposed language was adjusted based on feedback from that RFC." Reading the two documents side by side shows what the adjustment was, and in both cases the formal rule is looser than the preview.

On infrastructure, RFC-0033 said: "Cloud-hosted or hybrid-hosted Class D services must be deployed on a Class D Certified IaaS/PaaS." Six days later, FRC-CLD-CCH:

Providers seeking a FedRAMP 20x Class D Certification MUST be deployed on a FedRAMP Class C or FedRAMP Class D Certified Infrastructure-as-a-Service/Platform-as-a-Service offering; OR meet all applicable FedRAMP 20x Class D Self-Hosted or Hybrid-Hosted rules.

Class C infrastructure now qualifies. The alternative branch is honest about being empty: the rule's note says the Self-Hosted and Hybrid-Hosted rules "do not exist yet; they will be developed during Phase 4 separately," which is Tracks 2 and 3 of the same phase.

On third-party services, RFC-0033 said Class D services "must only use Class B, C, or D Certified Third-Party Information Resources in their Minimum Assessment Scope." The formal version, FRC-CLD-CTP, is a SHOULD — providers "SHOULD limit the likely handling of federal customer data" to resources inside a certified offering. A MUST NOT on your dependency graph became a recommendation about where customer data is likely to be handled, which is a materially different scoping exercise.

FRC-CLD-CTP also widens the acceptable set to "a FedRAMP Class B, Class C, Class D, or Class G Certified offering." Class G does not exist. FRD-CCL defines the Certification Class as increasing "from minimal assurance at Class A to significant assurance at Class D; currently available categories are Class A, B, C, or D," the string "Class G" appears nowhere in the 2026 datafile or the definitions, and RFC-0032 Offerings By Government — the closest candidate, and still unresolved since it closed on September 8 — maps agency-operated offerings onto Classes B, C, and D rather than proposing a new letter. A forward reference to an unannounced class is a small thing in a draft, but it is the kind of small thing worth asking about while the comment window is open.

The first substantive comment in the thread, posted the next day by an assessor, goes after the same rule from the opposite direction. It reads the Class C hosting allowance as a good practical move and then argues the obvious gap: "Class D assurance can't simply be inherited from a Class C platform, so the provider has to make up the gap at its own layer. FRC-CLD-CCH should say what that means." The suggested floor is customer-held keys outside the platform, plaintext never reaching the platform's managed services, and independent detection of control-plane actions. That is one assessor's reading rather than a rule, which is exactly the distinction the comment itself asks FedRAMP to settle — along with whether FRC-CLD-CCH reaches Rev5 Class D offerings or only 20x.

What you would actually have to build

Set the structural rules aside and the engineering asks in RFC-0036 are specific enough to estimate against.

Metric resolution replaces metric duration. SDR-CSX-KMT's Class D row today is a placeholder — providers "MUST significantly supersede the minimum requirements for lower Classes, with specifics to be set during the 20x Phase 4 Pilot." RFC-0036 fills it in: the 30-day summary and the year summary that Class C already owes, plus "metric data (including status of persistent validation) every 4 hours up to the past year (where available)." Class C owes daily data points over the same period. Six times the resolution, roughly 2,190 observations per indicator per year instead of 365, and it arrives nine days after FedRAMP deleted the only rule that set an evidence duration floor — the 18-month Class D lookback in FRC-CSX-MOT, removed on October 8. The program is not asking for a longer history. It is asking for a denser one.

The certification package becomes a service. CDS-CSX-API is new: Class D providers "MUST responsibly supply all machine-readable parts of the FedRAMP Certification Package via web-compatible Application Programming Interface (API)." Certification Data Sharing today has no 20x-specific subset at all, and its existing obligations are satisfiable by publishing files — CDS-CSO-PUB asks providers to "publicly share up-to-date information about the cloud service offering in both human-readable and JSON formats." An endpoint is a different artifact from a file. Uptime, authentication, versioning, and rate limits all become part of your compliance surface, and the 4-hour metric stream is explicitly meant to ride on it.

One clock does not speed up. VDR-TFR-MVX currently has no Class D row — it stops at Class C's 3-day cadence for verifying machine-based resources. RFC-0036 adds Class D at 3 days and notes that this "matches the current Class C expectation for this rule." Where the step from Class B to Class C was almost entirely cadence, this one is not, which is a useful signal about where Class D's difficulty is meant to sit.

Read both force words in VER-TFR-MRH. The RFC's note says it "proposes a change from SHOULD to a MUST for 20x Class D," and the sentence contains two. Making historical vulnerability activity available for automated retrieval becomes a MUST; updating it "at least once every 7 days" stays a SHOULD. The artifact is mandatory, the freshness is not.

Four automated methods per indicator is already live. RFC-0036's Key Security Indicator preamble says Class D providers "will need to use at least 4 different automated methods to track Key Security Indicator status." That is FRC-CSX-VVK as published in June, not a proposal — Class B SHOULD implement at least one automated method per indicator, Class C MUST implement at least two, Class D MUST implement at least four. Worth knowing before you treat it as a new line item.

Ten indicators, forty-six existing. The additions are KSI-CMT-TNP, KSI-IAM-MST, KSI-IAM-MPI, KSI-RPL-MCA, KSI-SVC-IED, KSI-SVC-UAS, KSI-PIY-DFC, KSI-PIY-RFP, KSI-PIY-RFB, and KSI-PIY-MFD. The last four are the Foreign Ownership, Control, or Influence set, and they land inside the existing Policy and Inventory family rather than the "new KSI theme" RFC-0033 described — taking KSI-PIY from five indicators to nine and making FOCI the plurality of a family that currently covers inventories, executive support, security investment, and the SDLC. "FOCI" appears zero times in the 2026 datafile today.

FedRAMP's half of FOCI is a MUST NOT on itself. FRC-FRA-FOD says FedRAMP "MUST NOT request details of the foreign ownership, control, or influence of providers and will not make determinations about whether a provider's foreign ownership, control, or influence is acceptable." The program verifies that you track FOCI; agencies decide whether yours is acceptable; FedRAMP declines to hold the sensitive material at all. The four indicators carry matching notes asking that sensitive details stay out of metrics.

Two rules nobody tracking the obvious RFC will see. CMU-CSO-PQS requires Class D providers to document the post-quantum status of key establishment and digital signatures, including a transition target date where applicable, and its note says plainly that it is "not included in RFC-0035 Cryptographic Module Use Rules Updates" — the cryptography RFC that opened the day before. If you are watching RFC-0035 for crypto changes, the post-quantum ask is in the other document. And VER-EVA-IOC asks Class D providers to judge when exploitation likelihood is high enough "to initiate forensic activities such as searching for indicators of compromise; then do so" — an entirely new rule, SHOULD for now, that the note says may be ported to Rev5 in CR27. Neither "forensic" nor "indicators of compromise" appears in the current corpus.

What this is like to build

Most of RFC-0036 is a data-plumbing problem wearing a policy hat. A year of four-hourly indicator status, served from an API that agencies can poll, with persistent validation state attached to each point, is not a document you write in the month before an assessment — it is a system you have been running long enough to have the history. That is the same reason the six-month dwell time at Class C exists. The evidence has to accumulate somewhere, and the only way to have a year of it is to have been collecting for a year.

It is also why the ordering rule, not the indicator list, is the thing to act on this week. Everything in the requirements section will move during the pilot, by FedRAMP's own statement. December 1 will not.

The pattern underneath it is the one that keeps showing up in this series from completely different directions: the program keeps converting things that used to be narrated into things that have to be queryable. A KEV entry asks whether you know what you run. RFC-0036 asks whether an agency can ask your system that question directly, every four hours, for a year.

So the question to carry into the November 18 publication: if the evidence has to be dense rather than long, what in your stack is currently producing a number only when someone asks for it?

Reference