Zero-day response: What to do before a patch is available

A newly disclosed zero-day can create an awkward gap for IT teams. A vulnerability may affect your environment, but the normal patching workflow can't fully address it because an appropriate fix isn't available yet. 

That doesn't mean the only option is to wait. 

The immediate objective shifts from patching to understanding and reducing exposure, identifying potentially affected endpoints, applying appropriate temporary mitigations, and preparing to act once suitable remediation becomes available. 

This response forms part of the broader vulnerability management process, where identifying vulnerabilities is only one part of understanding and reducing risk across your environment. 

What is a zero-day vulnerability? 

 A zero-day vulnerability is a newly discovered security flaw that defenders have had little or no opportunity to address, often because an official patch or security update isn't yet available. 

However, “zero-day” shouldn't be used interchangeably with “critical vulnerability” or “actively exploited vulnerability.” 

These distinctions matter because they can change how IT teams interpret and respond to vulnerability information. 

A zero-day describes how little opportunity defenders have had to address a previously unknown vulnerability. Known exploitation tells you whether attackers have actually been observed exploiting a vulnerability in the wild. 

The two can overlap, but they don't have to. 

A newly discovered zero-day may have no confirmed exploitation. Conversely, attackers may actively exploit an older vulnerability even though a patch has already been available for some time. 

Keeping the terms separate helps teams avoid treating every zero-day as actively exploited or every actively exploited vulnerability as a zero-day. 

For vulnerabilities assigned a Common Vulnerabilities and Exposures (CVE) identifier, that identifier also gives teams a standardized way to reference and track the same vulnerability across advisories and security tools. 

How to respond to a zero-day before a patch is available 

When a zero-day doesn't have an appropriate patch, the goal is to understand your exposure and reduce risk while preparing for eventual remediation. 

A practical response involves seven steps. 

1. Verify the vulnerability and available guidance 

Start with the affected vendor's security advisory and other authoritative sources. 

Security news, social media, or an internal alert may be how you first hear about a vulnerability. Before making changes across your environment, establish what is actually known: 

• Affected products and versions 

• Vulnerability characteristics 

• Known exploitation status 

• Detection guidance, where available 

• Whether remediation exists 

• Recommended temporary mitigations or workarounds 

CISA's Known Exploited Vulnerabilities (KEV) Catalog can also help determine whether there is evidence that a vulnerability has been exploited in the wild. However, absence from the KEV Catalog should not be treated as confirmation that exploitation has not occurred. 

NIST’s proposed Likely Exploited Vulnerabilities (LEV) metric provides a complementary perspective by estimating the likelihood that a vulnerability has already been exploited. While LEV can help inform prioritization decisions, its estimates should not be treated as confirmed exploitation evidence. 

For vulnerabilities assigned a CVE, the National Vulnerability Database (NVD) can provide additional vulnerability context where available, including descriptions, severity information, and references to relevant advisories. Vendor guidance should remain a primary source for product-specific information, such as affected versions, mitigations, and available fixes.  

Treat this information as something that may change. 

Affected versions may expand or narrow; new exploitation evidence may emerge, recommended mitigations may change, and an appropriate fix may eventually become available.  

Checking authoritative guidance isn't a one-time step; continue monitoring it throughout the response. 

2. Identify potentially affected endpoints 

Once you know which products and versions are affected, determine whether they're present in your environment and where. Compare the advisory against information such as: 

• Installed applications and versions 

• Operating systems 

• Relevant services or processes 

• Number of potentially affected devices 

• Device group or business context 

• Device availability 

For example, if an advisory identifies several vulnerable versions of an application, knowing that your organization uses the application isn't enough. You need to determine which endpoints are actually running an affected version. 

This turns an abstract vulnerability into an endpoint population your team can assess and manage. 

Accurate device and software inventory becomes particularly important here. Without it, teams may struggle to determine the scope of their exposure or identify which systems require action. Maintaining an up-to-date IT asset inventory can make it easier to connect vulnerability information to the devices and software actually present in your environment. 

