FedRAMP 20x Begins to Take Shape

Introduction

The FedRAMP 20X program is beginning to take shape. Over the past month, PMO released its first new set of guidance documents for public comment, offering a preview of what FedRAMP-published guidance could look like in the 20X era.

• RFC-0005 Minimum Assessment Scope Standard
• RFC-0006 20x Phase One Key Security Indicators
• RFC-0007 Significant Change Notification Standard
• RFC-0008 Continuous Monitoring Reporting Standard
• RFC-0009 Significant Change Notification Technical Assistance

After reviewing these RFCs, I had mixed reactions. On one hand, the guidance opens the door to new approaches to compliance which, ideally, could lead to efficiency and innovation. But on the other hand, I worry that the ambiguity of the guidance will result in vastly different interpretations of controls by agencies, 3PAOs, and CSPs. Historically, this has been one of the biggest challenges CSPs face in their pursuit of FedRAMP. As the PMO themselves have stated, CSPs often need to hire a consultant just to explain what the FedRAMP requirements actually mean.

Time to Leave the FedRAMP Gray Zone Behind

As a FedRAMP consultant, my least favorite conversations to have with CSPs revolve around the “gray areas” of FedRAMP compliance. CSPs want to know exactly what is needed to pass a FedRAMP assessment. If I’m going to tell an engineer that they need to rearchitect their application to encrypt traffic between containers running on the same node (using a FIPS-validated module nonetheless), they are going to want a strong justification to take to their leadership. I start by telling them that this is required based on Coalfire’s conservative interpretation of SC-8 and feedback we’ve gotten from the PMO. But as a trusted advisor, I also have a responsibility to provide Coalfire’s real world insights. So, I would share that “while 3PAOs could check for this level of encryption, in my experience, they usually don’t dig that deep” or “most agencies will overlook this, but technically, they would be justified to interpret SC-8 that way; it’s a gray area.”. This forces the CSP to choose if they should implement a costly security control that may not even be required (and question why they hired Coalfire as their advisor). 

I’m not saying CSPs do not care about security. I’m stating the reality that all CSPs are businesses. Implementing expensive security practices to address security risks with low likelihood and impact to the CSP just because a 3PAO or agency might require it is bad business. 

Which brings me back to the latest RFCs. 

For FedRAMP to be optimized for efficiency (which is clearly the goal of 20X) there needs to be agreement across federal agencies on what the minimum security requirements (indicators, controls – call them what you want) are and this needs to be clearly communicated to 3PAOs and CSPs. If each agency and 3PAO interprets the new FedRAMP baseline and guidance differently, it will result in a FedRAMP program that is even less efficient than before.

Coalfire’s Thoughts on the Latest RFCs

Here are the major takeaways, questions, and areas for improvement Coalfire has compiled in response to the first drop of draft standards.

RFC-0005: Minimum Assessment Scope Standard

1. “Replaces ALL previous guidance related to the boundaries of all FedRAMP authorizations”
   • The latest Boundary guidance supersedes all previously published and draft boundary guidance. But agencies, 3PAOs, and CSPs are not simply going to forget the foundational principles that have guided FedRAMP boundary scoping for more than a decade. Where the new guidance is vague, they are going to fill in the blanks with historical knowledge.
2. “information created, collected, processed....by or for the federal government, in any medium or form.”
   • This statement is incredibly ambiguous in the context of the boundary. For example, a POA&M may not contain any information that the government input into the SaaS (information created by the government), but it is collected and processed by an agency. As is a contract for services from the CSP, as it’s created for the government to procure the service. The latter used to not be in scope as part of a CRM, while the former was in scope. Are both in-scope now given the “federal information” context?
3. “Minimum Assessment Scope includes information resources that...Likely impact confidentiality, integrity, or availability of federal information”
   • “Likely” is difficult to interpret. Including examples of information types that fall into this category (like the examples of federal metadata in the 2021 Boundary Guidance) would be immensely helpful.
4. “Software and other such products (including agents and clients) that are installed, managed, and operated on agency information systems are outside the scope of FedRAMP.”
   • To clarify further on this, is the software’s method of communication (as a source) not in scope either, such as what FIPS module is being used by the agent as the crypto source for the connection? Effectively in scope is just the CSP agent management service deployed on the IaaS that receives/terminates the connection from the agent?
5. “Stakeholders should review best practices and technical assistance provided separately by FedRAMP for help with applying the Minimum Assessment Scope as needed.”
   • With the major changes of FedRAMP 20x and this guidance acting to replace other boundary guidance, what documents/resources specifically fit under the topic of “best practices and technical assistance provided separately by FedRAMP for help applying the Minimum Assessment Scope”? Is this mainly intended as a placeholder for future guidance?

RFC-0006: 20x Phase One Key Security Indicators (KSIs)

FedRAMP 20x is trying to fix a very real problem: Manual assessments are slow, painful, and disconnected from reality. If the goal is to automate assessments– scanning configurations, streaming telemetry, and surfacing risk posture in near real-time, that’s admirable, and technically plausible. But for automated compliance checks to work, there needs to be very clearly defined criteria for what pass vs. fail looks like. 

The security requirements defined in the nine draft KSIs are perfectly reasonable. They align with FedRAMP’s goal of simplifying control language and modernizing requirements for cloud-native environments while remaining rooted in NIST SP 800-53. However, given how high level the KSIs are, standardization of KSI validation, evidence, and assessment expectations will be key. The KSI’s use of ambiguous phrases like “continuous scanning”, “harden system configurations”, and “rapidly detect and remediate vulnerabilities” are a one-way ticket back to the Gray Zone. 

