How to Get FedRAMP 20x Certified: A Step-by-Step Guide for CSPs

FedRAMP 20x readiness starts with eligibility, class selection, boundary definition, KSI mapping, evidence sources, persistent validation, VDR, authorization data sharing, and current KSI evidence exports.

May 23, 2026|13 min read

Start with the current FedRAMP 20x framing

FedRAMP 20x is not just a faster version of the old FedRAMP process. It is a cloud-native certification model built around current authorization data, Key Security Indicators (KSIs), persistent validation, and evidence that can be reviewed repeatedly instead of reconstructed during a documentation sprint.

The current FedRAMP Consolidated Rules preview uses FedRAMP Certification as the umbrella term, with two certification types: FedRAMP Rev5 and FedRAMP 20x. That matters because older market content may still describe 20x as "validated" or talk about older pilot terminology. Use official FedRAMP pages as the source of truth before making roadmap or sales commitments.

Here is the practical path a cloud service provider should build toward.

Step 1: Confirm that 20x is the right path

FedRAMP 20x is designed for cloud-native commercial cloud services that are built on FedRAMP Certified infrastructure and platforms. It is the better starting point for many new SaaS providers, but it is not the right path for every system.

Use 20x when:

Your service is cloud-native and runs on inherited FedRAMP Certified infrastructure or platform services.
Your team can maintain current system inventory, security evidence, and validation results.
You are targeting Class A, Class B, or Class C certification.
Your engineering and compliance teams can support automated or repeatable validation workflows.

Use Rev5 or stay close to a Rev5 strategy when:

You operate physical datacenters or non-cloud-native infrastructure.
You need Class D certification.
You are already deep into an existing Rev5 authorization path and changing lanes would create more risk than benefit.
Your agency customer specifically requires the traditional agency certification path.

The decision should happen before package work begins. If you pick 20x, you are not just choosing a different export format. You are choosing an operating model where evidence, validation, vulnerability response, and authorization data stay current.

Step 2: Choose the right certification class

FedRAMP's 2026 preview organizes certification around classes instead of treating every cloud service as the same level of operational burden.

Class A is for mature services entering the federal marketplace with a smaller amount of information and initial ongoing reporting.
Class B is for common small-scale or light-use services.
Class C is for common enterprise services and is likely the most important target for many SaaS companies.
Class D is for mission-critical or high-impact usage and is not a 20x path in the current preview.

For most SaaS companies thinking about 20x, the working question is usually: "Are we preparing for Class B or Class C?" Class C requires more complete operating evidence, stronger ongoing reporting, and a more mature validation program.

Do not choose the lowest class just because it sounds easier. Choose the class that matches how federal agencies will actually use the service.

Step 3: Define the authorization boundary

Before you map KSIs or export a package, define what is in scope.

At minimum, document:

Cloud accounts, subscriptions, projects, clusters, and environments in scope
Application services and APIs in scope
Data stores, queues, logs, object storage, and backup locations
Identity providers, privileged roles, service accounts, and administrative paths
CI/CD systems and repositories that can affect production
Third-party services, external APIs, and inherited FedRAMP services
Network paths, ingress points, egress paths, and management interfaces

This is where many teams underinvest. A weak boundary creates weak evidence. If nobody agrees which resources are inside the cloud service offering, your KSI validation results will be impossible to trust.

The boundary should be understandable by both engineering and compliance. Engineers should be able to look at a resource and know whether it is in scope. Reviewers should be able to trace evidence back to the relevant part of the system.

Step 4: Build an inventory that can stay current

FedRAMP 20x depends on current authorization data. That means static spreadsheets and one-time asset exports are not enough.

Start with a living inventory for:

Machine-based resources such as compute, containers, serverless functions, databases, storage, network components, and identity resources
Non-machine-based resources such as policies, procedures, reviews, training, incident exercises, and human approval workflows
External dependencies such as third-party APIs, managed services, libraries, and supplier-controlled components
Evidence sources such as cloud APIs, SIEMs, vulnerability scanners, ticketing systems, CI/CD systems, source control, and policy repositories

