FedRAMP's Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules become mandatory on 7 December 2026. Under the 2026 Consolidated Rules, the monthly POA&M and its Deviation Requests give way to a list of accepted vulnerabilities. No one approves an entry on that list. You declare it, the 192-day clock runs from the day your evaluation finished, and the agencies using your service review your explanation when it is added, after you decided. A decision record minted when your evaluation closes stamps that day, so the start of the 192 days is not your word alone, and it keeps every version of the explanation an agency reads.
Found one tonight? In Class C, internet-reachable and likely exploitable is 2 days at PAIN-5.
The record opens with that CVE's facts already filled in: KEV status, EPSS and its date, weakness class, fixed versions, each from its public source. Our server dates it. Sign in with email, Google or GitHub to keep it. The first 100 records are free.
Accepted is where this example lands at day 192. On day 0 most teams record Deferred or Patch by a date, and the record keeps every version in one chain.
Deferred, or Patch by a date, while you still intend to fix it: overdue once its PAIN timeframe passes (FRD-ODV). Accepted: you do not intend to fix it, or it reaches day 192 unfixed (FRD-ACV).
Overdue (FRD-ODV): you still intend to fix it, and it has passed its timeframe. Accepted (FRD-ACV): you do not intend to fix it, or it will not be fixed within 192 days of evaluation (VER-TFR-MAV).
FedRAMP summarised the change in one sentence, and it is blunt.
"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." FedRAMP, What's Changing in 2026
"Providers MUST categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability." The count starts when your evaluation finishes, not when the scanner fired.
An accepted vulnerability is also one "that the provider does not intend to fully mitigate or remediate". Either way it goes on the list, and nobody signs it off.
Your tracking identifier. The time and source of the detection. The time of completed evaluation. Internet-reachable or not. Likely exploitable or not. The Potential Agency Impact N-rating. "Explanation of why this is an accepted vulnerability." Anything else that helps an agency assess the risk.
"FedRAMP will now require mandatory adoption of the new FedRAMP Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules by December 7, 2026 to align with CISA BOD 26-04." The grace period ends on 7 March 2027.
Read the verbs. The legacy rule counted from discovery: "FedRAMP requires Critical and High risks to be remediated within 30 days of discovery, Moderate risks within 90 days of discovery, and Low risks within 180 days of discovery." Its replacement, VDR-TFR-PVR, counts from evaluation and is a SHOULD. For Class C, which maps initially to the historical FedRAMP Moderate, it reads, in days from evaluation:
| Potential Agency Impact N-rating (PAIN) | Likely exploitable, internet-reachable | Likely exploitable, not internet-reachable | Not likely exploitable |
|---|---|---|---|
| PAIN-5 (N5) | 2 | 4 | 16 |
| PAIN-4 (N4) | 4 | 8 | 64 |
| PAIN-3 (N3) | 16 | 32 | 128 |
| PAIN-2 (N2) | 48 | 128 | 192 |
Class B and Class D carry their own matrices (VDR-TFR-PVR), and Class D's tightest cell is 12 hours. Miss a cell while you still intend to fix and the vulnerability is overdue (FRD-ODV). Reach day 192 unfixed, or know sooner that you will, and it is accepted, whatever you intend. The timeframes are a SHOULD. The MUSTs sit on evaluating, categorising and reporting, and FedRAMP warns that a not-likely-exploitable call made "recklessly or deliberately" (VER-EVA-ELX) will count against the provider. The rule that bites is the one about the record.
For Class C, an internet-reachable finding that is likely exploitable has a 2-day timeframe at PAIN-5 and 4 days at PAIN-4, counted from your evaluation. Both are a SHOULD. Record tonight what FedRAMP will ask for: the detection time and source, as your statement, your internet-reachable call, and your likely-exploitable call against FedRAMP's test, FRD-LEV: "A vulnerability that is not fully mitigated AND is reachable by a likely threat actor; AND a likely threat actor with knowledge of the vulnerability would likely gain unauthorized access, cause harm, disrupt operations, or otherwise have an undesired adverse impact within the cloud service offering by exploiting the vulnerability."
Illustrative entry.
Internet-reachable: yes. The service answers on a public listener.
Likely exploitable: yes. A likely threat actor can reach it, and the evidence frozen beside the call shows KEV status, EPSS and public exploit code. PAIN-5, so patch by a date inside the 2-day cell.
Write it about a component class, not a host. Nothing from your hosts leaves. See what a record holds.
Reachability is your call from your own network. The frozen evidence carries weight on the second half. Pick Mitigated or Patch by a date, not Accepted. You intend to fix it, so it is not an accepted vulnerability.
Does recording tonight fix the evaluation date? It fixes tonight. The stamp is the moment you record, and nobody can move it afterwards, you included. If your evaluation closed earlier, state that time. The stamp never takes it, and the reader sees both dates.
Under the old regime someone else dated your exception. The 3PAO validated it, or the agency AO approved it while it sat Pending. Under the 2026 rules nobody stamps it. Three readers take your word for the date, unless the record can prove it.
FedRAMP tells agencies that accepted vulnerabilities "generally only need to be reviewed when they are added or during an updated risk assessment due to changes in the agency's use or authorization" (VER-AGM-RVR). The explanation on file when the entry is added is the one they are most likely to read, and they read it after you decided. FedRAMP also recommends agencies review only overdue and accepted vulnerabilities rated above N2, so an N3 is read and an N2 usually is not. That makes the N-rating the call most worth dating. The authorization stays the AO's decision. The review is the agency's. The record gives it a date and an explanation it can check.
FedRAMP's assessor rules, IVV-IAS-VIM and IVV-IAS-VEF, tell assessors to review "the actual measures themselves at a technical level, such as reviewing underlying code as appropriate; don't simply review documentation or screenshots." The question becomes how this N-rating was reached, on what, and when.
The accepted-vulnerability JSON schema makes acceptanceRationale a required field. Of evaluationCompletedAt it says: "The clock for VER-TFR-MAV runs from this date."
The questions, in FedRAMP's own words:
"Time of completed evaluation"
"Explanation of why this is an accepted vulnerability"
"Is it a likely exploitable vulnerability or not?"
Still filing Deviation Requests before December? The Deviation Request asks the same thing in older words. For a Risk Adjustment, the "mitigating factors or compensating controls in place that reduce likelihood and/or impact of exploitation." For a False Positive, that the vulnerability "does not actually exist on the system." For an Operational Requirement, why it cannot be fixed, knowing "FedRAMP will not approve an OR for a High vulnerability". Anything Pending "must be approved by the federal agency AO prior to authorization." A Vendor Dependency, where the fix is the vendor's to ship, was never a request at all: FedRAMP says they "are not considered deviation requests and do not require approval."
Under the legacy rule the scanner supplied the start date, and when you needed longer, an approver dated the exception. The 2026 rules start the count at evaluation, a date only you hold. It reaches the agency as a cell in your monthly report.
Every day the evaluation date slips is a day added to both clocks, the Class C cell and the 192. FedRAMP knows it: VER-TFR-EVU says a Class C provider SHOULD evaluate within 5 days of detection, and the report carries both times. A date typed into a report row is exactly as late as its author chose.
The explanation is rewritten each time the report is rebuilt. When a question comes, the text on file when the entry was added is gone, and so is what was public about the CVE on the day you evaluated it.
It does, and an administrator at the provider being judged can edit or delete it. Its dates are the ticket's: opened, edited, closed. None of them is the evaluation date the 192 days run from.
It does, and it counts from detection, which is the legacy clock. The 192 days count from completed evaluation, a time no scanner records. The record stamps that time.
An approval stamp used to date the exception for you. Now the record has to.
A decision record is the dated account of one call: the verdict, the rationale, who made it, a review-by date, and what was independently known about the CVE that day. It is not FedRAMP's Vulnerability Detection and Response ruleset. Those rules say what to report. The record is what you report from.
Here is one against regreSSHion, a race condition in OpenSSH's server. The CNA says an unauthenticated, remote attacker "may be able to trigger it by failing to authenticate within a set time period." The CVE facts are real, read from the frozen record. The provider, the appliance, the calls and every date from day 0 on are illustrative.
First, the three calls FedRAMP makes you record, and the evidence the record puts beside each one:
| Call | FedRAMP's test | Evidence frozen on 29 June | The call, and whose it is |
|---|---|---|---|
| Internet-reachable | Could it be "triggered by a payload originating from a source on the public internet"? | Vector AV:N from the CNA and from NVD: triggerable over the network wherever sshd listens. | Not internet-reachable. The appliance's management interface answers only on the admin network. Yours. |
| Likely exploitable | Is it "reachable by a likely threat actor", who would likely do harm with it? | Not in KEV. EPSS 0.99506, top 0.06% of all CVEs, unchanged since 15 June 2026. Proof-of-concept code public since 2024-07-01. Vector AC:H. | Not likely exploitable, because no likely threat actor can reach it. Yours, and the agency reads it beside an EPSS of 0.99506. |
| Potential Agency Impact | An N-rating, N1 to N5. | CVSS 8.1 from the CNA, confidentiality, integrity and availability all high. | PAIN-3 (N3). Yours. |
Class C, PAIN-3, not likely exploitable: a 128-day SHOULD. From day 0, the rest of the clock is arithmetic.
| Day | Date | What happens | What the record holds |
|---|---|---|---|
| before | 2024-07-01 | Red Hat publishes the CVE, CVSS 8.1. Proof-of-concept code is public the same day. | Description, CWE-364, the 20 published ranges and the first unaffected version by branch, each with its source. |
| 0 | 2026-06-29 | Your evaluation closes. The appliance's firmware carries OpenSSH inside the published range "openbsd openssh >= 8.6 <= 9.8", and the vendor has not dated a fix. You defer to its firmware and mint the record from the triage ticket. | Server-stamped Evaluation completed 2026-06-29. Frozen with it: not in KEV, EPSS 0.99506 with its series date and scoring model, exploit code public since 2024-07-01. Rationale, version one. |
| 1 to 192 | every day | The record watches KEV and EPSS for this CVE. | Watching A KEV listing or a material EPSS move reaches the owner the day it lands, with its receipt. A move before day 192 is dated when it happened, not when the next report is built. |
| 120 | 2026-10-27 | Review-by. The record comes due in the owner's queue, eight days before the SHOULD lapses. | Due for review |
| 128 | 2026-11-04 | If the firmware has not shipped, the Class C timeframe lapses. You still intend to fix it, so it is overdue, not accepted. | Your overdue explanation, version two. VER-RPT-VDT asks it of every reported vulnerability until it is accepted: "Is it currently or is it likely to become an overdue vulnerability or not? If so, explain." |
| 161 | 2026-12-07 | The rules become mandatory. | Nothing changes. The record was already dated. |
| 192 | 2027-01-07 | If the firmware still has not shipped, the vulnerability MUST be categorized as accepted, by the clock rather than by intent. It goes on the list in your next monthly report, and at PAIN-3 FedRAMP recommends that each agency review it when it is added. | Every version kept Rationale, version three. Versions one and two still read as written, each dated by us. |
What the explanation itself reads like. It names a component class, never a host:
Deferred to the vendor's firmware. sshd on this appliance class listens only on the admin network, behind the bastion, so it is not reachable by a likely threat actor. Not internet-reachable, not likely exploitable, PAIN-3. Not in KEV on the day of evaluation. EPSS 0.99506 was read and weighed. Revisit on the vendor's release or on any KEV listing.
Accepted by the clock at day 192. The vendor has not shipped fixed firmware. The day 0 reachability call stands and the admin-network restriction is unchanged. Replacement hardware is scheduled.
The same record, set against FedRAMP's accepted-vulnerability schema, field by field:
| Schema field | On this record | Who vouches |
|---|---|---|
providerTrackingId | Your ticket ID, carried beside the record's own chain ID. | Chained |
detection | Your scanner's detection time and source, carried as your statement beside our stamp, so the gap between detection and evaluation sits in plain view. | Yours |
evaluationCompletedAt | 2026-06-29, server-stamped because the record was minted when the evaluation closed. For a backlog entry, your stated date sits beside our stamp and the reader sees both. | Server-stamped when minted at close |
isInternetReachable, isLikelyExploitable, currentRating | Your three calls, each beside the evidence above. | Yours, with dated evidence beside them |
overdueStatus | Your explanation at day 128, version two. | Every version kept |
acceptanceRationale | Your rationale, hash-chained. Version three at day 192. Versions one and two still readable. | Every version kept |
vulnerabilityDescription | The CNA's description, CWE-364 and the published ranges, each with its source date. | Sourced and dated |
supplementaryRiskInformation | The snapshot as of 29 June: KEV status, EPSS and its series date, public exploit code, first unaffected versions. | Frozen at mint |
finalDisposition | Remediated, when the firmware ships. The last version on the chain. | Chained |
How an agency checks it. Every record has a proof link. Put it in the entry's explanation cell of your monthly report, at the end of the acceptanceRationale text. Open it and the chain verifies in front of the reader: version three carries the hash of version two, which carries version one. The day's evidence was frozen and hashed with version one: KEV status, and FIRST's EPSS as held on 29 June, unchanged since 15 June. Anyone can recompute the hash to see it is intact. The stamp comes from a party with no stake in your 192 days. You pay for the record, and the proof link lets the agency check for itself that the stamp and the frozen evidence have not changed since it was written.
What the agency reads. The link is the record's own address, and it opens only for the people you name. Share the record with the named reviewer at each agency using your service. They open the link from your report and sign in with the email you named. They see that record and nothing else you hold: the current version, the earlier versions as written, our stamps and the evidence frozen on day 0. The record logs who opened it and when.
Mint when the evaluation closes, from the ticket where it closes. The API is in every plan, so your triage queue can mint the record the moment the ticket closes. The stamp is then your clock start, and nobody can move it afterwards, you included. The record also names the surface that wrote it, so a reader sees a deferral recorded by your triage queue at the moment it closed, not typed into a form a week later.
A backlog of older evaluations? Record them today and each one says so: minted today, beside the evaluation date you state, with KEV status and EPSS as they stood on that date. The stamp never takes the date you state. The reader sees both dates.
Filing a Deviation Request this month? The same record is the working paper behind it: what was independently known about the CVE on the day you filed. The AO still approves it, and the 3PAO validates it at the annual assessment. When the rules change in December, the record does not.
Your ISSO will ask first what leaves your system. The answer is short enough to list.
The CVE ID, the verdict, your rationale in your words, who recorded it, the review-by date, the server stamps, the hashes, and the public evidence about the CVE.
No inventory, no scan output, no host names, no configuration. We do not look at your hosts. Write the rationale about a component class, as the sample above does, and nothing about your system leaves but what you type. FedRAMP draws the same line for the report itself: you "MUST NOT irresponsibly disclose specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST disclose sufficient information for informed risk-based decision-making." The security page lists what the service does not do.
Reachability, exploitability and the N-rating are your determinations. Validation is what your independent assessor does. Under the 2026 rules, agency access to your package runs through your trust center.
What the record does is narrow and exact: it makes the one date and the one explanation FedRAMP asks for checkable by someone who has no reason to trust you.
An accepted vulnerability is not a document you file once. The same explanation is reported again and again, on FedRAMP's schedule.
Your report to all necessary parties, human readable, at least monthly. Each accepted vulnerability goes into it with the eight items above.
The OCR goes to all necessary parties every 3 months and covers the whole period since the last one. It MUST include a high-level summary of accepted vulnerabilities.
FedRAMP recommends that agencies review accepted vulnerabilities rated above N2, generally when the entry is added or during an updated risk assessment (VER-AGM-RVR). Every agency that reads it reads the same explanation.
Rebuilt by hand, each of those readings is an engineer rewriting the story from tickets, per CVE, per question. From a record, each report cites the version on file, and the amendments show as versions, not as edits.
| Plan | What a FedRAMP team uses it for |
|---|---|
| Free, 100 records | The record, its proof link and its watch, for the first acceptances you evaluate. |
| Practitioner, 500 records | Every evaluation your triage queue closes, each stamped at its own day 0. |
| Custody, unlimited | Your ISSO, your engineers and your assessor on one shared register, with each agency's named reviewer signing in to read what you share, and every opening logged. Records nobody can delete. The assessor's review joins the chain as a signature, and every record reads "under custody since" the day you joined. |
The API is in every plan, so your triage queue can mint the record the moment the ticket closes.
Every plan stamps day 0, freezes the evidence and chains every version the same way. What changes is how many evaluations, and who else signs.
Why start before December. An evaluation closed on 27 August 2026 reaches day 192 on 7 March 2027, the day the grace period ends. Every one you close from now on reaches it later. The entries your agencies will read under the new rules are being evaluated now, and a record minted in December for an evaluation closed in September says December.
The compliance and audit brief is for whoever assembles the monthly report. If you close the triage ticket, start at this week's KEV additions or the brief for SOC tier 2 and 3.
The record opens with that CVE's facts already filled in: KEV status, EPSS and its date, weakness class, fixed versions, each from its public source. Our server dates it. Sign in with email, Google or GitHub to keep it. The first 100 records are free.
Accepted is where this example lands at day 192. On day 0 most teams record Deferred or Patch by a date, and the record keeps every version in one chain.
Deferred, or Patch by a date, while you still intend to fix it: overdue once its PAIN timeframe passes (FRD-ODV). Accepted: you do not intend to fix it, or it reaches day 192 unfixed (FRD-ACV).