FEDRAMP
Back

Automating FedRAMP 20X Security Controls From Scratch

FedRAMP 20X is a security certification for companies that provide cloud-based software or services to U.S. federal agencies. This blog covers how our team built a compliance automation platform that enables organizations to persistently meet security controls, collect evidence, and track outcomes to achieve FedRAMP 20X Class C (and other) certifications.
Thomas Piñero Thomas Piñero
  • 21 min. read

FedRAMP evolved in 2026 to streamline the certification process

Before the FedRAMP 20X program was established, private cloud and software companies that wanted to sell to U.S. federal agencies often faced a slow, costly, and inefficient process. Anyone who wanted to get certified had to submit extensive documentation and go through several manual review cycles to prove that their cloud services met federal security requirements. Over time, that inefficiency kept on snowballing…

So, on March 24, 2025, the U.S. General Services Administration (GSA) announced FedRAMP 20X with the stated goal of approving new cloud services much faster. The new FedRAMP 20X framework asks cloud providers to continuously show that important security controls are in place across areas such as access, network security, monitoring, incident response, recovery, and internal security practices.

Because much of the evidence can be collected directly from cloud systems, FedRAMP 20X creates a clear opportunity for building platforms that automate the process. Not to mention, companies that participate in FedRAMP 20X pilots get the benefit of being listed on the marketplace ahead of others. With FedRAMP 20X creating an entirely new market for cloud security platforms, a US-based cybersecurity company hired our nearshore engineering team to build a multi-tenant compliance product from scratch. This blog explains how we turned the framework into a working product and the main technical challenges we had to solve.

If you want the short version before reading on, 38North Security has a useful plain-English video explanation of FedRAMP 20X.

FedRAMP 20X requires continuous security and compliance

The core idea behind FedRAMP 20X is that companies should be able to persistently meet a list of critical security controls. Those requirements are expressed as Key Security Indicators, or KSIs, grouped into families that cover identity and access, network security, monitoring, incident response, recovery, configuration, and internal security practices. At a high level, following the entire FedRAMP 20X program enables organizations to achieve multiple benefits, including:

  • Faster time to authorization. Instead of spending months building and reviewing large documentation packages, more of the process can be validated automatically using evidence from the live environment.
  • Less documentation to manage. Key Security Indicators reduce the need for hundreds of pages of written explanations by using machine-readable evidence collected directly from cloud systems.
  • More reuse across agencies. Once a provider has a current security posture published on the FedRAMP Marketplace, multiple agencies can review it instead of asking for the same information to be packaged again.
  • An easier path into the federal market. Providers can begin the certification process without first having an agency sponsor, which opens the door to companies that do not already have federal customers.
  • A chance to help shape the process. Companies that participate early can provide feedback as FedRAMP 20X evolves and start building the automation they may eventually need anyway.
  • Automation that is useful beyond FedRAMP. The same systems used to collect and validate FedRAMP evidence can also support SOC 2, ISO 27001, internal audits, and broader security reporting.

Keep in mind that although a company may comply with every security control on paper, FedRAMP creates the entire 20X program to ensure organizations are truly secure at the operational level. Let’s explore how these controls work in more detail…

Technical controls and process controls are different problems

To comply with all controls, the main engineering challenge was interpreting what each requirement meant, especially when the framework defined the security outcome but didn’t prescribe exactly how to prove it. This was particularly difficult for process-related controls, where there was often no single API, standard course, or technical setting that could return a simple pass or fail.

For every control we wanted to automate, we had to answer questions like these:

  • Which resources should the platform inspect?
  • Where does the relevant evidence live?
  • Which API or system can provide it?
  • What configuration should count as compliant?
  • What should cause the check to fail?
  • What evidence should be stored so another person can understand the result later?

Our team decided to first take a higher-level approach and split controls into two categories:

  1. Technical controls are usually easier to automate because cloud platforms already expose the data needed to validate them. In many cases, the required setting is either configured correctly or it is not, which maps directly to a pass or fail result. For example, the platform can check whether a resource is encrypted or whether a firewall rule exposes a service to the internet.
  2. Process-related controls are harder to automate because they depend on how the company operates. For example, FedRAMP may require employees to receive phishing training, but it does not define one specific course that proves compliance. In those cases, the platform can check that supporting evidence exists and is up to date, while an assessor still makes the final decision.

Across both groups, the evidence a provider has to produce falls into a handful of recurring categories:

