FedRAMP Just Retired the Flat Scan. The New Rules Ask for Proof of Exploitability.

FedRAMP spent more than a decade grading cloud providers on how many findings they closed. As of this month, that model is over. The Consolidated Rules for 2026 took effect July 4, and they say something the security industry has known for a long time and mostly refused to act on: a severity score is not a risk, and a finding a scanner flags is not the same thing as a vulnerability an attacker can actually use. The new rules sort findings by exactly that difference, and they say in writing that most findings scanners surface are not likely to be exploitable.

That is not editorializing. That is the rules.

What actually changed

On June 10, CISA issued Binding Operational Directive 26-04. It threw out the flat remediation clocks that governed federal patching for years and replaced them with a risk model built on four questions:

• Is the asset publicly exposed?

• Is the vulnerability on the Known Exploited Vulnerabilities list?

• Can exploitation be automated?

• Does exploitation hand an attacker partial or total control?

Two findings with identical CVSS scores can now carry completely different obligations depending on those answers.

FedRAMP moved within days. It aligned two of its rulesets, Vulnerability Detection and Response and Vulnerability Evaluation and Reporting, to the directive and pulled their mandatory date forward hard. VDR and VER are now required to obtain or maintain a FedRAMP Certification by December 7, 2026, with a grace period running only to March 7, 2027. After that, a non-compliant offering faces revocation. FedRAMP said the quiet part in writing: the legacy monthly scanning process most Rev5 providers run today is insufficient.

The clearest place to watch this land is the remediation clock. FedRAMP no longer sets deadlines by CVSS severity. It sets them by three things it makes providers evaluate for every single finding: how much agency impact exploitation would cause, whether the finding is a likely exploitable vulnerability, and whether it is reachable from the internet. A finding that is both likely exploitable and internet-reachable gets the tightest clock, as little as a day or less on the most sensitive systems. A finding judged not likely exploitable gets weeks or months at the same impact rating. CVSS became an input. Exploitability and reachability now move the deadline more than the raw score does.

Why this is the vulnerabilities-versus-weaknesses argument, written into federal policy

We have said for a while that scanners find weaknesses, not vulnerabilities. A weakness is a theoretical code issue. A vulnerability is something an attacker can actually exploit, with the steps to reproduce it. The whole scanner economy has run on collapsing those two things together and handing you a queue sorted by a number.

The 2026 rules pull them back apart. FedRAMP's own guidance states plainly that most traditional findings surfaced by scanners are not likely to be exploitable, because exploitation usually requires a set of conditions that never actually occur in the environment. So the rules now require providers to evaluate each finding in context and determine whether it is a likely exploitable vulnerability. Exposure, reachability, real impact. That is the exact distinction we built the product around, now the standard a federal certification hangs on.

Here is the structural problem for the incumbents. A scanner cannot clear that bar, because a scanner does not know what it cannot see. It emits weaknesses. It does not produce exploitability evidence, it does not reach the asset the way an attacker would, and it cannot tell you which of ten thousand findings is the one that chains to control of the system. When the deadline itself turns on proving exploitability and reachability, a tool that only emits weaknesses gives you nothing to argue a finding down with. Everything stays in the fast lane. That is not a tuning problem. It is what the tool is.

Where Xint fits, and why it is not a coincidence

Xint Code analyzes source and returns exploitable vulnerabilities with reproduction steps. Not a ranked list of maybes; the specific issue an attacker can use, and the path to reproduce it. That is exploitability evidence, which is the currency the VER rules now trade in.

Xint Web simulates a live attacker against the running application. Internet-reachability and real exposure are not fields we ask you to fill in; they are what the simulation measures directly. Put the two products together and you produce two of the three factors the clock runs on: Code speaks to whether a finding is a likely exploitable vulnerability, Web speaks to whether it is internet-reachable. The third, potential agency impact, stays your call. But the two that a scanner structurally cannot produce come out of the platform as evidence, not as an assumption you have to defend.

The reason both do this is the system, not the model. The differentiator is not which LLM sits underneath. It is the scaffolding around it:

• How files get selected

• How context gets assembled

• How the analyzer reasons about exploitability

• How the reproduction pipeline turns a finding into a demonstrated attack

And it maps to what the rules ask for on paper. The VER reporting rules require providers to state, for every vulnerability, whether it is internet-reachable and whether it is likely exploitable. Those are the two determinations the platform produces as output. A model alone produces text. A system produces the answer you have to report.

One more line worth sitting on. The VDR rules explicitly name penetration testing as a valid source of detection, listed right alongside scanning, threat intelligence, and bug bounties. Federal cloud has always leaned on the pen test to answer the exploitability question. The problem was never that the pen test was wrong; it was that it happened once a year and could not keep pace with a program that now demands continuous, machine-readable evidence. Xint is the first scalable alternative to the pen test. Which means the exploitability signal FedRAMP now wants continuously is the one thing we were built to deliver continuously.

The real shift

The 2026 rules did not invent a new burden. They retired an old fiction, the one where a wall of low-severity findings counted as security work and a high CVSS number counted as risk. The federal government just made exploitability and exposure decide the clock, not the size of the severity score. Providers on the flat scanner model have until December to move, and moving means finding a way to prove which of their vulnerabilities an attacker can actually use.

The question is no longer whether your program generates findings. Every program does. The question is whether it can prove exploitability fast enough, and often enough, to matter to the agencies relying on you. That is the bar now. What are you measuring against it?