Safe Harbor or Lawsuit? The VDP Clause That Protects You

Safe harbor in a vulnerability disclosure policy is explicit language promising that your organization will not pursue legal action against security researchers who report vulnerabilities in good faith. It converts vague expectations about “responsible” behavior into a written contract: stay in scope, don’t exfiltrate data, don’t disrupt the service, report through the official channel, and you are authorized to test. Without it, decades-old anti-hacking laws leave even ethical reporters exposed, and the researcher who found your bug has every reason to stay silent or sell it.

In May 2026, Microsoft showed the entire industry what happens when that clause is missing or ignored. The story is a near-perfect case study in how an ambiguous policy plus a reflexive legal threat destroys researcher trust overnight. The good news for founders: the failure was organizational, not technical, which means a startup can avoid it from day one with the right policy and process.

What Microsoft just did (and quickly undid)

Microsoft threatened a security researcher with a criminal investigation, faced days of public backlash from the infosec community, and then publicly reversed itself. The whole arc played out in roughly a month.

Starting in early April 2026, a pseudonymous researcher known as “Nightmare-Eclipse” publicly dropped proof-of-concept exploit code for a string of Windows zero-days without coordinating with Microsoft first. The count was a moving target: roughly six bugs by late May (with names like BlueHammer, RedSun, UnDefend, and YellowKey, a critical BitLocker bypass tracked as CVE-2026-45585), growing past that as the feud dragged into June. Microsoft published a blog post calling uncoordinated disclosure “never justifiable.” Its Digital Crimes Unit said it would “continue bringing cases against these actors and those that enable their criminal activity, coordinating as needed with law enforcement around the world.”

The community read that as a criminal-prosecution threat aimed at a researcher. The backlash was immediate and brutal. Around June 1 to 2, 2026, Microsoft backtracked, stating it had “no intention to pursue action against individuals conducting or publishing their security research,” with the caveat that it would work with law enforcement when someone “breaks the law and engages in malicious activity causing real harm to our customers.”

One detail is more revealing than the reversal itself. During the crisis, Microsoft quietly swapped the phrase “responsible disclosure” for “Coordinated Vulnerability Disclosure” in its messaging. That word change, which we will come back to, was a tell.

Why this is the number one trust failure in disclosure

The damage here was not caused by a clever exploit. It was caused by ambiguity. When a policy does not say in writing that good-faith researchers are safe, every report becomes a gamble, and the vendor’s mood on any given day decides whether a helpful stranger is a partner or a defendant.

The contradiction made it worse. Kevin Beaumont, a security researcher and former Microsoft employee, called the episode “a dumpster fire of their own making,” pointing out that Microsoft had previously hired SandboxEscaper, a researcher who had published Windows zero-day proof-of-concept code, the exact behavior the company’s blog post now framed as criminal. Inconsistent enforcement is indistinguishable from no policy at all. If researchers cannot predict how you will react, they assume the worst.

Katie Moussouris, who architected Microsoft’s original bug bounty program and now runs Luta Security, warned of “a chilling effect of fewer people coming forward to report bugs, making it less safe for all of us.” That is the core lesson. A disclosure threat does not just punish one researcher. It teaches the next hundred to stay quiet.

What “safe harbor” actually means

Safe harbor is the clause that removes the gamble. It is a written promise, published in your policy, that researchers acting in good faith will not be sued or referred for prosecution.

To qualify for the protection, researchers must typically meet a short list of conditions:

1. Act in good faith with the intent to improve security, not to extort or cause harm.
2. Stay within the defined scope of assets you have authorized for testing.
3. Avoid privacy violations and data exfiltration, accessing only the minimum needed to prove a bug.
4. Avoid service disruption, with no denial-of-service or destructive testing.
5. Report through the official channel and allow reasonable time to fix before public disclosure.

This is not fringe legal theory. The disclose.io safe-harbor framework, an open-source standard, was adopted in 2020 by CISA, voting-machine manufacturers, and several US states, and it ships by default with Bugcrowd programs. HackerOne maintains a “Gold Standard Safe Harbor.” Dropbox, Mozilla, and GitHub-era programs all use versions of it. Safe harbor is now the mainstream baseline, which is exactly why its absence reads as a red flag to the people you most want reporting to you.

Does the law already protect researchers? Mostly no

Many founders assume that since the US Department of Justice softened its stance on the Computer Fraud and Abuse Act, researchers are now safe and a custom clause is unnecessary. That assumption is wrong in two important ways.

On May 19, 2022, the DOJ revised its CFAA charging policy to say it would not pursue good-faith security research. That was real progress. But the DOJ itself was explicit that the change does not affect civil liability and does not bind state computer-crime laws. As the law firm Wilson Sonsini noted in its analysis, questions and possible civil liability remain for researchers.

Translate that into plain terms. A company can still sue a researcher in civil court. A state prosecutor operating under a state hacking statute can still bring charges. The federal criminal shield is narrow, and it is not yours to extend. The only instrument that closes those gaps for the people testing your systems is safe-harbor language in your own policy. The law sets a floor; your policy is what makes the invitation real.

“Responsible” versus “coordinated” disclosure: words matter

The terminology you choose signals whether you see researchers as collaborators or suspects, and the industry has deliberately moved away from the loaded term.

