Understanding Coordinated Disclosure Timelines

Coordinated disclosure requires balancing two competing interests: giving organizations time to fix vulnerabilities while not leaving users exposed longer than necessary. The timeline you choose affects both security outcomes and researcher relationships.

Standard Disclosure Timelines

Most organizations use 90-day disclosure timelines. This isn't arbitrary. It comes from Google Project Zero, which established 90 days as a reasonable compromise in 2015. Before that, timelines varied wildly, from immediate disclosure to indefinite delays that left users vulnerable for years.

The 90-day standard works for most vulnerabilities. It's enough time to develop, test, and deploy a fix for typical issues. It's short enough that users don't remain vulnerable for extended periods. Organizations that initially resisted this timeline have mostly adapted their processes to work within it.

Some organizations use different timelines. Microsoft traditionally uses 120 days. Many bug bounty platforms default to 90 days but allow extensions. Critical infrastructure organizations sometimes negotiate 180 days. Some independent researchers prefer 45 days, arguing that organizations with mature security programs should move faster.

When Timelines Start

The disclosure timeline starts when the organization acknowledges receipt of the vulnerability report. Not when the researcher sends it, not when it enters a queue, but when someone from the organization confirms they received and understood the report.

This distinction matters. If I report a vulnerability on Monday and don't hear back for two weeks, those two weeks shouldn't count against the 90-day timeline. The organization had the information but didn't act on it. Clear acknowledgment prevents disputes later.

A proper acknowledgment says something like "We received your report and will investigate." An auto-reply doesn't count. The researcher needs confirmation that a human reviewed their submission and accepted it as valid.

Timeline Extensions

Extensions happen, and that's fine when justified. Sometimes a vulnerability is more complex than it appeared. Sometimes the fix requires architectural changes that need more time. Sometimes the affected code is in legacy systems that are hard to modify safely.

Reasonable extension requests include specific justifications and new timelines. "We need another 30 days to test the fix in our staging environment" is reasonable. "We're busy with other priorities" isn't. Indefinite delays with no specific timeline aren't acceptable. Extensions without status updates make researchers question whether you're actually working on the issue.

When requesting an extension, explain why and provide a specific new date. Most researchers will grant reasonable extensions if you're communicating honestly about the situation.

Immediate Disclosure

Some vulnerabilities require immediate public disclosure, bypassing the usual timeline. Active exploitation changes everything. If a vulnerability is being exploited in the wild, the usual timeline doesn't apply. Users need to know immediately so they can take protective measures, even if a patch isn't ready.

Vendor unresponsiveness is different from a vendor requesting more time. If you've made multiple attempts to contact a vendor over several weeks and received no response, that's not coordinated disclosure anymore. You've made good faith efforts, and the vendor has chosen not to engage.

Critical infrastructure vulnerabilities that pose immediate danger may require fast action. Vulnerabilities in healthcare systems, utilities, or transportation infrastructure sometimes can't wait 90 days. The potential for harm outweighs the usual coordination process.

Partial Disclosure

Some disclosure models release limited information before the full timeline expires. Security teams might publish indicators of compromise or detection methods without revealing the underlying vulnerability. This helps defenders detect attacks without giving attackers a roadmap.

Vendors sometimes announce that a vulnerability exists and that a fix is coming, without providing exploit details. This alerts users to prioritize updates while not revealing how to exploit the issue. Coordinating this announcement with the researcher prevents confusion.

Timeline Violations

When someone violates the agreed timeline, options are limited. If a researcher publishes early, the vendor can fix and release immediately if possible, or explain to users that a fix is coming. Public criticism of the researcher usually backfires and discourages future reports.

If a vendor misses the deadline, the researcher can publish according to the original timeline. Some researchers give a grace period of 7-14 days, but this isn't required. The original agreement set the deadline, and vendors who can't meet it should have requested an extension earlier.

Sometimes a third party independently discovers and publishes the same vulnerability before the timeline expires. This happens. The original timeline becomes irrelevant once the information is public. Both parties should acknowledge what happened and move forward.

Cultural Differences

Disclosure timeline expectations vary by region and industry. Asia-Pacific organizations often favor longer timelines of 120-180 days and less public disclosure. European organizations are heavily influenced by GDPR requirements, with formal breach notification timelines. The United States has a mix of approaches, with government sectors often using longer timelines than private industry.

Open source projects present a unique case. Many prefer public issue trackers from the start, making "disclosure" less relevant. The entire development process happens in public, including security fixes. Private disclosure to maintainers happens for serious issues, but the expectation is that fixes will be developed publicly.

Setting Your Timeline

If you're establishing a vulnerability disclosure program, consider your actual capability to fix issues. How quickly can you develop, test, and deploy fixes? If your release cycle is monthly, 90 days makes sense. If you can hotfix within days, a shorter timeline might work.

Account for coordination requirements. Do fixes require coordination with hardware manufacturers, OS vendors, or downstream users? Add time for that. Security fixes need testing because rushing a patch that breaks production is worse than taking extra time to get it right.

Consider your communication capacity. Can your team maintain regular communication with researchers throughout the timeline? Longer timelines require more status updates. Researchers want to know you're working on their report, not ignoring it.

Timeline Communication

Regular status updates prevent misunderstandings. Acknowledge receipt immediately. Provide an initial assessment within a week covering severity and scope. Give a progress update around day 30. Share fix status and timeline around day 60. At day 90, either release the fix or request an extension with specific justification.

You don't need to reveal technical details in these updates. "We've identified the root cause and are developing a fix" is sufficient. Researchers want to know you're working on it, not the implementation details of your fix.

Exceptions Don't Make Rules

Every disclosure has unique circumstances. The 90-day standard works for most cases, but rigid adherence when circumstances warrant flexibility doesn't serve security. What matters is good-faith collaboration between researcher and organization, with both parties prioritizing user security over their own convenience.

The goal isn't perfect adherence to a timeline. The goal is getting vulnerabilities fixed before they're exploited while treating researchers respectfully. Sometimes that takes 45 days, sometimes 120 days. The timeline is a tool to ensure progress happens, not an end in itself.