Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- FedRAMP 20x is live for Classes A, B, and C, and the 2026 rules become generally mandatory on January 1, 2027.
- One Key Security Indicator describes automatic monitoring of third-party software for upstream vulnerabilities, using methods such as contractual notices.
- The Key Security Indicators never name dependencies or software bills of materials, so scope comes from the rules’ definitions.
- Finding vulnerabilities is a requirement, while Class C remediation timeframes are recommendations that providers can depart from with documented reasons.
FedRAMP 20x treats an out-of-date security document as a vulnerability. Under the vulnerability detection rules of the Federal Risk and Authorization Management Program (FedRAMP), a stale control statement in a provider’s Security Decision Record, which replaced the System Security Plan, gets detected and fixed like any other weakness.
If the paperwork has to keep pace with the system, so does the software inside it, including code you didn’t write. Third-party software running within a cloud service offering falls within scope under 20x, even though the Key Security Indicators (KSIs) never use the word “dependencies“. The rules get there by defining a cloud service offering, and some KSIs call out third-party software and supply chain risk directly.
What FedRAMP 20x Changes for Cloud Providers
FedRAMP, the federal program that standardizes security assessment for cloud services, sits inside the General Services Administration (GSA). What 20x changes is where the proof comes from. Providers now back their claims with evidence that a system can automatically validate, in place of long written plans that people review by hand.
FedRAMP also changed its vocabulary. It now calls the outcome a certification rather than an authorization. FedRAMP certifies the offering, and each agency still makes its own decision to authorize use.
Where FedRAMP 20x Stands After the Pilot
The FedRAMP 20x pilot ran in two phases. Phase 1 was a Low-impact proof of concept from April through September 2025. Phase 2 tested Moderate from November 2025 through March 2026, and the first Moderate pilot authorizations came on March 6, 2026. Both pilots are done, and the program is in Phase 3, wide-scale adoption.
The pilots fed into the Consolidated Rules for 2026 (CR26). The latest FedRAMP 20x news is mostly housekeeping, since the rules’ change log shows clarifications and small adjustments through October 8, 2026.
If you came looking for FedRAMP 20x Moderate, the current name is Class C. Low is now Class B and High is Class D. Class A is new, an entry point for providers with mature security programs that want to reach the federal market. The 20x path is open to Classes A, B, and C.
Revision 5 (Rev5), the older process, is on a clock. These are the dates to know.
| Date | Milestone |
|---|---|
| May 4, 2026 | CR26 public preview published |
| July 4, 2026 | Optional early adoption begins, with effective dates that vary by ruleset |
| August 31, 2026 | Class B and C pipelines opened |
| January 1, 2027 | General mandatory date for the 2026 rules. Some rulesets start earlier, such as the vulnerability rules on December 7, 2026, and some Rev5 grace dates run later |
| First half of fiscal year 2027 (October 2026 through March 2027) | Estimated Class D pilot |
| June 11, 2027 | FedRAMP stops accepting new Rev5 certifications |
| At least December 31, 2028 | Existing Rev5 certifications stay active unless FedRAMP is directed otherwise |
How the FedRAMP 20x KSIs Work
A FedRAMP 20x KSI states one security capability, such as logging changes to the service or monitoring third-party software for upstream vulnerabilities. Indicators generally list the related controls from National Institute of Standards and Technology (NIST) Special Publication 800-53, a widely used catalog of security controls, so they trace back to an existing framework.
You can also explore how these frameworks align across the industry in our guide to top cloud security standards.
FedRAMP groups the KSIs into themes. The current list includes Change Management, Identity and Access Management, Incident Response, Recovery Planning, Policy and Inventory, Service Configuration, and Supply Chain Risk, among others.
Providers validate these indicators persistently. FedRAMP defines it as repeating frequently in cycles, with gaps allowed if they’re intentional and documented, so it doesn’t mean strictly continuous. The firmer numbers come from the vulnerability rules, which have their own start date. Class C providers must verify and validate the status of machine-based resources, such as software, hardware, and cloud services, at least every three days. Resources that don’t run on computers, like policies and staff procedures, get that check at least every three months.
The Security Decision Record is a running record of a provider’s security decisions, and FedRAMP expects it to be maintained, verified, and validated persistently. Assessors, the term FedRAMP now uses in place of third-party assessment organizations (3PAOs), typically review the evidence behind it, and FedRAMP is the final assessor.
Some of those indicators reach into the software you run.
Where the KSIs Touch Third-Party Software
Scope does a lot of the work here. Providers have to identify every information resource likely to handle federal customer data or affect its confidentiality, integrity, or availability; that set constitutes the cloud service offering. FedRAMP defines an information resource broadly enough to include software, code, hardware, and cloud services. That covers third-party code running inside the offering, whether or not a rule names it.
The indicators get more specific from there. Three of them address third-party software and supply chain risk directly, and two cover inventories and integrity checks across the offering, including software.
| KSI | Theme | What it describes |
|---|---|---|
| KSI-SCR-MON | Supply Chain Risk | Third-party software is monitored automatically for upstream vulnerabilities, through methods that can include contractual notifications or active monitoring services |
| KSI-SCR-MIT | Supply Chain Risk | Supply chain risks are persistently identified, reviewed, and mitigated |
| KSI-CNA-IBP | Cloud Native Architecture | Use and configuration of third-party machine-based resources is persistently compared against the original provider’s best practices and guidance |
| KSI-PIY-GIV | Policy and Inventory | Inventories of information resources generated automatically from authoritative sources |
| KSI-SVC-VRI | Service Configuration | Cryptographic methods used to validate the integrity of machine-based resources |
The vulnerability detection rule also lists supply chain monitoring as one of the techniques providers use to identify weaknesses. None of the KSIs use the words dependency, open source, package, or SBOM. On a plain reading, a third-party library running inside your service is third-party software under KSI-SCR-MON. What the rules don’t spell out is how granular the monitoring has to be or what evidence satisfies an assessor, and that is where interpretation comes in.
From the Source: Control SA-22, Unsupported System Components, is mapped to KSI-SCR-MIT. It calls for replacing components once the developer, vendor, or manufacturer stops supporting them, or for providing alternative sources of continued support. It’s already part of FedRAMP Rev. 5 baselines for Classes B, C, and D.
Put SA-22 next to the scope definitions, and the expectation that you replace unsupported components or arrange continued support isn’t new. Under 20x, the evidence that you’ve handled unsupported components is expected to come from automated validation, not a written explanation.
What the Rules Require and What They Leave Open
The FedRAMP 20x vulnerability requirements come in two strengths, MUST and SHOULD, and FedRAMP defines both. MUST is an absolute requirement. SHOULD means a provider may have valid reasons to depart, but it must weigh the implications and explain its decision in its security documentation.
Finding and handling vulnerabilities is firmly on the MUST side. Providers have to systematically, persistently, and promptly identify vulnerabilities in their offerings, then track, evaluate, mitigate, and remediate them.
The clock is the flexible part. For Class C, the timeframes for mitigation or remediation are at the SHOULD level. They depend on a vulnerability’s potential impact on agencies, whether it can be reached from the internet, and how likely it is to be exploited, and they range from 2 days at the severe end of the table to 192 days at the other. Providers should also remediate Known Exploited Vulnerabilities (KEVs) by the due dates listed in the Cybersecurity and Infrastructure Security Agency (CISA) catalog, even if a vulnerability has already been fully mitigated, and should avoid deploying new machine-based resources that already carry one. In practice, that means a firm duty to find vulnerabilities in third-party code, with the timeframes for fixing them set as defaults that you can depart from only with documented reasons.
The KEV language traces to Binding Operational Directive (BOD) 26-04, which CISA issued on June 10, 2026. It applies directly to Federal Civilian Executive Branch agencies, which must work through FedRAMP to ensure their cloud offerings are FedRAMP-compliant.
The vulnerability detection and response rules run on their own calendar. Providers obtaining or maintaining certification are expected to follow them starting December 7, 2026, with a grace period through March 7, 2027. That’s earlier than the January 1, 2027 date for the rules in general.
Planning for FedRAMP 20x Compliance Now
A first-time applicant and a current Rev5 holder face different FedRAMP 20x compliance work. If you’re pursuing a first certification, new Rev5 certifications end June 11, 2027, so 20x is the more likely destination, unless you need Class D, which only Rev5 serves for now. If you already hold a Rev5 certification, deadlines differ by ruleset, and FedRAMP moved some Rev5 grace dates as recently as September 13, 2026, so check its deadlines page for yours.
For third-party software, start with the inventory. KSI-PIY-GIV, the inventory indicator, expects inventories to be generated automatically from authoritative sources whenever they’re needed, and a software bill of materials produced in your build can be one candidate source. Pair it with monitoring that covers transitive packages, the ones pulled in by other packages, as well as the ones you picked on purpose, since those are easier to lose track of.
KSI-SCR-MIT’s supply chain risk language also reads as broader than known vulnerabilities, so screening the risk of what arrives at install should be part of the plan.
Note: Under the Minimum Assessment Scope rules, where the scope-identification rule applies, each applicable third-party information resource needs documented usage and configuration, a justification, mitigation measures, and compensating controls. FedRAMP defines that term as any information resource not entirely included in the Minimum Assessment Scope for the cloud service offering, such as an external service. A library built into your own service would normally fall within the scope instead. KSI-SCR-MON covers “third party software information resources,” which is broader than the defined term ‘third-party information resource’ and takes in third-party code running inside your own service.
Then look at what you run past support. Components with no upstream maintainer tend to stay unpatched, and the usual advice is to bump the version, but upgrading isn’t always a safe fix, so a replacement or a backported patch needs to be on the table.
FedRAMP 20x governance, risk, and compliance (GRC) tooling is part of the picture too. In the Phase 1 pilot, GRC vendors accounted for the largest share of submissions, seeking certification for their own products. Whichever tool you pick, the evidence still comes from your own systems and gets validated on the schedule the rules set.
Know What’s Running Before an Assessor Asks
Sooner or later, an assessor is likely to ask which third-party packages your service runs and who patches them when upstream support ends. That’s an uncomfortable question when some of those packages arrived through other packages, or when their maintainers moved on.
SecureChain is one way to shrink that gap. For the packages it covers, TuxCare rebuilds each one from source in a hardened, isolated environment, scans it for hidden malware and suspicious code before it reaches your environment, and patches new CVEs under an SLA. When upstream maintainers stop shipping fixes, Endless Lifecycle Support continues the patching. Coverage spans JavaScript, Python, Java, Go, Rust, and PHP, and the builds include SLSA Level 3 provenance, SBOMs, and VEX records.
If you can’t name the third-party packages in your service today, or say what happens when one loses upstream support, that’s the problem to fix first.
FAQ
What Is FedRAMP 20x?
The Federal Risk and Authorization Management Program (FedRAMP) is the federal government’s standardized security assessment program for cloud services. FedRAMP 20x is its newer certification path, which replaces document-heavy reviews with automated validation and machine-readable evidence. It’s open to new certification applications, with a High-impact pilot planned for a later phase.
What Are FedRAMP 20x KSIs?
Key Security Indicators (KSIs) are statements of security capabilities that a cloud provider demonstrates for the Federal Risk and Authorization Management Program (FedRAMP) 20x path. They’re grouped into themes such as Change Management and Supply Chain Risk, and they generally list the federal security controls they relate to. FedRAMP expects automated validation wherever possible.
Is There a FedRAMP 20x Moderate Level?
Not by that name anymore. The Federal Risk and Authorization Management Program (FedRAMP) replaced its Low, Moderate, and High impact levels with Class B, Class C, and Class D certifications, so Moderate is now Class C. Class C is available through FedRAMP’s newer 20x path, while Class D is planned for a later pilot.
What Is the Status of the FedRAMP 20x Pilot?
Both pilots for 20x, the newer path in the Federal Risk and Authorization Management Program (FedRAMP), are finished. Phase 1 tested Low impact in 2025, and Phase 2 tested Moderate from November 2025 through March 2026. FedRAMP is now in Phase 3, wide-scale adoption, with its 2026 rules phase-in and a general mandatory date of January 1, 2027.
What Are the FedRAMP 20x Requirements for Vulnerabilities?
Under the Federal Risk and Authorization Management Program (FedRAMP), providers must find and respond to vulnerabilities in their cloud service. Class C providers, the former Moderate level, must also verify and validate the status of their technology resources at least every three days. Class C remediation timeframes are recommendations, and departing from one requires documented reasoning.
Are Software Dependencies in Scope for FedRAMP 20x?
Software within a cloud service falls within scope, including third-party code, because the Federal Risk and Authorization Management Program (FedRAMP) scope covers any information resource likely to handle federal customer data or affect its confidentiality, integrity, or availability. One Key Security Indicator (KSI) addresses monitoring third-party software for upstream vulnerabilities. No KSI uses the terms “dependency” or “software bill of materials,” but a third-party library within the service is still an in-scope information resource and third-party software under KSI-SCR-MON. How granular the monitoring must be is up to assessors.
What Does GRC Mean for FedRAMP 20x?
Governance, risk, and compliance (GRC) tools help teams organize compliance work and evidence. In the first pilot of 20x, the newer path in the Federal Risk and Authorization Management Program (FedRAMP), GRC vendors were the largest category of submissions, seeking certification for their own products. Tooling is one way to collect the evidence FedRAMP’s rules call for.
