Using the CISA KEV catalog as a patching SLA for Hawaii businesses

Published May 27, 2026 · HI Tech Hui · ~7 min read

What the KEV catalog actually is

CISA established the KEV catalog in November 2021 alongside Binding Operational Directive 22-01. The catalog is published as a continuously updated, machine-readable list at cisa.gov/known-exploited-vulnerabilities-catalog, with JSON and CSV downloads available for automation. Each entry includes the CVE, the affected vendor and product, a short description, the date added, the due date for federal remediation, and a link to authoritative guidance.

Per the CISA criteria for inclusion, a CVE is added to the catalog only when three conditions are met: it has a CVE ID, there is reliable evidence of active exploitation in the wild, and there is a clear remediation action available. The bar is “exploited,” not “exploitable.” That single rule is what makes the catalog more useful than CVSS for prioritization — it filters out the long tail of theoretical risk and surfaces the vulnerabilities attackers are using right now.

Why CVSS-only prioritization keeps missing

Almost every Hawaii business we audit has a vulnerability scanner producing a monthly report sorted by CVSS score. The report runs to hundreds or thousands of findings. The team patches what it can, defers the rest, and quietly accepts that the backlog will never reach zero. The problem with this model is not the backlog. The problem is that CVSS is a severity rating, not a likelihood rating. A CVSS 9.8 with no public exploit and a CVSS 7.4 in active criminal use are not the same operational risk, and a queue sorted by CVSS will routinely push the actively exploited issue down the list because something theoretically worse sits above it.

The KEV catalog is the inverse signal. Every entry is, by definition, being exploited. The catalog will not surface every dangerous CVE — nothing will — but it surfaces the ones that have moved from research to operations. For a small team, that is the queue that matters first.

The KEV-as-SLA model

The practical adoption for a Hawaii SMB is straightforward and does not require new tooling. It requires three things: an accurate asset inventory, a daily check against the KEV catalog, and an internal SLA that matches or beats the CISA due date.

1. Maintain an asset inventory that maps to CPE or vendor/product

You cannot patch what you do not know exists. The minimum useful inventory for KEV matching includes operating systems and versions on every server and endpoint, network appliances (firewalls, VPN concentrators, switches, wireless controllers) with firmware versions, hypervisors and virtualization stacks, perimeter devices including NAS and backup appliances, key SaaS platforms (Microsoft 365, Google Workspace, identity providers), and any line-of-business application with an internet-facing component. For organizations on HI Tech Hui managed IT services, this inventory is built and maintained as part of onboarding and refreshed continuously through endpoint management and network discovery.

2. Subscribe to the KEV feed and check it daily

CISA publishes the catalog as JSON and CSV, and offers a GovDelivery email subscription that notifies subscribers when new entries are added. A daily review takes minutes. For automation, pull the JSON feed once per day, diff against the prior snapshot, and alert on additions. The CISA feed is intentionally lightweight precisely so small organizations can consume it without a commercial vulnerability intelligence platform.

3. Set an internal SLA at or below the CISA due date

BOD 22-01 due dates are generally two weeks from the add date, with shorter windows for the most severe entries. For a private business, the defensible SLA model is:

• Internet-facing assets: remediate within 7 days of KEV addition, regardless of the CISA due date.
• Internal critical assets (domain controllers, identity providers, hypervisors, backup systems): remediate within the CISA due date.
• Internal standard assets: remediate within the CISA due date or the next scheduled maintenance window, whichever is sooner.
• Exception cases: documented compensating controls, a named owner, and a target remediation date — not an open-ended deferral.

This is the model federal agencies are required to operate under, scaled to an SMB’s asset base. It is also the model that holds up to a cyber insurance questionnaire, an SOC 2 control test, or a regulator’s incident-response interview far better than “we patch when we can.”

What ends up on KEV that Hawaii SMBs actually run

The catalog is not weighted toward enterprise-only software. A meaningful share of historical KEV entries cover products that are common in Hawaii small and mid-sized businesses: Microsoft Windows and Windows Server, Microsoft Exchange (on-premises and hybrid), Microsoft Office, VMware ESXi and vCenter, Fortinet FortiOS and FortiGate, Ivanti Connect Secure and Policy Secure, Cisco IOS XE and ASA, Citrix NetScaler / ADC, Palo Alto PAN-OS, MOVEit Transfer, Progress WS_FTP, Adobe ColdFusion, Atlassian Confluence, and Google Chrome. If your environment includes any of those, the catalog is already a personalized prioritization list waiting to be read.