How PDQ can help 

PDQ can help teams identify known vulnerabilities across managed devices and understand which software and endpoints are affected. 

For zero-day response, this becomes useful once the vulnerability is known and represented in PDQ's vulnerability data. Teams can then connect that vulnerability information with their managed endpoint inventory.  

By associating known vulnerabilities with software detected across managed endpoints, PDQ helps teams narrow down which devices may be affected. This gives IT teams a clearer starting point for investigating potential exposure and determining where remediation efforts may be needed. 

3. Assess exposure and prioritize the response 

Finding vulnerable software doesn't necessarily mean every affected endpoint presents the same level of risk. 

Suppose 100 endpoints are running an affected application. Some may be isolated test devices. Others could be privileged administrator endpoints or systems supporting business-critical functions. 

They share a vulnerability, but they don't necessarily share the same risk. 

Prioritize based on factors such as: 

• Known exploitation 

• Exploitability 

• Device or service exposure 

• Potential business impact 

• Access or privileges 

• Existing controls 

• Operational importance 

• Availability and impact of temporary mitigations 

CVSS can inform prioritization, but it measures vulnerability severity, not organizational risk. Combine it with exploitability, exposure, asset criticality, and other environmental context. 

A vulnerability's technical severity doesn't capture every aspect of how it affects your particular environment. An exposed or privileged system affected by a lower-scoring vulnerability may require more immediate attention than an isolated endpoint affected by a higher-scoring vulnerability. 

Known exploitation can provide another useful prioritization signal. 

Instead of asking only, “How severe is this vulnerability?” also ask: 

“How much risk does this vulnerability create on these particular systems?” 

A broader approach to prioritizing vulnerabilities can help teams combine vulnerability characteristics with environmental and business context rather than relying on a single score. 

PDQ provides vulnerability risk and exploitability context alongside affected-device information, giving teams additional context when determining what requires attention first. 

4. Apply appropriate temporary mitigations 

If an appropriate patch isn't available, check whether the vendor or relevant security authorities recommend temporary measures to reduce risk. 

Depending on the vulnerability, these may include: 

It is worth noting that this isn't a universal zero-day checklist. 

A mitigation that works for one vulnerability may be irrelevant for another. The appropriate action depends on the vulnerability, authoritative guidance, and your environment. 

There's also an important distinction between mitigation and remediation. 

Mitigation aims to reduce risk without necessarily eliminating the underlying vulnerability. Remediation addresses the vulnerability itself through an appropriate patch, upgrade, configuration change, software removal, or other corrective action. 

When a permanent fix isn't available, temporary mitigation may help reduce exposure until remediation becomes possible. 

Some measures may also sit outside endpoint management. Network segmentation, EDR, SIEM, and other security controls can complement the endpoint response but serve different purposes. 

How PDQ can help 

Where an approved mitigation can be implemented through an endpoint action, PDQ can help execute supported changes across managed devices using capabilities such as scripting, software deployment, and custom packages. 

For example, authoritative guidance might recommend a configuration change, script, or removal of unnecessary affected software. 

PDQ can provide the execution mechanism in that scenario. The appropriate mitigation should still be determined from authoritative guidance and your organization's evaluation. 

5. Track affected devices and exceptions 

Applying a mitigation to some devices doesn't mean the entire affected population has been addressed. 

Track: 

• Successfully mitigated devices 

• Failed actions 

• Offline or unavailable endpoints 

• Newly identified affected devices 

• Intentional exclusions 

• Systems where the mitigation isn't appropriate 

• Other exceptions requiring review 

This is particularly important for remote and hybrid environments. 

An endpoint that was offline during the initial response may reconnect later. Software may change. New devices may enter the affected population. 

A static device list created at the beginning of the response can therefore become outdated. 

PDQ's filtering and device-organization capabilities can help maintain relevant endpoint populations as device information changes, reducing reliance on static lists. 

Throughout the response, teams should be able to answer a simple question: 

Which affected devices still require action? 

6. Continue monitoring for changes 

What you know on the first day of disclosure may change. 

