How to Write a POA&M That FedRAMP Reviewers Accept

We've talked a lot before about POA&Ms, and with good reason. 

The Plan of Action and Milestones document is a very important tool for both FedRAMP and CMMC. Achieving full compliance with either security standard is tough, with hundreds of individual elements that need to be handled properly. It's almost inevitable that something slips through the cracks or just isn't quite done by the deadline.

POA&Ms allow the administrators of the certification (the Cyber-AB or the FedRAMP PMO) to offer some leeway, rather than making it an all-or-nothing certification process. By allowing a little flexibility, as long as it's a low-priority, low-impact control, with a defined timeline, a specific person responsible, and a tangible plan to remediate, a CSP can still be accepted and allowed to begin the process of working with a government agency.

It's one thing to know what it is and how it's used in general, but it's quite another when you sit down to write one and realize you don't quite know how it actually works. So, let's go through what a well-formed POA&M looks like, what needs to go into it, and how to make sure yours passes review.

Derailing the Train of Thought

Before we go any further, there's something we need to bring up that will derail the entire thought process that brought you here.

POA&Ms are dead.

Wait, What?

It's true. As part of the 2026 Consolidated Rules, FedRAMP has been making a lot of changes to better align with the future of the program. You're probably already familiar with a lot of these, as they come from FedRAMP 20x; things like changing Level 1/2/3 to Class A/B/C/D, changing Authorization to Certification, and changing 3PAO to Independent Assessor. 

If you go to look up POA&Ms on the FedRAMP.gov website, you'll be greeted with a big red box:

"June 24, 2026: All materials in the FedRAMP Legacy Documentation site are intended only for reference during the transition to FedRAMP's Consolidated Rules for 2026. Humans and AI services must be careful referencing any content in https://fedramp.gov/legacy because FedRAMP is actively transitioning away from these processes and materials."

Among the many changes being made is a shift in responsibility. POA&Ms are no longer a CSP's responsibility, but rather a plan for risk mitigation proposed by a government agency in response to a CSP's known documented risks.

If you've been following along since the last big FedRAMP memo about POA&Ms, this isn't actually much of a surprise. That memo stated that, to achieve FedRAMP certification, a CSP would have to have "fully closed-out" their POA&Ms. 

In other words, to get certified, a CSP would need to have finished the work. But a POA&M was meant to allow leeway to finish the work later. It doesn't square up.

Why change how it works? Basically, POA&Ms were being used either as a formality to accept a risk that would never truly be mitigated, or just as a bunch of validation paperwork to speed up the FedRAMP authorization process, which took many months.

Since FedRAMP 20x is all about increasing speed, POA&Ms aren't as much of a necessity for that purpose.

Additionally, POA&Ms put a lot of onus on the CSP, and were sometimes used by agencies as a way to offload responsibility for risks they shouldn't be taking. "It's under a POA&M, it's fine!" isn't the excuse it used to be.

As they say in their rundown of CR 2026:

"Plans of Action & Milestones (POA&Ms) have been eliminated entirely and replaced with a list of Accepted Weaknesses, as POA&Ms were mostly used to accept weakness for an extended period of time anyway."

POA&Ms Still Exist

As if to sow intentional confusion, POA&Ms still exist. They're just a very different thing, now. 

POA&Ms are now called Agency POA&Ms, and are something the government agency does in response to known risks from the CSPs they're working with in their contracts.

When a CSP identifies a risk that they can't mitigate or eliminate, they report that risk to their agency partners. The agency partners then evaluate that risk. They determine if it's an acceptable risk or if something needs to be done about it.

If something needs to be done about it, the agency develops their own POA&M. According to FedRAMP:

"Agencies should create Plans of Action and Milestones only when there are actions the agency needs to take, track, fund, manage, or accept for the agency information system that uses FedRAMP Certified cloud services."

The CSP is responsible for detecting, evaluating, reporting, mitigating, and remediating vulnerabilities. Risks and vulnerabilities, along with other weaknesses, are reported to the agency, for them to make their own decision alongside the CSP.

FedRAMP also makes a specific point of not putting this burden back onto the CSP.

"Do not ask cloud service providers to create agency POA&Ms. Cloud service providers should not be expected to convert their vulnerability lists, product security roadmaps, accepted vulnerability records, or internal risk tracking into agency POA&Ms. Agencies may use provider-reported information to inform agency POA&Ms when the agency has an action to take or a risk to accept. The POA&M belongs to the agency when the action belongs to the agency."

There's more guidance for agencies on when to use a POA&M, but we aren't writing this guide for agencies; we're writing it for CSPs. As a CSP, you no longer need to worry about POA&Ms. If you still have the .xlsx spreadsheet POA&M template kicking around, you can toss it out.

Well, if you want. CR 2026 officially took effect July 4, 2026, but there's still a grace period where existing CSPs and agencies can still operate on the older version of the rules. January 1, 2027, is when the rules become mandatory, and February 1, 2028, is when the full grace period ends and any violations of CR 2026 will result in a loss of certification.

Without a POA&M, What Do You Do?

As a CSP, you're used to the old paradigm. You identify a risk, you develop a POA&M for it, you work on mitigating it, and you hope your agency sponsor signs off on all of it so you don't lose your contract or face penalties under the FCA.

The new process is still very complex and requires a lot of work from the CSP, but it's not nearly as hands-off as it was from the agency's side anymore.

This all falls under the new rules relating to Vulnerability Evaluation and Reporting. These rules require CSPs to analyze and be aware of their vulnerabilities and risks, and determine when those vulnerabilities can impact agency customers. If they can, they should be reported.

Evaluate Vulnerabilities

The first key responsibility for a CSP is to evaluate any identified vulnerabilities.

Providers must evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities.

