What is a zero-day attack and how do you prepare for one?

A zero-day attack exploits a previously unknown hardware, firmware or software vulnerability, so no fix exists when it begins. You cannot patch what has no patch. You can reduce what an attacker reaches, detect odd behaviour, and move fast once a fix or workaround is published.

What does zero-day mean?

NIST's glossary, quoting CNSSI 4009 and NISTIR 8011, defines a zero-day attack as an attack that exploits a previously unknown hardware, firmware or software vulnerability. The name refers to the defender having had zero days to prepare: the flaw was unknown to the vendor, or at least unfixed, when it was first used.

Two terms get mixed up. A zero-day vulnerability is the flaw. A zero-day attack or exploit is its use. Once the vendor publishes a patch, the same flaw becomes a known vulnerability, and attacks that follow are attacks on unpatched systems, which are far more common.

How is it different from a known vulnerability?

A known vulnerability has an identifier, usually a CVE, and a description. You can scan for it and track it. A zero-day has none of that until someone discloses it. Your scanner reports clean while the flaw is being used.

The practical gap is the window between first exploitation and a deployed fix. It includes the time to discover the problem, for the vendor to build a patch and for you to apply it. Each part can take days, and the last part is the one you control.

How do you know which flaws are being exploited?

CISA's Known Exploited Vulnerabilities catalogue lists vulnerabilities with evidence of active exploitation. Many entries were zero-days when first used. The catalogue is a prioritisation tool: when a flaw appears there in software you run, treat it as urgent regardless of its severity score. US federal agencies face remediation deadlines for entries on the list, and the catalogue is open for anyone to use as a feed.

A constructed example

A company runs a file transfer server on the internet. On a Friday, the vendor announces a flaw being exploited with no patch yet and offers a configuration workaround: disable one feature.

Company A has an inventory, so within an hour it knows it runs the product, which version and who owns it. It applies the workaround, restricts the server's inbound access to partner addresses and searches logs for the odd requests the advisory describes. Company B finds out on Monday from a customer. The vulnerability was identical. The inventory and the ownership made the difference.

What reduces the damage?

Think in layers, assuming one will fail.

Know what you run. An accurate list of software, versions and dependencies, including libraries inside applications, lets you answer exposure questions in minutes.

Shrink exposure. Fewer internet facing services, default deny network rules and network segmentation mean an exploited host reaches less.

Limit privilege. A service running with minimal rights does less harm when taken over.

Detect behaviour. Zero-days have no signature, but what an attacker does afterwards, such as new accounts, unexpected outbound connections or odd child processes, can still be seen.

Rehearse the response. Decide in advance who can order a service offline, who talks to customers and how you will apply a workaround quickly.

What about zero-days in your own code and dependencies?

For software teams, the equivalent is finding flaws before attackers do. Reachability analysis separates a vulnerable function that your code actually calls from one that merely sits in a dependency, which helps focus attention when a new advisory lands. Safeguard's zero-day discovery and reachability analysis are designed for this, and its policies and gates can block a risky dependency from shipping. They reduce the window; they do not remove the possibility of an unknown flaw.

How to check or apply this

1. Build and maintain an inventory of software, versions, owners and internet exposure.
2. Subscribe to vendor advisories and the CISA KEV catalogue for products you run.
3. Write a runbook for no-patch situations: workaround, isolate, monitor.
4. Remove or restrict internet exposure for services that do not need it.
5. Run services with least privilege and segment the network.
6. Log process, account and outbound network behaviour in a place attackers cannot alter.
7. Practise the drill once a year with a made up advisory.

Quick check

Sources

• NIST glossary, zero-day attack
• CISA, Known Exploited Vulnerabilities Catalog
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations

Last reviewed: 18 October 2026.