
FedRAMP 2026 vulnerability rules make reachability a requirement | Blog | Endor Labs
Endor Labs breaks down FedRAMP's 2026 Consolidated Rules, effective July 2026 with December 2026 deadlines, which for the first time formally require cloud service providers to evaluate every detected vulnerability for exploitability and internet-reachability before remediation, replacing the old CVSS-driven POA and M model. It details the required per-vulnerability JSON reporting schema, the 192-day accepted-vulnerability clock, and cites Egnyte's and Rubrik's real-world reachability-driven FedRAMP ConMon programs as evidence the model works at scale.
What it is
Endor Labs' explainer on FedRAMP's 2026 Consolidated Rules, mandated through the FedRAMP PMO under GSA and available for optional adoption on July 4, 2026. Beyond the two named requirements (VER-EVA-ELX exploitability, VER-EVA-EIR internet-reachability), the piece surfaces the operational constraints and the escalation logic that determine whether a finding becomes a reportable incident.
How it works
Classification drives everything downstream — reporting obligations, incident thresholds, and timelines. An internet-reachable LEV with a high Potential Agency Impact rating can escalate to a FedRAMP Reportable Incident; a vulnerability that fails the exploitability test does not. The page frames reachability as a layered filter: if your code never calls the vulnerable function, no payload can reach it, so function-level unreachability is auditable evidence for a "not likely exploitable" / false-positive determination (VER-EVA-EFP, named as evaluation factor two after criticality). Endor states fewer than 9.5% of vulnerabilities are exploitable at the function level.
Preconditions / Affected
Applies to cloud service providers/offerings under FedRAMP ConMon. The hard constraint the summary omits: evaluation must be completed within 2 to 14 days of detection, depending on certification class — a compression from the old months-long ConMon cadence, which the page says rules out spreadsheets and manual judgment.
What to do
The page frames a defensible false-positive tool against three criteria from Fortreum's Ben Scudera (2024), which map onto the 2026 rules:
- Distinguish "we can't determine reachability" from "we're confident this is not reachable."
- An unreachable determination must hold from any source, not just the public internet.
- The tool must alert when a code change makes an unreachable vulnerability reachable.
Use these as an acceptance checklist for any reachability tooling you plan to submit as 3PAO evidence.
Caveats
- July 4, 2026 is described as the date for optional adoption, not a hard mandate — verify your own timeline.
- The 9.5% exploitable and Egnyte 91%/70% figures are Endor Labs' own research/customer results.
- Function-level reachability is stated as already evaluated by the FedRAMP PMO and 3PAOs Fortreum and Schellman, but acceptance remains case-by-case in practice.
A structural note the page makes: NIST began (this April) limiting NVD enrichment to prioritized CVEs, marking the rest "Not Scheduled" with no CVSS score. A remediation clock keyed to CVSS breaks when most vulnerabilities never receive one — the supply-side reason the old model was failing regardless of the rule change.
Organisations named here
- Egnyte
- FedRAMP
- Fortreum
- GSA
- Rubrik
- Schellman
Technologies named here
- Endor Labs
- Microsoft Defender
- Upwind
- Wiz
- Kovr
- NIST
Techniques named here
- Function-level reachability analysis
- Internet-reachability evaluation
- Exploitability evaluation
- False positive determination via reachability
- Grouping and deduplication of vulnerability findings
Threat actors named here
- Log4Shell
Related in GRC

Orca Security: NIST AI Risk Management Framework (AI RMF) Explained

FOSSA: CISA Releases the 2026 SBOM Minimum Elements
Teach Yourself to Phish | Huntress
