Imagine an AI agent infiltrating your network for two weeks, scanning, breaking in, and moving between systems, while a human reviews its output in brief messages. This scenario isn't hypothetical. Malbear Labs reported such an incident against a European telecom, using a jailbroken DeepSeek model and a custom harness. The entry point was a Cisco BroadWorks flaw with a high-severity patch available since Aug. 19.
The Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog and set a Nov. 24 deadline for civilian agencies. This deadline follows a June directive that replaced flat patching timelines with a sliding scale, allowing as little as three days for the riskiest exploited flaws. CISA's reasoning is that AI may further reduce the time defenders have once a patch is out.
This checklist helps you confirm that your vulnerability management program can meet this accelerated pace. Each item has a clear done/not-done state and a description of what effective implementation looks like.
Prerequisites
Before proceeding, ensure you have:
- A current asset inventory including internet-reachable and provisioning interfaces
- A designated owner for vulnerability management with authority to approve emergency changes
- Access to the CISA KEV catalog and your vendors' security advisories
- A documented patching policy to compare against the items below
Checklist Items
1. Your patch policy uses risk-based tiers, not one flat deadline.
Reference: NIST Cybersecurity Framework (CSF) 2.0, Identify and Protect functions; CIS Critical Security Controls, vulnerability management.
Done: Your policy defines at least one tier for known-exploited vulnerabilities with a deadline measured in days.
Effective implementation: Exploited flaws are prioritized by default, and severity score alone never places them in a slower queue.
2. The KEV catalog is a formal trigger in your process.
Done: A KEV listing automatically opens a ticket and starts the clock, with a named assignee.
Effective implementation: Someone reviews the catalog on a fixed schedule, and a KEV match against your asset inventory escalates without waiting for a monthly cycle. While private-sector firms aren't bound by CISA's directive, it serves as a defensible external benchmark for your own deadlines.
3. You measure time from patch release, not just time from detection.
Done: Your metrics record the gap between vendor patch availability and deployment.
Effective implementation: The BroadWorks case illustrates why. The fix was available on Aug. 19, yet exploitation followed. Your dashboard should expose that exposure window per asset class so leadership is aware.
4. Internet-reachable and provisioning interfaces are inventoried and tiered first.
Reference: NIST SP 800-53, CM-8 (System Component Inventory) and RA-5 (Vulnerability Monitoring and Scanning).
Done: Every externally reachable management or provisioning interface appears in your inventory with an owner.
Effective implementation: Telecom, voice, and other platform components outside the standard server fleet are not overlooked. The BroadWorks flaw affected anyone who could reach a provisioning interface, with no login required.
5. An emergency change path exists and has been tested.
Done: You have a documented expedited change procedure, and it has been exercised within the last year.
Effective implementation: Approvals for a three-day patch window take hours, not a standing committee cycle. Your auditors should see evidence of a rehearsal.
6. Compensating controls are pre-approved for unpatchable windows.
Done: For each critical platform, you have a written fallback such as restricting access to the vulnerable interface, disabling the affected feature, or segmenting the host.
Effective implementation: When a patch can't be applied within the deadline, risk acceptance is time-boxed, signed by the risk owner, and tracked to closure.
7. Default credentials are eliminated across internal systems.
Reference: CIS Critical Security Controls, secure configuration; NIST SP 800-53, IA-5.
Done: A scan confirms no production system retains vendor default credentials.
Effective implementation: Lateral movement is blocked. In the reported intrusion, a healthcare database holding millions of patient records was protected only by default credentials. Patching the entry point wouldn't have fixed that second failure.
8. Private keys and service identity material are rotated after exposure.
Done: Your incident playbook requires key and certificate rotation whenever a server could have leaked files.
Effective implementation: For any flaw that allows file disclosure, you rotate keys and component trust credentials as part of remediation, not as an afterthought. The attacker retrieved private keys, including one components use to authenticate to each other.
9. Detection assumes autonomous, tool-writing adversaries.
Reference: NIST Cybersecurity Framework (CSF) 2.0 2.0, Detect function.
Done: Your detection engineering reviews cover persistence after a tool is blocked.
Effective implementation: Endpoint blocks are treated as a signal to hunt, not a closed incident. The reported agent wrote a replacement tool after endpoint software stopped its first one, so your response must look for the second attempt.
10. Third-party and hosted-environment exposure is mapped.
Reference: ISO/IEC 27001 supplier relationships controls; ISO/IEC 27002.
Done: You know which suppliers host or operate systems on shared infrastructure alongside yours.
Effective implementation: Your contracts require timely patching and breach notification from providers. The agent mapped 13 organizations hosting systems in the telecom's environment, showing how one unpatched platform exposes its tenants.
11. AI-driven threats appear in your risk register.
Reference: ISO 31000; NIST AI Risk Management Framework for governance of your own AI use.
Done: The register has an entry for autonomous, AI-enabled exploitation with a named owner and treatment plan.
Effective implementation: Board reporting reflects shrinking time-to-exploit as a risk driver, with a stated risk appetite for exposure windows.
12. Evidence is retained for auditors.
Done: Tickets, approvals, scan results, and exception records are retrievable for each KEV-class vulnerability.
Effective implementation: You can show an auditor the timeline from advisory to remediation for any single flaw in minutes.
Common Mistakes
- Treating CVSS as the whole prioritization model. Exploitation status should outrank base score. A high-severity flaw already in KEV is more urgent than a critical one nobody is using.
- Patching the entry point and declaring victory. Credentials, keys, and lateral paths remain after the initial flaw is closed.
- Excluding "non-IT" platforms from the cycle. Voice and provisioning systems often fall outside server patch tooling.
- Writing exceptions with no expiry. Risk acceptance without a review date becomes permanent exposure.
- Reading CISA's directive as irrelevant because you aren't a federal agency. The sliding-scale logic describes where attacker timelines are heading, regardless of who is bound by it.
Next Steps
Start with items 1 through 3. If your policy lacks an exploited-vulnerability tier, that gap is your first remediation. Then run a tabletop exercise built around a known-exploited flaw on an externally reachable platform, measuring how long approval, testing, and deployment take. Report the result to your risk committee as a number, and compare it with the three-day floor in CISA's sliding scale. If your actual time is well above it, you have a quantified gap and a case for resourcing the fix.
