Zero-Day Response: What to Do in the First 24 Hours Before a Patch Exists

The first question a zero-day demands is not 'how do we patch this?' but 'do we even run this software?' That question is surprisingly hard to answer accurately and quickly, and the quality of your answer in the first two hours determines the entire trajectory of your response. If your asset inventory is complete, accurate, and queryable, you can answer the question in under thirty minutes. If it is not, you will spend days enumerating exposure while adversaries may already be working through your attack surface.

Start with your CMDB or asset management platform. Query for the vendor name, product name, and any known component names associated with the vulnerable software. Zero-days in libraries or embedded components are the most dangerous here because a search for 'Apache Log4j' will miss every application that bundles it as a transitive dependency without labeling it in the asset record. This is why SBOM programs matter before a zero-day hits, not after. For vulnerability classes in named products, a direct CMDB query is a reasonable first pass.

Layer your EDR fleet on top of the CMDB query. EDR agents maintain a running inventory of installed software and active processes. In CrowdStrike Falcon, query the Discover module with the product name or associated executable. In Microsoft Defender for Endpoint, the Advanced Hunting query DeviceSoftwareInventory | where SoftwareName contains 'target_product' returns all endpoints with the software installed, along with version numbers that you can match against the vulnerable range. Repeat this against your CSPM platform for cloud workloads. AWS Systems Manager Inventory, Azure Arc, and Google Cloud's OS Config all expose installed software queries that surface vulnerable versions on cloud instances that may not be in your CMDB.

The SIEM is the third layer. Search your log ingestion for process execution events, network connections, or authentication events associated with the vulnerable service. This is not about detecting active exploitation at this stage. It is about confirming that the service is running and actively generating logs, which validates that your asset inventory entries represent live production systems rather than decommissioned records that were never cleaned up. A system that appears in your CMDB but generates no logs in thirty days is worth investigating before you count it in your exposure surface.

Document everything you find in a working spreadsheet: system name, IP, business owner, environment (production, staging, dev), internet-facing status, and current software version. Sort by risk tier before anything else. Internet-facing production systems running the vulnerable software are your immediate priority. Internal development systems running the same software are a real exposure but not your first-hour concern.

Before you spend hours characterizing the theoretical severity of a vulnerability, check one source: the CISA Known Exploited Vulnerabilities catalog. CISA maintains a real-time list of CVEs with confirmed active exploitation in the wild, and they update it aggressively when evidence of exploitation emerges from federal network telemetry, vendor reporting, and threat intelligence partnerships. If your zero-day CVE is already on the KEV list, the strategic calculus changes immediately. You are no longer in a window of theoretical exposure. Exploitation is confirmed, and your compensating controls need to be in place within hours, not days.

The KEV entry also tells you the 'Required Action' CISA has assigned to federal agencies, which is effectively a recommended remediation or mitigation step. Even if you are not a federal agency, this is a vetted compensating control recommendation that you can implement immediately. CISA typically references vendor-published mitigations, workarounds, or interim fixes in the KEV entry notes.

If the CVE is not yet on KEV, monitor it. Set up an RSS feed or API poll against the KEV catalog filtered to your CVE. CISA adds entries continuously as evidence of exploitation surfaces, and a vulnerability that was not on KEV at 9 AM may be on KEV by 3 PM after a threat intelligence firm publishes exploitation evidence. The gap between initial disclosure and KEV addition has shrunk significantly as CISA has improved its operational cadence.

Supplement KEV with vendor threat intelligence sources. Microsoft MSRC tracks active exploitation for Windows and Azure vulnerabilities and publishes exploitation assessment in their security advisories. Google Threat Analysis Group and Mandiant both publish rapid analysis for high-severity zero-days within hours of disclosure. Shadowserver and GreyNoise publish scan data that shows whether attackers are actively probing internet-facing instances of the vulnerable service, which is an early signal of exploitation preparation even before confirmed successful attacks are reported.

