FedRAMP compliance: How cloud providers earn and maintain certification

Even after a cloud service earns FedRAMP certification, compliance work continues as software changes and vulnerabilities emerge. Maintained, minimal base images can reduce inherited CVEs and the work required to evaluate and respond to them. Your team still needs to assess each finding in your service’s context and verify that fixes reach deployed workloads.

The 2026 vulnerability rules make that work more context-specific: providers must assess each finding for likely exploitability, internet reachability, and potential agency impact instead of relying on scanner severity alone.

Your service’s certification type, class, and path determine which ongoing obligations and response targets apply.

What is FedRAMP compliance?

FedRAMP is the U.S. government’s standardized framework for assessing the security of cloud services, established in 2011. It builds on federal information-security requirements under the Federal Information Security Modernization Act (FISMA).

FedRAMP generally applies when a cloud service creates, collects, processes, stores, or maintains federal information on a federal agency’s behalf. The agency determines whether its planned use of the service falls within FedRAMP’s scope, then FedRAMP certifies the cloud service offering and provides a certification package that agencies can reuse as security evidence. Each agency then makes its own Authorization to Operate (ATO) decision for the federal information system that uses the service.

There are two different types of FedRAMP certifications, each with its own certification path:

• 20x Certification emphasizes measurable security outcomes and persistent, increasingly automated validation. It uses the Program Certification path, which goes directly through FedRAMP without the need for an agency sponsor.

• Rev5 Certification organizes its requirements around NIST SP 800-53 Revision 5 controls. It almost always requires Agency Certification through a sponsoring government agency, although narrow temporary Program Certification routes are available to eligible providers.

What changes for CVE remediation in 2026?

The 2026 Consolidated Rules update to FedRAMP changes how providers must prioritize findings, set response targets, and document their decisions. Instead of relying primarily on scanner severity, teams must evaluate likely exploitability, internet reachability, and potential agency impact.

These rules don’t take effect all at once, so here are some key dates to remember:

• July 4, 2026: Optional adoption opened for the Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules.

• December 7, 2026: The new vulnerability rules take effect for services obtaining or maintaining FedRAMP certification. An existing certified service that has not completed the transition can maintain its certification only under a corrective action plan that includes notifying its agency customers.

• January 1, 2027: The broader Consolidated Rules reach their general mandatory-adoption milestone. Individual rulesets retain their own effective dates, so this does not replace the earlier December vulnerability-management deadline.

• March 7, 2027: The vulnerability-rules grace period ends. FedRAMP will revoke the certification of any service that has not adopted the rules by this date.

Prioritize findings by their effect on your service

In the past, Rev5-certified services followed duration-based mitigation windows for vulnerabilities. However, the new Vulnerability Evaluation and Reporting rules require you to evaluate mitigation based on likely exploitability, internet reachability, and potential agency impact.

You must also assume that exploitation can be automated unless you have evidence showing otherwise. A component can be internet-reachable even without a direct public route. Another part of your application may pass it a payload triggered by internet activity. Trace that path before treating the component as unreachable. Trace that path before treating a component on a private network as unreachable.

Evaluate base-image vulnerabilities in the context of your service, just as you would vulnerabilities in your own code. Trace how the affected component can be reached and assess its potential impact on agency customers. Document that analysis before setting a response target. Base images with fewer inherited CVEs can mean fewer findings for your team to evaluate and document. You can also consolidate logically related findings across affected resources when grouping them improves response efficiency and effectiveness.

Match the response to the applicable timeframe

After evaluating a finding, set its response target using its Potential Agency Impact N-rating (PAIN) rating, exploitability, internet reachability, and your service’s certification class. FedRAMP’s certification classes, from Class A through Class D, describe the depth of assessment coverage and assurance information available to agencies. These classes are distinct from Low, Moderate, and High system-impact categories and do not represent an inherent security rating for the service.

For example, a Class D provider should evaluate every detected vulnerability within two days. If exploitation could have a debilitating effect on more than one agency, assign a PAIN-5 rating. If the vulnerability is likely exploitable and internet-reachable, respond within 12 hours after completing the evaluation. The response should reduce the finding to a lower PAIN rating through partial mitigation, full mitigation, or remediation, in line with the Class D response timeframes. Use the ruleset for your service’s class when setting targets.

Note that both the two-day evaluation target and the 12-hour response target in this Class D example are “SHOULD” rule examples. A SHOULD rule permits a different approach when you have a valid reason and have considered the consequences. Document your reasoning in your security records.

Keep three timeframes separate:

• Evaluation target: Measured from detection. Delaying the evaluation can miss this target and leave the service exposed for longer.

• Response target: Measured from the completed evaluation, and met by mitigation or remediation as your class’s ruleset defines it.

• Supplier patching timeframe: Set by the supplier, with its own start and finish. Chainguard’s, for example, starts when a qualifying fix is publicly available and ends when the fix is published, not when it’s running in your environment.

The supplier’s clock doesn’t pause or replace either FedRAMP clock. In the Class D example above, the 12-hour response target can come due before any supplier fix exists, so plan for mitigation as well as patching.