The platform’s requirements drastically changed during the development stage

Another challenge was that the list of requirements kept changing while we were building the platform. As FedRAMP 20X developed, the requirements became more specific, and the certification process became easier to follow. Several things changed along the way:

  • Requirements became more precise. Earlier versions sometimes left more room for interpretation. Over time, FedRAMP clarified what providers actually needed to prove and what type of evidence could support each requirement.
  • Some KSIs were reorganized or consolidated. Requirements that were originally separated across several indicators were sometimes brought together. Cybersecurity training is one example, where multiple related requirements were later consolidated into a simpler structure.
  • Process controls shifted from prescribing a method to proving an outcome. Earlier requirements could be interpreted as expecting a specific course, process, or internal procedure. The newer approach focuses more on whether the organization can show that the required practice exists and is consistently being followed.

For our team, the constant changes to the program meant that we could not hard-code the framework, we had to design the compliance logic so that rules and evidence requirements could be updated without rebuilding the platform each time FedRAMP changed. Finally, after a lot of iteration, in June 2026, FedRAMP published the Consolidated Rules for 2026, formalizing the program into a certification path that will become mandatory for all stakeholders on January 1, 2027. With the new rules in effect, our team had a set path forward: obtaining FedRAMP Class C certification. Below, we cover each class and what it means for companies going through the FedRAMP certification process.

Designing the platform for FedRAMP Class C certification

FedRAMP 20X no longer uses the old Low, Moderate, and High baselines. Instead, it organizes certification into four classes with increasing levels of compliance:

  • Class A is the entry point for providers with a mature commercial security program that are new to the federal market. It leans on a prior FedRAMP Rev5, SOC 2 Type II, or GovRAMP certification completed within the past 12 months, and automated validation is optional.
  • Class B is intended for broader federal use cases that require more assurance than Class A. Providers should implement at least one automated validation method for each Key Security Indicator and should supply historical data.
  • Class C is the most demanding class currently available. Providers must implement at least two automated methods for each indicator and must supply at least six months of historical metrics drawn from persistent validation.
  • Class D is the highest planned class. It requires at least four automated methods for each indicator and eighteen months of historical metrics, and it has not been released yet.

The main difference between the classes is not the type of security control being evaluated. The same core security areas remain in place, but the level of evidence and automation increases as you move up. Specifically, our client decided to build toward Class C for a few reasons:

  • Our client wanted to commercialize the product, and most of the potential customers they were speaking with were also aiming for Class C. 
  • Class C is the highest certification class available today, so designing for it creates a stronger baseline for customers with lower requirements.
  • Class C forces the product to generate stronger, more repeatable evidence instead of relying on a single validation method.

To achieve this level of compliance, a key design decision worth mentioning is that we used our own AWS environment as the platform’s first real test case. Instead of only building compliance checks for customers, our team ran those same checks against the infrastructure that powers the platform itself. For example, if the platform checks whether a customer’s S3 bucket is publicly exposed, it performs that same check on our own AWS account and records the result. This worked well for two reasons:

  • We could test the platform in a real environment. If it cannot collect and explain evidence from its own infrastructure, it will not work reliably for customers.
  • We could prepare for FedRAMP Class C ourselves. After several runs of using the platform in-house, the team could see what evidence was missing and what needed to improve before going through the certification process.

Great, so we need to achieve Class C. Now what? Well… it was time to break down every single security requirement and implement the respective technical control through automated, machine-readable code.

Our team had to automate every single security control

FedRAMP defines the security outcomes a provider needs to demonstrate, but it does not tell engineering teams exactly how to build software around them. Basically, our team had to turn ambiguous, written requirements into useful automated checks and workflows that could run persistently in a software platform.

Here’s how we modeled the controls:

  • We translated every control into a technical check. Before writing code, we identified what resources needed to be reviewed, where the evidence came from, which API provided it, what counted as compliant, and what data needed to be saved for future review.
  • We separated technical controls from process controls. Technical requirements, such as encryption or network exposure, can often be checked automatically with a clear pass or fail. Process requirements, such as employee training or internal procedures, usually depend on documentation and human review.
  • We only automated what the evidence could prove. For process controls, the platform can confirm that required documentation exists and is up to date. It does not assume that having a document automatically proves the process is being followed.
  • We implemented 46 KSIs across 10 security families. These requirements cover areas ranging from cloud architecture and identity to incident response and cybersecurity training. To manage them consistently, we built a shared evidence model instead of creating 46 separate scripts.