Zero-days reliably generate conflicting information in the first 24 to 48 hours. The vendor may publish a CVSS score that independent researchers immediately dispute. The vendor advisory may describe the vulnerability as 'requiring authentication' when a proof-of-concept published hours later demonstrates unauthenticated exploitation. A researcher may publish a CVSS 9.8 RCE while a second researcher argues the real-world exploitability is much lower due to memory layout requirements. Navigating this conflicting information accurately under time pressure is a critical skill.

Start with the CVSS score as a rough signal, not a decision driver. CVSS 3.1 base scores measure theoretical worst-case impact without regard to actual exploitability in real environments. A CVSS 9.8 unauthenticated RCE in a service that is not internet-facing at your organization is far less urgent than a CVSS 7.5 authentication bypass in your externally published login portal. Context matters more than the number. CVSS 4.0 introduced an improved threat metric component, but vendor adoption is inconsistent.

Weight independent researcher analysis heavily, particularly from organizations with track records of accurate exploitation characterization. Google Project Zero, Qualys Threat Research Unit, Rapid7 AttackerKB, and Tenable's Zero Day Research team all publish technical breakdowns that go beyond CVSS scores to assess actual exploit complexity, required attacker position (network vs. local), and known weaponization status. AttackerKB specifically aggregates practitioner commentary on real-world exploitability and is one of the fastest places to get ground-truth assessment from people who have tested the vulnerability.

When the vendor advisory conflicts with independent research, pay attention to whose analysis is based on actual exploitation testing versus theoretical severity assessment. Vendors have legal and business incentives to downplay severity in initial advisories. Researchers publishing proof-of-concept code have already confirmed exploitability by definition. If a working PoC exists, treat the vulnerability as fully exploitable regardless of what the vendor advisory says about complexity. The existence of public PoC code also materially changes your timeline: weaponized variants of PoC exploits typically appear within 24 to 72 hours of public PoC publication.

When no patch exists, compensating controls are your only technical mitigation. The appropriate compensating controls depend heavily on the vulnerability class. Deploying the wrong control wastes time and creates false confidence. The following framework covers the three most common and impactful zero-day classes.

For remote code execution vulnerabilities in network-accessible services, the primary compensating controls are network segmentation and WAF rule deployment. Network segmentation means restricting access to the vulnerable service to the minimum necessary network segments. If the vulnerable service is an internal application server, block inbound connections from all network zones except those with legitimate business need. If the vulnerable service is externally facing, consider whether it can be temporarily taken offline, placed behind a jump host, or restricted to specific IP ranges. WAF rules should be deployed for any vulnerability that can be triggered through HTTP request manipulation. Most vulnerability disclosures that affect web-facing services result in WAF vendor rule releases within hours. Check your WAF vendor's threat intelligence feed and deploy any available virtual patches immediately.

For authentication bypass vulnerabilities, the compensating controls center on reducing the attack surface of the authentication flow. Enforce MFA on any authentication path that the bypass might target. Restrict access to the authentication endpoint to known IP ranges where possible. Enable enhanced logging on the authentication service so that any successful exploitation generates detectable artifacts in your SIEM. Review your authentication logs for anomalous patterns immediately after deploying enhanced logging to check for exploitation that may have already occurred.

For privilege escalation vulnerabilities that require local access, the compensating controls operate at the endpoint layer. Deploy additional monitoring rules on your EDR for the specific techniques the vulnerability uses: token manipulation, named pipe abuse, DLL hijacking, or whatever the exploitation mechanism requires. Restrict privileges on accounts that could be targeted for initial exploitation that then uses the privilege escalation vulnerability as a chaining step. Review recently created local administrator accounts and privileged group membership changes in the 48 hours preceding the disclosure to check for pre-positioning activity.

