How to prioritize patches for exploited flaws using CISA's KEV and Cyber Centre alerts
At a glance
What you need
- An asset inventory that records software versions and internet exposure
- A vulnerability scanner or endpoint management tool
- Authority to schedule emergency changes
Most organizations cannot patch every vulnerability at once, and scanners report thousands of findings. The practical answer is to fix first the flaws that are being exploited in the wild, on the systems attackers can reach. Two free public sources make that possible for Canadian IT teams: the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalogue and the alerts and advisories published by the Canadian Centre for Cyber Security (Cyber Centre).
This guide shows how to wire both into a weekly routine, and which timelines to use.
Step 1: Understand what the KEV catalogue is, and is not
CISA adds a vulnerability to the KEV catalogue only when three conditions are met: it has a CVE identifier, there is reliable evidence it has been actively exploited in the wild, and there is a clear remediation action such as a vendor update. Proof-of-concept code or scanning activity alone does not qualify.
That makes KEV a short, high-signal list, not a complete one. A flaw can be exploited before CISA lists it. Treat KEV as a floor, not a ceiling.
The catalogue's legal force applies to U.S. federal civilian agencies. On June 10, 2026, CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, which supersedes BOD 22-01 and BOD 19-02. It keeps KEV status as one of four decision factors, alongside whether an asset is publicly exposed, whether exploitation can be automated and the technical impact. CISA encourages organizations outside the U.S. government to prioritize KEV entries as well, and to feed the catalogue into automated vulnerability and patch management tools.
Step 2: Subscribe to the right feeds
- Sign up for CISA's KEV email updates from the catalogue page, or have your scanner or ticketing tool pull the catalogue, which CISA publishes in machine-readable formats.
- Follow the Cyber Centre's Alerts and advisories on cyber.gc.ca. The Cyber Centre publishes them on its website and by RSS. Federal guidance notes that a Cyber Centre Cyber Flash can trigger an emergency patching scenario.
- Subscribe to security notifications from every vendor whose products face the internet: firewall, VPN, email gateway, remote-management and file-transfer products are the usual targets.
- Route all three into one queue so nothing depends on one person's inbox.
Step 3: Know which assets are exposed
- Tag every asset in your inventory with its exposure: reachable from the internet, internal only, or isolated.
- Record the vendor, product and version. Without versions, you cannot match a KEV entry or Cyber Centre advisory to your environment.
- Record end-of-support dates. A KEV entry for a product that no longer receives updates usually means the product has to go. CISA's guidance is that end-of-life products that cannot be updated should be removed from networks.
Step 4: Set your remediation timelines
The Government of Canada's Patch Management Guidance suggests minimum timeframes by impact rating:
- Extreme: emergency patch within 48 hours.
- High: within two weeks.
- Medium: at the next major update or within three months.
- Low: at the next major update or within a year.
The guidance calls these suggestions and asks for a risk-based approach that considers exploit likelihood, threat profile and mitigating controls. A sensible local rule: any KEV entry or Cyber Centre alert affecting an internet-facing asset is treated as extreme; a KEV entry on an internal asset is treated as high at minimum. The Cyber Centre ranks patching operating systems and applications as the second most important of its top 10 IT security actions.
Step 5: Run a weekly triage
- Pull the KEV entries and Cyber Centre alerts published since the last review.
- Match them against your inventory by vendor, product and version.
- For each match, open a change ticket with the timeline from Step 4, an owner and a due date.
- Where no patch can be applied in time, apply the vendor's mitigation (disable the vulnerable feature, restrict access to the management interface, or take the service offline) and record it as temporary.
- Review scanner findings not on KEV afterwards, sorted by severity and exposure.
Step 6: Patch and verify
- Test on a standby or non-production device where you can, then deploy. For edge devices, the Cyber Centre's Security considerations for edge devices (ITSM.80.101) advises installing security patches as quickly as possible after testing.
- Rescan to confirm the fix. A patch that failed silently is a common gap.
- Check for signs of compromise. When a flaw was exploited before you patched, updating the software does not remove an attacker who is already in. Review vendor indicators of compromise and logs for the exposure period.
Step 7: Measure and report
- Track the median time from KEV listing or Cyber Centre alert to remediation, split by internet-facing and internal assets.
- Track overdue items and accepted risks, with an executive sign-off for each exception.
- Report monthly to management. Clear numbers make it easier to get maintenance windows and to fund the replacement of unsupported devices.
A worked example
Suppose CISA adds a flaw in your firewall vendor's SSL VPN to the KEV catalogue on a Tuesday, and the Cyber Centre publishes an alert the same day. Your inventory shows two affected gateways, both internet-facing. Under the local rule in Step 4, that is an extreme-impact item: the owner applies the vendor's mitigation within hours, schedules the firmware update for that night, rescans on Wednesday, and reviews VPN and administrator logs back to the date the vendor says exploitation began. The ticket records each step, so the next monthly report shows the item closed within 48 hours.
Common mistakes
- Relying on CVSS scores alone. A medium-rated flaw being exploited on your VPN matters more than a critical flaw on an isolated lab server.
- Forgetting firmware and appliances, which endpoint patching tools often miss.
- Skipping the compromise check after an emergency patch.