Each inventory item should have an owner, scope status, source system, last-seen timestamp, and relationship to the service boundary. Without this, persistent validation becomes a pile of disconnected checks.

Step 5: Map your system to the KSI themes

20x centers around Key Security Indicators. KSIs are not just a shorter checklist. They describe security outcomes that need supporting decisions, implementation details, validation logic, and evidence.

Start by mapping your system across the major KSI themes:

Authorization by FedRAMP
Cloud Native Architecture
Identity and Access Management
Service Configuration
Monitoring, Logging, and Auditing
Change Management
Policy and Inventory
Cybersecurity Education
Incident Response
Third-Party Resources
Recovery Planning

For each KSI, capture:

The security decision or goal
The systems and resources affected
The validation method
Whether the validation is machine-based, non-machine-based, or hybrid
The evidence source
The expected cadence
The owner
The remediation path when validation fails

This turns 20x from a policy exercise into an engineering workflow.

Step 6: Connect evidence sources

The difference between a 20x-ready program and a document-generation exercise is evidence quality.

Connect evidence sources where the truth already lives:

Cloud configuration APIs for network, storage, compute, encryption, and logging settings
Identity provider APIs for MFA, privileged access, groups, service accounts, and session controls
CI/CD systems for deployment history, approval gates, test results, and infrastructure changes
Source control for infrastructure-as-code, branch protection, and code review records
Vulnerability scanners for findings, severity, reachability, exploitability, and remediation status
SIEM or logging platforms for audit trails, detection coverage, and alert handling
Ticketing systems for change management, incident response, and remediation ownership
Policy repositories for human-process evidence and procedural approvals

Evidence should include what was checked, when it was checked, which resource it applies to, what result was produced, and where the raw source can be reviewed.

Screenshots can help a human understand context, but they should not be the foundation of a 20x evidence program.

Step 7: Implement persistent validation

Persistent validation is one of the biggest operational changes in 20x.

For machine-based resources, the current FedRAMP 20x persistent validation guidance requires validation at least every 7 days for Low and at least every 3 days for Moderate. Non-machine validation must be completed at least every 3 months.

In practice, your validation program should answer:

Which KSIs are validated automatically?
Which KSIs require human or process evidence?
Which resources are covered by each validation?
How often does each validation run?
How are failures triaged?
How are exceptions documented?
How does a reviewer know the validation process itself is reliable?

Do not treat this as "run a scanner every few days." A scanner output is only one signal. Persistent validation should produce a defensible result: pass, fail, partial, not applicable, or exception, with evidence attached.

Step 8: Remediate KSI gaps before packaging

Once validation starts running, expect gaps.

Common early gaps include:

Incomplete inventory inside the boundary
MFA or privileged access exceptions that were not documented
Logging that exists but is not complete across all in-scope services
Encryption settings that are inconsistent across environments
Vulnerability findings without owner, due date, or exploitability context
CI/CD changes that are approved in practice but not evidenced consistently
Third-party dependencies that are not tied back to supplier risk evidence

The best remediation workflow is assertion-level. Instead of saying "IAM is weak," your system should identify the exact failed KSI assertion, affected resource, missing evidence, likely owner, and recommended fix.

This is where a platform like Boundera should help: not by producing prettier documentation, but by turning failed validations into work that engineering can actually close.

Step 9: Build the VDR workflow

FedRAMP 20x moves vulnerability management toward persistent Vulnerability Detection and Response (VDR). The important shift is that vulnerability posture becomes part of current authorization data, not just a monthly spreadsheet artifact.

Your VDR workflow should cover:

Continuous vulnerability discovery from scanners, cloud services, suppliers, and disclosure channels
Severity, reachability, exploitability, and impact analysis
Ownership and remediation routing
Exception and risk-acceptance documentation
Evidence that the vulnerability was fixed or mitigated
Reporting that can be shared as authorization data

Do not wait until the package is ready to design this. If VDR is not wired into the engineering workflow, your authorization data and evidence views will look current only on export day.

20x assumes relevant parties can access current authorization data. That makes your trust center or sharing mechanism more than a marketing page.

A 20x-ready sharing model should handle:

Who can access authorization data
What data is shared
How requests are approved or denied
How access is logged
How current package data is refreshed
How agencies or reviewers find the latest inventory, validation results, vulnerabilities, and supporting evidence

This is also a sales issue. Federal buyers do not just want to know that you have a security page. They need enough current detail to make a reuse or risk decision.

Step 11: Prepare authorization data and KSI evidence exports

FedRAMP's official language is centered on authorization data, KSI validation, persistent validation, VDR, and assessor-facing outputs. In Boundera product language, we use "KSI evidence package" to describe a practical export that brings those materials together for review.

A practical 20x evidence export should include:

Boundary and service description
KSI mapping and applicability decisions
Validation results by KSI
Evidence references and source systems
Validation cadence and last-run timestamps
Inventory and dependency data
VDR status and vulnerability response evidence
Exceptions, risk decisions, and remediation plans
Assessor-facing summaries where required
Machine-readable artifacts where applicable

The output should be explainable to humans and usable by machines. If a reviewer asks why a KSI passed, the export should trace from the result to the evidence and from the evidence to the source system.

Step 12: Prepare for independent assessment

Under 20x, assessors do not only review the final output. They need to verify the processes that generate the output.

Be ready to show:

How validation logic works
How evidence is collected and protected
How coverage is determined across the boundary
How failures are detected and routed
How exceptions are approved
How stale evidence is identified
How changes affect validation results
How human-process KSIs are reviewed

This is a major difference from a document-heavy Rev5 mindset. The package matters, but the machinery behind the package matters more.

Step 13: Maintain certification continuously

FedRAMP 20x does not end when the package is submitted.

After certification, keep the same operating loop running:

Refresh inventory
Run persistent validation
Remediate failed KSI assertions
Keep VDR current
Share current authorization data
Track significant changes
Maintain incident and security inbox workflows
Update evidence when the system changes
Prepare for recurring independent validation

The winning model is boring in the best way: evidence stays current because the system keeps producing it.

A simple implementation roadmap

Days 0-30: Scope and evidence foundations

Confirm 20x eligibility and target class
Define the authorization boundary
Build the initial inventory
Identify KSI owners
Connect the first evidence sources: cloud, identity, source control, CI/CD, vulnerability scanner

Days 31-60: KSI mapping and validation

Map KSIs to systems, evidence sources, and validation methods
Classify validations as machine-based, non-machine-based, or hybrid
Start running validation on a schedule
Create failure routing and remediation workflows
Establish exception handling

Days 61-90: Package and assessment readiness

Generate a draft authorization data and KSI evidence export
Review evidence traceability
Harden VDR reporting
Prepare authorization data sharing
Walk through the validation process with assessor-style questions
Fix the gaps before formal review

What to validate before publishing your own 20x plan

FedRAMP 20x is moving quickly, so every public guide should be checked against official sources before publication. Use this lightweight checklist:

Claim	Official source to check	How to word it safely
20x is for cloud-native commercial services	FedRAMP 20x overview and 2026 certification preview	"FedRAMP describes 20x as a cloud-native certification process..."
Class A/B/C/D rules	2026 certification preview	"In the current preview..."
Class D availability	2026 certification preview	"Class D is not a 20x path in the current preview."
KSI themes and applicability	FedRAMP KSI docs	"KSIs apply to 20x offerings and should be addressed across the assessment scope."
Persistent validation cadence	FedRAMP PVA docs	"Current guidance requires..."
VDR obligations	FedRAMP VDR docs	"VDR requires persistent vulnerability detection and response..."
Authorization data sharing	FedRAMP ADS docs	"20x programs need a way to share current authorization data..."

This avoids the biggest content risk: repeating old pilot language after FedRAMP has updated its terminology.

Key takeaways

FedRAMP 20x is an operating model, not just a faster paperwork path.
The work starts with boundary, inventory, KSI mapping, evidence sources, and persistent validation.
A 20x evidence export should be generated from current evidence and validation results, not manually assembled as a static report.
VDR and authorization data sharing need to be designed early, not bolted on later.
Before publishing or committing to a roadmap, validate terminology and class rules against official FedRAMP pages.