When a vendor releases an emergency patch for a zero-day, the default assumption that you should patch immediately is not always correct. Emergency patches are developed under extreme time pressure and have historically introduced regressions, broken critical functionality, or in some cases introduced new vulnerabilities. The decision to patch must be an explicit decision, not a reflexive one, and it must account for the specific risk profile of each affected system.

Build a tiered patching priority based on three factors: exposure to the internet, business criticality, and availability of compensating controls. Tier one systems are internet-facing production systems with no viable compensating controls. These get patched first, on the fastest feasible timeline, with abbreviated testing cycles if necessary. The risk of being exploited outweighs the risk of a regression. Tier two systems are internet-facing systems where compensating controls have been successfully deployed. These get patched on a compressed but not emergency timeline, with at least basic functional testing. Tier three systems are internal systems where network access controls significantly limit exploitation feasibility. These go through your normal accelerated patching process.

For tier one systems where the patch represents significant functional risk, consider isolation as an alternative to emergency patching. Taking a system offline eliminates exploitation risk entirely, which may be preferable to deploying an undertested patch in production. This decision requires business owner involvement because it means accepting service downtime. Document the business owner's explicit approval before taking any system offline for emergency maintenance.

Vendor patch quality signals are worth tracking before you deploy broadly. Monitor the vendor's support forums, Reddit security communities, and your peer network in the first two to four hours after a patch is released. Widespread reports of regressions or broken functionality are an early warning that the patch needs additional validation before broad deployment. CISA's Known Exploited Vulnerabilities catalog sometimes notes patch quality concerns when vendor patches are incomplete or have known issues.

Zero-day response fails organizationally when communication is either too narrow or too broad at the wrong times. Operational response decisions should be made by the security team with minimal committee overhead in the first two hours. Briefing leadership too early, before you have a preliminary exposure assessment, generates uninformed pressure and decision-making noise. Briefing leadership too late, after they read about the vulnerability in a news article, destroys credibility and may trigger disproportionate escalation.

The CISO should receive an initial briefing within two hours of the vulnerability being confirmed as relevant to your environment. This briefing should include confirmed exposure scope, initial risk assessment, compensating controls deployed or in progress, and the patching timeline. It should not be a request for permission to respond. It should be a factual status update that gives the CISO what they need to answer questions from the board or leadership if they are asked.

Legal counsel needs to be engaged if there is any indication that active exploitation has occurred or that customer or employee data may be at risk. Most jurisdictions have breach notification timelines that begin when an organization becomes aware of a potential breach, not when a breach is confirmed. Your legal team needs visibility into potential exposure situations early enough to assess notification obligations. The threshold for legal engagement should be a confirmed exploitation attempt against your environment, not just the existence of a public vulnerability.

Board notification thresholds vary by organization and jurisdiction but are generally triggered by material breaches with financial, reputational, or regulatory impact. For a zero-day with no confirmed exploitation at your organization, board notification is typically not required in the acute phase. If your organization is publicly traded, work with legal to assess whether the zero-day creates a material cybersecurity risk that requires disclosure under SEC rules. The SEC's 2023 cybersecurity disclosure rules require material incident disclosure within four business days, so legal needs to be in the loop on exposure and response progress throughout.

Once a zero-day is in active exploitation, your threat intelligence function needs to shift from general vulnerability monitoring to CVE-specific IOC tracking. Adversaries exploiting a specific vulnerability leave consistent artifacts: specific user agents, request patterns, exploitation payloads, network signatures, and post-exploitation tooling that appears repeatedly across different victims.

Track CISA, US-CERT, and vendor threat intelligence feeds for CVE-specific IOC publications. These typically include network indicators (IP addresses used in exploitation campaigns, C2 infrastructure associated with post-exploitation payloads) and host-based indicators (file hashes, process trees, registry modifications). Load these IOCs into your SIEM and EDR with the highest priority alert tier. A hit on a CVE-specific IOC in your environment during active exploitation of that CVE is a high-confidence signal of successful exploitation, not just probing.

