Opinion / Commentary

The 90-Day Patch Clock Is a Threat Actor Countdown Timer — We Should Use It That Way

Pwn2Own's 90-day coordinated disclosure window is designed to give vendors time to patch. But for enterprise defenders, it is also a confirmed, public notice that specific classes of zero-day vulnerability exist in named products. Most organisations wait for the patch to act. The ones that prepare during the 90-day window have a meaningful advantage.

CipherWatch Editorial · Security Intelligence Platform
4 min read

There is an interesting asymmetry at the heart of Pwn2Own’s 90-day disclosure process. When researchers demonstrate a zero-day at the competition, technical details go to the vendor under a confidentiality agreement. The vendor has 90 days to develop and release a patch before the technical writeup becomes public.

From the vendor’s perspective, this is a managed disclosure process. From the attacker’s perspective, this is public notice that a valuable zero-day exists in a named, widely deployed product — plus a confirmation that the competition’s disclosure will drive a detectable patch that can be reverse-engineered. The 90-day window is the working period before that reversal becomes easy.

Most enterprise defenders treat the 90-day window as a waiting period: patch is not available, therefore no action is possible. That is wrong. The 90-day period is actually the highest-signal window available for defensive pre-positioning — precisely because the existence and category of the vulnerability is known, even if the technical details are not.

What You Know During the 90-Day Window

After Pwn2Own Berlin 2026, enterprise defenders know the following with certainty:

VMware ESXi has a cross-tenant code execution vulnerability. You do not know whether it requires network access or local VM access, what the preconditions are, or which ESXi version is most affected. But you know that hypervisor isolation between tenants can be bypassed on current production ESXi. You can act on that.

Microsoft Exchange Server has a three-bug SYSTEM RCE chain. You do not know the specific request pattern, the triggering conditions, or whether it requires any prior access. But you know that an unauthenticated attacker with network access to Exchange can achieve SYSTEM. You can act on that.

Windows 11 has four independent LPE paths. You do not know the specific components. But you know that any attacker with user-level access to a Windows 11 system can reliably escalate to SYSTEM. You can act on that.

The actions that you can take before the patch arrives — network access restriction, attack surface reduction, pre-positioning patch deployment capacity, threat hunting for existing compromise — are all legitimate, useful, and deployable without knowing the specific CVE details.

The Patch Release Changes the Timeline

When a Pwn2Own patch is released, the attacker’s timeline accelerates sharply. Two things happen simultaneously:

First, the patch implicitly confirms which component was vulnerable. Security researchers with the patch in hand and the competition description as context can reconstruct the vulnerability class and, in many cases, produce a proof-of-concept within 72 hours. This is not hypothetical — the ProxyLogon vulnerability was fully reconstructed within days of the patch, despite Microsoft declining to publish technical details. The patch binary contains the answer.

Second, the 90-day hold lifts (or approaches lift). When the ZDI writeup is published, the details go public and weaponisation accelerates further.

For Exchange, this history is not theoretical. DEVCORE’s ProxyLogon was reconstructed from the patch binary within 72 hours. Nation-state actors had weaponised it and were conducting operations within a week. DEVCORE is the same team, Exchange is the same target, and the same category of attackers are watching.

The Correct Response Posture

Enterprise security teams should have a standing policy: when a Pwn2Own competition produces results for products in the environment, the 90-day window is a confirmed, documented pre-patch window that requires active defensive response.

That response does not need to be dramatic. It needs to be deliberate:

Review the network access perimeter around the affected product. Reduce it where it is broader than necessary. Review monitoring coverage for the vulnerability class that was described (authentication bypass means monitoring pre-auth endpoints; LPE means monitoring privilege transition events). Pre-stage the patch deployment pathway so that the process starts within hours of release. Run a targeted threat hunt for exploitation indicators now, before the patch creates the false sense that past exposure has been closed.

The patch is the fix. The 90 days is the preparation time. Most organisations wait for the patch to start preparing. The ones that use the 90 days correctly are ready when the patch arrives, and can deploy within the critical 24-hour window before weaponised exploits appear.

Pwn2Own gives the industry a public, time-stamped calendar of upcoming critical patches. Using that calendar is not advanced security work. It is basic operational security planning with unusually good advance notice.

Share this article