Project Zero will disclose vulnerabilities 90 days after reporting

Google Project Zero launched a redesigned vulnerability disclosure framework called Full X, replacing the policy that granted software makers ninety days for remediation alongside a thirty-day soak window. Under projectzero.google's report, the team immediately eliminated that thirty-day rollout extension to counter rapid automated exploitation. The shift addresses an environment where machine learning tools allow threat actors to identify defects and dissect patches almost instantaneously.

This analysis details the mechanics of the revised disclosure policy, the multi-year implementation timeline, and the removal of case-by-case extensions. It is designed for enterprise security teams, vulnerability researchers, software vendors, and infrastructure engineers who must adapt patch pipelines to tighter mandatory deadlines.

01Elimination of thirty day soak periods

Since 2021, Project Zero allowed software maintainers up to ninety days to develop a patch plus thirty additional days to distribute updates to users. Security researchers observed that large language models dramatically compressed the time attackers need to discover flaws or reverse engineer patches. In this accelerated landscape, granting a thirty-day soak period exposes users to heightened danger while offering false secrecy.

Defenders face a shrinking patch gap, the duration between the public release of a fix and user installation. Because threat actors now analyze code updates to derive exploits almost immediately, zero patch-to-exploitation latency has become a realistic model of adversary capabilities. Maintainers must shorten distribution intervals or implement runtime safeguards while remediation proceeds rather than relying on delayed disclosures.

Internal operations at Project Zero also prompted the change, as automated tooling accelerated bug discovery. The security team now flags several vulnerabilities every week within targets that previously yielded only a handful of flaws per year. That surging volume rendered subjective timeline negotiations and administrative grace period reviews unmanageable for researchers and vendors alike.

02Phased deadlines from ninety to thirty days

The new Full X framework anchors public disclosure to a rigid timeline measured from the initial vendor notification. Effective immediately, Project Zero operates under Full 90, which publishes vulnerability details exactly ninety days after submission regardless of patch readiness. This standard removes the former thirty-day post-fix buffer while preserving an initial adjustment period for engineering teams.

The schedule will accelerate over the next two years to enforce faster remediation cycles across the industry. On February 2, 2027, Project Zero will transition to Full 60, shortening the public disclosure window to sixty days. The policy reaches its final configuration on January 3, 2028, establishing Full 30 as the permanent standard that discloses reported flaws after thirty days.

Automating the policy remains a primary objective, allowing Project Zero and external engineering teams to manage tracking programmatically. By standardizing deadlines into deterministic date offsets, researchers and maintainers eliminate ambiguous status updates. The schedule establishes clear milestones so organizations can upgrade automated testing and build systems before tighter deadlines take effect.

03Three narrow disclosure exceptions and vendor requests

Alongside the new schedule, Project Zero eliminated most discretionary carve-outs, stripping away informal grace periods and custom variant policies. The revised policy retains only three specific exceptions to its fixed disclosure calendar. These narrow carve-outs address immediate user peril, preexisting public exposure, and direct requests from the affected maintainers.

Vulnerabilities actively exploited in the wild bypass the standard Full X counter entirely and follow Google's established application security disclosure framework. If external parties publicly expose vulnerability details before the deadline expires, Project Zero reserves the discretion to release its technical data early. Maintainers may also request an early public disclosure if their fixes complete ahead of schedule.

Hardware vulnerabilities represent an edge case where traditional software patching models do not cleanly apply. Project Zero encourages silicon vendors to plan for exposure through architectural mitigations and non-patch defense strategies. The team confirmed it will continue granting rare exceptions for complex architectural flaws, citing historical precedents such as Spectre and Meltdown.

04Industry feedback and bug prioritization risks

Project Zero solicited feedback from the vendors receiving the highest volume of its vulnerability reports before finalizing the policy. Maintainers cautioned that an abrupt reduction in remediation timelines would leave unpatched flaws exposed before organizations modernized development pipelines. An immediate collapse of disclosure windows could consequently inflict net harm on enterprise users during the transition.

Vendors also warned that overly aggressive deadlines could distort engineering priorities across security departments. Maintainers might rush resources toward low-impact bugs solely to beat public disclosure timers, leaving critical internally discovered vulnerabilities unaddressed. Furthermore, software teams facing impossible deadlines might abandon compliance altogether, conceding that timely remediation cannot be achieved.

Project Zero maintained that vulnerability severity cannot serve as a reliable basis for altering public disclosure dates. While Project Zero only files reports for flaws carrying substantial severity and verified impact, severity does not influence whether attackers discover a flaw. Attackers locate easy and obscure bugs alike, making standardized timelines necessary regardless of internal risk scoring.

05Decoupling fix verification from release dates

The revised policy officially separates the technical assessment of bug fixes from the disclosure timetable. In previous years, confirming whether a bug was genuinely resolved required extensive back-and-forth negotiations between Project Zero and affected engineering groups. That verification burden proved especially fraught for server-side infrastructure and proprietary code not distributed directly to end users.

The rise of alternative remediation techniques further complicates binary determinations of whether a vulnerability is fixed. Vendors increasingly deploy interim defenses, such as disabling vulnerable code execution paths or restricting network interfaces, rather than publishing traditional code patches. Project Zero recognized that arbitrating whether these temporary mitigations constituted complete fixes created unmanageable friction.

Project Zero will continue tracking remediation progress and communicating status with vendors, but fix validation will not influence publication dates. Instead, the team will document defensive measures publicly alongside technical write-ups so users understand their actual protection posture. This approach allows researchers to share defensive insights transparently without imposing subjective penalties on maintainers.