“Responsible disclosure” is value-laden. It quietly implies that anyone who does not follow the vendor’s preferred timeline is being irresponsible, which puts the moral burden entirely on the reporter and none on the vendor who sat on a fix. CERT/CC and most of the security community now use Coordinated Vulnerability Disclosure (CVD), which describes the process without the finger-wagging. It frames disclosure as a two-way coordination problem, which is what it actually is.

This is not academic hair-splitting. Recall that Microsoft itself switched from “responsible” to “coordinated” mid-crisis. Moussouris flagged the original framing as “the first strike.” When the company at the center of the storm changes its vocabulary under pressure, that tells you which word the people who report bugs are listening for. Use “coordinated” in your policy. It costs nothing and it signals respect.

The cost of having no VDP: silence or the grey market

When researchers cannot report safely, the vulnerability does not disappear. You simply do not hear about it until it is weaponized, because the finder went quiet or found a better-paying buyer.

The scale of the gap is large. By HackerOne’s own count, 93% of Forbes Global 2000 companies have no published way for researchers to report a security issue. That is HackerOne’s finding rather than an independent census, but the direction is not controversial: most organizations have no front door.

The alternative market is brutal economics. Grey-market exploit prices dwarf any vendor bounty. Brokers like Crowdfense have advertised up to roughly $9 million for a full mobile zero-click exploit chain; browser exploits fetch $3 million to $3.5 million; Zerodium has advertised up to $2 million for an Android remote-code-execution chain. You are not competing with those prices, and you do not need to. You only need to make coordinated reporting safe and frictionless enough that a researcher chooses the legal path. A threat letter pushes them the other way.

The five ingredients of a policy that protects both sides

A disclosure policy that works is short and concrete. It has five parts, and a researcher should be able to read it in two minutes and know exactly what is allowed.

On timing, anchor to established norms so neither side has to negotiate from scratch. The de facto industry-standard disclosure window is around 90 days; CERT/CC defaults to about 45 days; Google Project Zero uses a 7-day deadline for bugs under active exploitation. A 24-to-48-hour acknowledgment SLA is common practice and the single cheapest trust signal you can offer. The Nightmare-Eclipse researcher’s central grievance was about mistreatment, a revoked account, withheld bounty, and stripped attribution, not the absence of a payout. Get the trust signals right and most disputes never start.

How to stand one up from day one, without enterprise overhead

The reason most startups skip a VDP is not disagreement with any of the above. It is that the existing guidance is either an abstract standard or a legal template, with no running program attached. OWASP gives you the theory. disclose.io gives you the clause. Neither gives you triage, SLAs, or a place for researchers to actually file a report and watch it progress.

This is exactly the gap Kit’s security module closes. Instead of stitching together a policy document, a contact form, and a spreadsheet, you configure one program that maps directly to the five ingredients above:

• Safe harbor and scope are part of the program configuration, so the authorization language and in-scope asset list live in the policy a researcher reads, not in a founder’s memory.
• A guided setup flow walks a new account from zero to a live program, so “where do I even start” never becomes a dead end.
• A standardized coordinated-disclosure workflow handles triage, severity assessment, and duplicate checks the same way for every reporter, which is the consistency Microsoft lacked.
• Researcher-facing trust signals are built in: in-program messaging, transparent triage status, researcher karma, and a clean bounty and ledger trail, so no one feels ignored or stiffed.
• Committed SLAs and visible timelines keep response fast and auditable, removing the slow-and-silent pattern that pushes researchers toward public disclosure.

One honest caveat, because the whole point of this article is not overclaiming. Kit gives you the operational scaffolding and the right place to put safe-harbor language. It is not legal advice. Have counsel review your final policy text before you publish it, especially the authorization and scope wording. Saying so out loud is itself a trust signal, and it matches the thesis: clarity beats ambiguity every time.

If you want the deeper mechanics, our guide on how to set up a vulnerability disclosure program covers the intake plumbing, and when researchers go public digs into why slow handling, not hostility, is what produces zero-day dumps. If you ship into the EU, the Cyber Resilience Act disclosure deadline makes a CVD policy a legal requirement, not just a best practice.

A founder’s day-one checklist

You do not need a security team to do this. You need an afternoon. Here is the minimum:

1. Publish a safe-harbor clause stating you won’t pursue legal action against good-faith researchers who stay in scope. Borrow from disclose.io and have counsel review it.
2. Define your scope explicitly: which domains and assets are fair game, and what is off-limits (no data exfiltration, no DoS, no social engineering, no third-party services).
3. Open one reporting channel and advertise it with a security.txt file at /.well-known/security.txt.
4. Commit to a response SLA: acknowledge within 48 hours, give a realistic fix and disclosure timeline.
5. Use “coordinated,” not “responsible,” disclosure throughout, and promise attribution to anyone who wants it.

Microsoft’s mistake was reaching for a legal threat when it should have reached for a clear policy. A startup has the advantage of building the policy first, before the first angry researcher, before the first awkward report in support@, before the count of unfixed bugs starts climbing in public. Encode safe harbor, scope, SLAs, and trust signals into your disclosure program now, and you never have to write the apology blog post later.

Stand up a researcher-safe VDP this afternoon, not next quarter. Start free with Kit and configure your disclosure program in one place.