Why We Re-Test Every Customer Within 48 Hours of a CISA KEV Add

The pen-test industry sells annual or quarterly engagements. The economics make sense for a labor-intensive deliverable, but the cadence is wildly out of step with how attackers actually move once a vulnerability becomes weaponized. Once CISA puts a CVE on the KEV, you do not have a quarter to think about it. You have days.

This post explains why we rebuilt our customer re-test pipeline around the KEV feed, what the 48-hour SLA actually requires under the hood, and what we found when we ran it for Q1 2026.

What happened

In late 2025 we noticed a consistent pattern in our customer post-mortems. A customer would have a clean monthly scan. Three weeks later, an incident response engagement would land on our desk involving a CVE that had been exploited in the wild, often for several days, before the customer detected it. We pulled the data on twelve of these incidents from Q4 2025. In every case, the CVE was not in our test set at the time of the customer's last scan — because it had not yet been publicly weaponized, or had been weaponized so recently that no public detection signature existed.

In every case, by the time the customer was breached, CISA had added the CVE to the KEV catalog. The median gap between the KEV add date and the date of the customer incident was 11 days. The median gap between the KEV add date and the customer's next scheduled monthly scan was 14 days. Customers were getting breached in the window between "this is a known exploited vulnerability" and "your next scheduled re-test."

We rebuilt the pipeline. Now: every KEV add triggers a global test-catalog augmentation within 6 hours, and every customer with internet-facing surface gets re-tested against the new entries within 48 hours of the KEV add. No exceptions, no maintenance-window scheduling, no "wait for the monthly cycle."

Why it kept working (the old way, for attackers)

Monthly scanning is a calendar artifact. It exists because pen-test firms sell their work in quarterly or monthly retainers, and because the underlying scan machinery historically took hours to days to run, so customers wanted to schedule it during quiet windows. Neither of those constraints survives modern infrastructure. Our scan engine completes a full external surface assessment in under an hour for the median customer. There is no operational reason to wait a month between scans except that monthly is what the engagement contract said.

Attackers are not constrained by your engagement contract. The Verizon DBIR has reported for three consecutive years that the median time-to-exploit for a high-severity, internet-exploitable vulnerability is now under 10 days from public disclosure. For CVEs that land directly on KEV — meaning CISA has confirmed evidence of active exploitation — the window is shorter, because the CVE is already being exploited at the time it's listed. KEV listing is a lagging indicator of threat. By the time you see the listing, the campaigns are running.

The pen-test industry's typical response to this is some variant of "we'll add it to the next scan." Which means: we'll test for active exploitation against your environment between zero and thirty days from now, depending on where you are in the calendar. If the attacker happens to start campaigns against you in that window, we hope you have other defenses.

That is not security. That is a billing schedule.

What to check today

Whether you use CELVEX Group, another vendor, or run your own program, these are the questions to answer about your current process.

1. What is your end-to-end latency from a KEV add to a confirmed test result on your environment? Not "when do you receive a notification." Not "when does your team start working on it." When do you have a definitive answer — yes you are vulnerable, no you are not — about every internet-exposed asset in your inventory, against the new KEV entry? If the answer is more than a week, attackers are already inside that window.
2. Is your asset inventory accurate enough to support the question? A 48-hour re-test SLA is meaningless if your asset list is missing the subdomain that's actually vulnerable. Your KEV-driven re-test is only as good as your asset coverage. We refresh customer asset inventories continuously, not on the same monthly cadence as the scans.
3. Does your pipeline distinguish between "tested clean" and "not tested"? When CISA adds a new CVE, your prior scan results are silently invalidated for that specific test. A "clean scan" report from last week does not include a test for a CVE that wasn't in the catalog last week. Customers consistently underestimate this. They see a green dashboard and assume it covers everything CISA cares about today, when in fact it covers everything CISA cared about as of the date the scan ran.
4. Do you have an emergency re-test channel that doesn't require a sales conversation? If the answer to "we just saw this on KEV, can you re-test our environment by tomorrow" is "let me get you on the calendar with our PM next week," your vendor is not built for this threat model. Re-tests on KEV-listed CVEs should be a free, automatic, contractually-bound part of any continuous testing engagement. Anything else is friction the attackers exploit.
5. Are you tracking your own MTTR on KEV-listed vulnerabilities? CISA's own Binding Operational Directive 22-01 requires federal agencies to remediate KEV entries within 14 days for the most critical class. Private-sector benchmarks should be tighter, not looser. If your average time from KEV add to remediation is over two weeks, the directive that protects federal agencies is more aggressive than your internal SLA.

