Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Rev5 providers keep the legacy POA&M until they adopt FedRAMP’s 2026 vulnerability rules, which are required starting December 7, 2026.
- A scanner finding fixed before it’s past due needs no entry on the legacy POA&M, and a listed one closes once evidence of the fix is ready.
- Routine library patching skips agency approval under the legacy Playbook and notification under the 2026 rules.
- A patched component that a scanner still reports has no clear status under FedRAMP’s 2026 definitions.
If you’re a cloud service provider (CSP) shipping open source components, a fix for one can change what your plan of action and milestones (POA&M) has to say. The legacy guide doesn’t require you to list a scanner-found vulnerability you fix before it’s past due. A vulnerability already listed can move to Closed once corrective actions are applied and evidence of mitigation is ready for third-party verification.
FedRAMP’s legacy POA&M page is now marked reference only, and its 2026 Revision 5 (Rev5) Class C vulnerability rules have no POA&M rule for providers. Until you adopt those rules, which become required on December 7, 2026, you still keep the legacy POA&M. So what does a patch change about an item’s status, who verifies the new status, and which change process applies, before and after you switch? The answers sit in different documents, and none addresses a backported fix.
A patched component fits FedRAMP’s entry and closure rules, but the documents leave two gaps: whether an open source maintainer counts as a vendor, and what status the component has while a scanner still reports it.
Where the FedRAMP POA&M Stands Today
Under the legacy Rev5 process, you keep the POA&M in FedRAMP’s template. The legacy guide to that template, the POA&M Template Completion Guide (version 2.2, November 23, 2021), describes the POA&M as a record of the system’s known weaknesses and security deficiencies, paired with the corrective activities you plan. You upload an updated copy each month as part of your continuous monitoring cycle, and the agency’s authorizing official (AO) reviews it per the legacy Continuous Monitoring Playbook. Since June 24, 2026, FedRAMP’s legacy site has described its POA&M page and Playbook as reference only during the transition to the 2026 rules.
FedRAMP’s Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules opened for optional adoption on July 4, 2026. They become required for Rev5 providers on December 7, 2026, and the grace period ends March 7, 2027. Their mitigation and remediation timeframes start when the provider evaluates a vulnerability, and providers must report vulnerability detection and response activity to all necessary parties at least monthly.
The rules quoted here are FedRAMP’s Class C versions. FedRAMP says Class C covers most Low and Moderate security objectives, and providers certified at Class B or D should check their own class’s rules. In the Rev5 Class C rules, the only POA&M rule is Maintain Agency Plans of Action and Milestones (VER-AGM-MAP), and it’s addressed to agencies. It says they SHOULD use what you report to maintain POA&Ms for their own security programs when agency policy calls for it. FedRAMP defines SHOULD as a rule a party may depart from for valid reasons if it documents the decision, and MUST as an absolute requirement. FedRAMP’s summary of the 2026 changes says POA&Ms “have been eliminated entirely.” Any POA&M under the 2026 rules is an agency’s own, built from your reports.
How an Item Enters and Leaves the POA&M
Under the legacy guide, timing decides whether a scanner finding reaches the FedRAMP POA&M during continuous monitoring. You list it once it’s past due (30, 90, or 180 days from discovery, depending on severity). Findings from other sources, such as penetration tests and interviews, go on whether or not they’re past due. So does each item with a deviation request, the form you submit to your AO for a false positive, a risk adjustment, or an operational requirement. A footnote notes that any service-level agreement or AO preference still applies, and either can call for a listing of all open risks.
Under the guide, an item can move to the Closed worksheet once you’ve applied all corrective actions and have “evidence of mitigation” ready for inspection. A third-party assessment organization (3PAO), the legacy term that the 2026 definitions replace with assessor, verifies the evidence during initial and periodic assessments, and your AO may request it at any time. An item can also move there when your AO approves a false positive deviation request. Vendor dependencies, which await a vendor’s fix, and operational requirements, which the legacy POA&M page describes as findings that can’t be remediated, remain on the Open worksheet.
Note: The legacy guide says that false positives identified in the Security Assessment Report (SAR), backed by supporting evidence such as a clean scan report, don’t have to be included in the POA&M.
| Stage | Legacy documents | 2026 rules | Basis |
|---|---|---|---|
| Enters | Scanner findings once past due. Other findings, whether they are past due or not. Items with deviation requests. | A monthly report of vulnerability detection and response activity to all necessary parties. No 2026 rule requires providers to keep a POA&M. | Legacy guide §3; VER-TFR-MHR and VER-RPT-VDT (2026, MUST) |
| When no fix lands | Vendor dependencies and operational requirements stay open. | A vulnerability that is not, or is not expected to be, fully mitigated or remediated within 192 days of evaluation is labeled an accepted vulnerability. | Legacy POA&M page (reference only); VER-TFR-MAV (2026, MUST) |
| Closes | Corrective actions applied with evidence of mitigation, or an AO-approved false positive. | No closed status is defined. Remediated (neutralized or eliminated, no longer detected) is the end state, with a final disposition in the report. | Legacy guide §2.2; 2026 Definitions; VER-RPT-VDT (2026, MUST); VDR-CSO-RES |
| Verified by | A 3PAO, during initial and periodic assessments. The annual assessment’s scope also covers closed items, vendor dependencies, and deviation requests. The AO approves false positives. | The Rev5 Class C VDR and VER rules don’t name anyone. A yearly independent assessment covers all applicable rules. | Legacy guide §2.2; legacy Annual Assessment page; VDR and VER (2026); IVV-CSO-FIA (2026, MUST) |
| Kept by | The CSP, with the AO reviewing monthly. | Agencies, for their own programs. | Legacy Playbook, Overview; VER-AGM-MAP (2026, SHOULD) |
What a Patched Component Changes
In this article, a patched component is a library or package you deploy after a maintainer, vendor, or another party supplies a fix. It’s not a FedRAMP term.
Entry and closure are separate events in the legacy guide. If you deploy a fix before a scanner-found vulnerability is past due, the guide doesn’t require an entry for it. If the item is already listed, the deployed fix counts as one of your corrective actions, and closure follows the guide’s two routes.
A vendor dependency follows a different timeline. The legacy POA&M page ties it to a downstream vendor, such as the maker of a commercial off-the-shelf (COTS) product, whose fix isn’t available yet. A high-risk vendor dependency still has to be mitigated to a moderate through compensating controls within 30 days. Once the vendor makes the fix available, the guide starts the remediation period on that date, asks you to record the release date, and allows you to overwrite the scheduled completion date.
The legacy POA&M page also advises providing evidence of vendor interactions about patch status, such as notifications and email exchanges. That’s a different kind of evidence from the evidence of mitigation that closes an item.
Deploying the fix is also a change. The legacy Playbook sorts changes into routine recurring, adaptive, and transformative. It classifies minor, incremental patches with no breaking changes, including routine library patches, as routine recurring changes that don’t require AO review and approval. Updates to libraries with known breaking changes are an example of an adaptive change, which does.
The 2026 Significant Change Notification (SCN) rules keep those three types. Under the Evaluate Changes rule (SCN-CSO-EVA), you evaluate each potential significant change to find its type. The No Notification Requirements rule (SCN-RTR-NNR) states that providers SHOULD NOT send formal notifications for routine recurring changes. FedRAMP gives SHOULD NOT the same latitude as SHOULD. Its examples still include routine library patching. Under the Notification Requirements rule (SCN-ADP-NTF), you give notice within 10 business days after an adaptive change finishes. The SCN rules will be required for Rev5 providers starting January 1, 2027.
What the Documents Leave Open
Responsibility stays with you, whoever writes the fix. The Vulnerability Response rule (VDR-CSO-RES) places the responsibility for tracking, mitigating, and remediating detected vulnerabilities on the provider. The Vulnerability Detection rule (VDR-CSO-DET) lists supply chain monitoring among the ways a provider detects them, so you must also detect vulnerabilities that come with a component.
When you’re waiting on someone else’s fix, the legacy documents offer the vendor dependency status, but neither the guide nor the POA&M page says whether an open source maintainer counts as a vendor. If one does, a vulnerability still awaiting its maintainer’s fix can remain open, with monthly check-ins. If not, it goes past due like any other scanner finding. That’s the first gap.
A patched component whose fix leaves the version number unchanged may continue to appear in scan results after you deploy it. Red Hat’s security backporting documentation explains why: some scanning and auditing tools determine whether a component is vulnerable based solely on its version number. Those tools flag a component as vulnerable when a fix taken from a newer release is applied to an older version.
In FedRAMP’s 2026 definitions, a remediated vulnerability is neutralized or eliminated and no longer detected. A fully mitigated one has negligible risk but is still detected. A false positive is a detected vulnerability that isn’t actually present and never was. The legacy guide ties closure to evidence of mitigation, and the 2026 rules keep mitigation and remediation apart (VDR-CSO-RES).
Note: FedRAMP’s definition of false positives also excludes remediated and fully mitigated vulnerabilities.
Take a patched component that a scanner still reports. Under those definitions, it isn’t remediated while it’s detected, and it isn’t a false positive because the vulnerability was present before the fix. Fully mitigated comes closest in wording, but none of the documents named in this article say so for a fix that leaves the version number unchanged.
The legacy guide leaves the status open too. You can close an item on evidence of mitigation, or you can ask your AO to approve a false positive. The guide doesn’t specify which one applies to a patched component that a scanner still reports. The same problem hits at entry: a finding that a scanner keeps reporting can go past due even though you fixed it.
That’s the second gap. Before you switch, ask your AO or assessor which status they expect for this component in the legacy POA&M and in your 2026 vulnerability reports. Also ask whether they treat an open source maintainer as a vendor.
Getting a Fix Without Waiting on the Maintainer
SecureChain from TuxCare screens the source code of open source packages for malware, rebuilds them from that code in isolated environments, and blocks packages that fail inspection before they reach your environment. Under a service-level agreement, SecureChain patches active components. For versions that upstream maintainers no longer support, Endless Lifecycle Support (ELS) backports fixes for critical, high, medium, and low-severity vulnerabilities to the versions in use. Together, SecureChain and ELS cover JavaScript, Python, Java, Go, PHP, and Rust. SecureChain’s records about what it delivers include Supply-chain Levels for Software Artifacts (SLSA) Level 3 provenance, a software bill of materials (SBOM), and Vulnerability Exploitability eXchange (VEX) data. VEX data can state that a package already contains the fix for a vulnerability. That gives your AO or assessor a record to check when a scanner still flags the package.
If you can’t say where the fix for a component will come from once its maintainer stops, or which vulnerabilities a component brought into your service, see how SecureChain for Open Source Software approaches both.
FAQ
What Is a POA&M in FedRAMP’s Documents?
A plan of action and milestones (POA&M) is, in FedRAMP’s POA&M Template Completion Guide (version 2.2, November 23, 2021), a record of a system’s known weaknesses and security deficiencies, paired with the corrective activities a cloud service provider (CSP) plans. FedRAMP has marked its legacy POA&M page as reference only since June 24, 2026.
Who Maintains and Reviews a POA&M?
In the legacy Continuous Monitoring Playbook, the cloud service provider (CSP) uploads an updated plan of action and milestones (POA&M) monthly, and the agency’s authorizing official reviews it. FedRAMP has marked the Playbook as reference only since June 24, 2026. Under rule VER-AGM-MAP in the 2026 Vulnerability Evaluation and Reporting rules, agencies SHOULD (are recommended to) maintain their own POA&Ms when their security policies call for it.
What Does a Provider’s Vulnerability Report Include Under the 2026 Rules?
Rule VER-RPT-VDT of FedRAMP’s Vulnerability Evaluation and Reporting rules, required from December 7, 2026, lists what a provider reports on each detected vulnerability. Examples include detection time and source, internet reachability, likely exploitability, estimated harm to agencies (the Potential Agency Impact N-rating), and final disposition. Accepted vulnerabilities, which are not, or are not expected to be, fully mitigated or remediated within 192 days of evaluation, are listed separately.
When Do FedRAMP’s 2026 Significant Change Rules Apply?
Optional adoption of FedRAMP’s Significant Change Notification rules in the Consolidated Rules for 2026 began July 4, 2026. For Revision 5 (Rev5) providers, they’re required from January 1, 2027, and the grace period ends on June 1, 2027. The vulnerability rules run on their own dates.
What Do Significant Change Requests and Notifications Say About Related Vulnerabilities?
A legacy significant change request lists the related plan of action and milestones (POA&M) item when the change addresses a known risk, according to the legacy Continuous Monitoring Playbook, which FedRAMP now marks as reference only. Under rule SCN-CSO-INF of the 2026 Significant Change Notification rules, a notification must include the related vulnerability, if applicable, among other required details.
