A zero-day vulnerability is one that the vendor doesn't know about yet, or has known about for fewer hours than it takes to ship a fix. When one surfaces in software your organisation runs, the clock starts immediately. There's no patch queued, no ACSC advisory with a remediation checklist, and no community knowledge base full of workarounds. What your team does in the first hours determines whether the incident stays contained or becomes a notifiable data breach.
What makes zero-days different from ordinary CVEs
Most vulnerabilities follow a predictable arc. A researcher finds a flaw, reports it through a coordinated disclosure process, and the vendor ships a patch before anything goes public. Your patch management program picks it up, you apply it within your agreed SLA, done. Zero-days break that arc entirely. Exploitation often precedes disclosure. By the time a CVE number gets assigned and vendors confirm the issue, attackers may have been active for weeks or months.
The 2023 MOVEit Transfer exploitation by Cl0p is the sharpest recent example. The group had developed the exploit before any public knowledge of the flaw existed. Australian organisations using MOVEit had no vendor guidance to act on when attacks began. Some didn't realise they were affected until customers or regulators told them. That pattern, exploitation before awareness, is definitionally what a zero-day produces.
It's worth understanding why most Australian organisations already fall behind on standard patch management. Zero-days land on top of that backlog, which makes the gap worse.
The immediate steps when a zero-day surfaces
Speed matters more than perfection in the first few hours. Your first job is situational awareness, not remediation. Answer three questions fast:
- Do we run the affected software or hardware, anywhere in our environment?
- Is the vulnerable component exposed to untrusted networks, including the internet?
- Is there any evidence of exploitation already in our logs?
Getting accurate answers to those three questions requires solid asset inventory. If your CMDB is stale or incomplete, you'll lose hours just trying to establish scope. This is one of the concrete reasons the ASD's Essential Eight maturity model makes asset management a baseline expectation, not a nice-to-have.
Once you know your exposure surface, move to isolation and containment. Block network access to the vulnerable component if it can be done without taking down critical services entirely. Temporarily restricting external access to an internal file-transfer service is disruptive. Leaving a known-vulnerable endpoint facing the internet during active exploitation is catastrophic. Choose the disruption.
Working without a patch: vendor mitigations and workarounds
Vendors typically publish a security advisory within hours of going public, even when a patch isn't ready. That advisory usually includes one or more mitigations: disabling a specific feature, blocking a network port, adjusting a configuration value, or deploying a vendor-supplied rule for WAFs and IDS systems. These are not permanent fixes. They reduce the attack surface while a patch is built and tested.
Apply those mitigations immediately, even if they break some functionality. Document what you changed and when, so the changes can be reversed cleanly once the patch arrives. Don't wait for internal change management approval cycles that were designed for scheduled maintenance windows. Most organisations need a lightweight emergency change process that can move in under two hours for critical security events.
If the vendor hasn't published a mitigation yet, look at network-level controls. Segment the affected systems away from sensitive data stores and identity infrastructure. Even rough network segmentation reduces the blast radius significantly. Network segmentation is one of the most effective controls for limiting damage after a breach, and zero-days are exactly the scenario where it earns its keep.
Threat hunting during the uncertainty window
While mitigations are being applied, your security operations team should begin threat hunting. The question isn't whether you've been attacked yet. The question is whether you were attacked before you knew the vulnerability existed.
Focus the hunt on indicators of compromise published by threat intelligence vendors and the ACSC. Common patterns to look for include unexpected outbound connections from the affected system, new scheduled tasks or services created in the hours or days before the advisory was published, and lateral movement from the system toward identity stores or backup infrastructure.
Log retention matters here. If your SIEM only keeps 30 days of logs and the zero-day has been exploited in the wild for 60 days, you have a visibility gap. Many Australian organisations discovered this problem during the MOVEit and ESXiArgs incidents. Thirty days is not enough for zero-day post-mortems. Ninety days is the practical minimum for most threat hunting workflows.
What to tell leadership and when
IT teams often delay internal escalation while they gather more information. That instinct is understandable but risky. Leadership needs to know three things early: what system is affected, what the business impact of isolation or shutdown would be, and whether there's any indication of actual compromise.
If compromise is suspected, the Privacy Act's Notifiable Data Breaches scheme sets a 30-day notification window from the point of awareness. That clock starts when your organisation first becomes aware that a breach has likely occurred, not when it's confirmed. Legal counsel needs to be in the loop early so that the assessment process starts at the right time.
Brief leadership in plain language. The vulnerability has no patch yet. We've applied mitigations. We're hunting for signs of exploitation. We'll have a clearer picture in X hours. That's enough for an initial briefing. Resist the temptation to over-detail the technical specifics until you understand the situation more clearly.
After the patch arrives
Patching after a zero-day isn't just a technical task. It's also a documentation task. Record the timeline of detection, mitigation, hunting, and patching. Capture what worked and what slowed you down. The bottlenecks you hit during a zero-day response, stale asset inventories, unclear change approval paths, missing log data, are almost always the same ones that will slow you down next time.
Run a formal post-incident review within two weeks. Not to assign blame, but to make concrete improvements before the next event. Zero-days aren't rare events reserved for nation-state targets. Ransomware operators regularly weaponise zero-days against mid-market Australian businesses. Treat each one as a rehearsal.