How CELVEX Group tests for this

The pipeline is implemented as a continuous chain: KEV feed ingestion, catalog augmentation, customer fan-out, scan execution, finding triage, customer notification, remediation tracking. The full flow is exercised end-to-end every time CISA publishes a new entry. We test the flow itself with a synthetic KEV entry once per week to make sure no link in the chain has silently broken.

The wrapping test, METHODOLOGY-KEV-RETEST-PIPELINE-001, lives in core/test_catalog/_supplement_methodology_2026-03.py. It validates four things on every customer:

1. The customer's most recent comprehensive scan post-dates every KEV entry currently in the catalog by no more than 48 hours, OR a targeted re-test exists for any KEV entry added since.
2. For each KEV entry in scope for the customer's stack, a corresponding scanner test exists in the active catalog with a non-stale signature (added or refreshed within 6 hours of KEV add).
3. For each KEV-driven re-test that found a positive, a remediation tracking ticket exists in the customer's integrated workflow (Jira, Linear, Plane) with an SLA clock that started at notification time.
4. The pipeline's own latency: KEV add timestamp to first customer notification timestamp is under 6 hours for catalog augmentation, and under 48 hours for confirmed scan completion across all customers.

Customers see this as a separate widget on the dashboard: "Hours since CISA's last KEV add: N. Customers re-tested against the new entry: X / Y. New positives: Z." There is no version of this dashboard where the number on the left ever exceeds 48 without a paged engineer.

What we found in Q1 2026

CISA added 187 new entries to the KEV catalog in Q1 2026. We ran the pipeline against our active customer base for every one of them. The results, by the numbers:

• 23 customer instances of newly-KEV-listed CVEs surfaced as new positives — meaning the CVE was not flagged in the customer's prior monthly scan (because it wasn't yet in the catalog), and was flagged in the KEV-driven re-test within 48 hours of being added.
• All 23 patched within 7 days. The fastest was 14 hours from notification to confirmed remediation. The slowest was 6 days, gated by a customer's scheduled change window.
• 0 incidents against any of those 23 customers in the window between KEV add and confirmed patch. We are not claiming the attackers didn't try; we are claiming the patches landed before any of those customers showed up in our incident response queue.
• Median pipeline latency from KEV add timestamp to customer notification was 4 hours 12 minutes. The 95th percentile was 5 hours 47 minutes.
• Median customer remediation time on KEV-flagged findings was 2 days 3 hours. CISA's 14-day federal directive would have been met by 100% of our customer base; the actual remediation cadence ran roughly 7x faster than the federal SLA.

Bottom line

The KEV catalog is a curated list of vulnerabilities that CISA has confirmed are being actively exploited right now, by real adversaries, against real victims. Treating it as anything other than a same-week priority is a policy decision, and the policy decision attackers most want you to make is "we'll catch it on the next monthly scan."

A 48-hour re-test SLA is not a marketing claim. It is the minimum cadence at which a continuous-testing program can credibly say it is responding to active threat intelligence rather than reacting to a calendar. If your current vendor is not measuring this metric, ask them why. If they don't have an answer, ask them what their answer would have been for the 23 customers who would have spent the next 14 days exposed.