The two categories where KEV has been most operationally painful for SMBs in recent years are perimeter devices and managed-file-transfer software. Both have the same pattern: an authentication bypass or remote code execution flaw is added to the catalog, exploitation begins within days (sometimes hours), and the gap between the vendor advisory and the organization’s patch deployment becomes the entire window of compromise. The KEV due date exists precisely because that gap is closeable, but only with a process designed for it.

What this looks like for Hawaii’s targeted sectors

• Hawaii healthcare and clinics: KEV-listed vulnerabilities on internet-facing systems holding or proximate to PHI become HIPAA-relevant the moment they appear in the catalog. The catalog due date is also a useful internal evidence artifact for HIPAA Security Rule risk management documentation.
• Hawaii finance and professional services: Cyber insurance applications now routinely ask whether the organization tracks the KEV catalog and remediates within the published due dates. A documented KEV SLA is the cheapest underwriting answer to produce.
• Hawaii law firms: Most firms have at least one remote-access appliance and a document management system exposed to the internet. Both are categories that recur on KEV. A weekly partner-level review of any KEV entries affecting the firm’s stack is a practical governance step that takes minutes.

Where KEV ends and your program begins

The KEV catalog is not a complete vulnerability management program. It is the highest-priority lane. Around it, a Hawaii business still needs a Patch Tuesday process for the broader monthly cumulative updates (see the patch compliance verification playbook), a posture for third-party applications that may never appear on KEV, configuration hardening for identity (see the AiTM defense plan), and detection coverage for the post-exploitation activity that follows a successful intrusion. KEV makes the queue defensible. The rest of the program makes the environment defensible.

What KEV does uniquely well is force a conversation. When a CVE lands on the catalog and your asset inventory says you run the affected product, the question is no longer “how bad is this?” The question is “are we meeting the due date, and if not, what is the compensating control?” That is a much easier question to govern than a CVSS spreadsheet, and a much better one to answer in front of an auditor or a board.

The 30-day adoption plan

For a Hawaii business that has not formalized this yet, a realistic 30-day plan looks like this:

• Week 1. Inventory every internet-facing system and every internal critical system. Capture vendor, product, version, and patch state. Identify the named owner for each.
• Week 2. Subscribe to the CISA KEV update notification. Pull the current catalog, filter to entries that match the inventory, and treat the matches as an initial backlog with an explicit target close date.
• Week 3. Document the internal SLA (the four-tier model above is a defensible starting point). Identify any KEV CVEs that cannot be remediated in time and document the compensating control and target date for each.
• Week 4. Wire the daily KEV check into the routine that already exists — the morning standup, the weekly leadership review, the monthly board packet. The goal is not a new meeting. The goal is to make “we are inside KEV due dates” or “we have N open exceptions” a recurring, governed answer.

What this looks like with HI Tech Hui

For organizations on HI Tech Hui managed IT services, KEV monitoring is built into the operating model: daily catalog ingestion, matching against the maintained asset inventory, ticketing inside the internal SLA, an exception process with named owners and target dates, and detection coverage through the Cyberuptive 24/7 SOC for techniques associated with the most active KEV entries. Clients receive a monthly KEV posture report — additions, remediations, open exceptions, and posture relative to the CISA due dates — that is suitable for board, audit, and insurance use. For Microsoft 365 environments and on-premises Windows fleets, KEV-driven prioritization is folded into the same patch cadence as Patch Tuesday rather than competing with it.

Sources

• CISA — Known Exploited Vulnerabilities Catalog
• CISA — Reducing the Significant Risk of Known Exploited Vulnerabilities (program page and criteria)
• CISA — Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA Insights — BOD 22-01 vulnerability management requirements (PDF)
• CISA — #StopRansomware: Known Exploited Vulnerabilities guidance

Need help wiring the CISA KEV catalog into a defensible patching SLA for a Hawaii business? HI Tech Hui’s managed IT services team handles inventory, KEV monitoring, exception governance, and detection coverage through our SOC. Get in touch.