Here’s how we built the platform:

  • We built the platform as independent modules and microservices. Compliance monitoring, change management, and vulnerability management run through separate backend components, so a problem in one area does not affect the entire platform.
  • We split the compliance workflow into specialized services. Separate components handle cloud scanning, scan coordination, evidence processing, storage, and sending results back to the application.
  • We designed the compliance logic to be easy to update. FedRAMP 20X was still changing while we were building, so we kept the core scanning and reporting architecture stable while allowing individual rules and evidence requirements to evolve.
  • We separated cloud-specific data collection from the FedRAMP requirement itself. A network security requirement is the same whether a customer uses AWS, Azure, or GCP. What changes is how the platform collects the evidence from each cloud provider.
  • We added automated tests around the compliance logic. Unit, integration, and smoke tests help us add or update controls without breaking checks that are already working
     

Now, let’s look at an example of how this works for a given control in AWS.

Example of implementing a FedRAMP 20X KSI through AWS compliance automation

Disclaimer: a bunch of technical jargon coming ahead… Feel free to skip a few paragraphs 🙂

The best example our team can think of is KSI-CNA-RNT, a FedRAMP 20X requirement focused on limiting inbound and outbound network traffic. It relates to controls such as AC-17(3), CM-7(1), and SC-7(5), which address restricting remote access, reducing unnecessary functionality, and controlling network connections. Ultimately, we want to answer: are cloud resources only allowing the network traffic they actually need?

To answer that question, the scanner checks every configured AWS account and region. It uses the EC2 APIs to understand which Security Groups are actually attached to resources and what rules those Security Groups allow, like:

  • DescribeNetworkInterfaces to identify which Security Groups are currently attached to active resources.
  • DescribeSecurityGroups to inspect the inbound and outbound rules configured for each group.

From there, the platform looks for patterns that could indicate unnecessary exposure. For example, it checks for inbound access from 0.0.0.0/0 or ::/0, which means traffic can come from anywhere on the internet, as well as publicly exposed administrative ports such as SSH. It also looks for completely unrestricted outbound traffic and whether the default AWS Security Group is actively being used.

Putting the technical jargon aside, the part is that the platform doesn’t simply return a generic message saying the KSI passed or failed. Each Security Group is stored as an individual resource and identified by its AWS ARN, so the result can always be traced back to the exact configuration that was evaluated. For each resource, the platform records information such as:

  • Whether it PASSED or FAILED.
  • The AWS account and region.
  • The Security Group name and description.
  • The VPC where it exists.
  • The specific finding that caused the result.
  • The date the evidence was collected.
  • The source of the evidence, such as the AWS EC2 API.

Once the scanner collects the information, several backend services process it before the user sees anything. First, the scanner creates evidence artifacts for that customer, environment, scan, and KSI family. Then, a normalization service interprets those artifacts and converts them into a consistent format. From there, the ingestion service validates the scan and stores the results, metrics, and individual resources. Finally, the Reader API makes that information available to the application. By the time the result reaches the application, the user can see a lot more than just a pass/fail status:

  • The overall status of the KSI.
  • The compliance percentage.
  • How many resources were evaluated.
  • How many passed and failed.
  • The exact Security Groups that need attention.
  • Why each resource failed.
  • How the result compares with previous scans.

The value of building a fully automated platform is that, for a large group of security indicators beyond the one we just discussed, teams can continuously recheck the same requirements, track findings, and see how compliance changes over time.

Building FedRAMP-compliant software with senior FedRAMP engineers

The key lesson learned is that building software for FedRAMP absolutely requires having a strong engineering team. While FedRAMP gives you a list of controls based on NIST, your engineers have to figure out how the product will actually prove it! 

After all, our client’s biggest competitive advantage on this project was staffing the team with cloud security engineers and senior backend developers who could translate security requirements into software. The know-how required to build products that handle regulated data is expensive and hard to find. So, if your organization is considering building software for the security industry, we have written more about cybersecurity staffing services and how bringing in a nearshore fractional CISO can make sense when you’re in the process of setting up a security team.

Frequently Asked Questions (FAQ)

What is a FedRAMP 20X compliance automation platform?

A FedRAMP 20X security platform helps organizations automate FedRAMP security controls. Rather than validating these security checks and processing compliance documents manually, an automated platform connects to the cloud environment and security tools, collects information directly from those systems, and uses that data to show whether security requirements are being met. Additionally, these platforms include useful features such as collecting evidence, reporting on metrics through dashboards, and operationalizing workflows to trigger security improvements across the organization.

