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

FedRAMP ConMon Observation Period: No 60–90 Day Rule; Class C/D Floor Removed October 8

On October 15 a provider preparing a Rev5 Class D certification posted a question to FedRAMP's community discussions that almost everyone coming out of the old process has asked some version of:

Is an observation period required? Specifically, could our independent assessor verify that our continuous monitoring process is in place and the tools are configured correctly, instead of us showing evidence of it running over a set period? Assessors have told us a 60 to 90 day period is needed, but we haven't been able to find where that requirement is written.

Thirteen hours later a FedRAMP maintainer answered, and the answer was short:

If an assessor cites a rule or requirement to you but can't show you where that rule is written down officially then that might be a red flag. Historically there were "ghost rules" that assessors learned from bad experiences with FedRAMP and piled on, but we have been quite clear over the past two years that it doesn't work like that anymore. [...] There is no current FedRAMP rule requiring 90 days of conmon data to be reviewed during assessment, though it's a value add if you have it and can do it.

Three hours after that, a former 3PAO assessor added the history. The 60-to-90-day number, they explained, was not invented. It was a consequence of one of six federal mandates that used to be enumerated mostly in the Readiness Assessment Report: can the CSP consistently remediate vulnerabilities within 30/90/180 days?

In order to determine if someone is consistently remediating vulnerabilities, you need enough of a history to show that any high vulns were addressed in a timely fashion. That's where the "we need 60-90 days of conmon data" came from. [...] Regardless, one cannot evaluate this requirement as a simple point in time check; it de facto needs history.

Both of them are right, and the thread stops one step short of the thing a provider actually needs to know. The rule is gone — but it was still in force seven days before the question was posted, and what replaced it is specific enough to plan against.

The word is not in the rules, with one exception worth saving for the end

Start with the cheap check, because it is the one the asker was trying to run. The Consolidated Rules for 2026 are published as a single machine-readable datafile, currently version 2026.10.13.01, about 586 KB of JSON covering every definition, requirement, recommendation, and Key Security Indicator. You can grep it.

The word "observation" appears exactly once in the entire corpus, and not in any rule. lookback is absent, and so is every phrasing of the old vulnerability mandate's numbers — "90 days," "60 days," "180 days" return nothing. Across all nineteen ruleset reference pages on fedramp.gov, "observation" returns nothing at all.

That is the maintainer's answer, confirmed from the primary artifact rather than taken on authority. It is also less interesting than the version history.

There was an observation floor, and it was longer than the one the assessors quoted

Writing about who populates the Security Decision Record two days ago, we noted in passing that the October 8 release removed a rule called FRC-CSX-MOT as "duplicative" with SDR-CSX-KMT. We did not say what FRC-CSX-MOT said. Here it is, from the commit that deleted it:

FRC-CSX-MOT (Metrics Over Time for Key Security Indicators)

Class A: Providers seeking 20x Class A Certification MAY supply historical metrics for Key Security Indicators. Class B: Providers seeking 20x Class B Certification SHOULD supply historical metrics for Key Security Indicators. Class C: Providers seeking 20x Class C Certification MUST supply historical metrics including status from persistent validation over at least the past 6 months for all Key Security Indicators. Class D: Providers seeking 20x Class D Certification MUST provide historical metrics including status from persistent validation over at least the past 18 months for all Key Security Indicators.

So FedRAMP did have an observation period, written down, with a force word and a floor — and the floor at the top class was eighteen months, not ninety days. It governed obtaining a certification rather than maintaining one, which is the phase where an observation period actually bites. It survived from the June 24 launch until October 8, 2026, seven days before the question was posted.

What replaced it is not the same requirement with a tidier home. SDR-CSX-KMT asks a Class C provider for a summary of each metric over the past 30 days, a summary of each metric "up to the past year (where available)," and all daily metric data "up to the past year (where available)." Read the prepositions: MOT said over at least the past 6 months, a floor. KMT says up to the past year, where available, which is a ceiling with an escape clause attached. The two rules cover the same subject matter. They do not impose the same obligation, and the one that imposed a minimum is the one that was deleted.

The same commit moved MOT's note onto KMT, which is how the carve-out the asker was hoping for ended up in the current rules:

Note: For initial FedRAMP Certification, providers will need to have mechanisms in place and agree to meet this requirement in the event the cloud service has not been operating with related metrics available for the required period prior to applying for initial certification.

Mechanisms in place, plus an agreement to meet the requirement going forward. That is the answer to "could our assessor verify that the process is in place instead of us showing it running for a set period," and it is written into the rule that comes closest to naming a period.

Two things about how that landed are worth noticing. The site changelog for release 2026.10.08.01 opens with "This update does not make any significant changes; typos and convenience only," and its entry for the change reads "Updated SDR-CSX-KMT to change from MUST to SHOULD for Class B and clarify that persistent validation status is one of the metrics to include." The added note is not mentioned. Only the per-rule changelog on the Security Decision Record page records it, in two words: "added note." If you track rule changes from the release notes, the one sentence in CR26 that speaks directly to initial-certification history is invisible to you.

And none of it binds the person who asked. FRC-CSX-MOT and SDR-CSX-KMT are both scoped Type: 20x in the datafile. The asker is on the Rev5 track, where the Security Decision Record's Rev5 subset contains a single rule, SDR-CSF-CTF, which asks for a summary per control covering parameter values, implementation status, the mechanisms that address it, the verification and validation in place, the independent verification and validation, any provider response to those, and control-specific artifacts. No metric history and no window — the historical-metrics floor that existed until October 8 was never theirs to miss.

Every clock CR26 does name runs the other direction

This is the pattern that makes the absence feel deliberate rather than accidental. The rules are full of durations. They are almost all limits on how stale something may be, not minimums on how long you must have been running.

  • FRC-APP-FCP: the initial Certification Package must show current status as verified and validated by the provider within the previous 7 days.
  • FRC-APP-FIA: at every class, the initial independent assessment must have been completed within the previous 3 months.
  • FRC-APP-USA: a stale assessment may be freshened by a delta review rather than a re-assessment, unless it is more than 9 months old.
  • VER-TFR-MRH asks providers to publish "all recent historical vulnerability detection and response activity" in JSON — and specifies the update cadence (every month at Class A and B, every 14 days at Class C, every 7 days at Class D) while leaving "recent" entirely undefined. "Persistently" and "Regularly" are defined terms in CR26. "Recent" is not.

Since October 8 there is exactly one rule left in the Consolidated Rules that mandates a minimum historical window, and it is CDS-CSO-AVR: a web service showing current and historical availability of core services over at least the past 30 days, in human-readable and machine-readable form, that stays up when the service doesn't. The lone surviving lookback floor in the program is a status page.

Why the assessor's instinct is still correct

The former 3PAO's closing caution is the part of the thread that will age best:

Just a word of caution that while something may not be a firm black letter rule, sometimes a necessary consequence of evaluating or satisfying that rule (i.e. vulnerability history in this case) has some required-but-unwritten aspect of it.

The Independent Verification and Validation ruleset backs this, and it does so by splitting the asker's question in half. Two rules, both MUST, both applying to 20x and Rev5 alike:

IVV-CSO-SEI (Supply Evidence of Implementation) requires evidence that the documented measures are implemented — "this evidence is the result of verification." Its note: if the documentation says firewall rules block traffic, show that the firewall rules are in place, "preferably by allowing them to see how firewall configurations are deployed from a source of truth."

IVV-CSO-SEE (Supply Evidence of Effectiveness) requires evidence that those measures are effective — "this evidence is the result of validation." Its note continues the same example: after verifying the firewall configuration, "the provider would validate that traffic is actually being blocked and supply evidence of that validation to assessors (such as by allowing them to see metrics on the traffic that is blocked vs not)."

So: is the tool configured correctly is verification, and a configuration read from a source of truth satisfies it at a point in time. Is the tool working is validation, it is a separate MUST, and the example FedRAMP chose to illustrate it is a metric — traffic blocked versus not — which is a quantity you can only have by having been running. The assessor-side mirrors, IVV-IAS-VIM and IVV-IAS-VEF, both carry the same instruction: "This requires reviewing the actual measures themselves at a technical level, such as reviewing underlying code as appropriate; don't simply review documentation or screenshots."