For now, this appears to be by design. FedRAMP plans to work directly with CSPs, 3PAOs, and federal agencies throughout the FedRAMP Low 20x pilots to define “minimum expectations for validation, evidence, and assessment”. 

RFC-0007: Significant Change Notification Standard & RFC-0009: Significant Change Notification Technical Assistance

• Requirement to start 3PAO assessment in 1 day and finish in 7 days
  • Many CSPs bundle significant change assessments into their annual assessments to reduce costs and increase efficiency. It will be very difficult to meet these timelines when planning around an annual 3PAO assessment.
• Documentation
  • Is the FedRAMP SCR form still required? If not, this could lead to each agency designing their own SCR form, increasing the burden on CSPs to deliver SCRs in varying formats.
• Technical Assistance (RFC-0009)
  • After reading RFC-0007, we were concerned over the vagueness of the newly defined "adaptive" and "transformative" changes. RFC-0009 provided the necessary clarity and context. Coalfire urges the FedRAMP Team to continue supplementing standards with similar "technical assistance" guidance.

Conclusion: A Call for Clarity

FedRAMP leadership has an opportunity to reset the FedRAMP program in 20X and make gray areas a thing of the past. By clarifying ambiguous controls, standardizing assessor and agency expectations, and continuing to publish guidance, the program can achieve its goals of becoming more efficient and growing the Marketplace all while raising the bar for cloud security.

 Bonus Material: Additional FedRAMP “Gray Zone” Areas

“You're navigating through another dimension, a dimension not only of controls and ATOs, but of interpretation. A journey into a nuanced landscape where clarity fades and judgment rules. That's the signpost just ahead—your next stop, the FedRAMP Gray Zone.”

As I was crafting the blog above, I thought about several of the other “gray zone” areas I often come across when advising against the current FedRAMP baseline. Below, I have summarized a few more examples of the types of situations FedRAMP 20x should strive to avoid.

Pod-to-Pod Encryption on the Same Node

Containerization is now foundational in modern cloud architectures. Yet FedRAMP’s guidance hasn’t fully kept pace. The SC-8 requirement for encryption “between compute instances - including containers” leaves CSPs asking:

• Does this apply to pod-to-pod and container-to-container traffic on the same node?
• What if the traffic never leaves the node?
• Do all 3PAOs interpret this the same way?

While encrypting intra-container traffic can provide security benefits, it can be costly to implement and hinder system performance. Some CSPs encrypt all internal data in transit religiously. Others? Not at all. The guidance needs to evolve.

Vulnerability Data Inside the Boundary

FedRAMP requires that vulnerability scan results stay within the authorization boundary. Meanwhile, the developers who need that data to fix vulnerabilities often sit outside that boundary—and aren’t subject to FedRAMP personnel controls. This creates a paradox: How can developers fix vulnerabilities if they’re not allowed to see the scan results? The unspoken truth? Most CSPs simply share the data anyway, and 3PAOs rarely question it. It’s one of the many “don’t ask, don’t tell” dynamics in FedRAMP. More clarity is needed on how to operationalize this rule without compromising security or developer agility.

Compliance Scans: Manual Verification or Assumption?

FedRAMP requires that CSPs validate secure configurations using tools like Tenable, Qualys, or OpenSCAP. These tools automate many checks, but not all. Here’s the gray area: For the non-automated checks,

• Some 3PAOs manually verify a sample of settings.
• Others do nothing beyond reviewing scan output.
• Still others flag all manual checks as findings, putting the burden on CSPs to justify or deviate.

There’s no consensus. The absence of standardized validation criteria introduces significant variation—and frustration.

STIGs and CIS Benchmarks: What Really Applies?

The general FedRAMP position is: “If a STIG or CIS benchmark exists for a component, apply it.” But enforcement tells a different story. What’s clear is that server OS hardening is non-negotiable— it’s easy to check, easy to enforce. Hardening of databases and network devices is also consistently enforced. Where It’s Gray:

• Containers: Most tools that advertise “container compliance scanning” only scan the worker nodes, engine, or orchestration platform—not the actual container OS. True container OS hardening compliance scanning is possible (e.g., with OpenSCAP), but not widely adopted or enforced.
• Everything else: STIGs and CIS Benchmarks exist for numerous applications (e.g., Apache Tomcat, Active Directory, Microsoft Office 365, Firefox), and there’s also the generic STIGs (e.g., Container Platform, Web Server).

This inconsistency confuses CSPs and reduces the real-world value of these controls.

Covert Data Exfiltration: A Control with No Teeth

The requirement to prevent covert exfiltration feels like something from a spy novel. NIST mentions steganography—yes, hiding data in images—as an example. But in practice? Most SSPs write a paragraph or two on “defense in depth” and move on. 3PAOs rarely push for more, and there’s no detailed guidance on what to look for or expect. If this is truly a risk FedRAMP wants CSPs to mitigate, it needs to define it better. If not, it’s just noise.

Supply Chain Risk Management (SCRM): The Ultimate Gray Area

The SR control family, added in Revision 5, is both valuable and vague. Controls like SR-3, SR-5, and SR-6 essentially say: “Design a supply chain risk management program appropriate for your organization.” Which sounds great—until you try to implement it. FedRAMP seems to be saying: “You're smart—figure it out.” But that flexibility has downsides:

• CSP compliance teams argue with dev teams over what’s “appropriate.”
• 3PAOs apply their own interpretations, inconsistently.
• Agencies may disagree with both.

This isn’t a knock on the intent—SCRM is essential. But clearer expectations would yield better security outcomes and reduce costly back-and-forths.