Google Project Zero has scrapped its long-standing “90 + 30” disclosure rule and will now release technical details on a fixed timetable after reporting a flaw, patched or not. The window starts at 90 days and falls to 30 by January 2028, which puts real pressure on the major suppliers UK organisations depend on.
What happened
On 13 November 2026, Google’s Project Zero research team published a revised vulnerability disclosure policy, written by researcher Natalie Silvanovich. The team calls it “Full X”: a flaw is made public X days after Project Zero reports it to the affected vendor, with no further negotiation over whether a fix has landed.
The change takes effect in three steps. From 13 November the policy is Full 90. On 2 February 2027 it becomes Full 60. On 3 January 2028 it tightens to Full 30. Under the previous arrangement, in force since 2021, vendors had up to 90 days to fix a reported bug, after which Project Zero waited a further 30 days of so-called soak time to let patches reach users before releasing technical details. That meant up to 120 days of secrecy; by 2028 the ceiling is a quarter of that.
Project Zero is also removing most of the special cases that had built up around the old rule, including the grace period and the variant policy. Three exceptions remain: bugs already being exploited in the wild, which follow Google’s separate application security disclosure policy; flaws whose details someone else has already made public; and cases where the vendor itself asks for publication. Rare hardware exceptions, as with Spectre and Meltdown, remain possible.
The detail
The reasoning in the post rests almost entirely on large language models. Project Zero argues that AI tooling has made it faster for attackers to find and weaponise flaws, and more likely that several parties, some of them hostile, will stumble on the same bug independently.
The second argument concerns patches. Reverse engineering a fix to work out the underlying flaw used to take skill and time. The team now treats zero patch-to-exploitation time as “a reasonable, though imperfect, model” of how attackers behave. If that holds, soak time offers little real protection and may give vendors and customers a misleading sense that details are still secret. Project Zero instead wants vendors to shrink the patch gap, meaning the interval between a fix being released and users actually installing it, or to use other protective measures while remediation is under way.
Then there is volume. In some targets, Project Zero says, a yearly handful of bugs has become several each week. Arguing with each vendor about whether a bug counts as fixed, or whether a grace period applies, no longer scales. A flat, date-driven rule can be automated on both sides.
Severity plays no part in the timing. Project Zero says it only files bugs with substantial, demonstrated impact, but argues that how serious a flaw is has no bearing on how likely an attacker is to find it. The team will still record whether each bug is fixed and say so publicly, but that status will no longer decide when details are released.
Why phase it in? The post says the vendors Project Zero reports to most often warned that an overnight switch could hand attackers unfixed bugs while their processes caught up. They also raised two subtler risks: that hard deadlines might push teams to fix Project Zero reports ahead of more serious internal findings, and that a target some suppliers simply cannot hit might lead them to stop trying.
Why it matters for UK organisations
Much of Project Zero’s work targets large vendors: operating system, browser, mobile and cloud platform suppliers whose products run across almost every UK business and public body. When its clock shortens, theirs does too, and so does the time between a fix appearing and full technical details being published.
For UK organisations, the practical effect is that the comfortable lag between patch release and public technical write-up is going away. Cyber Essentials already requires critical and high-risk updates to be applied within 14 days of release, and the NCSC’s vulnerability management guidance pushes organisations to automate updates wherever they can. Once soak time disappears, a vendor patch is effectively a public announcement, and the window between “fix available” and “exploit in circulation” narrows sharply.
It also sharpens supplier assurance. With the Cyber Security and Resilience Bill set to raise expectations on managed service providers and critical suppliers, asking how fast a supplier can remediate, and how it protects customers when it cannot, now matters more.
Expert view
I have spent a long career watching coordinated disclosure deadlines become the norm, and this is the most significant shift in that norm for years. The 90-day convention that Project Zero popularised became the de facto benchmark across the industry, built into many bug bounty programmes and vendor vulnerability disclosure policies. When the team that set the standard moves, others tend to follow, and I expect other research groups and bounty platforms to revisit theirs.
In my experience, when we test client estates the gap that hurts most is rarely the zero-day; it is the known, patched flaw that never got deployed. Project Zero is essentially saying out loud what attackers already know: once the patch exists, the secret is out.
There are fair concerns. Smaller vendors and hardware makers will struggle with 30 days, and some may respond with rushed or partial fixes. Project Zero’s own post acknowledges the risk that suppliers give up on deadlines they cannot meet. The policy also assumes high-quality, reproducible reports, and Project Zero accepts vendors may treat weaker submissions differently, a relevant caveat while bounty programmes wrestle with floods of automated reports.
What to do now
- Treat vendor patches as public disclosure. Assume exploit details may follow a fix within days, not weeks. Prioritise internet-facing systems.
- Meet the Cyber Essentials 14-day rule as a ceiling, not a target. Aim for critical browser, operating system and edge device updates within days, with automatic updates enabled wherever practical (the security update management control).
- Plan for non-patch mitigations. Know how you would disable a vulnerable feature, restrict access or apply a virtual patch when a fix is late or cannot be deployed quickly.
- Ask suppliers about remediation speed. Add questions on fix timelines, out-of-band patching and interim mitigations to supplier due diligence and contract reviews.
- Review your own disclosure policy. If you run a VDP or bug bounty, check whether your stated timelines still look credible against a 60 and then 30-day industry benchmark, and make sure triage can keep pace.
- Measure your patch gap. Track the time from vendor release to full deployment across your estate; it is the metric this policy change makes most visible.
Bottom line
Project Zero has decided that time-limited secrecy, not patch availability, is the only promise it can make to vendors, and that promise shrinks to 30 days by 2028. For UK organisations, the takeaway is simple: the period during which a published patch is quietly safe to delay is effectively over, and patching speed is now the defence that counts.
