Project Zero drops patch grace time and moves to 30-day disclosure

Project Zero drops patch grace time and moves to 30-day disclosure

13 November 2026: Google's Project Zero, whose researchers report flaws to Microsoft, Apple, browser makers and many other vendors, has replaced its "90 + 30" disclosure policy with a fixed "Full 90": a bug's details go public 90 days after the vendor is told, whether or not users have installed the fix. The window shortens to 60 days on 2 February 2027 and to 30 days on 3 January 2028.

Not yet independently verified. The policy and its reasons come from Project Zero's own post; we have not seen how vendors that receive its reports have responded. We will update this when it can be confirmed, and remove this note.

From 90 + 30 to Full X

Under the policy Project Zero had run since 2021, a vendor had 90 days to fix a bug, and the team then waited up to 30 more days of "soak time" so users could install the patch before technical details came out. The new policy, published by researcher Natalie Silvanovich on 13 November, counts only one thing: days since the report.

The stages are:

• Full 90, from 13 November 2026;
• Full 60, from 2 February 2027;
• Full 30, from 3 January 2028.

Most special cases go with the change, including the grace period a vendor could ask for when a fix was nearly ready and the separate rules for variants of a bug already reported. Whether a bug has been fixed is no longer a decision point either. Project Zero says it will still track fixes and say publicly when a bug remains unfixed.

The three exceptions left

Only three routes change the timing. A bug exploited in the wild is handled under Google's application security disclosure policy instead. A bug already made public by someone else may have its details published at Project Zero's discretion. And details come out early if the vendor asks. Hardware bugs are not a category of their own, although the team has made exceptions before, for Spectre and Meltdown, and says it may do so again. The severity of a flaw plays no part, because, the team argues, it does not change how easy the bug is to find.

Why the team says soak time stopped working

Project Zero gives three reasons. AI tools let attackers find and exploit bugs faster, and the same bug is increasingly found by more than one party. Attackers reverse engineer patches quickly once they ship, so "patch soak time is no longer meaningful". And the number of reports has grown to the point where the negotiated parts of the old policy were "quickly becoming unmanageable". The gradual steps down to 30 days came from vendors, who warned that cutting at once would leave unfixed bugs exposed while they reworked their processes.

The post puts the burden on what it calls the patch gap, the time between a fix being released and a user installing it, and says vendors should shrink it "either by reducing patch rollout time or using other strategies to protect users while remediation is in progress".

What changes for teams that patch

For an IT team, the practical effect is that a Project Zero write-up, often detailed enough to build an exploit from, may now land while a fix is still working through a monthly or quarterly patch cycle. Under Full 30 from January 2028, a bug reported to a vendor in the first week of a month can be public before that month's update has reached many fleets. Teams that hold vendor patches for weeks of testing will want to know which of their suppliers receive Project Zero reports and how fast those suppliers ship. Our vulnerability management category lists 17 products and patch management seven.

Sources

• Google Project Zero: Policy and Disclosure, 2026 Edition (Natalie Silvanovich), 13 November 2026