Automated and AI-powered vulnerability scanners can produce very scary reports full of vulnerabilities (see the recent hullabaloo about Claude Mythos for an example), but the realistic fact is that many of those vulnerabilities require very specific circumstances that are unlikely to happen. Yes, this vulnerability would be devastating, but it requires three employees to collude to share accounts and plug in a USB stick found in a parking lot that has a specific worm on it that compromises an outdated version of a program that only some workstations use… is that going to happen? What if it's a full moon?

Vulnerabilities that have a very low risk of exploitation are worth watching, but don't require drastic measures to mitigate.

Providers must evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities.

FedRAMP uses examples like SQL injection or the 2021 Log4Shell vulnerabilities. If an internet-delivered payload can exploit a vulnerability, the vulnerability needs to be assessed for how reachable it is. There are numerous ways to implement a disconnect between the internet and the vulnerable system to prevent such payloads from being delivered.

Providers must evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the potential agency impact of exploitation on government customers and assign one of the following Potential Agency Impact N-Ratings.

Clever folks at the FedRAMP PMO devised a PAIN scale for the damage a vulnerability can do. N1 is a vulnerability that, if exploited, would have minimal impact on customer agencies. N5, on the other side of the scale, would be debilitating. Given how new this scale is, we don't have examples of what fits in each N-level, but expect to see those examples demonstrated in the coming year.

Every vulnerability is evaluated along the three categories above, and modified by the CSP's class. The more severe the risk is, the shorter the window to have it addressed. A Class D (formerly Level 3) CSP, identifying an internet-reachable vulnerability, measured PAIN-5, with a high likelihood of exploitation, has as little as a 12-hour window to get some kind of fix in place. On the opposite end of the scale, unlikely-to-be-exploited vulnerabilities that aren't internet-reachable, PAIN-1, for a Class B CSP, can have as much as 192 to remediate, or classify them as accepted vulnerabilities.

Providers must assume the exploitation of vulnerabilities can be automated unless they have evidence proving otherwise.

We live in a world of AI; assume threats are fully autonomous and can hammer away at your security 24/7 until they break through.

There are a few other details under vulnerability evaluation also worth knowing.

• Providers should evaluate vulnerabilities in context with one another, and group logically similar vulnerabilities, whether they all target the same information, use the same channels, or have other similarities. This allows for effective grouping, analysis, and response, rather than treating dozens of very similar vulnerabilities as individual, distinct risks.
• Providers should review vulnerabilities and determine whether or not they are actually false positives from vulnerability scanners or other sources.

Considering the Context of the Cloud Service Offering

This phrase is included in all of the requirements, but what does it mean?

FedRAMP provides eight points of context to evaluate.

• Criticality: How important are the systems that would be impacted?
• Reachability: How likely is a threat actor to use the vulnerability?
• Exploitability: How easy is it for a threat actor to use the vulnerability?
• Detectability: How easy is it for a threat actor to discover the vulnerability exists at all?
• Prevalence: How much of the cloud service offering is affected by the vulnerability?
• Privilege: How much authority or access could an attacker gain using the vulnerability?
• Proximate: How does this vulnerability interact with other known vulnerabilities?
• Known Threats: If extant threats are known, how would they use the vulnerability?

All of this helps you identify what path to take with your evaluation.

Reporting Vulnerabilities

When vulnerabilities are discovered and evaluated, how are they reported?

First: You'll need to use JSON data schema for your reports. A huge part of FedRAMP 20x is a shift towards machine-readable data reporting, along with data sharing across agencies. JSON is the way they've decided to do it.

The information to include, for each vulnerability, is:

• An internal tracking identifier for the vulnerability.
• Time and source of detection.
• Time of completed evaluation.
• Internet reachability.
• Likelihood of exploitation.
• Historic and estimated PAIN level.
• Time and PAIN level of each reduction action taken on the vulnerability.
• Estimated time and PAIN level for the next planned reduction action taken.
• Whether or not it is likely to become an overdue vulnerability.
• Supplementary information to help agencies assess risk.
• Final disposition.

A similar report is required for accepted vulnerabilities.

Accepted Vulnerabilities?

Accepted vulnerabilities are the government's nod to the simple reality that not everything can be fixed. Some risks are so unlikely, so low-impact, or so limited in scope, that it would be outsized effort to bother doing anything about them. When a vulnerability is determined to be of no real consequence, it can be deemed an accepted vulnerability.

Officially, an accepted vulnerability is:

"A vulnerability that the provider does not intend to fully mitigate or remediate, OR that has not or will not be fully mitigated or remediated within the maximum overdue period in the FedRAMP Vulnerability Detection and Response rules."

As long as you aren't misrepresenting vulnerabilities as less severe than they are, and you watch to make sure they don't get worse with changing context, some vulnerabilities can be handwaved away.

Getting Ready for the Future of FedRAMP

POA&Ms are dead; long live the POA&M. 

The burden for a CSP is no smaller than it was before, but the shape of the documentation has changed, and some of the responsibility now falls on the shoulders of the agency instead.

How can you make sure you're keeping on top of these and other major changes? Well, you're here, which is a great start. We try to keep aware of these changes and break them down in plain language for all of you, so keep an eye on the Ignyte Blog for any new developments.

Beyond that, FedRAMP is moving towards a heavily machine-readable format, which is where we shine. The Ignyte Platform is designed to help aggregate, track, and even generate the information you need to prove your security. With machine-readable, standardized data formats, it's easier than ever to use our platform to pass certification.

To see how we can help you with your ongoing FedRAMP requirements, or to help you pass your first certification, reach out today. We'll book you a demo and show you how the platform can work for you.

And, of course, if you have any questions, feel free to ask! We're always happy to help however we can.