Continue monitoring for: 

• Updated vendor advisories 

• New exploitation evidence 

• Changes to affected products or versions 

• Revised mitigations 

• KEV inclusion, where relevant 

• Availability of an appropriate patch or other remediation 

Your endpoint population can change too. 

Devices may reconnect, software may change, and new vulnerability information may affect which systems require attention. Maintaining endpoint visibility can help teams keep an accurate picture of their exposure as those conditions change. 

However, endpoint visibility shouldn't be confused with security threat monitoring. 

Knowing that vulnerable software exists on an endpoint isn't the same as knowing that the endpoint is being attacked or has been compromised. 

That's an important distinction in endpoint security management. EDR, SIEM, threat hunting, forensic investigation, and other security capabilities serve different purposes and may be required to detect or investigate active exploitation. 

7. Prepare for remediation 

You don't have to wait for a patch to start preparing for deployment. 

Before remediation becomes available: 

• Maintain an updated group of affected devices 

• Identify who can approve an urgent deployment 

• Determine an appropriate test population 

• Establish deployment priorities 

• Plan for failed or offline endpoints 

• Decide how remediation will be verified 

• Record temporary changes that may need review afterwards 

Doing this work early reduces the number of decisions that need to be made after a fix is released. 

If you've already identified affected endpoints, established deployment priorities, selected an appropriate test population, and determined who can approve an urgent change, the team can move more efficiently once remediation becomes available. 

Once an appropriate fix is released, transition into your emergency or out-of-band patching workflow. 

How can IT teams manage endpoint security without a dedicated security team? 

Smaller IT teams may not have dedicated vulnerability analysts or a SOC. The same team may be responsible for endpoint management, user support, software deployment, patching, and vulnerability response. 

PDQ's 2026 State of Sysadmin report reflects that pressure as 51% of sysadmins say timely security patch implementation takes too much time. 

A repeatable operating model can make urgent vulnerability response easier without forcing the team to invent a new process every time. 

The objective isn't to turn a sysadmin into an incident-response specialist. It's to make the operational responsibilities the IT team can reasonably own predictable and repeatable. 

Endpoint management can support the operational side of this process, but it doesn't replace specialist security capabilities. 

Threat hunting, compromise assessment, forensic investigation, and incident response may require additional tools or expertise. 

What should you do when a zero-day patch becomes available? 

nce an appropriate patch or other remediation becomes available, the response shifts from temporary exposure reduction toward addressing the underlying vulnerability. 

1. Recheck the advisory 

Return to the vendor's latest guidance and confirm that the remediation applies to the affected products and versions in your environment. 

Also check whether anything has changed since your initial assessment, such as affected versions, exploitation information, prerequisites, installation instructions, or known issues. 

2. Refresh the endpoint list 

Your environment may have changed while you were waiting. 

Refresh the affected-device population to account for devices that have reconnected, software changes, or updated vulnerability information. 

This gives you a current deployment target rather than one based on an earlier snapshot of your environment. 

3. Test where appropriate 

Balance urgency, exploitation evidence, operational risk, and vendor guidance when determining the appropriate level of testing. 

A vulnerability under active exploitation may warrant a much shorter testing window than one without evidence of exploitation. 

A representative test population can still help identify installation failures, compatibility issues, unexpected reboots, or other problems before broader deployment. 

The goal is controlled speed, not delay for its own sake. 

4. Prioritize and deploy 

Move affected endpoints into the appropriate emergency or out-of-band patching workflow. 

Use the prioritization work completed earlier to determine which systems should receive remediation first. 

For vulnerabilities that can't wait for the normal update cycle, an out-of-band patching framework can help teams make more deliberate decisions about testing, prioritization, and urgent deployment. 

5. Verify remediation 

Don't treat successful deployment alone as proof that the vulnerability has been resolved. 

A deployment can complete successfully without necessarily proving that the endpoint has reached the expected remediated state. 

Depending on the fix, verify that: 

• The expected patch is installed 

• The application has reached the fixed version 