FedRAMP 20X Key Security Indicators, or KSIs, describe security capabilities that a cloud service provider needs to demonstrate.  Basically, KSIs organize FedRAMP security controls around broader capabilities and then prove those capabilities with evidence such as:

  • What does this security outcome mean in our environment?
  • Which cloud resources are relevant?
  • What technical or process evidence demonstrates it?
  • Where does that evidence come from?
  • Can we collect it automatically?
  • How do we know the evidence is accurate?
  • How often should it be validated?
  • How do we show that the capability continues to work over time?

At the current stage of the 20X program, these indicators cover broad security groups (control families) such as identity and access management, cloud architecture, network security, monitoring and logging, incident response, recovery, change management, cybersecurity training, and service configuration.

Not really, as it depends on the type of control. Some controls are easier to automate because the evidence is objective, while other checks are more subjective and still require a security expert to review them (so can’t be 100% fully automated). Broadly speaking, there are two groups:

  • Technical controls: These are usually easier to automate because they rely on machine-readable data. A platform can check things like encryption settings, IAM permissions, Security Groups, logging, or other cloud configurations and compare them against a defined rule. In most cases, the output can be a clear pass or fail.
  • Process-based controls: These are much harder to automate because they depend more on the company’s context. While a platform can (potentially) confirm that a policy exists or that an employee completed security training during onboarding, a security expert may still need to manually validate whether the requirement is met against the security framework.

FedRAMP 20X Class C requires providers to continuously validate their applicable KSIs using automation. For each KSI, they need at least two automated validation methods, plus historical metrics covering at least the previous six months.

In order to get certified, organizations need to:

  • Keep automated KSI validation running continuously.
  • Use at least two validation methods for each applicable KSI.
  • Collect and retain historical metrics for at least six months.
  • Store the evidence behind each result so it can be reviewed later.
  • Track whether each security capability remains healthy over time.
  • Document enough detail for an independent assessor to understand how each KSI is being validated.
  • Be able to explain failures, changes in status, and how issues were corrected.

Logically, teams can use an automated platform to automate most of the points above.

Machine-readable evidence makes compliance much easier to manage over time. Instead of repeatedly collecting screenshots, PDFs, configuration exports, and other manual evidence, teams can pull structured data directly from the systems they are evaluating. In turn, that evidence can be updated automatically, validated consistently, compared over time, and reused across assessments. Under M-24-15 Section V on Automation and Efficiency, FedRAMP calls for authorization and continuous monitoring artifacts to be provided as machine-readable data in OSCAL format through APIs where feasible. 

Considering that AI is starting to play a larger role in automating compliance, using structured data makes a lot of sense. Doing so makes it much easier to analyze, compare, validate, and act on structured evidence than information buried in screenshots or hundreds of pages of documents. Leveraging machine-readable evidence also improves traceability because, instead of seeing only a pass or fail result, teams can understand exactly what was evaluated, including:

  • Which cloud resource was evaluated
  • Which AWS account and region it belongs to
  • What configuration was found
  • Which KSI the check relates to
  • How the result was validated
  • When the evidence was collected
  • What metric or finding came from that evidence

Another final point is that when something changes, the system can collect new evidence and compare it with what existed before in a structured, standardized format.

By connecting directly to AWS through APIs, a platform can continuously inspect cloud resources, configurations, permissions, network settings, logging, encryption, and other machine-readable security data, enabling teams to visualize:

  • Which Security Groups exist
  • Which resources they are attached to
  • Which inbound and outbound rules are configured
  • Whether Security Group rules allow inbound traffic from the public internet.
  • Which ports and protocols are allowed
  • Which AWS account and region the resource belongs to
  • Whether the configuration passes the validation logic defined for the KSI

Then, the platform can ingest and store both the result and the underlying evidence. A useful AWS compliance automation check should not simply return PASS or FAIL. An engineer, security reviewer, or assessor should be able to see which resource was evaluated, which configuration was found, which rule was applied, when the check ran, and why the platform reached its conclusion. This allows teams to evaluate the AWS environment that is actually running instead of relying only on documentation describing how the environment is supposed to be configured.

Lastly, this approach works the same way for Azure and GCP, making it possible to automate much of the evidence collection and validation across multi-cloud environments.

