Tell them before the date, not after. Explain what is blocking the fix, offer a new date you believe in, list any interim mitigation, and invite them to disagree. Early honesty keeps most researchers willing to wait, while silence is the usual reason they go public.
What researchers actually want
CISA's directive cites a National Telecommunications and Information Administration survey of vendors and researchers. Over nine in ten researchers wanted some deadline for remediation, but only 18 percent of those who expected a timeline thought vendors should keep to it regardless of the circumstances of a bug. The directive's conclusion is that communicating how you decide on priority matters more than holding a fixed date, because it lets the researcher calibrate expectations.
OWASP says the same thing from the other side: throughout the process, give regular updates on status and expected timeline, even if there is no firm date, so that the researcher knows the vulnerability was not forgotten.
When to send the message
Send it as soon as you know. Common triggers are a test failure, a dependency that needs an upstream release, a change that touches many components, or a coordination dependency with another vendor. CISA notes that complex situations, including multi-party coordination, may need extra time.
A message that works
Include these parts, in this order:
- The old date and the fact that you will miss it.
- The reason, in plain terms.
- What is done so far.
- The new date, and how confident you are.
- Any interim mitigation customers can apply.
- A question: does this change your plans?
- The date of your next update.
Example wording
"We committed to a fix by 14 days from your report. We will not make that date because the fix touches the session layer, and our first approach failed testing. The new approach is built and in review. We now expect to release by a date, and we will update you on a date even if nothing changes. Meanwhile, customers can reduce exposure by turning off the affected feature. Does this timing work for you?"
What not to do
| Mistake | Why it hurts |
|---|---|
| Going silent | Researchers read silence as indifference |
| Blaming the researcher for the delay | Burns trust |
| Pushing the date again without a reason | Looks like stalling |
| Asking for an open ended extension | Leaves no shared plan |
| Hiding the interim mitigation | Leaves customers exposed |
Offer mitigation
If users can reduce risk before the fix, say so in the researcher message and plan it for the advisory. Disabling a feature, restricting access, adding a rule at the edge or changing a setting can all be useful. Keep wording factual.
What if they publish anyway
Plan for it. See what to do when a researcher goes public before your fix. Having a draft advisory ready lets you respond within hours.
Related
Our guide on response times you can keep helps you set dates you can honor. For fixes in third party packages, Safeguard's autonomous remediation can open fix pull requests (off by default, every category on manual), which may shorten waits that depend on dependency upgrades. There is also a free scan.
Quick check
How much extra time is reasonable?
There is no fixed number. Give a date you can defend and explain the reason. Researchers judge honesty more than length.
Can we ask the researcher to keep quiet?
You can ask and give reasons, but they may decline. Mitigation guidance helps your customers either way.
Sources
- CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy
- OWASP Vulnerability Disclosure Cheat Sheet
Last reviewed: 19 October 2026.
