FedRAMP Consolidated Rules 2026: What “MUST” CSPs Do? What “SHOULD” I do?

FedRAMP Consolidated Rules 2026 are here and the FedRAMP framework will never be the same. Deadlines are approaching rapidly and Cloud Service Providers everywhere are asking, “What does this mean for me? What is required? What is optional?”

To answer these questions, having a good understanding of the new “Force” keywords is vital for all CSPs, Assessors, and Agencies: MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY. These “Force” keywords carry specific compliance implications and determine whether a requirement is mandatory, recommended, prohibited, or optional. And you shouldn’t assume that you understand the meaning in the context of FedRAMP just from the plain reading. Instead, go to the actual definitions.

MUST: Mandatory Compliance

When a FedRAMP rule includes the MUST Force designation, the requirement must be implemented. FedRAMP defines these rules as an “absolute requirement that must be met and documented, with failure potentially requiring corrective action or denial of initial or ongoing certification”.

From a practical standpoint:

• A MUST requirement represents a compliance obligation.
• Auditors and assessors will expect evidence demonstrating implementation, specifically automated evidence from CSPs pursuing 20x Certification.
• Failure to satisfy a MUST requirement can result in findings, corrective actions, or impacts to certification status.

MUST NOT: Explicitly Prohibited

If a rule states that an activity MUST NOT occur, FedRAMP is prohibiting that behavior. Specifically, FedRAMP defines these rules as “an absolute prohibition that must be observed and documented with the same potential consequences for failure”.

This is more than simply recommending against a practice. It establishes a hard boundary. Conduct that violates a MUST NOT rule is considered non-compliant, regardless of the rationale behind the decision.

A useful way to think about MUST NOT requirements is that they define unacceptable risk. If MUST requirements tell providers what they are obligated to do, MUST NOT requirements establish what they are forbidden from doing.

For compliance teams, MUST NOT statements should be translated directly into technical controls, administrative procedures, and governance policies.

SHOULD: Strongly Recommended

The keyword SHOULD often creates the most confusion.

A SHOULD requirement is not strictly mandatory, but it is STRONGLY recommended. FedRAMP expects stakeholders to follow the requirement unless there is a compelling, documented reason not to do so. FedRAMP specifically notes that “departures may have valid reasons, but parties must carefully weigh the implications and document their decisions.” Any decisions to NOT implement a SHOULD requirement must be documented and made clear to all relevant parties, including the FedRAMP PMO and Agency customers.

In practice:

• Compliance with SHOULD requirements is the expectation, with departures only in unavoidable circumstances.
• Organizations that choose an alternative approach should document the rationale.
• Assessors may scrutinize deviations to ensure equivalent outcomes are achieved.

SHOULD NOT: Strongly Discouraged

The inverse of SHOULD is SHOULD NOT. FedRAMP notes “the discouraged action may be justified in particular circumstances, but parties must carefully weigh the implications and document their decisions”.

FedRAMP uses SHOULD NOT to indicate practices that are strongly discouraged but not absolutely prohibited. A stakeholder could pursue such an action if there is sufficient justification, but doing so introduces additional burden of explanation and risk acceptance.

In many organizations, SHOULD NOT requirements become internal policy prohibitions because the cost of defending exceptions frequently outweighs any operational benefit.

Compliance leaders should view SHOULD NOT requirements as warning signs. While exceptions may be possible, they should be rare, deliberate, and documented.

MAY: Optional but Allowed

The keyword MAY is the easiest to understand.

A MAY statement signifies that FedRAMP permits an action but does not require it. The organization is free to decide whether the capability, process, or documentation provides value within its environment. The specific language from FedRAMP notes “the rule is optional, and parties should explain their decisions in security documentation”.

Examples within the Consolidated Rules include supplemental capabilities, optional documentation elements, and implementation approaches that FedRAMP allows but does not mandate.

Key characteristics of MAY requirements:

• They are optional.
• Choosing not to implement them is not a compliance finding.
• Implementing them can still provide operational, security, or customer benefits.

A MAY requirement should be evaluated based on risk, cost, and business value rather than compliance necessity.

A Simple Compliance Hierarchy

The easiest way to remember the force levels is to rank them by strength:

Relevant Links

• Changelog - FedRAMP Consolidated Rules for 2026
• 2026 - FedRAMP Consolidated Rules for 2026
• Ruleset Reference - FedRAMP Consolidated Rules for 2026
• Rev5 Deadlines - FedRAMP Consolidated Rules for 2026

Related Resources

• Review FedRAMP 20x and CR26 resources
• Explore FedRAMP 20x services
• Use the ATO Path Finder

Contact InfusionPoints at info@InfusionPoints.com or 336-990-0252.