A FedRAMP 20X KSI and a NIST SP 800-53 control are not the same thing, and they do not map one-to-one. In fact, FedRAMP 20X was created to evolve toward a new framework that can operationalize controls and prove “What evidence shows that this security capability is actually working?”

To better understand their difference, NIST controls define individual security safeguards and requirements, while a KSI looks more broadly at a security capability. Because of that, a single KSI can relate to controls across several different NIST control families. So, NIST SP 800-53 remains the foundation for many of these requirements. However, instead of assessing each requirement only as an individual control, FedRAMP 20X uses KSIs to group related controls around broader security outcomes and gives providers more flexibility in how they demonstrate that those outcomes are working.

The main difference between the two frameworks is how they organize and validate security requirements. FedRAMP Rev. 5 is based entirely on NIST SP 800-53, so companies must comply with hundreds of individual controls, enhancements, parameters, documents, and supporting evidence. In other words, the process is much more control-by-control.

On the other hand, FedRAMP 20X is organized around Key Security Indicators, or KSIs. Importantly, KSIs are not simply another abstraction layer placed on top of NIST controls. Instead, they are designed to give cloud service providers more flexibility by focusing on broader security capabilities and then demonstrating that those capabilities are effectively working.

Note that the KSIs are still closely connected to NIST SP 800-53. In fact, FedRAMP identifies related NIST controls for each KSI so providers can understand how the two approaches connect. However, the relationship is not one-to-one because a single security capability often depends on controls from several different NIST families. For example, at first glance, you might expect an identity and access management KSI to relate mainly to Identification and Authentication controls, since those cover things like user identities, authentication methods, and credential management. Yet, proving that identity and access management is actually working requires much more. The same capability can also depend on:

  • Access Control, to define what authenticated users are actually allowed to access.
  • Audit and Accountability, to record login activity, privilege changes, and other identity-related events.
  • Personnel Security, to make sure access is granted, reviewed, and removed appropriately as people join, change roles, or leave the organization.

So, rather than looking at each NIST family in isolation, FedRAMP 20X looks at how several controls work together to provide a complete security capability. The new 20X framework allows security teams and organizations to automate checks for questions such as “Do we have an effective identity and access management capability?” or “Are our network security controls actually working?” Then, organizations can leverage all of the automated validations and evidence gathered to demonstrate how compliant and secure they are.

No, and this is actually an important distinction! 

FedRAMP does not issue ATOs, and there is no such thing as a single “FedRAMP ATO.” The difference matters because FedRAMP and the agency are responsible for two different parts of the authorization process.

  • FedRAMP 20X certification: This gives a federal agency the security information it needs, in a reusable and consumable format, to evaluate a cloud service. More importantly, the certification package lays out the controls, requirements, and shared responsibilities so the agency can clearly understand what the cloud service provider is responsible for and what the agency still needs to configure, manage, or secure on its side.
  • Authorization to Operate (ATO): The ATO is the agency’s decision to actually approve that cloud service for its specific use. The agency reviews the FedRAMP package together with its own architecture, data, integrations, configurations, and risk requirements. Then, based on that assessment, the agency’s Authorizing Official decides whether to issue the Authorization to Operate.

This is where FedRAMP provides a major advantage. Without that reusable authorization package, a cloud provider could end up going through a largely separate security architecture and assessment process for every federal agency it wants to work with. Instead, FedRAMP gives agencies a common security foundation they can start from, including a clear view of the shared responsibility model.

In short, FedRAMP 20X certification gives an agency the security information it needs to evaluate the product and understand its responsibilities, while the ATO is the agency’s final decision to approve that product for its specific use case.

Working with a security engineer experienced with FedRAMP (or other security frameworks) is extremely valuable for breaking down security requirements and implementing them across cloud environments like AWS, Azure, and GCP. Our team has firsthand experience helping clients with tasks such as:

  • Breaking down written security requirements into technical checks and implementation tasks.
  • Identifying which cloud services, resources, APIs, and configurations are relevant.
  • Defining what should count as compliant, what should trigger a warning, and what should fail.
  • Determining what evidence needs to be collected and stored.
  • Making sure security requirements are reflected in the architecture from the beginning.
  • Working with backend, cloud, DevOps, and product engineers to implement the controls correctly.
  • Helping the team avoid building something that works technically but is difficult to validate during a FedRAMP assessment.

If you need help with any of these, feel free to reach out to our team 🙂

AI Highlights Extractor

Key Highlights:

Loading...