Anatomy of a Zero-Day: What to Do Before a Patch Exists

A zero-day is a vulnerability being exploited before a fix exists. What makes it dangerous is not sophistication but timing: for a period measured in days or weeks, the normal response — patch it — is unavailable, and everyone knows it.

The first two hours

Do we have it? This is an asset inventory question and it is where most organisations lose their first day. If answering "do we run this product, and where" takes a day of emails, that is the finding to act on after the incident.

Is it reachable? An internet-facing instance is an emergency. The same product on an isolated clinical VLAN is a scheduled change. Exposure changes the response completely.

Compensate. Before a patch exists, reduce reachability: block at the perimeter, disable the vulnerable feature, restrict source addresses, add a WAF rule, take a non-essential service offline. These are unglamorous and they are what the window is for.

Hunt. Assume it may already have been used against you. Look for the indicators in the advisory, and for the behaviour the exploit would produce, across the retention period you have — see threat hunting.

Assume prior exploitation

The sequence is almost always: exploited quietly, discovered, disclosed, patched. By the time you read the advisory, the flaw may have been in use for weeks.

That has two implications:

1. Patching does not remediate a compromise that already happened. If you were vulnerable and exposed, hunt before you close the door and assume you may be shutting an attacker in.
2. Check your log retention against the disclosed exploitation window. If the flaw has been exploited for three months and you keep 30 days, you cannot answer the question — see logging strategy.

The healthcare constraint

Emergency patching a clinical system carries its own risk: an untested patch on an EHR or an instrument can cause a clinical outage, which is a patient safety event. The resolution is not to skip the patch but to make the decision explicitly, with clinical leadership, weighing:

• Is the system internet-reachable? If yes, the balance shifts sharply to patching
• Can we compensate instead for 48 hours while testing?
• What is the clinical impact if the patch breaks it?
• What is the clinical impact if it is exploited?

Have this decision route agreed in advance — who can authorise an emergency clinical change out of hours — because establishing it during an active exploitation event costs the time you do not have.

Communicating during the window

Zero-days attract attention, and leadership will ask before you have answers. What works:

• State what is known, what is not, and when you will update. "We run the affected product on four systems, none internet-facing, we are hunting for prior exploitation and will update by 4pm" is a complete answer.
• Do not speculate on exploitation before hunting. "No evidence of compromise" after searching means something; before searching it means nothing and will be quoted back.
• Give clinical leadership the operational version: which systems may go offline, when, and for how long.
• Expect the scope to change. Advisories are updated, affected version lists grow, and initial guidance is sometimes wrong.

What to prepare now

• An asset inventory that answers "do we run X" in minutes
• An emergency change path with named out-of-hours authority
• Advisory monitoring — CISA KEV, vendor feeds, Health-ISAC
• Retention exceeding plausible exploitation windows
• A tested compensating-control playbook: perimeter block, feature disable, isolate

The inventory is the one that pays back on every future event.

GuardsArm supports healthcare organisations through zero-day response including exposure triage and compensating control design. Book a scoping call.