If a patch isn’t available, you can block the exploit path by filtering or rejecting the triggering payload before it reaches the vulnerable component. Confirm that the control covers the relevant paths, retain the evidence, then reevaluate the vulnerability’s reachability and potential agency impact. Suppressing a scanner finding without evidence or a control that changes the underlying risk does not change that evaluation.

Record the response as engineers perform it

For each finding, record its detection time and source, the evaluation completion time, whether it is internet-reachable and likely exploitable, and any change in its PAIN rating. Your vulnerability reports must also document completed reductions in potential agency impact, the target and expected timing of the next reduction, and whether the vulnerability is or is likely to become overdue.

If you have not fully mitigated or remediated a vulnerability within 192 days of evaluation—or do not expect to do so—classify it as accepted. Accepted vulnerabilities have separate reporting requirements, including an explanation of why the vulnerability was accepted. Acceptance does not remove the vulnerability from reporting.

Connect these records to your deployment workflow. When a fixed base image becomes available, rebuild and test your application, deploy the updated image, and verify that affected workloads are running it. Retain evidence of the deployed image and that verification with the finding. A supplier’s publication shows that a fix is available; it does not establish that the vulnerability has been remediated in your environment.

How does FedRAMP compliance work?

The vulnerability rules above are part of the work required to sustain an ongoing FedRAMP certification. At a high level, preparing a cloud service for certification and keeping it certified involve four connected activities:

1. Define: Establish the service boundary and identify the applicable certification type, class, path, and rules.

2. Implement and assess: Implement the required security measures and, where required, have an independent assessor verify them and document the supporting evidence.

3. Certify and authorize: Complete the FedRAMP certification process for the cloud service offering. Each agency then makes its own risk decision and authorizes the federal information system that uses the service.

4. Monitor: Perform ongoing vulnerability detection, patching, and reporting at the intervals required for your service, and review significant system changes.

The exact requirements will depend on the service’s certification profile. Rev5 organizes its requirements around NIST SP 800-53 controls, while 20x emphasizes measurable security outcomes and persistent validation. In either case, initial certification establishes the service’s status, while ongoing certification requires the evidence to remain current as the service changes.

Security baselines and control families

National Institute of Standards and Technology Special Publication 800-53 (NIST SP 800-53) groups security controls into families, including Access Control, Incident Response, System and Communications Protection, and Configuration Management.

Federal agencies categorize their information systems under Federal Information Processing Standard 199 (FIPS 199), which defines three impact levels. NIST SP 800-53B provides a corresponding security control baseline for each level, and FedRAMP Rev5 uses tailored controls from those baselines. These impact levels describe the potential consequences of losing the confidentiality, integrity, or availability of federal information or systems:

• Low: Limited adverse effects on operations, assets, or individuals.

• Moderate: Serious adverse effects on operations, assets, or individuals.

• High: Severe or catastrophic adverse effects on operations, assets, or individuals.

The 2026 program uses certification Classes A through D to describe the depth of assessment requirements and the amount and frequency of assurance information available to agencies. These certification classes loosely align with the FIPS 199 impact levels, but there is no direct one-to-one mapping.

Agencies still categorize their own federal information systems under FIPS 199 and decide whether a service’s certification package supports their intended use. Providers should generally pursue the lowest certification class that meets their agency customers’ requirements and fits their business needs.

Maintaining certification as your service changes

An Authorization to Operate (ATO) records an agency's decision to accept the risk of operating its federal information system. When that system uses a FedRAMP-certified cloud service, the agency remains responsible for its authorization while the provider separately maintains the service’s FedRAMP certification.

Under the 2026 rules, ongoing certification means keeping the service certified by following the applicable FedRAMP practices. Continuous monitoring still supports that work. The Collaborative Continuous Monitoring rules require Ongoing Certification Reports every three months, summarizing changes, accepted vulnerabilities, reportable incidents, and other information agencies use to assess risk.

These reporting changes have their own transition dates. Existing Rev5-certified services should adopt the Collaborative Continuous Monitoring rules by April 2, 2027. A service that has not adopted them by then must operate under a corrective action plan during the grace period, which ends October 1, 2027. (Note that this later reporting transition does not change the December 7, 2026 deadline for adopting the Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules.)

Steps to become FedRAMP compliant

Documentation is essential to FedRAMP, but it must describe security measures that are implemented, repeatable, and supported by current evidence.

If your team is preparing a cloud service offering for certification, these steps will help you plan the work, although exact details depend on the certification type, class, path, and intended agency use.

1. Assess readiness: Compare your systems against the applicable FedRAMP requirements—Rev5 controls or 20x rules and Key Security Indicators—and identify gaps that could block certification.

2. Draw boundaries: Identify the information resources likely to handle federal customer data or affect its confidentiality, integrity, or availability. Document relevant information flows, dependencies, shared services, and responsibilities without unnecessarily pulling unrelated systems into the assessment.

3. Determine your certification type, class, and path: Select the lowest certification class that meets your agency customers’ requirements and business needs, then confirm the applicable path.