No duration is named because the duration was always a proxy. What the program wants is objective evidence that the control produces its intended effect, and the honest amount of history for that is however much makes the effect visible. IVV-CSO-USR says providers MAY use representative samples during verification and validation, with IVV-CSO-DUS requiring that the sampling be documented and explained — and the note on USR is the whole thesis of 20x in one sentence: "Many modern cloud services using effective automation do not need to use representative sampling and are capable of persistently verifying and validating the majority of their security measures automatically."

Sampling windows are what you negotiate when the evidence has to be assembled. If the system answers the question directly, the window stops being a variable.

The document the ghost rule lived in is being switched off

One more piece of context the thread gestures at without closing. The former 3PAO noted that the six mandates were "published primarily in the RAR," and that it was odd the Readiness Assessment Report was the main place anyone could read them.

The RAR is on its way out. FRC-CSF-RDY (FedRAMP Ready Conversion) requires providers with Rev5 Ready status to convert to a FedRAMP Certification by whichever is later: the expiration of their annual assessment, or November 17, 2026. Legacy FedRAMP Ready status is removed entirely on December 31, 2027, and services that do not convert get renamed Legacy FedRAMP Ready and retired from the program. The one place the RAR still appears by name is FRC-CLA-EAM, which treats FedRAMP Ready as an alternative security framework for Class A purposes and asks for the "Readiness Assessment Report, Security Assessment Plan, and any other materials required by FedRAMP" as external assessment materials. Being an input to someone else's determination is a different status from being the place a requirement is defined.

Meanwhile the ruleset you would expect to own an observation period doesn't have a place to put one. Collaborative Continuous Monitoring has three subsets: Agency Guidance, Ongoing Certification Reports, Quarterly Reviews. Its central obligation, CCM-OCR-AVL, is an Ongoing Certification Report every 3 months "covering the entire period since the previous summary." CR26's ConMon rules are structurally about what happens after you are certified, and for a Rev5 provider they do not even bind for obtaining initial certification until January 1, 2027 — optional adoption has been open since July 4, 2026. Which is precisely the overlap window where a requirement nobody can cite is easiest to assert.

What the work actually is before your assessment

If you are the provider in that thread, the practical version is narrower than "find out whether we need 90 days."

  • Ask the assessor which rule, and expect a rule ID. CR26 gives every requirement a trigram, a force word, a class scope, and a per-rule changelog. "Where is this written" is now a question with a URL for an answer, and a request for one is not an argument.
  • Separate your verification evidence from your validation evidence before anyone asks. IVV-CSO-SEI and IVV-CSO-SEE are different MUSTs with different evidence shapes, and most pre-assessment packages are heavy on the first and thin on the second. The gap is usually not monitoring coverage, it is that nobody kept the output.
  • Read the per-rule changelogs on the rules you depend on, not the release notes. The release that deleted a MUST with an eighteen-month floor was published as typos and convenience, and the sentence that helps you most was logged as "added note."
  • If your history is genuinely short, say so and show the mechanism. SDR-CSX-KMT's note anticipates exactly that case for 20x initial certification: mechanisms in place, and an agreement to meet the requirement once the data exists. That is a position you can take in writing on day one.

The reason we build the audit engine to render evidence from live system state rather than to store finished documents is the same reason this question is hard to answer from a document set. Persistent validation produces history as a byproduct of running — you either have the six months because the system has been answering the question all along, or you have a plan to have it, and those are both better answers than a folder of screenshots dated the week before the assessment. It also means a question nobody anticipated is a new query instead of a new project, which is the property that made the sampling conversation disappear for us.

The question worth carrying

Here is the exception promised at the top. The single appearance of the word "observation" in the whole of the Consolidated Rules for 2026 is inside FRD-DTM, the definition of Deterministic Telemetry:

Verifiable data collected directly from an authoritative source that represents a factual and reproducible observation of the attributes of a system such as the system's state, configuration, or behavior.

An observation of state, not a period of time. It is a definition no rule currently cites, which makes it a fair guess at where the program is heading rather than a requirement you have to meet. The old mandate asked whether you had been consistent for long enough to be trusted. This one asks whether your answer is reproducible.

So if the 60-to-90-day window is a proxy for consistency, and the window is gone: what would an assessor have to run against your system, today, to see consistency directly?

Reference