Zero-Day Response: What to Do Before the Patch Exists

By David Mundy, VP of Marketing, Tuskira

Zero-day response is the discipline of closing exposure during the gap between disclosure, exploitation, and durable remediation. That gap is the whole problem. Exploitation now starts in hours; a patch may not exist yet, and even when it does, applying it safely everywhere takes days. The teams that handle zero-days well aren't faster at patching. They're faster at answering four questions and deploying a compensating control while everyone else is still building a spreadsheet.

Key takeaways

• A zero-day is a response problem, not a patching problem: at disclosure there may be nothing to patch, so the goal is closing exposure through controls you already own.
• Four questions decide everything: Do we run it? Is it reachable? Is it already defended? What can it reach next?
• The scramble fails at the first question. Most organizations take days to establish where a vulnerable component is deployed; exploitation now begins in minutes.
• Measure zero-day readiness in time-to-verdict and time-to-mitigation, not time-to-patch. The patch date belongs to your vendor; the exposure window belongs to you.

Why the old playbook stopped working

The traditional zero-day drill: news breaks, someone opens a war room, teams kick off emergency scans, results land in a spreadsheet, and the organization waits for a vendor patch while executives ask "are we exposed?" several times a day. That playbook assumed the attacker needed weeks. Attackers now weaponize disclosures in hours, and AI-assisted vulnerability research is compressing the pipeline further. As documented in our Patch Gap report, one AI-driven research effort disclosed 1,596 verified vulnerabilities across 281 open-source projects in 63 days, roughly 25 per day, against a typical enterprise remediation rate near 1.5 per day.

Scanning alone is the wrong dependency for hour one, too. Scanners tell you where a CVE signature matches, on their schedule, after the scan window. The question that actually matters in hour one is different, and no single tool can answer it.

The four questions of zero-day response

Every zero-day resolves into the same four questions. Answer them with evidence and the panic disappears; fail to answer them and every instance is critical by default.

1. Do we run it? Not "does the CVE exist," but where, exactly, is the vulnerable component deployed, including transitive dependencies, embedded libraries, and the SaaS vendors in your supply chain?
2. Is it reachable? Is any vulnerable instance exposed to an attack path: internet-facing, reachable from a compromised user segment, or sitting behind a control that doesn't inspect the exploit's protocol?
3. Is it already defended? Would an existing WAF rule, EDR policy, or network control block the exploit pattern as deployed today? A vulnerable-but-defended instance is a different priority than a naked one.
4. What can it reach next? If the instance is compromised, what do its privileges and connections put in blast radius: which identities, which data, which crown jewels?

Answering these requires joined context: software inventory, network exposure, identity privileges, and control state, connected in one model. This is what a security context graph exists to do, and it's why teams that maintain one answer in minutes what takes scan-and-spreadsheet teams days. It's also the same validation logic that separates real vulnerability prioritization from severity-score sorting the rest of the year.

This four-question loop is the operating model behind Quell, Tuskira's zero-day response agent, which runs it continuously instead of per-incident.

Compensating controls: closing exposure without a patch

The defining move of modern zero-day response is the compensating control: a change to the defenses you already own that blocks the exploit path while the patch doesn't exist or can't yet be safely applied. A WAF rule that drops the exploit pattern. An EDR policy that kills the post-exploit behavior. A segmentation change that removes reachability. An identity restriction that shrinks the blast radius.

Two properties make a compensating control real rather than theater. It must be validated against the actual attack path, shown to block the actual technique as deployed in your environment, not assumed to. And it must be tracked to retirement, applied as a bridge, then removed or kept deliberately once the patch lands. Untracked temporary controls become permanent mystery rules that nobody dares delete.

This is also where the economics shift. A patch cycle on a production system means testing, change windows, and risk. A validated control change through tooling you already own takes minutes and is reversible. Close the exposure first; patch on your schedule, not the attacker's.

The first 24 hours, run well

• Hour 0: Disclosure. The CVE drops. Instead of launching scans, query current state: deployment map, reachability, control coverage. With a live context graph this is a lookup, not a project.
• Hour 1: Verdict. Every instance sorted into exposed, defended, or not deployed, with evidence. Executives get an answer, not a status update.
• Hours 2-4: Mitigation. Compensating controls deployed through the existing stack on every exposed path. Exposure window: closed for the reachable paths you can control. This is the step Quell operationalizes: reachability verdicts in minutes, recommended control changes with the evidence attached.
• Day 1+: Remediation. The vendor patch ships and rolls out under normal change management, because the exposure emergency ended at hour four. Temporary controls are verified and retired. Run continuously, this loop is the mobilization step that most continuous threat exposure management programs stall on.

What to measure

Zero-day readiness shows up in four numbers: time-to-verdict (disclosure to evidence-backed exposure answer), time-to-mitigation (disclosure to closed exposure), percent of estate answerable (how much of your environment the deployment question can be answered for at all), and control retirement rate (temporary mitigations actually cleaned up after patching). Time-to-patch is worth tracking, but as a vendor metric, not a readiness one.

Frequently asked questions

What's the difference between zero-day response and patch management?

Patch management remediates known vulnerabilities on a cycle, with patches available. Zero-day response closes exposure to a vulnerability that has no patch yet, using reachability analysis and compensating controls. The first is scheduled hygiene; the second is an evidence race.

Are compensating controls a substitute for patching?

No. They're a bridge. A validated control closes the exposure window immediately; the patch remains the durable fix. The failure mode to avoid is the reverse: waiting exposed for a patch when a control change could have closed the path in an hour.

How fast should a team be able to answer "are we exposed?"

For a well-instrumented environment, minutes to low hours. The constraint is whether deployment, reachability, and control state already exist as queryable context. If the answer requires launching new scans, the honest answer is days.

Does AI change zero-day response?

On both sides. Attackers use AI to find and weaponize vulnerabilities faster, which compresses the response window. Defenders use AI agents to run the four questions continuously and validate mitigations, but only when the agent reasons over connected environment context; an AI that sees only scanner output can just re-rank the scramble. (How to evaluate that difference: our buyer's guide.)

See how Tuskira answers zero-day reachability on your stack, or read how the platform works.