Knox's FedRAMP 20x Vulnerability Management Rubric
We are making our risk logic public so customers, Agencies, and the entire FedRAMP ecosystems can see exactly how vulnerabilities are prioritized, timed, and reported.
A vulnerability management program should not be a black box.
Customers should not have to guess why one finding has a 12-hour deadline while another can be addressed through routine operations. Agencies should be able to see the evidence behind each decision. Security teams should be able to reproduce the result instead of relying on an analyst’s subjective judgment.
That is why Knox is making its FedRAMP 20x vulnerability management rubric public.
The rubric translates vulnerability data into a clear remediation deadline using three primary questions:
- What could happen if the vulnerability is exploited?
- Can an attacker reach the affected resource from the internet?
- Is exploitation likely?
The answer is not driven by CVSS severity alone.
This approach aligns with FedRAMP’s Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rules, which prioritize actual agency impact, internet reachability, and exploitability likelihood. FedRAMP describes this model as a move beyond traditional vulnerability scoring toward the context in which a weakness exists and the risk it presents to federal information.
Why the Old Model Is Not Enough
Traditional vulnerability management often starts and ends with a scanner-generated severity:
That may be useful as an initial signal, but it does not tell the full story.
A “medium” vulnerability on an internet-facing system with a working exploit and the potential for full compromise may require immediate action. A “critical” vulnerability on an isolated, non-exploitable component may present significantly less immediate risk.
FedRAMP’s new rules reflect that reality. Vulnerability response must be systematic, persistent, prompt, and based on the actual circumstances surrounding each finding. Providers are also expected to use automation to improve and streamline detection and response.
At Knox, every vulnerability is therefore evaluated through a repeatable decision process rather than assigned a deadline based on its raw severity score.
The Knox Decision Model
Every finding receives three core classifications: potential agency impact, internet reachability and exploitability likelihood.
1. Potential Agency Impact
We first determine the consequence if the vulnerability were successfully exploited.
FedRAMP expresses this as the Potential Agency Impact N-rating, or PAIN rating. The higher the PAIN rating, the more serious the potential effect on the affected cloud service and its federal customers.
Knox uses the following plain-language mapping:
Knox’s Multi-Agency Assumption
Knox cloud environments support more than one federal agency. We therefore evaluate vulnerabilities under a conservative multi-agency assumption.
Under this approach:
- The single-agency N3 case is not normally produced.
- A finding that might otherwise fall into N3 is elevated to N4.
- When potential impact cannot yet be determined, the vulnerability is treated as N5 Debilitating until evidence supports a lower rating.
This is a Knox security overlay. It is intentionally conservative and prevents uncertainty from being used to justify a longer remediation period.
2. Internet Reachability
Next, we determine whether the affected resource or vulnerable path is reachable from the public internet.
Knox validates reachability using technical evidence such as:
- Cloud attack-path analysis
- Network and security-group configuration
- Load balancer and gateway exposure
- VPC Flow Logs
- Application routing
- Identity or authentication barriers
- Web application firewall controls
- Input validation or other payload-deflecting safeguards
A resource is not treated as unreachable simply because it is not intended to be public. The decision must be supported by Attack Surface Management validation.
Controls such as a WAF, authentication gateway, or effective input validation may reduce reachability or exploitability, but they must be validated against the specific attack path. Their presence alone does not automatically close the finding.
3. Exploitability Likelihood
Knox determines whether exploitation is likely based on evidence that an attacker can realistically use the vulnerability.
A vulnerability is classified as likely exploitable when one or more of the following conditions apply:
- A known exploit exists.
- The vulnerability appears in the CISA Known Exploited Vulnerabilities Catalog.
- Threat intelligence shows active or credible exploitation.
- The vulnerability has an Exploit Prediction Scoring System score of 10% or higher.
- Security tooling validates an exploitable attack path or identifies the finding as a credible threat or risk.
A vulnerability is classified as not likely exploitable only when affirmative technical evidence supports that conclusion. The absence of a public exploit does not, by itself, prove that a vulnerability cannot be exploited.
The 10% EPSS threshold is a Knox operating threshold. EPSS estimates the probability that a published vulnerability will be exploited in the wild during a near-term period. Knox uses it as one signal alongside exploit availability, KEV status, threat intelligence, reachability, compensating controls, and resource context.
Evaluation Windows
The remediation clock is assigned after the finding is evaluated. Knox must therefore complete the evaluation quickly.
FedRAMP’s 2026 rules establish the following evaluation expectations:
- Class C, corresponding to FedRAMP Moderate: evaluate all vulnerabilities within five days of detection.
- Class D, corresponding to FedRAMP High: evaluate all vulnerabilities within two days of detection.
Knox attaches the supporting technical evidence to the vulnerability record, including the impact analysis, reachability determination, exploitability evidence, and relevant scanner or cloud-security findings.
The Deadline Formula
Once the three inputs are established, Knox calculates the deadline as follows:
Deadline = the earliest applicable date produced by the FedRAMP PAIN matrix, the CISA KEV due date, or the Knox 72-hour Threat and Risk track.
In practical terms:
deadline = MIN(
PAIN matrix deadline,
applicable CISA KEV deadline,
Knox validated Threat or Risk deadline
)
The KEV deadline and Knox 72-hour track can make the required response faster. They can never be used to extend the FedRAMP PAIN deadline.
There is no minimum CVSS score required before this logic applies.
Class D: FedRAMP High Rubric
For Class D environments, Knox uses the following FedRAMP remediation matrix. The timeframe begins when the vulnerability is evaluated.
Class C: FedRAMP Moderate Rubric
For Class C environments, Knox uses the following matrix:
Additional Knox Acceleration Rules
The PAIN matrix establishes the maximum risk-based timeframe. Knox applies additional rules that may shorten it.
Validated Threats and Risks: 72 Hours
When Knox’s cloud-security tooling validates a finding as a credible Threat or Risk, Knox places it on an accelerated 72-hour response track.
A ticket is created and routed to the responsible team with the evidence needed to validate, mitigate, remediate, or dispute the finding.
This is a Knox security overlay and may produce a deadline shorter than the standard PAIN matrix.
Known Exploited Vulnerabilities
Known Exploited Vulnerabilities follow the applicable CISA KEV due date or a shorter Knox or FedRAMP deadline.
FedRAMP’s 2026 rules state that providers should remediate KEVs according to the dates in CISA’s KEV Catalog, including when a vulnerability has been mitigated but not fully remediated.
Reportable Incidents
For Class C and Class D environments, an internet-reachable, likely exploitable vulnerability with a PAIN rating above N3 should be treated as a FedRAMP Reportable Incident until it is sufficiently mitigated.
A likely exploitable N5 vulnerability that is not internet-reachable may also meet the criteria for reportable-incident treatment until its potential impact is reduced.
Knox flags these findings for rapid customer and agency coordination rather than treating them solely as routine vulnerability tickets.
What Counts as Remediation?
The goal is to eliminate or meaningfully reduce the risk, not merely close a scanner finding.
Depending on the situation, an acceptable response may include:
- Applying a vendor patch
- Upgrading or replacing the affected component
- Removing the vulnerable service
- Disabling the affected feature
- Blocking the exploitable path
- Removing public reachability
- Implementing a validated compensating control
FedRAMP permits partial mitigation, full mitigation, or remediation to a lower potential-agency-impact rating within the applicable timeframe.
Any mitigation must be technically validated. A plan to fix the issue later is not the same as reducing the current risk.
Accepted Vulnerabilities Are Reported, Not Hidden
Some vulnerabilities cannot be fully remediated immediately. A vendor patch may not exist, a mission dependency may prevent an upgrade, or an approved architecture decision may require the affected component to remain in place.
These findings do not disappear from reporting.
FedRAMP requires any vulnerability that is not, or will not be, fully mitigated or remediated within 192 days of evaluation to be categorized as an Accepted Vulnerability. Providers must also report vulnerability detection and response activity in a human-readable format at least monthly.
Knox documents:
- The affected resource
- The vulnerability and technical condition
- The PAIN rating
- Internet-reachability status
- Exploitability evidence
- Existing mitigations
- Remaining risk
- The reason full remediation is not currently possible
- The responsible owner
- The expected remediation or review date
Acceptance is not concealment. It is a documented, visible security decision.
What Knox Customers See
Customers receive clear and actionable vulnerability information rather than a list of scanner results without context.
Reporting
Knox provides:
- Daily and weekly summaries for rapid visibility
- A cumulative vulnerability posture at least monthly
- The assigned remediation deadline for each relevant finding
- The logic and evidence used to calculate that deadline
- Status of open, mitigated, remediated, disputed, and accepted vulnerabilities
FedRAMP also expects Class C historical vulnerability data to be made available in machine-readable JSON at least every 14 days and Class D data at least every seven days.
Ticketing
Knox creates ServiceNow tickets for validated Risks and Threats affecting customer-managed resources.
Each ticket includes:
- The affected asset
- Technical evidence
- Assigned PAIN rating
- Reachability and exploitability determinations
- Required response date
- Recommended next action
Incident Coordination
Findings meeting the reportable-incident criteria are elevated for customer and agency acknowledgment and coordinated response.
Accepted Vulnerability Records
Findings that cannot be remediated within the required period are formally documented and reported. They are not silently deferred or removed from view.
What Knox Asks of Customers
Vulnerability management is a shared operational responsibility.
For findings affecting customer-managed resources, Knox asks the responsible customer team to acknowledge the finding and provide one of the following:
- Evidence that remediation is complete
- Evidence that an effective mitigation has been implemented
- A technically supported false-positive explanation
- Evidence supporting a different reachability, exploitability, or impact determination
- A current status and planned completion date
- Documentation supporting acceptance of the remaining risk
This evidence keeps the vulnerability record accurate and ensures that deadlines reflect the real security condition of the environment.
A Worked Example
Consider a vulnerability initially rated “medium” by a scanner.
Knox determines that:
- The affected application is publicly reachable.
- A working exploit is available.
- Successful exploitation could compromise the underlying resource.
- The environment supports multiple federal customers.
The resulting classification is:
Potential Agency Impact: N5 Debilitating
Internet Reachability: Yes
Likely Exploitable: Yes
For a Class D environment, the PAIN matrix produces a 12-hour deadline.
The original “medium” label does not override the actual risk. The finding receives the deadline supported by its impact, exposure, and exploitability.
Now consider a scanner-rated “critical” vulnerability where:
- The affected package is not invoked by the application.
- The vulnerable service is disabled.
- The resource is not reachable from an attacker-controlled path.
- Technical evidence confirms the vulnerable code cannot be executed.
That finding may receive a longer timeframe because the real-world likelihood of exploitation is lower. The decision must still be supported by affirmative evidence and continuously reassessed if the environment changes.
The Logic in One View
1. Detect the vulnerability.
2. Evaluate it within:
- 5 days for Class C
- 2 days for Class D
3. Determine:
- Potential Agency Impact
- Internet reachability
- Exploitability Likelihood
4. Assign the PAIN matrix deadline.
5. Compare it against:
- Applicable CISA KEV due date
- Knox 72-hour validated Threat/Risk track
6. Use the earliest deadline.
7. Track the finding until it is:
- Remediated
- Fully mitigated
- Reduced to a lower PAIN rating
- Validated as a false positive
- Formally documented as an Accepted Vulnerability
Why We Are Publishing This
Transparency improves security.
Publishing the rubric gives customers, agencies, assessors, and technology partners a common way to understand how Knox makes vulnerability decisions. It also allows those decisions to be reviewed, challenged, automated, and improved.
The purpose is not to claim that every vulnerability can be solved instantly. The purpose is to ensure that the most dangerous vulnerabilities are addressed first, every deadline is supported by evidence, and unresolved risk is visible to the people responsible for the mission.
FedRAMP 20x is shifting vulnerability management away from monthly spreadsheets and static severity labels toward persistent detection, contextual evaluation, machine-readable evidence, and rapid action based on actual risk. FedRAMP has stated that legacy monthly scanning alone is insufficient to meet the government’s updated vulnerability-response expectations.
Knox is operationalizing that model today.
Find continuously. Evaluate consistently. Remediate on the real risk. Report everything.
_Horizontal_RGB.png)