4. Complete the required assessment: For Classes B, C, or D, engage a FedRAMP Recognized independent assessment service to verify and validate your implementation. Class A instead builds on a qualifying assessment under an approved alternative security framework and follows that framework’s assessment requirements.

5. Build and maintain the certification package: Traditional Rev5 packages included a system security plan (SSP), security assessment report (SAR), and plan of action and milestones (POA&M). The 2026 package model moves away from the traditional SSP. The Certification Package Overview describes the offering. The Security Decision Record captures implementation decisions and supporting evidence. Each ruleset has its own transition date, so adopting the vulnerability rules does not change every package artifact at once.

6. Submit and respond: Submit the package through the applicable Program or Agency Certification path and address reviewer questions and findings until FedRAMP reaches a certification decision.

7. Operate continuously: Maintain the required security measures and certification data, evaluate and respond to vulnerabilities, and report changes, findings, and incidents at the required intervals.

Common challenges in achieving FedRAMP compliance

FedRAMP requires coordinated work across engineering, documentation, and assessment. Some costs come before certification. Teams also need to budget for vulnerability response, evidence upkeep, and change management after certification.

• Upfront time and cost: The timeline and cost of initial certification depend on the service’s scope, readiness, certification class, and path. Make sure to budget for internal engineering, applicable independent assessment, documentation, and ongoing monitoring, as well as outside advisory support if needed.

• Software vulnerabilities and patch chains: Managing CVEs takes engineering time, and manual patching can lead to version drift or missed fixes. When a supplier publishes a fix, update the pinned base-image digest, then rebuild, test, deploy, and verify that affected workloads run the new image—rebuilding from an old digest leaves the old components in place. Minimal images and supplier-maintained packages reduce inherited findings and upstream patching work, but your team still owns those deployment steps.

• Documentation and audit prep: An incomplete or outdated provenance trail slows assessment, and automating evidence collection takes time to set up. Manually assembling Software Bills of Materials (SBOMs), signatures, and provenance can leave your team scrambling to fill gaps mid-assessment. Tie those records to the image version actually deployed and its vulnerability findings.

• Container hardening and cryptography: Rev5 vulnerability-scanning guidance prioritizes applicable Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs), followed by Center for Internet Security (CIS) Benchmarks or another documented approach when neither is available. Meeting that guidance may add configuration scanning and image changes to your CI/CD workflow, but it doesn’t necessarily require a custom base image. Cryptographic requirements also vary by certification class. A validated cryptographic module still needs correct application integration, and hardening still leaves runtime and infrastructure config to your team.

• Evolving requirements and staggered transitions: FedRAMP's Rev5 and 20x rules keep changing, and during the 2026 transition, different FedRAMP rulesets take effect on different dates. Assign an owner to track the applicable deadlines and map each change to your controls, CI/CD workflows, certification data, and reporting processes.

How Chainguard helps companies achieve and maintain FedRAMP compliance

Chainguard Containers reduces the base-image CVEs your engineers have to manage. Our minimal container images leave out unnecessary packages, and we maintain the packages we supply. With fewer inherited findings, your team has fewer exploitability and reachability evaluations to complete and fewer response records to keep current.

We also publish updated base images, so your engineers can use maintained components instead of preparing those package fixes themselves. Your team still evaluates findings in the context of its service, then rebuilds, tests, deploys, and verifies each update. Reducing base-package upkeep gives engineers more time to complete that work within the applicable FedRAMP response windows.

These capabilities support that work:

• FIPS container variants: These images include FIPS-validated cryptographic modules, so your team does not need to prepare those components. ****Select the right variant and use its module in FIPS-approved mode.

• Minimal base images rebuilt daily: We maintain the supplied packages and publish updated images. Your team rebuilds, tests, and deploys its application on those updates. That cuts base-image patching, and your application code and any components you add stay with your team.

• Built-in SBOMs, provenance, and image signing: Use these image records to identify components and verify the artifacts you consume. Connect them to deployment and vulnerability records when preparing assessment evidence.

• STIG hardening support: For a supported subset of Containers, we supply image-hardening checklists. Application-specific configuration and runtime management stay with you.

• Ongoing CVE remediation: We patch covered images within published timeframes under our CVE policy, described in the next section.

• Proven FedRAMP success: See how Snowflake used Chainguard to streamline container vulnerability management on its FedRAMP High accreditation journey.

What Chainguard’s CVE policy covers

Our CVE policy applies to the latest version of each supported version stream of a Chainguard Container. When a CVE in a covered image has a qualifying patch (a verified upstream fix, or a rebuild with updated compilers or libraries), we use commercially reasonable efforts to patch it within these timeframes:

The commitment excludes end-of-life version streams, vulnerabilities without an assigned CVE, and backports into third-party software. Packages added through Custom Assembly may fall outside it, and a CVE in a FIPS-validated component may stay unpatched if fixing it would void the validation.

The policy counts a CVE as patched once the fix is published. Your team’s remediation is complete only after the updated image is deployed and verified.

Fewer inherited CVEs mean fewer findings to evaluate and document. Our published patching timeframes keep fixes coming for the images you build on. Talk to one of our experts.