Patching Known Exploited Vulnerabilities: A Practical KEV Playbook

Published October 23, 2026 · Last reviewed October 23, 2026

Why the KEV list beats a score

A severity score says how bad a flaw could be. The KEV catalogue says that someone is already using it. For a business with a few hours a week to spend on patching, that is the better question. Each entry names the vendor and product, the date it was added, a short description, the action CISA expects, and a due date for U.S. federal agencies under Binding Operational Directive 22-01. The due date does not bind a private business, but it is a useful benchmark, and it is labelled as one in this guide. Entries also carry a field showing whether the flaw is known to have been used in ransomware campaigns.

The catalogue is published as a web page, a JSON feed and a CSV file at cisa.gov, and it changes often.

The weekly routine

1. Keep a simple inventory: a sheet listing every internet-facing device and service, every server, and the main software on workstations, with the vendor and product name as the vendor writes it.
2. Once a week, download the KEV list (or read the newest additions on the catalogue page) and filter by the vendors and products on your sheet.
3. For each match, record the date added, whether you run the product, whether it faces the internet, and the vendor’s fixed version from the vendor advisory.
4. Apply the timeline below, then record the date you patched and how you confirmed the fix.

A command-line filter, for anyone comfortable with curl and jq, can show recent entries for a vendor named on your sheet. Replace the vendor name with your own:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | jq -r '.vulnerabilities[] | select(.vendorProject | test("examplevendor"; "i")) | [.cveID, .dateAdded, .dueDate] | @tsv'

The action timeline

Action

Within 4 hours of learning of a match on an internet-facing device: confirm whether you run the affected product and version from the vendor advisory, and restrict access to its management interface or the affected service (firewall rule, VPN-only access or temporarily taking it offline).

Why it helps

Exploitation is already happening, so the exposure window closes only when the service is unreachable or fixed. Containing access takes minutes; patching may take longer.

Verification

From a network outside yours (a phone hotspot is enough), check that the management page or port no longer answers.

Fallback if delayed

If you cannot restrict access, take the device offline until a fix is applied, and decide with the owner whether the business can run without it.

Action

Within 24 hours: apply the vendor’s fix to internet-facing matches, using the admin console of the product. Take a configuration backup first. Profile A Profile B/C delta: for on-premises directory servers in a hybrid setup, schedule the fix with the same priority; the exposure path differs but the urgency does not.

Why it helps

A fix that arrives after the attacker has settled in does not remove them, but it stops everyone else. The sooner it lands, the shorter the period in which a second attacker can arrive.

Verification

Read the product’s version in its admin page or from its command line and compare it with the fixed version named in the vendor advisory. Record the version and the date.

Fallback if delayed

Apply the vendor’s documented workaround or mitigation, and record that the system remains at risk until the real fix is installed.

Action

Within 7 days: patch matches that are not internet-facing, such as workstation software, internal servers and line-of-business applications, using Windows Update, your management tool or the vendor’s updater.

Why it helps

Internal flaws matter once an attacker is inside. A short, fixed window keeps the backlog from growing.

Verification

On Windows, open Settings, Windows Update, Update history; on macOS, System Settings, General, Software Update. Spot-check three machines against the fixed version.

Fallback if delayed

For systems that cannot be updated, isolate them from the internet and from the main network, and note the date to revisit.

When patching is not enough: assume compromise

If a flaw is on the KEV list and the affected service was reachable from the internet at any point during the time the flaw was exploited (the exposure window), do a compromise assessment, not only a patch. Patching removes the way in. It does not remove an attacker who used it earlier, and attackers commonly create accounts, install tools or steal credentials during that window.

• Review the device’s logs from the day the flaw was added to the catalogue (or earlier, if the vendor says so) for unfamiliar sign-ins, new administrator accounts and unexpected configuration changes.
• List outbound connections from the device to destinations you do not recognise.
• Reset credentials stored on, or reachable from, the device, and review its configuration against a known-good backup.
• Where logs are missing, or the device handled sensitive data, ask your MSP or an incident-response firm to examine it, and call your cyber insurer first if you hold a policy.

The IOC rule applies: use only indicators published by authoritative sources, and otherwise look for behavioural signs such as new local accounts, unexpected service restarts and changed settings.

Common failure mode

The inventory lists the product but not the thing that is exposed: a forgotten firewall, a camera system, an old remote-access appliance, or a vendor-managed device that nobody patches. The sheet says “patched” because the owner believed the vendor would do it. Confirm by reading the version number, never by assuming.

How it works

The catalogue exists because defenders cannot patch everything. CISA adds an entry when there is evidence of exploitation and a clear fix or mitigation, and the entry gives defenders a short, high-confidence list. Researchers at the National Institute of Standards and Technology describe the same idea in their patch management guidance: group assets by how much the business depends on them, and plan maintenance around risk rather than an equal schedule for everything.

The timeline puts that idea into hours. Containment comes first because it is the fastest control, the fix follows, and the broader estate is handled on a regular cycle. The compromise assessment is the step most small businesses skip. It exists because the date a flaw is added to the catalogue is not the date exploitation began, so the exposure window may begin before you heard about it. For which devices to put on the inventory first, see internet-facing exposure.

Worked example

Suppose, as a hypothetical, a 60-person firm runs one remote-access appliance from a vendor whose name appears in a new KEV entry. The owner’s inventory sheet shows the appliance faces the internet.

At hour one the IT lead reads the vendor advisory and confirms the firm runs an affected version. The management page is limited to the office network by a firewall rule, and an outside check from a phone hotspot confirms it no longer answers. By hour twenty the firm has taken a configuration backup, installed the vendor’s fixed version and recorded the version string. Because the appliance was reachable for the whole window, the lead then reviews the appliance logs for unfamiliar administrator accounts and resets the credentials it stored. Nothing odd is found, and the lead writes that down with the dates. Every detail here is invented to show the sequence; real products, versions and findings will differ.