You can, but it is the hardest exception to defend. Active exploitation means the risk is not theoretical. If you must accept one, require senior approval, proof the vulnerable code is exposed or unexposed, strong tested compensating controls, a very short end date and daily or weekly review.
Why exploitation changes the case
CISA's Known Exploited Vulnerabilities catalog is described by CISA as the authoritative source of vulnerabilities exploited in the wild, and CISA advises all organizations to use it as an input to prioritization. Being in the catalog means exploitation has been observed, so the usual argument that nobody would bother is gone.
That shifts the burden. For ordinary findings the approver asks whether the risk is small enough. For a known exploited one, the approver should ask whether there is any reason not to fix it now.
Questions to answer first
- Is the vulnerable component present in a deployed asset? If not, close the finding.
- Is the vulnerable code reachable, and is the asset exposed? CISA's catalog entries note that stakeholders are responsible for evaluating each asset's internet exposure.
- Can it be patched or upgraded today? If yes, do it.
- Is there a tested workaround? Disabling the affected feature is often faster than a full upgrade.
- Would exploitation reach sensitive data or other systems? This sets the blast radius.
When acceptance might be reasonable
| Condition | Example |
|---|---|
| Not exposed, not reachable, and evidence exists | Library present, vulnerable feature not compiled in |
| Fix cannot be applied yet, strong workaround in place | Vendor patch pending, feature disabled and tested |
| Asset is isolated and scheduled for retirement | Short remaining life, network cut off |
Even in these, treat it as a temporary state, not a settled one.
Extra requirements
- Approver at executive risk-owner level, not the team lead.
- Written evidence of the control test, attached.
- Term in days. Set it to the real fix date.
- Frequent review. Weekly check of the exploitation news, the vendor status and the control health.
- Detection. Add monitoring for exploitation attempts on that asset.
- Tell the people who need to know. Incident response should know which assets carry this risk.
What not to do
Do not accept because the fix is inconvenient, because the scanner score seems high, or because a customer has not complained. Do not record it as not affected unless you can show it. See risk acceptance vs VEX not_affected, and check your stack against the CISA KEV file.
Where Safeguard fits
Safeguard surfaces zero-day findings and dependency vulnerabilities with reachability analysis and uses policies and gates to require approval on waivers.
Quick check
Does KEV status automatically mean we must patch?
CISA advises using it as a prioritization input. Whether a given obligation applies depends on your own policy and any regulation that covers you. Check those directly.
What is a safe maximum term for this kind of exception?
Set it to the shortest realistic fix date, usually days or a few weeks, and review it often.
Sources
Last reviewed: 19 October 2026.