• The required configuration is present 

• The endpoint no longer appears vulnerable 

• Failed or missed endpoints have been identified for follow-up 

Verification should be part of the remediation workflow rather than an afterthought. 

6. Review temporary mitigations 

Finally, revisit the temporary changes made while waiting for remediation. 

Some may need to be reversed. Others may still provide useful protection. Some may need to be modified. 

Review them against the vendor's latest guidance and your organization's requirements rather than automatically rolling everything back. 

PDQ can support the transition by helping teams identify affected endpoints and move supported vulnerabilities into relevant deployment or patching workflows once appropriate remediation is available. 

How endpoint management supports zero-day response 

Endpoint management supports the operational side of zero-day response by helping IT teams understand which devices and software may be affected and take appropriate endpoint actions. 

PDQ brings these capabilities together across vulnerability management, inventory, deployment, automation, and patching. 

This can help shorten the operational path between learning about a vulnerability, determining which devices may be affected, and taking supported action. 

The gap is significant. According to PDQ's research, 73% of sysadmins want endpoint management to be mostly or fully automated, but only 23% describe their current state that way. 

However, endpoint management is only one part of zero-day response. A vulnerability scanner can help identify and assess known vulnerabilities, while other security capabilities may be needed to detect active threats or investigate potential compromise. 

 PDQ complements rather than replaces EDR, SIEM, threat intelligence, threat hunting, and incident-response capabilities or the work of a SOC. 

Build a zero-day response process before you need it 

The middle of a high-risk vulnerability disclosure isn't the best time to decide who owns the response or how affected endpoints will be identified. Prepare the fundamentals in advance: 

• Maintain current endpoint and software inventory 

• Define trusted advisory sources 

• Establish vulnerability-prioritization criteria 

• Assign response ownership and escalation paths 

• Establish a process for deploying approved mitigations 

• Account for failed and unavailable devices 

• Maintain an out-of-band patching workflow 

• Define how remediation will be verified 

• Record temporary changes for later review 

You can't predict what the next zero-day will affect, what mitigation will be recommended, or when a permanent fix will become available. What you can do is reduce the number of operational decisions that need to be invented after one appears. For lean IT teams, that preparation can be especially valuable. Every process defined in advance is one less decision competing for attention during an urgent vulnerability response. 

Stay ready when the patch isn't 

A zero-day without an available patch creates uncertainty, but it doesn't leave IT teams without options. 

Focus first on understanding whether you're affected, which endpoints require attention, what mitigations are appropriate, and how you'll track the response. 

Continue monitoring authoritative guidance and your affected-device population as the situation develops. New exploitation evidence may emerge, mitigations may change, and previously unavailable endpoints may reconnect. 

At the same time, prepare your remediation workflow before the fix arrives. 

The goal isn't to claim the vulnerability has been eliminated when it hasn't. It's to reduce exposure where appropriate, maintain visibility into what still requires attention, and put your team in a better position to act once suitable remediation becomes available. 

FAQs 

How do you mitigate a zero-day vulnerability? 

Confirm the affected products and versions, identify potentially affected systems, and follow vendor-recommended mitigations. These may include disabling vulnerable functionality, changing configurations, restricting access, or isolating systems until appropriate remediation is available. 

Can you patch a zero-day vulnerability? 

 You can patch the vulnerability once an appropriate vendor patch becomes available. Until then, focus on reducing exposure through approved mitigations and preparing affected endpoints for remediation when a fix is released. 

Should you disable vulnerable software if no patch is available? 

Only when doing so is appropriate for the vulnerability and your environment. Follow vendor guidance and consider the operational impact before disabling functionality, stopping services, or removing vulnerable software. 

Does a zero-day vulnerability mean your system has been compromised? 

No. A zero-day vulnerability indicates a potential security risk, but its existence does not necessarily mean attackers have exploited it or compromised your systems. Even if the vulnerability is being actively exploited in the wild, that does not confirm your organization has been affected. Determining whether exploitation has occurred requires additional evidence from security monitoring or investigation.