In January, FedRAMP released six interrelated Requests for Comment (RFCs) at once. This unusually large update signals a major shift in how cloud security authorizations will work going forward. Together, these RFCs represent what many in the industry see as the completion of the vision laid out in the FedRAMP legislation and related OMB guidance. Rather than incremental changes, this package introduces structural updates to cost reporting, authorization terminology, marketplace operations, validation pathways, and automation. Most importantly, these RFCs are designed to be read as a set. Reviewing them in isolation can be misleading, since terminology and requirements often depend on context from the others. If you are a cloud service provider (CSP), assessor, advisor, or federal stakeholder, now is the time to engage. Public feedback submitted through the FedRAMP GitHub discussions is the primary mechanism for shaping the final outcome.

Key Timeline

• RFC Release: January 13
• Public Comment Deadlines: First group closes February 19, second group closes February 26
• Some policy impacts may begin as early as March

Stakeholders should review and submit feedback before these deadlines.

Why Six RFCs at Once?

FedRAMP originally considered releasing these changes in phases. However, because the updates are tightly connected, the Program Management Office (PMO) opted to publish them together. This approach reflects a strategic reset. After these changes are implemented, future updates are expected to be more incremental rather than foundational.

RFC 19: Reporting Assessment Costs

Purpose

RFC 19 requires CSPs to report detailed information about the cost of FedRAMP assessments. This supports Congressional and OMB directives to improve transparency and evaluate the financial burden of authorization.

Key Points

• CSPs may be required to report historical assessment costs, not just future ones
• Penalties for noncompliance can include denial of authorization, resubmission delays, or revocation pathways
• Separate requirements exist for Rev 5 and 20x pathways
• Cost data may be reported as an appendix to the Security Assessment Report (SAR)

Consideration

One open question is how significant change assessments fit into this framework. These activities can represent major ongoing costs and may warrant clearer treatment.

RFC 20: Authorization Designations

Purpose

RFC 20 restructures FedRAMP terminology and introduces a numbered level system, replacing Low, Moderate, and High. It also distinguishes between Certified (primarily associated with Rev 5) and Validated (associated with 20x).

Why This Matters

Historically, the term authorization has caused confusion. By law, only agencies can grant an Authority to Operate (ATO). FedRAMP does not accept risk on their behalf. The new terminology reinforces this distinction and reduces misunderstanding.

Potential Challenge

Some stakeholders may interpret certified and validated as implying different levels of quality or rigor. Clear communication will be essential to prevent misperceptions.

Lifecycle Improvements

RFC 20 also improves visibility into where providers are in the authorization lifecycle, helping agencies and partners better understand readiness and intent.

RFC 21: Expanding the FedRAMP Marketplace

Purpose

This RFC aims to transform the FedRAMP Marketplace into a more functional and transparent platform.

Major Enhancements

• Expanded data on cloud service offerings
• Introduction of a clearer preparation stage
• Increased visibility into assessor and advisor services
• New pricing structure disclosure requirements

Strategic Impact

The preparation stage allows CSPs to appear on the Marketplace earlier, helping address the long-standing challenge of needing sponsorship before gaining traction. This change can accelerate engagement with agencies and reduce upfront risk.

Pricing Transparency

While transparency benefits buyers, defining standardized pricing structures will be challenging. Many services vary widely based on system scope and complexity.

Trust Centers

The RFC aligns with Authorization Data Sharing initiatives, requiring CSPs to publish Trust Centers that display validation and compliance status.

RFC 22: Leveraging External Security Frameworks

Purpose

RFC 22 enables CSPs pursuing the 20x pathway to reach Validated Level 1 by leveraging existing security certifications.

Accepted Frameworks Include

• SOC 2 Type II
• ISO standards
• HITRUST
• StateRAMP
• CMMC

Additional frameworks may be recognized over time.

Why This Matters

CSPs can build on prior investments instead of repeating assessments. This reduces cost and time to entry while maintaining security rigor.

Requirements

Providers must map their external assessments to FedRAMP requirements to support PMO validation decisions. This pathway effectively serves as a modernized on-ramp for innovative and emerging providers.

RFC 23: Rev 5 Program Certification

Purpose

RFC 23 introduces a pathway for some CSPs to complete Rev 5 certification without an agency sponsor. This responds to situations where providers lose sponsorship after investing heavily in compliance.

Key Limitations

• Not available for the highest certification levels
• Time limited: submissions must occur before December 16
• No grace period
• Future balance improvements may be required

Strategic Value

This pathway helps preserve momentum for qualified providers and prevents capable systems from stalling due to administrative hurdles. It also reflects the transition away from traditional FedRAMP Ready toward more integrated certification models.

RFC 24: Machine-Readable Authorization Packages

Purpose

RFC 24 advances the transition to machine-readable authorization packages, primarily using OSCAL.

Current Reality

Despite years of development, OSCAL adoption has been limited. In 2025, no Rev 5 submissions used OSCAL.

Why It Still Matters

Manual document review does not scale effectively. Machine-readable formats support automation, continuous monitoring, faster reviews, and better interoperability.

Open Questions

• What tools will agencies use to process these packages
• What tools will CSPs use to generate them
• How will consistency be maintained across frameworks

Near-Term Opportunity

Continuous monitoring data is already structured. Machine-readable formats could streamline compliance if tooling and standards mature.

Overall Takeaway

Collectively, these RFCs are designed to modernize FedRAMP by improving cost transparency, clarifying authorization roles, accelerating market entry, reducing dependency on sponsorship, leveraging existing security investments, and enabling automation and validation. The overarching goal is to help agencies access secure cloud services faster while lowering barriers for qualified providers.

Take Action: Participate in the Public Comment Process

FedRAMP is actively seeking industry input through its GitHub RFC repositories. This is the most effective way to influence final policy decisions. Stakeholders are strongly encouraged to review the RFCs and submit thoughtful feedback before the February deadlines.

Comment on Each RFC

RFC-0019: https://github.com/FedRAMP/community/discussions/109

RFC-0020: https://github.com/FedRAMP/community/discussions/110

RFC-0021: https://github.com/FedRAMP/community/discussions/111

RFC-0022: https://github.com/FedRAMP/community/discussions/112

RFC-0023: https://github.com/FedRAMP/community/discussions/113

RFC-0024: https://github.com/FedRAMP/community/discussions/114

General Discussion and Q&A for RFC-0019 – RFC-0024:

https://github.com/FedRAMP/community/discussions/115