US federal · FedRAMP and CMMC
FedRAMP and CMMC with end-of-life software
A FedRAMP or CMMC system can run end-of-life software only if each known flaw is identified, reported and corrected in time, or formally accepted and reported. NIST SP 800-53 SI-2 and SP 800-171 3.14.1 set that duty, SA-22 allows an alternative source of support for components the vendor dropped, and FedRAMP's 2026 rules set maximum fix times by class.
Published . Clause text checked 26 October 2026against the sources listed at the foot of the page. OSSeva's evidence supports your own assessment; it does not make you compliant.
Scope
FedRAMP or CMMC: which one binds you
Both lean on NIST, but they bind different people. FedRAMP certifies a cloud service offering that federal agencies use. CMMC is the Department of Defense program for contractors that handle federal contract information or controlled unclassified information. The open source component is inside your boundary either way, so the duty to correct its flaws is yours, whoever wrote the code.
| Topic | FedRAMP (Rev5) | CMMC |
|---|---|---|
| Who it applies to | A cloud service provider (CSP) whose offering federal agencies use | A defense contractor or subcontractor with FCI or CUI on its systems |
| Flaw-remediation basis | NIST SP 800-53 Rev. 5 SI-2, plus the FedRAMP vulnerability rules | FAR 52.204-21 (Level 1) and NIST SP 800-171 Rev. 2, requirement 3.14.1 (Level 2) |
| Who assesses | Independent assessors and the agency, under FedRAMP's rules | Self-assessment, a C3PAO, or DIBCAC, by level |
| What an unfixed flaw becomes | An accepted vulnerability, reported with a reason | A NOT MET finding, with narrow room for a POA&M |
FedRAMP
FedRAMP: the 2026 remediation timeframes
FedRAMP's Consolidated Rules for 2026 replace one list of days by severity with timeframes that depend on three things: the Potential Agency Impact N-rating (PAIN), whether the flaw is likely exploitable (LEV) and whether it is internet-reachable (IRV). FedRAMP marks the timeframes as maximums to beat, and the clock runs from evaluation. The Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) rules become mandatory for offerings obtaining or maintaining certification on 7 December 2026, with a grace period to 7 March 2027 under a corrective action plan, according to FedRAMP notice NTC-0014.
If your documents quote fixed 30, 90 and 180-day windows by severity, check them against the current rules, which no longer list timeframes that way. This page covers Rev5 certification for vulnerability management. FedRAMP 20x offerings follow their own rulesets.
| PAIN rating | Class B | Class C | Class D |
|---|---|---|---|
| PAIN-5 | 4 days / 8 days / 32 days | 2 days / 4 days / 16 days | 12 hours / 1 day / 8 days |
| PAIN-4 | 8 days / 32 days / 64 days | 4 days / 8 days / 64 days | 2 days / 8 days / 32 days |
| PAIN-3 | 32 days / 64 days / 192 days | 16 days / 32 days / 128 days | 8 days / 16 days / 64 days |
| PAIN-2 | 96 days / 160 days / 192 days | 48 days / 128 days / 192 days | 24 days / 96 days / 192 days |
Each cell reads: likely exploitable and internet-reachable / likely exploitable but not internet-reachable / not likely exploitable. The page lists PAIN-2 to PAIN-5. Source: rule VDR-TFR-PVR, marked SHOULD for each class. For known exploited vulnerabilities, providers should remediate by the due date in the CISA catalog (VDR-TFR-KEV).
FedRAMP
What happens to a flaw with no upstream fix
On an end-of-life line the project publishes no fix, so the timeframes above have nothing to count against unless someone ships the patch. The 2026 rules do not ban the component. They tell you what to do with the flaw, in order, and the last step is where an ended line ends up if no patch arrives.
| Step | Rule | What it means for an ended line |
|---|---|---|
| 1. Detect | VDR-CSO-DET: providers must systematically, persistently and promptly discover vulnerabilities. | The ended component is scanned like any other. Its end-of-life date is a fact to record. |
| 2. Evaluate | Providers evaluate whether each flaw is likely exploitable (VER-EVA-ELX) and internet-reachable (VER-EVA-EIR), and assume exploitation can be automated unless they have evidence otherwise (VER-EVA-AIA). VER-TFR-EVU asks for this within 7 days of detection (should, Class B). | A VEX statement that a CVE does not affect the build, with a reason, answers the evaluation. For a CVE that does, the rating and reachability set the clock. |
| 3. Mitigate or remediate | VDR-CSO-RES: respond to every detected vulnerability. If full remediation is not possible, partially mitigate promptly and progressively. | A patched build is remediation. Isolation or removal of internet reachability is partial mitigation that lowers the rating. |
| 4. Accept | VER-TFR-MAV sets 192 days for marking a vulnerability as accepted when it is still not fully mitigated or remediated. | An ended line with no patch source reaches this step. A patched build keeps it out. |
| 5. Report | VER-RPT-AVI: accepted vulnerabilities are reported with a reason for acceptance. CCM-OCR-AVL: the Ongoing Certification Report, every three months under the Collaborative Continuous Monitoring rules, summarises accepted vulnerabilities. | Agencies see the accepted list. A CVE record per release shows what was fixed and when. |
CMMC
CMMC: levels, controls and the POA&M limit
CMMC maps flaw remediation to a different requirement at each level. 32 CFR 170.14 states that Level 2 requirements are identical to NIST SP 800-171 Rev. 2, so for most contractors the one that matters is 3.14.1, "Identify, report, and correct system flaws in a timely manner." The discussion in 800-171 says organizations set their own time periods, based on factors including how severe the flaw is.
| Level | Information protected | Flaw-remediation requirement | Assessment |
|---|---|---|---|
| Level 1 | Federal contract information (FCI) | FAR 52.204-21(b)(1)(xii): identify, report and correct information and information system flaws in a timely manner. 15 requirements in all. | Self-assessment. No POA&M is permitted. |
| Level 2 | Controlled unclassified information (CUI) | SI.L2-3.14.1, identical to NIST SP 800-171 Rev. 2 3.14.1. It is worth 5 points in the scoring methodology. | Self-assessment or a C3PAO, as the contract requires. |
| Level 3 | CUI, for contracts that call for Level 3 | 24 selected NIST SP 800-172 requirements. SI.L3-3.14.1e asks you to verify the integrity of security-critical and essential software using root of trust mechanisms or cryptographic signatures. | DIBCAC (DCMA) assessment. |
DoD is phasing CMMC into contracts (32 CFR 170.3(e)). Phase 1, which asks for Level 1 or Level 2 self-assessments at award, began with the DFARS rule on 10 November 2025. Phase 2 begins one calendar year after Phase 1 and adds Level 2 certification by a C3PAO at award, which DoD intends to require. The solicitation tells you which level and status your contract needs.
Unfixed flaws
POA&M, accepted vulnerabilities and what each lets you carry
The two programs treat an unfixed flaw very differently. FedRAMP lets a provider carry an accepted vulnerability if it is evaluated, reported and justified. CMMC lets a contractor carry a POA&M item only in narrow cases, and 3.14.1 is not one of them.
| Topic | FedRAMP 2026 rules | CMMC (32 CFR 170.21 and 170.24) |
|---|---|---|
| What you can carry | An accepted vulnerability, reported with a reason and its N-rating. | A POA&M item, only for a requirement worth 1 point. SI.L2-3.14.1 is worth 5 points, so it cannot sit on a POA&M. |
| Threshold | 192 days to mark a vulnerability accepted; rating reductions inside the class timeframes. | A score of at least 80 percent of the Level 2 total for Conditional status, and POA&M closeout within 180 days of that status date. |
| What helps an ended line | A patched build moves the vulnerability to fixed, with the evidence in the next report. | The scoring methodology treats an enduring exception that the system security plan describes with its mitigations as MET. |
NIST
SI-2, SA-22 and 3.14.1: what the controls say
These three NIST controls sit behind both programs. SI-2 and 3.14.1 ask for correction of flaws. SA-22 is the one written for components the vendor has stopped supporting, and it names a route that fits extended support.
| Control | What it asks | OSSeva evidence | What stays with you |
|---|---|---|---|
| SI-2 Flaw Remediation (NIST SP 800-53 Rev. 5) | Identify, report and correct system flaws; test updates before installation; install security-relevant updates within an organization-defined period; build flaw remediation into configuration management. FedRAMP lists SI-2 for Rev5 Classes B, C and D. | CVE records and VEX statements to identify and report; a patched build inside the patch window to correct. Critical CVEs are patched within 48 hours and High within 7 days. | Testing, installing within your defined period, and configuration management. |
| SA-22 Unsupported System Components | Replace components when the vendor no longer supports them, or provide options for alternative sources of continued support. The discussion says contracts with external providers can include open-source software value-added vendors, and that isolating a component reduces the added risk. | A patched build from an alternative source of support, for an open source line the project has ended. | The SA-22 decision, the choice between replacing and supporting, and any isolation. FedRAMP lists SA-22 for Rev5 Classes B, C and D. |
| SP 800-171 Rev. 2 3.14.1, CMMC Level 2 | Identify, report and correct system flaws in a timely manner. | CVE records and VEX statements to identify and report; a patched build inside the patch window to correct. | Scoping, your system security plan and the assessment with your assessor. |
Evidence
Evidence an assessor can use
OSSeva supplies the same pack for a patched build whatever the program. The compliance matrix lists it against every clause. Compliance documentation is part of OSSeva Assure and is delivered under NDA, and OSSeva's SOC 2 Type II report is available under NDA for vendor risk review.
| Item | What it records | Supports |
|---|---|---|
| CVE record and attestation letter | CVE id, CVSS, affected versions, patch delivery date and build identifier for each release. | SI-2 and 3.14.1 (report and correct); FedRAMP report of what was fixed and when |
| VEX statement per CVE | Whether the CVE is fixed in this build or does not affect it, with the reason. | FedRAMP evaluation (VER-EVA); SI-2 and 3.14.1 (identify) |
| Patched build | The build with its release date, signed with GPG or cosign and a SHA-256 checksum. Patches apply to upstream source, with no fork. | SI-2, 3.14.1, SA-22 |
| SBOM | The components in the patched build, in CycloneDX or SPDX. | Identifying which systems an announced flaw affects |
| Assure documentation | Evidence matrices and remediation records for the frameworks your auditors use. | Your assessment file |
A signed build you can verify is an input to integrity checks such as SI.L3-3.14.1e; whether it satisfies that requirement is for DIBCAC. Verify signatures with the steps on the security page. For public-sector buyers, see OSSeva for public sector, and for how assessors read this evidence, see what auditors accept for end-of-life software. The longer treatment of SA-22 is in NIST SA-22 and unsupported system components.
Service levels
Service levels and what drives the price
Critical CVEs are patched within 48 hours and High within 7 days, for every technology OSSeva supports. OSSeva Operate adds 24/7 coverage with a 15-minute P1 response, a 1-hour P2 and a 4-hour P3. OSSeva Assure includes 24/7 reactive support and the audit evidence. OSSeva does not publish prices. Support is priced per cluster, in three tiers (Patch, Assure and Operate), and the drivers are how many clusters and which technologies and versions are in scope, and the tier.
Not a fit for
- You want a FedRAMP or CMMC authorisation from OSSeva. OSSeva makes no FedRAMP certification or authorization claim and is not a cloud service provider, a C3PAO or a 3PAO. It supplies patched open source builds you install inside your own boundary.
- You need an assessor. OSSeva does not certify that you comply with FedRAMP, CMMC or NIST, and it does not file reports for you.
- You need a 3.14.1 fix on a POA&M. CMMC does not allow that requirement on a POA&M, so the flaw has to be corrected or described as an enduring exception in the system security plan.
- Your component is closed source. OSSeva patches open source lines; check yours on the supported versions page.
Can a FedRAMP system run end-of-life software?
The FedRAMP 2026 rules do not ban it by name. They require the provider to detect and respond to every vulnerability, to evaluate each one, and to mitigate or remediate within class timeframes. A vulnerability still not fully mitigated or remediated at 192 days is marked as accepted and reported with a reason. NIST SA-22, which FedRAMP lists for Rev5 Classes B, C and D, asks you to replace unsupported components or provide an alternative source of support.
What are FedRAMP remediation timeframes?
For Rev5 they depend on the class, the Potential Agency Impact N-rating, whether the flaw is likely exploitable and whether it is internet-reachable. Class B ranges from 4 days (PAIN-5, exploitable and internet-reachable) to 192 days (PAIN-3 or PAIN-2, not likely exploitable). Class C ranges from 2 to 192 days and Class D from 12 hours to 192 days. Known exploited vulnerabilities follow the CISA catalog due dates. The timeframes are maximums, and the VDR and VER rules become mandatory on 7 December 2026.
Can an end-of-life flaw go on a CMMC POA&M?
Not for 3.14.1. Under 32 CFR 170.21 a POA&M may include only requirements worth 1 point, with one exception for CUI encryption, and SI.L2-3.14.1 is worth 5 points under 170.24. A flaw has to be corrected, or described with its mitigations as an enduring exception in the system security plan, which the scoring methodology assesses as MET.
Does SA-22 allow a third party to support an end-of-life component?
Yes. SA-22 asks you to replace components the vendor no longer supports or to provide options for alternative sources of continued support. Its discussion says external providers can support such components through contracts, and that these can include open-source software value-added vendors. Your assessor decides whether a given arrangement satisfies the control.
Sources
Checked 26 October 2026. Clause numbers and wording are from the official texts below. OSSeva does not certify that you comply with any of these rules, does not act as an assessor and does not file reports for you.
- NIST SP 800-53 Rev. 5 (SI-2, SA-22)
- NIST SP 800-171 Rev. 2 (3.14.1)
- FedRAMP Consolidated Rules for 2026: Vulnerability Detection and Response, Rev5 Class B
- FedRAMP Consolidated Rules for 2026: Vulnerability Evaluation and Reporting, Rev5 Class B
- FedRAMP Consolidated Rules for 2026: Vulnerability Detection and Response, Rev5 Class C
- FedRAMP Consolidated Rules for 2026: Vulnerability Detection and Response, Rev5 Class D
- FedRAMP definitions
- FedRAMP 2026 controls: System and Information Integrity (SI-2)
- FedRAMP notice NTC-0014 on CISA BOD 26-04
- 32 CFR 170.14 (CMMC Model)
- 32 CFR 170.21 (POA&M requirements)
- 32 CFR 170.24 (CMMC scoring methodology)
- 32 CFR 170.3 (applicability and phased implementation)
- 48 CFR 52.204-21 (basic safeguarding of covered contractor information systems)
- 48 CFR 204.7504 (CMMC clause and phase dates in DFARS)
Get a quote
Need evidence for an end-of-life component in a federal system?
Ask for a sample evidence pack. It shows what one patched build ships with: the SBOM, VEX statements, signed build and CVE record. Your assessor decides what it proves.