Decoding RFC 2119: The Weight of “SHOULD” in FedRAMP 20x
There is a specific moment, if you spend enough time reading FedRAMP documentation, where a requirement stops you cold. You hit a line that uses the word “SHOULD” and your brain does what brains do. It translates. “Oh, that one’s optional. We can skip it.” Then you keep reading.
That translation is wrong, and under FedRAMP 20x it is expensive.
The FedRAMP Consolidated Rules for 2026 (CR26) spell this out directly in the Force of the Rule section of Using the Consolidated Rules. FedRAMP bases its capitalized key words (MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY) on IETF RFC 2119. So far, nothing surprising. Most federal cybersecurity documents inherit RFC 2119 without comment. But then FedRAMP defines what each word demands of you, and for SHOULD it draws a very bright line.
The use of “SHOULD” does not just make something optional for fun. There must be a valid reason not to implement a recommendation that has been carefully weighed. For FedRAMP 20x, cloud service providers must document this reasoning in their certification/authorization package. Providers who do not implement recommendations may also be assessed as being less secure than those who do, and may be less likely to be reused by federal agencies.
Read that twice. Because if you are a CSP chasing a 20x Validated designation, that paragraph is a compliance obligation, a risk statement, and a competitive warning all stacked into one.
What RFC 2119 Actually Says
Before getting into why these matters for 20x specifically, it is worth going back to the source.
RFC 2119 was published by Scott Bradner at Harvard in March 1997 as Best Current Practice 14 for the IETF. The abstract is short. It defines how a handful of capitalized words should be interpreted in standards-track documents so that implementers, auditors, and authors are all reading from the same sheet music.
Here is what RFC 2119 actually says about SHOULD:
SHOULD. This word, or the adjective “RECOMMENDED”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Notice what that definition does and does not say. It does not say SHOULD is optional. It does not say you can skip it if you feel like it, or if implementing it is inconvenient, or if the sprint is already overloaded. It says the full implications of deviating from the recommendation must be understood and carefully weighed.
RFC 2119 even has a Security Considerations section, which is unusual for a document about grammar. Bradner wrote that the effects on security of not implementing a MUST or SHOULD, or of doing something a specification says MUST NOT or SHOULD NOT, may be very subtle, and that document authors should take the time to elaborate those implications because most implementers will not have had the benefit of the experience and discussion that produced the specification.
In other words, the RFC itself knows that people will try to read SHOULD as MAY. It was already anticipating this in 1997.
What FedRAMP 20x Layered On Top
FedRAMP did not invent new semantics for SHOULD. It adopted RFC 2119 by reference, the same way nearly every RFC-family document does. What FedRAMP did do was add a program-specific obligation about how a provider proves they did the “carefully weighed” part.
Under legacy Rev5, that weighing happened mostly through narrative. A CSP would explain their approach in the System Security Plan, describe compensating controls, walk through risk treatment, and the Independent Assessor (formerly 3PAO) would assess whether the explanation held up. It was documentation-heavy, interpretation-heavy, and often inconsistent in how deeply SHOULDs were examined.
20x is a different animal. The program is built around machine-readable certification data, Key Security Indicators, and persistent validation. FedRAMP is explicit that the goal is to produce “native machine-generated deterministic telemetry that is persistently distributed via machine-readable artifacts,” per RFC-0024. When the evidence model shifts from narrative SSPs to structured data and continuous validation, the treatment of SHOULD has to shift too.
So FedRAMP did two things with the 20x SHOULD callout that are worth separating:
First, they made the reasoning requirement explicit. If you choose not to implement a recommendation, your certification package must document the valid reason, and that reason must reflect that the full implications were understood and weighed. This is not a vibe. It is a documented, reviewable artifact that an assessor and FedRAMP will read.
Second, they introduced a competitive and reuse consequence. Providers who skip recommendations may be assessed as less secure and may be less likely to be reused by federal agencies. In a program where reuse across agencies is a primary design goal, and where agencies are sorting through a growing FedRAMP Marketplace to pick services, being tagged as “less secure than the provider next door who implemented the recommendation” is not a neutral outcome.
This matters even more in the context of the broader 20x certification framework. Under CR26, “FedRAMP Certified” is the program term for what the statute calls FedRAMP authorized, and Certification Classes A through D describe the category of assurance a cloud service offering supplies, from minimal at Class A to significant at Class D. A Class tells an agency how much assurance the package supplies. It is not a head-to-head security ranking, so the specific judgment about whether a provider is “more secure” or “less secure” relative to peers is left to agencies reading the package. When a provider has a stack of undocumented SHOULD deviations, agencies will notice. They are supposed to.
Why This Trips Up Practitioners
I have watched smart security people and smart GRC leads read SHOULD and round it down to optional. It is not a character flaw. It is how the word behaves in everyday English. When your spouse says you should take the trash out, there is a tone, a social pressure, a relationship consequence, but there is not a written artifact where you justify your decision not to.
RFC 2119 is intentionally borrowing the word and loading it with a much heavier meaning. That is useful for precision, but it also creates a gap between what the word feels like and what the word means inside an authorization package. In FedRAMP 20x, that gap is where packages get weaker than they should be.
The other trip wire is familiarity with legacy Rev5 habits. Under legacy Rev5, a CSP might have dealt with SHOULDs informally, folded them into narrative, and moved on. The 20x or modern Rev 5 approach does not leave that room. The CR26 Independent Verification and Validation (IVV) rules expects providers to define security objectives in code, validate them continuously, and have those processes assessed directly by a recognized Independent Assessor or by FedRAMP. Recommendations that are skipped without documented reasoning sit awkwardly in that model. They are not validated. They are not explained. They just sit there, visible to anyone reviewing the package.
What “Documented Reasoning” Should Actually Look Like
FedRAMP does not dictate how to write up a SHOULD deviation, and that is intentional. Under CR26 the rationale belongs in your Security Decision Record, which replaces the traditional SSP, but the rules’ “It’s Not a Trap!” section makes clear FedRAMP is deliberately avoiding opinionated implementations. Providers are expected to bring their own approaches, as long as they apply them consistently and can explain them. But RFC 2119’s own language gives you the shape of what a defensible justification looks like.
The RFC says there must exist valid reasons in particular circumstances, and that the full implications must be understood and carefully weighed. Translating that into a certification package, a strong SHOULD justification includes at least these elements:
A specific statement of the recommendation not being implemented, quoted or cited precisely from the relevant FedRAMP 20x document. Vague references to “the recommendation around logging” will not hold up. Point to the exact requirement ID.
The valid reason. Not “it was too expensive” in isolation, but the circumstance that makes the recommendation inappropriate or unnecessary for this specific service. Architectural constraints, service model limitations, superseded by a stronger control, incompatible with the platform, and so on.
The analysis of implications. What does skipping this recommendation mean for the security posture of the offering? What threats does it leave unaddressed or partially addressed? This is the “carefully weighed” part that RFC 2119 demands.
The compensating approach, if any. If you are not implementing the recommendation, what are you doing instead, and why does that alternative reach a comparable or better security outcome?
Evidence that someone with authority reviewed and accepted this. A timestamp, an owner, a decision record. Persistent validation thinking suggests this should live in a system that can regenerate the record on demand, not a footnote in a Word document that nobody will reread.
None of this is novel if you have worked in risk management. What is different is that FedRAMP 20x expects it to be in the certification package, not discovered in a follow-up conversation with an Independent Assessor.
The Reuse Angle
The part of the FedRAMP 20x SHOULD callout that gets the least attention, and maybe deserves the most, is the reuse consequence. FedRAMP explicitly warns that providers who do not implement recommendations may be less likely to be reused by federal agencies.
Reuse is the whole point of FedRAMP. A CSP invests enormous resources to get authorized so that agency after agency can leverage the package. If your package shows up in an agency’s review queue next to a competitor’s package, and yours has eight undocumented SHOULD deviations while theirs has zero, you are not competing on equal ground. An agency authorizing official looking at both is going to ask the obvious question.
This is the competitive dynamic FedRAMP is building into 20x on purpose. The program wants to pull the marketplace toward implementing recommendations by default and documenting exceptions honestly when they exist. Providers who treat SHOULDs as optional noise are opting into a weaker position in that marketplace.
The Practical Takeaway
If you are building or maintaining a FedRAMP 20x package right now, or transitioning from legacy Rev 5 to modern Rev 5 under CR26 here is the short version.
Every SHOULD in every applicable FedRAMP 20x document is a decision point. You either implement it or you document why you did not, and the documentation has to show that you understood the implications. Treating SHOULD as MAY is a real assessment risk and a real marketplace risk.
Do an inventory. Go through the Key Security Indicators and the underlying standards that apply to your offering. Pull every SHOULD and every RECOMMENDED. Mark each one as implemented, partially implemented with justification, or not implemented with justification. The ones in the second and third buckets are the ones that need a paper trail inside your certification package.
Build the reasoning into your persistent validation process rather than bolting it on at the end. 20x is trying to get providers away from tacking GRC onto the finish line. The same logic applies to how you handle recommendations. If your engineering teams know early that a recommendation is being skipped and why, the justification is a natural byproduct of the decision rather than a last-minute documentation sprint.
Assume an agency reviewer will read it. Every SHOULD deviation in your package is a sentence an agency authorizing official might weigh when deciding whether to leverage your FedRAMP Certification and issue an authorization to operate. Write it so that reviewer walks away understanding the tradeoff and respecting the call.
Closing Thought
RFC 2119 turns 29 years old next year. It has outlasted most of the protocols it was originally written to support. Part of the reason is that the distinction between MUST, SHOULD, and MAY turns out to be useful wherever technical people have to make collective decisions and be clear about the force behind them.
FedRAMP 20x leans on that clarity and then adds an explicit expectation that providers will honor the weight of SHOULD by writing down their reasoning when they deviate. It is a small paragraph on a documentation page, and it is one of the more consequential pieces of the 20x posture.
Treat SHOULD like a recommendation that was carefully weighed by the people who wrote the standard, because that is exactly what it is. Your certification package, your assessor, and the agencies considering your service will all read it the way RFC 2119 intended.