The KEV catalog is the best threat intel source nobody operationalizes

I assumed every MSSP was running weekly KEV triage across their clients. Turns out most aren't. Here's why that surprised me.

Ritchy Joseph
Ritchy Joseph
April 2026 · 6 min read

When I built the KEV module for AEGIS, I thought I was building something tablestakes. Then I started showing it to MSSPs and realized I wasn’t. This one genuinely surprised me.

I’ll admit my bias up front. I spent a chunk of my career in security roles where the CISA Known Exploited Vulnerabilities catalog was the Monday-morning starting point. You’d pull the new entries, cross-reference against your asset inventory, kick off patching, file the evidence. It felt boring-and-mandatory, like running backups.

So when I built the KEV workspace in AEGIS, I thought I was adding a checkbox feature — something every MSSP was already doing, just in ten different spreadsheets. I was wrong. Most people I’ve shown it to are either not doing it, or doing it so informally it barely counts.

Why I think this happens

I don’t believe this is because MSSPs are lazy or ignorant. Every one of them knows the KEV exists. The issue is that operationalizing it across a client portfolio is a boring, repeating, easy-to-skip workflow that breaks somewhere around the fourth client.

Here’s the realistic Monday for a 3-person MSSP:

  • Pull new KEV entries from the previous week.
  • For each entry, look up which vendors are in scope (this is an ad-hoc mental exercise for most people).
  • For each affected vendor, figure out which of your 12 clients actually runs that vendor.
  • For each of those clients, check patching state — which is often "I think they patched last week, let me ask."
  • Write it up, send it, move on.

Multiply that by 8–15 clients and the human loss rate is high. By week four, someone’s Tuesday turns into "catch up on last week’s KEV triage." By week eight, the ritual quietly dies.

The CVSS habit gets in the way

The other thing I’ve noticed is the gravity of the CVSS-first habit. CVSS is older, it’s baked into every scanner, it’s how ticketing systems default to prioritization. Teams have muscle memory for "9.8 gets patched first." The KEV is a different lens — "someone is exploiting this right now" — and that lens is better, but it takes a workflow rewrite to adopt.

I was pushing back against this with a beta user last week. He said something that stuck with me: "I know KEV is higher-signal. The problem is I can’t get my ticketing system to sort by it, and my team already sorts by CVSS, so that’s what gets worked."

That’s a real constraint. It’s not a knowledge problem. It’s a tooling problem. And until KEV-based prioritization is as frictionless as CVSS-based prioritization, CVSS wins by default. That’s the specific gap AEGIS tries to close — make the KEV view the default per client, and make the export format look like something their ticketing system can consume.

The evidence angle almost nobody is playing

Here’s the thing that actually surprised me most. For clients in regulated industries, documented KEV triage is audit evidence. Not just a nice-to-have. HIPAA, PCI-DSS, SEC cyber rules, CMMC — all of them want to see that you’re aware of known exploited vulnerabilities and doing something about them on a clock.

"We check the KEV" is a sentence. "Here are 42 KEVs relevant to the vendors in your environment this quarter, 38 remediated inside the CISA deadline, 3 in progress, 1 accepted with documented justification" is a document. An auditor can read the document. They can’t verify the sentence.

Most of the MSSPs I talk to are already doing most of the work that would produce that document. They’re just not producing the document because no one built the tool that compiles it automatically. This is probably the single biggest under-used revenue lever for an MSSP selling into regulated sectors.

What I built, and what it still can’t do

AEGIS pulls the full KEV catalog every few hours. For each entry, it maps the affected vendor against each tenant’s deployed stack (which you onboard via a short wizard). Per tenant, I show: new-this-week, in-flight remediation, overdue, accepted-risk. The per-tenant report exports as PDF and CSV, both formatted for an audit binder.

It still can’t tell you which specific asset inside your client’s environment is affected. That requires asset-level visibility AEGIS doesn’t have (and probably shouldn’t have — your scanner does, and I’m not trying to be a scanner). The integration path to pull that data back from common scanners is on my list but not shipped.

It also can’t distinguish between a patch that’s deployed and a patch that’s deployed but not yet rebooted. Someone said that one out loud in a beta call and I haven’t stopped thinking about it.

One request if you’re reading this

If you’re running KEV triage in some form across multiple environments and you’ve found a workflow you like — spreadsheet, ticketing system, another tool, whatever — I genuinely want to hear about it. I’ve been building AEGIS against a composite of what I used to do and what beta users tell me. The worst thing I could do right now is optimize for a workflow that doesn’t match real practice. support@axivum.io goes to me.

If you want to see what AEGIS does with the KEV today against your actual vendor stack, request beta access. No sales deck.


Written while building AEGIS. Subscribe below for the next one.

Get the next post when it ships.

Written by Ritchy while building AEGIS. One email per post — no cadence, no marketing, no "this month in cybersecurity" round-ups.