CISA KEV vs CRA: Understanding Your Vulnerability Reporting Obligations

By Sydney Parker — Starcaller Intelligence Platform

Published July 18, 2026 · 5 min read

The Two Systems, Explained

You're probably already familiar with CVE — the Common Vulnerabilities and Exposures database maintained by MITRE. There are over 240,000 CVEs. Most of them have never been exploited in the wild. The CRA doesn't care about all of them.

What the CRA cares about are actively exploited vulnerabilities. And the closest thing the industry has to an authoritative list of those is the CISA KEV catalog.

What "Actively Exploited" Actually Means

This is the part that trips people up. The CRA doesn't limit "actively exploited" to CISA KEV entries. It means any vulnerability that is being exploited against real systems in the wild. The CISA KEV catalog is the minimum — the floor, not the ceiling.

If you become aware that a CVE affecting your product is being exploited — through customer reports, threat intelligence feeds, your own telemetry, or any other channel — you have 24 hours to notify ENISA. Even if it's not in the KEV catalog yet.

This is why automated monitoring is essential. You can't manually check 240,000 CVEs every day, cross-reference against the KEV catalog, and draft an ENISA notification within 24 hours. The pipeline has to be automated.

The VEX Problem

Alongside the 24-hour ENISA notification, the CRA requires a VEX document — Vulnerability Exploitability eXchange. This declares whether your product is affected, not affected, or under investigation for each reported vulnerability.

A VEX document needs to contain:

• The CVE ID
• Affected product name and version
• Status: affected, not_affected, or under_investigation
• Justification if not affected (e.g., "vulnerable code not present," "component not in executable path")
• Remediation if affected (patch version, mitigation steps)

If you have 50 CVEs matching your SBOM and need to produce VEX documents for the ones that match KEV entries — that's a lot of manual work without tooling.

What Your Pipeline Should Look Like

SBOM generation (every release)
    ↓
Daily CISA KEV matching (automated)
    ↓
Match detected? → Generate VEX document
    ↓
Actively exploited? → Draft ENISA notification
    ↓
Submit to ENISA within 24 hours (with VEX attached)

Common Misconceptions

"GitHub Dependabot handles this"

Dependabot monitors for CVEs, not specifically for KEV entries. It doesn't produce VEX documents. It doesn't draft ENISA notifications. It's a useful signal — it's not a compliance pipeline.

"We can wait for the NVD to update"

The NVD's enrichment pipeline has had known backlogs. If a KEV entry is published at 10 PM on a Friday and you don't catch it until Monday, you've missed the 24-hour window. Direct KEV monitoring is faster.

"Only IoT companies need to worry"

The CRA applies to any product with digital elements — software, hardware, SaaS platforms that ship components. If your software ends up in a product, the manufacturer's obligations cascade to you.

The Free Tier: What You Can Do Today

The CRA Watch API provides daily CISA KEV matching against your SBOM — free, no signup:

# Check your SBOM against today's KEV catalog
curl -X POST https://cra-watch.starcaller-teq.workers.dev/check \
  -H "Content-Type: application/json" \
  -d @sbom.json

# Response (example):
{
  "checked_at": "2026-07-18T14:30:00Z",
  "kev_matches": [
    {
      "cve": "CVE-2026-12345",
      "component": "requests@2.28.0",
      "kev_date_added": "2026-07-15",
      "required_action": "Apply vendor patch by 2026-08-05"
    }
  ],
  "match_count": 1
}

Part 1: What the CRA Means for Your Repo · Part 2: Generating Your First SBOM