Monitor your web application firewall and intrusion detection system logs specifically for exploitation attempt signatures, even if you have deployed compensating controls. Knowing that adversaries are actively probing your vulnerable services tells you two things: your internet-facing exposure is real and visible to threat actors, and the time pressure on patching is increasing. A jump in exploitation probes against your environment is also a signal to review your compensating controls for bypass techniques, since determined adversaries may test control effectiveness before a patch is available.

Threat intelligence sharing through ISACs is particularly valuable for zero-day response. If you are a member of an information sharing and analysis center relevant to your sector, check whether peers have published exploitation indicators or compensating control effectiveness observations specific to the active zero-day. Peer organizations in the same industry often face the same zero-days against the same third-party software, and firsthand remediation experience from peers is more operationally useful than general vendor guidance.

Vendor security advisories for zero-days are written under legal review and optimized for liability minimization rather than operational clarity. They frequently understate severity, omit critical technical details needed for effective detection, and describe workarounds in vague terms that security teams cannot directly implement. When the advisory is insufficient, direct engagement with the vendor's product security or security response team is necessary.

For major vendors with formal security response programs, identify the correct contact channel before you need it. Microsoft MSRC, Cisco PSIRT, Palo Alto Unit 42, and similar teams all have documented contact mechanisms for security inquiries. Some vendors maintain customer-specific security liaisons for enterprise accounts. If you are an enterprise customer with a dedicated account team, your account manager can escalate to the security response team faster than the public contact channel.

When you contact the vendor, be specific about what you need. Generic requests for more information rarely produce useful responses. Specific requests work better: 'Your advisory states the vulnerability requires local access. Our threat intelligence indicates there is a network-accessible exploitation vector. Can you confirm or deny a network-based attack path?' or 'The advisory references a workaround involving a registry key change. Can you confirm this fully mitigates the RCE without requiring a system restart?' Specific technical questions get routed to engineering teams faster than general inquiries.

Document all vendor communications with timestamps. If a vendor provides a verbal assurance that a workaround is effective and it later proves not to be, the documentation protects your organization and informs post-incident review. If you disagree with the vendor's severity assessment based on independent research, document that disagreement and your reasoning. Post-incident reviews of zero-day responses frequently reveal that internal teams had accurate severity assessments that were overridden by vendor communications, and documentation establishes organizational accountability.

Once the vendor ships a patch and your team completes the deployment across affected systems, the response is not over. The 72-hour post-patch review serves two functions: confirming that the patch was applied correctly and that no evidence of prior exploitation exists, and capturing process improvements before institutional memory of the response fades.

Validate patch deployment completeness. Run the same queries you used in hour zero of the exposure assessment against your EDR, CMDB, and CSPM to confirm all vulnerable instances have been remediated. Mismatches between your patch deployment records and the asset query results reveal either deployment failures or asset inventory gaps that need to be addressed. Any system that appears in the post-patch query as still running a vulnerable version despite being on the patch deployment list requires immediate investigation. Prioritize internet-facing systems in the validation sweep.

Conduct a retrospective exploitation hunt. Review all logs from the period between the vulnerability's public disclosure and the time your compensating controls were deployed. Look specifically for the exploitation patterns documented in threat intelligence from the response period. You are checking whether adversaries exploited the vulnerability before your controls were in place. A clean retrospective hunt does not definitively rule out exploitation, particularly if log coverage was incomplete, but it is a necessary step before closing the response.

Document the lessons learned in enough detail to drive process changes. The most common zero-day response failures are: incomplete asset inventory that delayed initial exposure assessment, absence of compensating controls for the vulnerability class that required building new rules under time pressure, unclear escalation thresholds that led to delayed CISO briefing, and slow patch deployment because change management processes were not adapted for emergency timelines. Map each failure to a specific process improvement and assign ownership. Zero-days repeat, and the organizations that improve their response capability between zero-days are the ones that avoid breaches in subsequent events.