On disclosure timelines: when ninety days is too long, when it is too short

The ninety-day disclosure window has become a load-bearing convention in the security industry. It is also, on examination, an arbitrary one. Project Zero formalised it in 2014 because the alternative was infinite patience with vendor inaction. It worked. The window pressured vendors into shipping fixes for serious flaws that they had previously been content to leave open. Two decades later it is still the default for most coordinated disclosure programs.

We work mostly in financial-sector vulnerability research. The defaults that suit a browser vendor’s release cadence do not always suit ours. Some thoughts on when ninety days is the right window, when it is not, and how to argue about that with vendors and reporters.

When ninety days is correct

The window is correct when the cost of a fix is bounded by the vendor’s release cadence and not by their customers’ deployment cycles. Browsers, operating-system kernels, runtimes, and most cloud infrastructure software fall into this category. The vendor cuts a release; users update; the patch is in production within a week or two. Ninety days is generous; the vendor that needs more is a vendor that is choosing not to prioritise the fix.

For these classes of software, public disclosure at ninety days plus exploit development is not just acceptable, it is a positive forcing function. A vendor that knows the window is hard learns to staff and budget for it.

When ninety days is too long

Some vulnerabilities should not wait ninety days. Pre-authentication remote code execution in widely-deployed network infrastructure — the Fortinets and Ivantis of the world — does not deserve a stately coordination period. Active exploitation in the wild does not deserve a coordination period at all; it deserves a public alert, immediately, naming the affected products and offering whatever mitigations are available.

We have argued more than once that the appropriate window for a mass-exploited bug is “before the next sunrise on the time zone where the most affected customers are operating.” Vendors find this uncomfortable. The discomfort is the point. It signals to all parties that a coordination process designed for orderly patching is not in operation; an emergency response is.

When ninety days is too short

This is the case that gets less discussion in the industry, and that matters most in our work.

Some financial-system software — core banking platforms, settlement infrastructure, central-bank payment rails, regulated trading systems — cannot ship a patch in ninety days. Not because the vendor lacks intent. Because the certification regime they operate under requires multi-month testing before a binary changes on a regulated host. Pushing the vendor on that timeline does not produce a faster patch; it produces a chaotic-quality patch, or it produces a public disclosure of a bug whose fix the customer cannot legally deploy. Both outcomes harm the end-user.

When the customer is a regulator, ninety days is not a deadline; it is a guarantee of public exposure during a period when the system is structurally unable to defend itself.

In these cases the responsible window is longer, and it is calibrated to the certification cycle. We have shipped advisories with embargo periods of nine months and twelve months when the affected institution operates in a jurisdiction where regulatory acceptance of an emergency change would itself take that long. We have also walked away from disclosures where the vendor refused to engage at any timescale; in those cases the shorter window is correct because the alternative is indefinite unaddressed exposure.

The rule we operate to: the disclosure window should be the shorter of (a) the time the vendor needs to patch in good faith, plus a small margin, and (b) the time during which the bug remains plausibly unknown to capable threat actors. When the second clock runs faster than the first, the disclosure ships, certification cycle or not.

The reporter’s responsibility

Reporters tend to think of the timeline as a battle of wills with the vendor. It is not. The reporter’s responsibility is to the prospective victim, not to the vendor and not to themselves. The questions worth asking, repeatedly:

1. Who is harmed by an early disclosure? If the answer is “every customer of an unpatched product,” the window should be longer.
2. Who is harmed by a late disclosure? If the answer includes “active exploitation of a population that has no idea they are exposed,” the window should be shorter.
3. What is the vendor’s actual constraint? Engineering time, QA time, certification time, fear of disclosure itself? The first two are negotiable; the third is sometimes; the fourth is not.
4. What does coordinated mean? If the vendor will not coordinate, the disclosure is not coordinated. Calling it coordinated when only one party participated misrepresents the work.

A disclosure timeline is a calibration problem with no single answer. The right answer is the one that minimises total harm to the population of users, not the one that wins the negotiation with the vendor. Most of the time those align. Occasionally they do not, and when they do not the reporter’s loyalty has to be settled in advance.

A practical note

We publish our coordinated-disclosure policy at https://internationalmoneyflow.com/legal/disclosure. The default window is ninety days. The negotiable bounds are: thirty days for an exposure with active exploitation, three hundred sixty days for a regulated payment-rail system with a documented certification cycle. Outside that range we walk away from the negotiation rather than agree to terms we will later regret.

If you are a vendor we are about to coordinate with, please read the policy before the first call. It saves us both a meeting.