"Zero-day exploited in the wild" makes for a dramatic headline and suggests there is nothing anyone could have done. For most companies, though, the more common story is different: the vendor released a fix weeks or months ago, and the company's own systems were never updated. The gap between a patch being published and a patch being applied is where n-day vulnerabilities do their damage.

This article explains the difference between zero-days and n-days, how attackers turn a fresh patch into a working exploit, why VPNs, firewalls and other edge devices are such popular targets, and what defenders can do before the vendor has a fix. It is written for IT staff and managers responsible for internet-facing systems and network equipment.

Definitions: zero-day and n-day

NIST defines a zero-day attack as "an attack that exploits a previously unknown hardware, firmware, or software vulnerability"[1]. Mandiant, part of Google, uses a more precise split when it measures exploitation timelines: a zero-day is a vulnerability exploited before a patch is made available (excluding end-of-life products), and an n-day is a vulnerability first exploited after a patch is available[2]. You will also hear "1-day" for flaws exploited very shortly after the patch is released; these are still n-days.

These terms describe when exploitation happens relative to the patch, not how severe the flaw is. The same vulnerability is a zero-day if it is exploited before the fix ships, and becomes an n-day for every organization that has not yet installed the fix.

The clock starts when the patch ships

A patch is itself a clue. By comparing the code before and after the update, a technique known as patch diffing, attackers can find exactly what was changed, work back to the underlying flaw and build an exploit. NIST's patch management guidance notes that once a vulnerability becomes publicly known, risk usually increases because attackers are more likely to develop exploits that target it[3].

How short is that window? Mandiant's analysis of vulnerabilities exploited in 2023 found an average time-to-exploit of just five days (after excluding outliers). Among n-days, 12% were exploited within one day of the patch, 29% within a week, and more than half (56%) within a month[2]. Mandiant's M-Trends 2026 report, published in March 2026, estimates that the mean time to exploit has fallen to minus seven days, meaning exploitation routinely starts before a patch is even released. Exploits were also the most common initial infection vector for the sixth consecutive year, accounting for 32% of intrusions[4].

If zero-days are increasing, why do patched flaws matter most?

The data does show zero-days becoming more prominent. Of the vulnerabilities Mandiant saw exploited in 2023, the ratio of zero-days to n-days was 70 to 30[2]. CISA and its international partners likewise found that the majority of the most frequently exploited vulnerabilities in 2023 were initially exploited as zero-days[5].

The same CISA report, however, notes that attackers have the most success exploiting vulnerabilities within two years after public disclosure[5]. A flaw may start life as a zero-day, but as long as large numbers of systems stay unpatched after the fix is released, it keeps being exploited for a long time. As of the November 6, 2026 version, CISA's Known Exploited Vulnerabilities (KEV) catalog lists 1,769 vulnerabilities with confirmed exploitation, and every entry comes with a clear required action, such as applying the vendor's update or mitigations[6]. For a typical company, the most common risk is not the unstoppable zero-day but the vulnerability that already has a fix nobody applied.

Why attackers go after edge devices

Google Threat Intelligence Group (GTIG) tracked 90 zero-day vulnerabilities exploited in the wild in 2025. Of these, 43 (48%) targeted enterprise software and appliances, a new high, and about half of those (21) were in security and networking products. Across the year, 14 zero-days were identified as affecting edge devices, a figure GTIG says likely underrepresents the true scale because detection on these devices is limited[7].

GTIG's reasons are straightforward[7]:

  • Edge devices sit at the perimeter of the network and remain high-value targets.
  • Most routers, switches and security appliances cannot run EDR (endpoint detection and response), which creates a blind spot for defenders and makes it hard to gather host-level evidence after a compromise.
  • These devices hold high privileges and reach across systems and networks, so control over one gives an attacker a path inward.

Patching cadence adds to the problem. NIST points out that routine patching is often postponed because installing updates can interrupt operations, for example by requiring reboots, and that each delay gives attackers additional windows of opportunity[3]. Firewalls and VPNs, where a restart affects the whole company's connectivity, fall into this trap easily.

End-of-support (EOS) devices are worse still: the vendor no longer ships updates, so every newly discovered flaw stays unpatched forever. In February 2026 CISA issued Binding Operational Directive BOD 26-02, citing widespread exploitation campaigns by advanced threat actors targeting EOS edge devices. It requires US federal civilian agencies to inventory such devices within 3 months, remove all EOS edge devices within 18 months, and establish continuous discovery of edge devices within 24 months[8]. The directive only binds US federal agencies, but the same inventory-and-replace approach applies to companies in Taiwan. For more hardening steps, see the hardening checklist for VPNs, firewalls and other edge devices.

What defenders can do when there is no patch

When a zero-day is announced, the vendor often has mitigation advice before it has a fix. NIST's guidance calls this scenario emergency mitigation: reduce risk with temporary measures until a patch is available, such as disabling the vulnerable feature or using firewalls and network segmentation to shrink the attack surface; assets that cannot be patched should be handled long-term through isolation and similar methods[3]. Many KEV entries carry the same logic in their required action: apply mitigations per vendor instructions, or discontinue use of the product if mitigations are unavailable[6].

Reduce exposure first

  • Check whether the affected interface (an SSL VPN portal, a device management page) really needs to be reachable from the internet. Management interfaces should only accept connections from an internal management network or specific source IPs.
  • Apply the vendor's interim mitigations: disable the affected feature or service, change settings, update IPS or WAF rules.
  • If no mitigation is possible and the risk is high, consider shutting the service down temporarily or switching to an alternative, and record the decision, the owner and a review date.

Assume you may already be compromised

Patching closes the hole; it does not evict an attacker who is already inside. For the most urgent tier of vulnerabilities, CISA's BOD 26-04 requires remediation or mitigation within three days plus a forensic triage of the affected asset to check for compromise[9]. In practice:

  • Forward edge device logs (logins, configuration changes, admin account changes) in real time to a central platform outside the device, so an attacker cannot simply erase them.
  • When the vendor or an advisory publishes indicators of compromise (IOCs), search your logs for them right away. See How to check your environment against advisory IOCs.
  • Run any integrity-check tool the vendor provides and look for unknown accounts, scheduled tasks or configuration changes.
  • If you find signs of intrusion, follow The first 24 hours of a suspected breach.

Patch as soon as the fix lands

Prepare an emergency patching process in advance: who can approve downtime, how maintenance windows are agreed, and how to roll back if an update fails. NIST also warns that postponing routine patches makes emergency patching harder and more time-consuming, because earlier updates that the new patch depends on must be installed first[3]. Keep watching vendor bulletins and our security advisories so you can move the moment a patch is released.

Action checklist

  • List every device and service exposed to the internet (VPN, firewall, email gateway, file transfer, remote management) with model, firmware version and vendor end-of-support date.
  • Identify edge devices that are out of support and schedule their replacement; until then, restrict their management interfaces to internal access only.
  • Set up emergency patching and emergency mitigation procedures for edge devices in advance, including approvers, acceptable downtime windows and a rollback plan.
  • Send edge device logs to a central platform, covering at least logins, configuration changes and admin account changes.
  • Compare new KEV entries and vendor security bulletins with your inventory every day; when a zero-day is announced, confirm the same day whether you are affected and apply mitigations.
  • After patching a KEV or zero-day vulnerability, also check for compromise. Do not stop at confirming the version number.
  • Use the tiering approach in patch management to put n-day fixes on fixed deadlines, and browse recent cases under vulnerability advisories.