Paid Vulnerability Disclosure and the Line Between Research and Extortion

Summary. A security researcher who asks to be paid for a vulnerability report is not committing a crime, but a researcher who conditions silence on payment probably is, and the difference turns on sequencing, framing, and what is conditioned on what. This article explains why the underlying research is legally uncertain under the Computer Fraud and Abuse Act after Van Buren v. United States, state computer crime statutes, and the DMCA anti-circumvention rules, and what the Department of Justice's 2022 charging policy does and does not protect. It then sets out the federal and state extortion statutes that govern the demand, including the Hobbs Act, 18 U.S.C. 875(d), and the computer-extortion clause of the CFAA, and identifies the four features that change the character of a payment request. The Uber case, in which the intruders were convicted of extortion and the company's chief security officer was convicted of obstruction and misprision, is examined from both sides. Practical sections show researchers how to structure a lawful paid disclosure, show companies how to respond without creating their own liability, and close with the two emails annotated line by line, an FAQ, and takeaways.

Two emails. Both arrive on a Tuesday morning. Both are polite.

The first says: We identified a vulnerability in your customer portal that exposes account records. We are disclosing it to you now. Here is the technical detail. We would like to discuss compensation for the time invested and a release of claims. We will publish nothing.

The second says: We identified a vulnerability in your customer portal. We have not disclosed it. We are prepared to keep it confidential. Please respond within 72 hours to discuss terms.

To a general counsel reading quickly, those look similar. Legally they are not remotely the same document. One is coordinated vulnerability disclosure with a compensation request attached, which is lawful, increasingly common, and useful to everyone involved. The other has the structural shape of extortion, and the person who sent it may have committed a federal crime before anyone answered.

The distance between them is a matter of sequencing, framing, and what is conditioned on what. That distance is the subject of this article.

I write this from a specific vantage. I am a technology attorney and a former software engineer, and I get called by both sides: researchers who found something and want to know whether contacting the company will end their career, and companies staring at a message they cannot tell apart from a ransom note. The two groups are almost always more afraid of each other than the facts warrant, and both are usually wrong about which parts are actually risky.

This article is the analytical piece. The step-by-step procedure for each side is in Reporting or Receiving a Security Vulnerability: A Practical Guide for Researchers and Companies. The program-building tasks for a company are in the Vulnerability Disclosure Program and Safe Harbor Checklist: A Practical Checklist, and the letters, policies, and agreements discussed below are collected as fill-in templates in the Vulnerability Disclosure Toolkit: VDP Policies, Safe Harbor Terms, Researcher Agreements, and Response Letters.

The short version

Finding a vulnerability is not a crime. How you found it might be. The access question is governed by the Computer Fraud and Abuse Act, 18 U.S.C. § 1030, by state computer crime statutes, and sometimes by the anti-circumvention rules of 17 U.S.C. § 1201.
Telling a company about a vulnerability is not a crime, and asking to be paid for your work is not a crime either.
Conditioning silence on payment, explicitly or by clear implication, is where criminal exposure begins, and no amount of professional vocabulary in the email fixes it.
The Supreme Court narrowed part of the CFAA in 2021, in Van Buren v. United States, 593 U.S. 374 (2021). The Department of Justice adopted a policy in 2022 saying it will not charge good-faith security research. Neither development gives a researcher immunity, and both are frequently oversold.
The statutes in play for the demand are the Hobbs Act, 18 U.S.C. § 1951; the interstate threat statute, 18 U.S.C. § 875(d); the CFAA's own computer-extortion clause, 18 U.S.C. § 1030(a)(7); the federal blackmail statute, 18 U.S.C. § 873; and every state extortion law in the country.
For companies on the receiving end, the mirror-image risk is real and underappreciated. How you respond to a vulnerability report can create liability where none existed, and the leading case on that point ended with a chief security officer convicted of two federal felonies.

Part One: Why the underlying research is legally uncertain

A statute written for a different world

The Computer Fraud and Abuse Act was enacted in 1986, building on a narrower 1984 computer crime statute. The House report on the 1984 legislation is commonly cited for its reference to the 1983 film WarGames, which tells you something about the mental model Congress was working from: a teenager dialing into a military mainframe.

The statute makes it a crime to intentionally access a computer "without authorization" or to "exceed authorized access," and thereby obtain information from a protected computer. That is § 1030(a)(2), the provision that matters most for security research. A "protected computer," after decades of amendment, includes any computer "used in or affecting interstate or foreign commerce or communication," which means essentially any computer connected to the internet.

The statute defines "exceeds authorized access" but never defines "without authorization." That single omission has produced forty years of litigation, because the whole edifice rests on a word that means different things to a network engineer, a contract lawyer, and a prosecutor.

Before 2021 the federal circuits split badly on the "exceeds authorized access" half. The First and Seventh Circuits read it broadly: in EF Cultural Travel BV v. Explorica, Inc., 274 F.3d 577 (1st Cir. 2001), a competitor's use of a scraper built with a former employee's confidential knowledge was enough to support a CFAA claim, and in International Airport Centers, L.L.C. v. Citrin, 440 F.3d 418 (7th Cir. 2006), an employee's authorization ended when he breached his duty of loyalty. The Ninth and Fourth Circuits went the other way. The en banc Ninth Circuit in United States v. Nosal, 676 F.3d 854 (9th Cir. 2012) refused to turn every violation of a computer-use policy into a federal crime, and the Fourth Circuit agreed in WEC Carolina Energy Solutions LLC v. Miller, 687 F.3d 199 (4th Cir. 2012). A researcher's exposure therefore depended in part on which circuit the target company chose to sue in.

Van Buren narrowed half the problem

In Van Buren, the Supreme Court took up "exceeds authorized access." A Georgia police sergeant had run a license plate lookup in a law enforcement database he was authorized to use, in exchange for money, as part of an FBI sting. The government argued that using authorized access for an unauthorized purpose exceeded authorization.

The Court disagreed, adopting what has become known as the gates-up-or-down approach. If you are authorized to be in a system and authorized to obtain the information in question, you do not violate the CFAA by obtaining it for a bad reason. The clause reaches people who access areas of a system (files, folders, databases) that are off limits to them, not people who misuse information they were entitled to retrieve. Justice Barrett's majority opinion worried openly that the government's reading would criminalize "a breathtaking amount of commonplace computer activity," such as checking sports scores on a work computer.

For security research, that matters enormously in one specific circumstance and not at all in another.

It matters if you had legitimate access. A pentester with a credentialed account, a customer poking at an API they are authorized to call, a researcher on a platform whose terms they technically violated: those situations got substantially safer.

It does nothing if you were never authorized to be there. Guessing an admin URL, brute-forcing credentials, or exploiting an authentication bypass is still access "without authorization," which Van Buren did not touch. Most interesting vulnerability research lives in exactly that category, which is why the decision was a smaller victory than the headlines suggested. The Court also expressly declined to decide (in a footnote that has generated its own literature) whether the gates it described must be technological barriers or can be drawn by contracts and policies.

The scraping cases and the public-gate question

The Ninth Circuit's scraping cases fill in part of what Van Buren left open. In hiQ Labs, Inc. v. LinkedIn Corp., 938 F.3d 985 (9th Cir. 2019), the court held that hiQ had raised serious questions whether scraping profiles that LinkedIn made available to the general public, without a login, was access "without authorization" at all. The Supreme Court vacated that decision for reconsideration in light of Van Buren, and on remand the Ninth Circuit reached the same conclusion in hiQ Labs, Inc. v. LinkedIn Corp., 31 F.4th 1180 (9th Cir. 2022): where a website is open to the public, there are no gates to lift or lower, and the "without authorization" concept does not apply. The broader litigation history, including the contract claims that ultimately decided the dispute, is in Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims.

The same court has held, on the other side, that authorization can be revoked. In Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058 (9th Cir. 2016), a company that kept accessing Facebook after receiving a cease and desist letter and having its IP addresses blocked acted without authorization from that point forward. And in United States v. Nosal, 844 F.3d 1024 (9th Cir. 2016), a former employee who used a current employee's password after his own access was revoked was liable even though the password's owner consented. For a researcher, the lesson is concrete: a block, a revocation, or a written demand to stop changes the analysis immediately, and continued testing after any of them is the most dangerous thing you can do.

There is also a nuance people miss. Some conduct that feels obviously fine remains contested. Incrementing an ID in a URL to see whether the server returns someone else's record is, functionally, the most common way insecure direct object reference (IDOR) vulnerabilities are discovered. It is also, on an aggressive reading, obtaining information from a protected computer that the operator did not intend you to have. The best-known prosecution on these facts, of a researcher who harvested roughly 114,000 iPad user email addresses from an AT&T web server by incrementing device identifiers, ended when the Third Circuit vacated the conviction on venue grounds without deciding whether the access was unauthorized, in United States v. Auernheimer, 748 F.3d 525 (3d Cir. 2014). Courts have not converged, and the number of records taken mattered to the government's theory in that case.

Civil liability survived entirely

The CFAA has a private right of action at § 1030(g). A company that believes it suffered damage or loss can sue, provided the conduct involves one of the statutory factors, most commonly "loss" aggregating at least $5,000 in a one-year period. Suit must be brought within two years of the act or the discovery of the damage.

This is the piece researchers most often overlook. Every reassurance about prosecutorial discretion is about criminal charges. None of it stops a company from filing a civil complaint, and the threshold for civil exposure is lower than for criminal conviction. "Loss" is defined in § 1030(e)(11) to include "any reasonable cost to any victim, including the cost of responding to an offense, conducting a damage assessment, and restoring the data, program, system, or information to its condition prior to the offense." That means a company can generate its own damages by having its incident response team spend a weekend on your disclosure. Van Buren noted that the statute's damage and loss provisions focus on technological harms, which some courts have read to narrow what counts, but the investigation-cost theory remains alive.

That does not mean such suits are common or that they succeed. It means the risk does not disappear when a prosecutor declines.

State law is often worse

There are state computer crime statutes considerably broader than the federal one. California's Comprehensive Computer Data Access and Fraud Act, Cal. Penal Code § 502, reaches anyone who "knowingly accesses and without permission" uses or takes data, and it carries its own civil action with attorney's fees in subdivision (e). Some states criminalize unauthorized access with no requirement of damage, loss, or intent to defraud. Texas's breach of computer security offense, Tex. Penal Code § 33.02, is a misdemeanor at its base level and requires only knowing access without the owner's effective consent. Some state statutes have been enforced in ways that would surprise anyone reasoning only from federal law.

Which state matters is not always obvious. Plausible candidates include where the target's servers are, where the target is headquartered, where the researcher was sitting, and sometimes where the affected users are. That can be four different answers for one piece of research on one company.

If you are advising on a multi-target engagement, this is why the analysis cannot be done once and generalized. It has to be done per target.

The DMCA problem nobody remembers

If the research involved circumventing a technological protection measure, and it often does with hardware, firmware, DRM, or licensing checks, then 17 U.S.C. § 1201 is in play. Section 1201 prohibits circumventing access controls on copyrighted works, and software is a copyrighted work under 17 U.S.C. § 101. Section 1201 carries civil remedies under § 1203, including statutory damages per act of circumvention, and criminal penalties under § 1204 for willful violations for commercial advantage or private financial gain. The courts have read the statute differently: the Federal Circuit in Chamberlain Group, Inc. v. Skylink Technologies, Inc., 381 F.3d 1178 (Fed. Cir. 2004) required a nexus to infringement, while the Ninth Circuit rejected that requirement in MDY Industries, LLC v. Blizzard Entertainment, Inc., 629 F.3d 928 (9th Cir. 2010). The Second Circuit's decision in Universal City Studios, Inc. v. Corley, 273 F.3d 429 (2d Cir. 2001) confirmed that publishing circumvention code can itself be enjoined, which matters to a researcher planning to release a proof of concept.

There is an exemption for good-faith security research, adopted through the Copyright Office's triennial rulemaking and codified at 37 C.F.R. § 201.40(b). It defines good-faith security research as accessing a computer program solely for purposes of good-faith testing, investigation, or correction of a security flaw or vulnerability, carried out in an environment designed to avoid any harm to individuals or the public, where the information derived is used primarily to promote the security or safety of the class of devices or machines on which the program operates, or those who use them, and is not used or maintained in a manner that facilitates copyright infringement. The exemption also requires that the device or program be lawfully acquired and that the research not violate any other applicable law, including the CFAA.

Read those conditions carefully, because each is a place to fail. "Solely." "Designed to avoid any harm." "Used primarily to promote the security or safety" of the affected class of devices or users. "Does not violate any applicable law." A researcher whose primary use of the information is to extract a payment has an obvious problem with the third condition, and a researcher whose access violated the CFAA has lost the exemption through the fourth.

The exemption is also renewed on a three-year cycle, which means it is not permanent law and its exact contours shift. It was first granted in 2015, broadened in 2018, and renewed in 2021 and 2024, and the Copyright Office opened the tenth triennial proceeding in June 2026, with renewal petitions due that August (91 Fed. Reg. 34796). First Amendment challenges to § 1201 brought by security researchers, including Green v. U.S. Department of Justice (D.C. Cir. 2024), have so far not produced relief. The rulemaking history is traced in The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions.

Part Two: The DOJ policy, and what it does not do

On May 19, 2022, the Department of Justice revised its CFAA charging policy in the Justice Manual (section 9-48.000). Federal prosecutors are directed to decline prosecution where the conduct consisted of good-faith security research. The policy also addressed conduct that merely violates a website's terms of service or a contractual access restriction, which after Van Buren was largely academic anyway. A federal district court had reached a similar conclusion two years earlier for academic researchers testing websites for discrimination, holding in Sandvig v. Barr, 451 F. Supp. 3d 73 (D.D.C. 2020) that violating a site's terms of service is not a CFAA crime.

The definition DOJ adopted is borrowed almost word for word from the Copyright Office's § 1201 language quoted above: accessing a computer "solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety" of the devices, machines, or online services involved or their users.

This was a meaningful development and it is routinely misdescribed. Four limits are worth stating plainly.

It is policy, not law. The Justice Manual creates no rights. It is not enforceable by a defendant. A subsequent administration can revise it, and internal charging policy has never been a defense at trial.

It binds only federal prosecutors. State attorneys general and district attorneys are unaffected. Given how broad some state statutes are, this is a substantial gap.

It does nothing about civil liability. The company can still sue under § 1030(g), under state statutes such as Cal. Penal Code § 502(e), and under contract and trespass theories. California's highest court limited trespass to chattels for electronic contact in Intel Corp. v. Hamidi, 71 P.3d 296 (Cal. 2003), requiring actual impairment of the system, but a test that degrades a production server can satisfy that standard.

It contains an explicit carve-out for exactly the conduct this article is about. DOJ's announcement of the policy stated that research done for a bad purpose, giving as its example "discovering security holes in devices, machines, or services in order to extort the owners of such devices, machines, or services," "might be called 'research,' but is not in good faith."

That sentence should be printed and taped to the wall of anyone building a paid disclosure practice. The federal government anticipated this business model and wrote the exclusion into the policy that everyone in the field cites as their protection.

So the shield exists, and it has a hole in it shaped precisely like a payment demand tied to silence.

Part Three: Where the line actually is

The statutes

Four bodies of law govern the demand side.

The Hobbs Act, 18 U.S.C. § 1951, reaches extortion affecting interstate commerce, defined in § 1951(b)(2) as "the obtaining of property from another, with his consent, induced by wrongful use of actual or threatened force, violence, or fear." Courts have long read "fear" to include fear of economic loss, and reputational harm that translates into lost business fits comfortably within that reading. The Supreme Court has policed the "obtaining" element: in Scheidler v. National Organization for Women, Inc., 537 U.S. 393 (2003), it held that the defendant must actually acquire property, not merely deprive the victim of it, and in Sekhar v. United States, 570 U.S. 729 (2013), that the property must be transferable. Money paid for silence is both.

Section 875(d) of Title 18, 18 U.S.C. § 875(d), makes it a crime, with intent to extort money or any thing of value, to transmit in interstate commerce a communication containing a threat to injure the property or reputation of the addressee or another. An email is a communication in interstate commerce. The maximum penalty is two years.

The CFAA's computer-extortion clause, 18 U.S.C. § 1030(a)(7), is the provision most often overlooked in this debate and the one most precisely aimed at it. It punishes anyone who, with intent to extort money or any other thing of value, transmits a communication containing (A) a threat to cause damage to a protected computer, (B) a threat to obtain information from a protected computer without authorization or in excess of authorization, or "to impair the confidentiality of information obtained from a protected computer without authorization or by exceeding authorized access," or (C) a demand for money in relation to damage to a protected computer, where the damage was caused to facilitate the extortion. Subparagraph (B) describes, almost exactly, a researcher who pulled data without authorization and then offers to keep it confidential for a fee. Conspiracy to commit it is charged under 18 U.S.C. § 371.

State extortion and blackmail statutes cover the same ground with local variations, and many are broader than the federal versions. California defines extortion in Cal. Penal Code § 518 and lists in § 519 the threats that qualify, including a threat to "expose, or to impute to him, her, or them a deformity, disgrace, or crime" and a threat to "expose a secret affecting him, her, or them." A threat to publish an unpatched vulnerability is not obviously a "secret" in the traditional sense, but no careful lawyer would bet a client's liberty on that distinction. The federal blackmail statute, 18 U.S.C. § 873, separately reaches demanding or receiving money "under a threat of informing, or as a consideration for not informing, against any violation of any law of the United States," which becomes relevant the moment a demand hints that the researcher will report the company's own legal violations.

The operative word across all of them is "wrongful." Asking a company for money is not extortion. Threatening a lawsuit is not extortion. Publishing true information about a company is not, by itself, extortion. What makes a demand wrongful is the linkage: you are threatening to do something in order to obtain property you have no lawful claim to, where the threat itself is the mechanism of obtaining it. The Supreme Court framed the point in labor terms in United States v. Enmons, 410 U.S. 396 (1973): the use of force or fear is "wrongful" under the Hobbs Act when the person has no lawful claim to the property obtained.

Three cases that show how courts draw the line

The leading cases on reputational extortion are not about security research, but they map onto it closely.

The paternity letter. In United States v. Jackson, 180 F.3d 55 (2d Cir. 1999), a young woman who claimed to be the daughter of a famous entertainer wrote to him demanding $40 million, and said that if he did not pay she would sell her story to a tabloid. The Second Circuit held that § 875(d), despite its literal breadth, reaches only threats that are "wrongful," and that a threat to injure reputation is wrongful when it is used to obtain property to which the sender has no plausible claim of right, or where there is no nexus between the threat and any claim of right. On rehearing, the court concluded that the jury instruction error it had identified was harmless and affirmed the conviction. The framework is the one a prosecutor would apply to a researcher: is the money tied to something the researcher has a plausible right to be paid for, or is it the price of not publishing?

The lawyer and the sneaker company. In 2019, a well-known plaintiffs' lawyer told an athletic apparel company that he would hold a press conference about alleged misconduct in its amateur basketball program unless the company paid his client a settlement and retained him and a colleague to conduct an internal investigation for a fee of $15 million to $25 million. He was convicted under the Hobbs Act and § 875(d), and the Second Circuit affirmed in United States v. Avenatti, 81 F.4th 171 (2d Cir. 2023). The court's analysis turned on the gap between the client's plausible claim and the lawyer's demand for money for himself. The case is a template for what not to do in the disclosure context: a demand to be hired, at a self-set price, to investigate the very problem you are threatening to expose.

The demand letter that was not protected speech. In Flatley v. Mauro, 39 Cal. 4th 299 (2006), the California Supreme Court held that a lawyer's letter threatening to publicize accusations against a celebrity and to report him to immigration and tax authorities unless he paid a settlement was extortion as a matter of law, so the lawyer could not use the anti-SLAPP statute to strike the resulting civil suit. The court distinguished ordinary settlement demands, which are protected, from demands that link payment to threats of exposure and criminal referral. Later California decisions, including Mendoza v. Hamzeh, 215 Cal. App. 4th 799 (2013), applied the same reasoning to a letter threatening to report a business owner to authorities.

None of these cases involved code. All of them involved a demand that tied money to the sender's power to cause reputational harm, and in each one the courts looked past the vocabulary to the structure.

Why vulnerability disclosure sits uncomfortably close

Here is the structural problem, stated as plainly as I can.

A researcher who has found a serious vulnerability holds something the company badly does not want made public. Publication would cause real reputational and possibly financial harm. The researcher would like to be paid.

Every element of the extortion fact pattern is present in the raw materials. The company's fear is genuine and economic. The researcher's ability to cause harm is real. Money is changing hands.

What separates a lawful transaction from a criminal one is not the presence of those elements. It is whether the payment is being obtained by means of the threat.

If the disclosure happens regardless, and the payment is compensation for identifiable value delivered, the threat is not the mechanism and the elements do not line up. If the disclosure is withheld pending payment, the threat is the entire mechanism, and the professional vocabulary wrapped around it is decoration.

The four features that change the character of a demand

In practice, prosecutors, regulators, and opposing counsel look at a handful of things. So should you.

Is disclosure conditioned on payment? This is the single most important question. A letter that says the report will be provided when terms are agreed is conditioning. A letter that provides the report and separately requests compensation is not.

Is there a deadline, and what happens when it expires? A deadline that implies publication, regulatory referral, or contact with customers is a threat, even if the word "threat" never appears. Coordinated disclosure does involve timelines, and a standard 90-day disclosure timeline is an accepted industry norm rather than a threat; Google's Project Zero popularized 90 days, and the CERT Coordination Center has long used a 45-day default. The difference is that a genuine disclosure timeline runs whether or not anyone pays, and it does not accelerate or extend based on the state of negotiations. The moment your deadline moves in response to a payment discussion, it has become leverage.

What is the payment consideration? "Pay us and we will stay quiet" is buying silence. "Pay us for the time invested, a release of claims, cooperation with remediation, and an agreement not to make further access attempts" is buying identifiable things a company would rationally purchase. The second version is also a materially better deal for the company, which is why it is easier to close.

Was the vulnerability sought out for this purpose? DOJ's carve-out language turns on purpose. A researcher who found something in the course of legitimate work and then sought compensation is in a different position from an operation that systematically scans for flaws in order to generate payment demands. Prosecutors look at pattern evidence, and a portfolio of identical letters to fifty companies is pattern evidence.

Feature	Reads as disclosure	Reads as extortion
Technical detail	Delivered in the first message	Held back "pending terms"
Deadline	Fixed remediation window, extendable on request	Short, unrelated to remediation, tied to payment
What the money buys	Hours, release, covenant not to retest, retest help	Silence
Third parties	Not mentioned, or expressly disclaimed	Regulators, press, or customers raised near the price
Pattern	One finding, found in ordinary work	Many targets, identical letters, scanning for leverage

The Uber case, which cuts both ways

The most instructive case in this area is not about a researcher at all. It is about a company.

In 2016, two individuals used credentials found in a private code repository to access an Amazon cloud storage bucket belonging to Uber and downloaded records associated with roughly 57 million riders and drivers, including some 600,000 driver's license numbers. They contacted Uber's chief security officer, Joe Sullivan, and demanded a large payment.

Uber paid them $100,000 in bitcoin, routed through its bug bounty program, at a time when the program's published rewards were far smaller. The company had the individuals sign nondisclosure agreements that falsely recited that they had not taken or stored any data, later re-executed in their true names once they were identified. The breach was not reported to the Federal Trade Commission, which was at that moment investigating Uber's data security practices over a separate 2014 incident, nor publicly disclosed until new management announced it in November 2017.

Two things happened.

The individuals who took the data, Brandon Glover and Vasile Mereacre, pleaded guilty in 2019 to conspiracy to commit computer-related extortion, in connection with both the Uber incident and a similar intrusion and demand at Lynda.com, the LinkedIn learning subsidiary. Whatever the payment was labeled, the underlying conduct was prosecuted as extortion.

And Sullivan was charged. In October 2022, a federal jury in San Francisco convicted him of obstruction of an FTC proceeding under 18 U.S.C. § 1505 and misprision of a felony under 18 U.S.C. § 4. In May 2023 he was sentenced to three years of probation, 200 hours of community service, and a fine. Judge Orrick, imposing that sentence, said the first-of-its-kind nature of the case justified leniency and cautioned that future defendants in similar positions should expect custody, even if they had Sullivan's record of good character. Sullivan appealed, and the Ninth Circuit affirmed in United States v. Sullivan, 131 F.4th 776 (9th Cir. 2025), later amending its opinion and denying rehearing en banc in November 2025.

The misprision count deserves a closer look, because it is the part of the case that most directly addresses the bug bounty label. Misprision requires that a felony was actually committed, that the defendant knew it, and that the defendant took an affirmative step to conceal it. The government's theory was that the intruders' access and demand were felonies when they happened, and that the bounty paperwork and nondisclosure agreements were the affirmative concealment. Sullivan argued on appeal that the NDA amounted to Uber's authorization of the intruders' access, so that no CFAA felony had been completed. The Ninth Circuit called that "a false premise," because the hackers had no authorization at the moment of access, and it put the holding in a sentence worth repeating to any client: "Their illegal conduct could not be laundered through an NDA." The panel also rejected the claim that Sullivan reasonably believed the NDA cleansed the access of its illegality, noting his background as a federal computer crimes prosecutor. That is the practical reason a researcher should not plan around retroactive blessing, and a company should not try to give one.

Read the case from both directions.

For anyone sending a payment demand: labeling a transaction as a bug bounty does not transform its legal character. The label did not save Glover and Mereacre. Prosecutors looked at what actually happened, which was money paid in exchange for silence about stolen data, and charged it accordingly.

For anyone receiving one: the way you respond can create your own criminal exposure. Sullivan was not convicted for the breach. He was convicted for how the company handled it, specifically for concealment while a federal agency was investigating. The NDAs were treated as evidence of concealment rather than as ordinary commercial documents.

The case has been criticized, including by people who think it makes companies and security leaders less willing to engage with researchers. That criticism has force. It is also not a defense to anyone reading this. The conviction stands.

Part Four: Structuring a paid disclosure that is not a crime

Assume a genuine case. A researcher found a real flaw, wants the company to fix it, and reasonably believes the work has value. How do you actually do this?

Decouple disclosure from payment

Send the report. Not a teaser, not a redacted summary with the critical detail withheld pending terms. The report.

This feels wrong to researchers, who correctly observe that it eliminates their leverage. That is the point. Leverage is the legal problem. A researcher who has already disclosed cannot be accused of conditioning disclosure, because there is nothing left to condition.

It also works better than people expect. Companies respond to reports that arrive with the technical detail intact, because the security team can immediately verify the finding, and verification converts an ambiguous email into a real internal priority. A report that arrives with the substance held back gets routed to legal, and legal's first instinct is to treat it as a threat.

If disclosing everything up front is truly unacceptable in a given case, an intermediate structure exists: disclose to a neutral third party, such as the CERT Coordination Center, a sector coordinating body, or counsel for the company under an agreed protocol. That preserves the researcher's ability to prove what they had and when, without conditioning the company's access to the information on payment.

Frame the compensation for what it actually buys

The request should be for consideration a company would rationally pay for on its own terms. In practice that means the time invested in identifying and documenting the vulnerability, a release of any claims arising from the research, a covenant not to make further access attempts, cooperation on remediation and verification, and confidentiality for a defined period tied to the remediation timeline.

Notice that confidentiality can be part of the package. Time-limited confidentiality during remediation is standard practice in coordinated disclosure and nearly every VDP includes it, because publishing an unpatched vulnerability harms users. What matters is that confidentiality is one term among several in a commercial agreement, rather than the sole thing being sold, and that its duration is tied to the fix rather than to the payment.

Get this framing into the first email. Documents written later, after a negotiation has gone badly, look exactly like what they are.

Keep the timeline off the negotiating table

State the disclosure timeline once, early, and treat it as fixed. Ninety days is the common industry default and is defensible precisely because it is a norm rather than an invention.

Then do not move it in response to the negotiation. Do not extend it as an inducement. Do not threaten to shorten it. The moment the date becomes responsive to the payment discussion, you have converted an industry-standard practice into a lever, and a prosecutor reading the email thread will see that immediately.

Never invoke regulators or customers as pressure

Mentioning that a breach may trigger notification obligations is legitimate legal information and often genuinely useful to a company that has not thought about it. Saying that you will contact the regulator if you are not paid is a threat to injure reputation with intent to extort, and, if the regulator would be told about a legal violation, it is the precise conduct § 873 describes.

The line between those two sentences is thin on the page and enormous in a courtroom. The safest practice is simply not to raise regulators, journalists, or affected customers in any communication that also discusses money. If the company needs to be told about its notification obligations, that is a conversation its own counsel should have.

Document the research boundary

Contemporaneously, before any contact: what systems were touched, what was accessed, whether any data was retrieved and if so exactly what and how much, whether anything was retained, and when it was deleted.

The single best posture is to have retrieved the minimum necessary to demonstrate the flaw and to have deleted it immediately with a record of deletion. A researcher who downloaded one record to prove an IDOR exists and deleted it that afternoon is in a categorically better position than one who pulled ten thousand records "to assess scope."

This documentation serves three purposes. It supports a good-faith characterization. It answers the question every company asks first, which is whether their data is still out there. And it establishes the factual baseline that any lawyer will need in order to give you an accurate risk assessment.

Understand what anonymity can and cannot do

Researchers frequently want to stay anonymous, and lawyers are often asked to be the shield. Some of that works. Much of it does not, and clients are routinely misled about which is which.

An attorney can represent an undisclosed principal. Counsel can send the correspondence, decline to name the client, and conduct the entire commercial negotiation without disclosing who the researcher is. That is ordinary practice.

Attorney-client privilege protects confidential communications made for the purpose of legal advice, as the Supreme Court explained in Upjohn Co. v. United States, 449 U.S. 383 (1981), and federal courts apply it under Fed. R. Evid. 501. It generally does not protect the client's identity or the fact of the retention. Against a subpoena, a grand jury, or civil discovery, the anonymity is far weaker than clients assume. Narrow exceptions exist where disclosing the identity would itself reveal a confidential communication, but they are fact-bound and contested. The privilege doctrine for business clients is covered in Attorney-Client Privilege and Work Product for Businesses: Upjohn, In-House Counsel, and the Common Interest.

And the practical squeeze comes at settlement. A company paying money wants a release. A release from an unnamed party is worth very little to the company's counsel, who will say so. So identity often becomes the price of closing. There are structures that mitigate this, including releases executed through counsel, an entity formed to hold the claims, or disclosure to opposing counsel on an attorneys-eyes-only basis rather than to the company generally. Pick one deliberately at the outset rather than improvising when the settlement agreement is being drafted. The mechanics of the release itself are in Drafting a Settlement Agreement and Release: A Practical Guide.

Privilege has one further limit that matters here more than anywhere else. The crime-fraud exception reaches communications made in furtherance of a crime or fraud, and under United States v. Zolin, 491 U.S. 554 (1989), a court may review the communications in camera to decide whether the exception applies once the government makes a threshold showing. If the demand is characterized as extortion, the privilege that was supposed to protect the researcher can be pierced, and the lawyer's file becomes evidence. This is the practical reason a competent lawyer will insist on the non-coercive structure. It is not fastidiousness. It is the difference between a privileged file and a discoverable one.

Part Five: Safe harbors, VDPs, and what "authorization" really means

The mechanism

The cleanest way to make security research lawful is for the system owner to authorize it. If the owner has granted permission, access is not unauthorized, and the central CFAA problem evaporates.

That is what a vulnerability disclosure policy does. A VDP is a unilateral public statement in which an organization authorizes specified testing against specified assets under specified conditions, and commits not to pursue legal action against researchers who stay inside those lines. A bug bounty program is a VDP with money attached, usually run through a platform whose own terms add another contractual layer.

The international standards are ISO/IEC 29147, which covers vulnerability disclosure, and ISO/IEC 30111, which covers vulnerability handling. Federal civilian agencies were directed to publish VDPs by CISA's Binding Operational Directive 20-01, issued in September 2020, which is why most federal civilian agencies now publish a disclosure page with a stated scope and a safe harbor commitment. The location convention most tooling relies on is a security.txt file, standardized by the IETF in RFC 9116, which tells a researcher where to send a report and where the policy lives. For connected-device makers, the IoT Cybersecurity Improvement Act of 2020 pushed VDP expectations into federal procurement, and medical device manufacturers now must describe coordinated vulnerability disclosure in premarket submissions under section 524B of the Food, Drug, and Cosmetic Act. Those product-side obligations are covered in Building a Product Security Program for Connected Devices: A Practical Guide and Connected Device Security and Software Liability: Regulators, Standards, and the Duty to Patch.

What a safe harbor does not do

Researchers over-rely on these, so it is worth being precise.

Scope is a wall, not a suggestion. A VDP authorizes testing of listed assets by listed methods. Test something outside scope and you have no authorization for that conduct at all. Subdomain enumeration finding a forgotten host that is not on the list is exactly the scenario that goes wrong.

Most programs exclude data exfiltration. "Demonstrate the vulnerability without accessing user data" is standard language, and pulling records to prove severity violates it even when the researcher's intent is entirely benign.

Many programs exclude payment demands outside the program. If a company runs a bounty program with published reward tiers, a separate demand for a larger negotiated payment may fall outside the authorization entirely, and could be characterized as an attempt to circumvent the program.

A safe harbor binds the company, not the government. It is a promise not to sue and not to refer. It cannot bind a prosecutor, and a company that later decides you acted outside scope can revisit its position.

Authorization is generally prospective. This is the uncomfortable lesson of the Sullivan appeal. A company cannot reliably reach back and retroactively authorize access that was unauthorized when it happened; the Ninth Circuit held that the intruders' conduct could not be laundered through post hoc authorization in an NDA. That holding came on facts involving stolen credentials and a demand, and there are arguments that a good-faith researcher's position differs, but a researcher should not plan around retroactive blessing.

A safe harbor does not reach third parties. The company can authorize testing of its own systems. It cannot authorize testing of its cloud provider's infrastructure, its payment processor, or a customer's tenant, and a well-drafted VDP says so.

The practical instruction is simple: before testing anything, look for a VDP. Read it. Stay inside it. If there is no VDP, you are operating without authorization and every subsequent decision carries more weight.

For companies: publish one

If you do not have a VDP, you are choosing a worse version of this problem.

Without one, every researcher who finds something faces a choice between contacting you blind, staying silent, or selling the finding elsewhere. Guess which of those most often gets chosen when a company has a reputation for sending threatening letters.

A serviceable VDP is not a large project. It needs a scope statement, a description of permitted and prohibited testing, a security contact that reaches a human, a commitment to respond within a stated period, a safe harbor commitment that expressly covers the CFAA, state computer crime laws, and § 1201, a disclosure timeline you can actually meet, and a statement that payment demands outside the program will not be honored. Publish a security.txt file so automated tooling can find it. The program-level tasks are in the Vulnerability Disclosure Program and Safe Harbor Checklist: A Practical Checklist, and a policy template and safe harbor clause are in the Vulnerability Disclosure Toolkit: VDP Policies, Safe Harbor Terms, Researcher Agreements, and Response Letters. For the device-maker variant, with severity matrices and advisory templates, see the Product Security Toolkit: SBOMs, Vulnerability Disclosure, and Recall Decisions.

The return is that you convert an adversarial encounter into a managed process, you find out about your vulnerabilities from people who are telling you rather than from people who are using them, and you dramatically reduce the odds of receiving the second email from the opening of this article.

Part Six: If you receive a vulnerability report

Companies get this wrong in both directions, and the wrong reactions are predictable.

Do not lead with a threat

The reflex, particularly from outside counsel who have not worked in this area, is a cease and desist letter accusing the sender of unauthorized access.

Sometimes that is appropriate. Usually it is a mistake, for four reasons.

You may be wrong about the facts. Plenty of reports come from customers who noticed something ordinary, or from researchers who stayed entirely within your published policy.

It converts a person who was trying to help into an adversary with a grievance and a copy of your vulnerability.

It generates terrible press if it becomes public, and it usually becomes public. The most-cited example remains the 2021 Missouri incident in which a newspaper reporter notified a state agency that educators' Social Security numbers were exposed in the HTML source of a public website, and held the story until the agency fixed it. The governor responded by publicly calling the reporter a hacker and referring the matter for prosecution. The technical reality was that anyone could view the page source in any browser, and the county prosecutor ultimately declined to bring charges. The episode became a case study in how not to respond.

And it discourages the next person from telling you at all.

The better first move is neutral: acknowledge receipt, thank the sender, ask for technical detail, and say nothing about legal consequences while you verify. If a cease and desist letter is truly warranted later, the considerations on both sides are in Responding to a Cease and Desist Letter: A Practical Guide. One caution from the Power Ventures line of cases: a written revocation does change the legal position of a researcher who keeps testing, so if you send one, mean it, and know that it also forecloses the cooperative path.

Verify before you characterize

Have your security team reproduce the finding. Determine whether it is real, whether it is already known, whether it is in scope of any VDP you publish, and what the actual severity is.

This step matters legally as well as operationally. Whether the sender accessed data, and how much, determines whether you have a reportable breach. It also determines whether their conduct was arguably within your authorization. Preserve the logs before anyone rotates them; the discovery and evidentiary consequences of losing them are worse than the storage cost.

Work out your own notification obligations immediately

This is the part that gets companies in trouble.

If the report indicates that personal data was actually accessed, you may have obligations under state breach notification statutes such as Cal. Civ. Code § 1798.82, sectoral regimes such as the HIPAA breach notification rule at 45 C.F.R. part 164 (subpart D) or the FTC's Safeguards Rule notification requirement at 16 C.F.R. part 314, contractual obligations to enterprise customers, and, for public companies, securities disclosure requirements for material incidents under Item 1.05 of Form 8-K and Item 106 of Regulation S-K, 17 C.F.R. part 229. Banks have a 36-hour notice rule to their primary federal regulator under 12 C.F.R. part 53 and its counterparts. If you operate in the EU or UK, separate regimes apply with their own short clocks. The fifty-state picture is in Data Breach Response and Notification: The Fifty-State Patchwork, Regulators, and Litigation, and the federal sectoral regimes are in Cybersecurity Regulation for Businesses: The FTC Safeguards Rule, NYDFS Part 500, SEC Cyber Disclosure, and State Laws.

Those obligations run on their own timeline. They are not suspended by a negotiation with the researcher, and they are not satisfied by an NDA. Many state statutes exempt good-faith access by an employee or agent, but a stranger who retrieved records through a flaw is not that, and a researcher's honest assurance of deletion is a fact for the risk-of-harm analysis that some states allow, not a substitute for it.

Which brings us back to Uber. The lesson of that case is not that companies may never pay researchers. Companies pay researchers constantly and lawfully. The lesson is that a payment plus an NDA cannot be used to make a reportable incident go away, and that doing so while a regulator is already looking at you is how a security executive ends up with a felony conviction.

If your response to a vulnerability report starts to feel like it is designed to keep something from a regulator, stop and get counsel who will tell you no.

Do not route an extortion payment through your bounty program

Bug bounty programs are for researchers. They are not a mechanism for laundering the characterization of a ransom payment.

If someone has taken your data and is demanding money to delete it, that is an extortion event, not a bounty submission. It has its own playbook: law enforcement, incident response, counsel, insurer notice, notification analysis, and a sanctions screen, because a payment to a person on the Treasury Department's sanctions lists can violate the International Emergency Economic Powers Act, 50 U.S.C. § 1705, and the cyber-related sanctions regulations at 31 C.F.R. part 578, regardless of what the payment is called. Recharacterizing it as a bounty payout does not change what it is, and the attempt is itself evidence of consciousness of guilt. The payment decision for data-theft extortion is analyzed in Ransomware and the Payment Decision: OFAC Sanctions, Reporting Duties, Insurance, and Negotiating With Attackers, and the first two weeks of response are in Responding to a Ransomware Attack: A Practical Guide for the First Two Weeks.

Distinguish the two emails

Go back to the opening. When something arrives, ask the questions from Part Three. Did the report arrive with the technical detail, or is the detail being held? Is there a deadline, and what does it threaten? Is the money framed as compensation for identifiable value, or for silence? Does the sender appear to have looked for this specifically in order to sell it?

If it is the first email, you are dealing with a researcher and you should engage. If it is the second, you are dealing with something else, and your next call should be to counsel and possibly to the FBI, not to your finance department.

Part Seven: Practical guidance for researchers

Condensed rules, in rough order of importance.

Look for a VDP before you touch anything. Check /.well-known/security.txt, the legacy /security.txt location, the security page, and the major bounty platforms. If one exists, read the scope and stay in it.

Take the minimum. Prove the vulnerability with the least data possible. One record beats a thousand. A screenshot of a single response beats a database dump. Every additional record increases both your exposure and the company's obligations.

Delete what you took, and document the deletion. Timestamped, with a method.

Keep contemporaneous notes. Dates, systems touched, methods used, what was accessed. You will need these whether things go well or badly, and reconstructing them later looks like reconstruction.

Stop when told to stop. A block, a revoked credential, or a written demand to cease ends any argument that further access is authorized.

Do not test third-party infrastructure. A vulnerability in a company's cloud provider, payment processor, or CDN is not that company's system to authorize.

Get advice before first contact, not after. The first email is the document that will be read most carefully if this goes wrong. Once it is sent, it cannot be unsent. This is the cheapest possible moment to involve a lawyer and the one most often skipped.

Send the technical detail. Yes, it gives up leverage. It also gives up the element that makes the conduct look criminal.

Ask for compensation in terms of value delivered. Time, release, cooperation, non-recurrence. Not silence.

Set a disclosure timeline once and do not move it. Ninety days. Stated at the outset. Unrelated to the payment discussion.

Never mention regulators, press, or customers in a message that mentions money.

If they refuse to pay, disclose anyway or do not. Both are defensible. What is not defensible is disclosing because they refused to pay, and saying so. The moment the publication is framed as retaliation for non-payment, it retroactively colors every earlier communication.

Do not build a business that scans for flaws in order to sell them. Whatever the individual letters say, the pattern is what a prosecutor will look at, and DOJ's policy names this model specifically.

Part Eight: Notes for counsel

Some observations for lawyers taking one of these on, from either side.

Get the technical facts first, in detail. You cannot assess CFAA exposure from a client's characterization. You need to know precisely what was touched and what came back. Clients minimize without meaning to, and "I just looked at it" frequently turns out to mean something quite different.

Scope the criminal analysis per target, not per project. The state where each system sits changes the answer.

Settle the client identity question before evidence reaches you. Whether the researcher is your client, someone else's client, or neither determines your duties, what is privileged, and what happens when the target asks who is behind the letter. This cannot be fixed retroactively. A lawyer who takes possession of exfiltrated data has a separate problem: it may be evidence, and holding it is not the same as holding privileged advice.

Watch your own exposure. A lawyer who sends a demand that is later characterized as extortion has an ABA Model Rule 8.4(b) problem (a criminal act reflecting adversely on fitness) and potentially a Rule 1.2(d) problem (assisting a client in criminal conduct). Many states retain a rule, descended from former Disciplinary Rule 7-105, prohibiting threats of criminal charges solely to gain advantage in a civil matter, and ABA Formal Opinion 92-363 describes the narrow conditions under which mentioning criminal exposure is permissible. Avenatti and Flatley are the cautionary tales. And a lawyer who becomes a participant in the underlying conduct becomes a fact witness, which means someone else has to try the case. The professional responsibility background is in Legal Ethics in Practice: Conflicts, Confidentiality, Fees, and the Duty of Technological Competence.

Explain the privilege limits explicitly and in writing. Clients believe privilege does more than it does, particularly around identity. Correct that early.

On the company side, separate the researcher question from the notification question. They run on different clocks and different bodies of law, and conflating them is how companies end up in the Uber posture. Run the notification analysis under privilege, through counsel who is not also negotiating with the researcher where the matter is serious enough to justify it; the structure is discussed in Conducting an Internal Investigation: Scope, Privilege, and Reporting.

Check the insurance policy before anyone pays anything. Cyber policies typically require notice and consent before an "extortion expense" is incurred, and a voluntary payment can forfeit coverage. See Directors and Officers and Cyber Insurance: Towers, Triggers, Allocation, and the Claim You Must Notice.

Consider whether the company should authorize prospectively. For a company facing repeated reports, the right advice is often to publish a VDP rather than to litigate each encounter.

Part Nine: The two emails, annotated

Abstractions are less useful than text. Here are both versions of the opening email, with the operative language marked.

The one that creates criminal exposure

We have identified a critical vulnerability in your customer portal that permits retrieval of arbitrary user records. We have not disclosed this to anyone and are prepared to keep it confidential.

We are prepared to provide full technical details upon agreement of terms. Our fee for this engagement is $25,000.

Please respond within 72 hours. If we do not hear from you, we will proceed accordingly and may be obligated to notify affected users and the relevant regulator.

Four problems, each independently serious.

"We have not disclosed and are prepared to keep it confidential" identifies silence as the thing being sold. If the sender retrieved records to find the flaw, this sentence is close to a textbook offer not "to impair the confidentiality of information obtained from a protected computer without authorization" under § 1030(a)(7)(B).

"Full technical details upon agreement of terms" conditions the company's access to the information on payment. The company cannot fix the flaw until it pays. That is the definition of leverage.

The 72-hour deadline has no relationship to remediation. Nothing can be fixed in 72 hours. It exists to create pressure.

"We will proceed accordingly" plus the reference to users and regulators is a threat to injure reputation. The passive construction and the word "obligated" fool nobody; there is no obligation, and the sentence appears in a paragraph about money.

Note that nothing in this email is impolite. Politeness is not the variable.

The one that does not

We identified a vulnerability in your customer portal permitting retrieval of user records belonging to other accounts. Full technical details, reproduction steps, and our assessment of severity are attached. We accessed a single record belonging to a test account we created, retained nothing, and have deleted our working notes; a deletion log is included.

We are providing this information to you unconditionally. We ask nothing in return for it.

Separately, we would like to discuss compensation for the approximately forty hours invested in identifying and documenting this issue, together with a mutual release, our agreement not to make further access attempts, and our assistance verifying your remediation. We are glad to discuss what that is worth to you.

We follow a standard 90-day coordinated disclosure timeline, running from today, during which we will publish nothing. That timeline is not contingent on the compensation discussion and we will not shorten it. If you need longer for remediation, tell us and we will accommodate that.

Our preferred contact is [counsel]. We have not contacted and do not intend to contact regulators, press, or your customers.

Every structural problem is inverted.

The information is delivered, not held. There is nothing left to condition.

The compensation request is explicitly severed from the disclosure and is tied to identifiable value: hours worked, a release, a covenant, and remediation assistance. A company would rationally buy those things.

The timeline is an industry norm, stated as fixed, expressly decoupled from the negotiation, and offered as extendable rather than shortenable. Offering to extend is powerful evidence of good faith, because it is the opposite of leverage.

The minimization language handles the CFAA and the notification question at once. The company learns immediately that the scope of access was one self-created test account, which is the single most useful fact in the message. A single record from the researcher's own account is not someone else's personal information, and that one sentence may take the company out of the breach notification analysis entirely.

And the final line removes the implicit threat by naming it and disclaiming it.

A company receiving the second email has a problem to fix and a commercial decision to make. A company receiving the first has an incident, and probably a call to make to the FBI.

What happens next, in the version that works

Suppose the second email went to a fictional payments company, Harrow Ledger, Inc., from a researcher named Priya Okafor, through counsel. Harrow's security team reproduces the flaw within a day. Because Okafor touched only her own test account, Harrow's privacy counsel concludes that no notification is triggered, and documents why. Harrow's general counsel replies with a neutral acknowledgment, confirms receipt of the deletion log, and proposes a payment of $6,000 under a short researcher agreement: a mutual release, Okafor's covenant not to retest outside an agreed window, her help verifying the fix, and a confidentiality period ending on the earlier of the patch date plus 30 days or the original 90-day date. Harrow screens the payee against the sanctions lists, issues the payment through accounts payable rather than the bounty platform (Harrow has no bounty program), and publishes a VDP the following month so that the next researcher does not need a lawyer to say hello. Nothing in the file would embarrass anyone in front of a regulator, a jury, or a reporter.

That outcome is ordinary. It is also unavailable to the sender of the first email, no matter how the negotiation goes.

Common mistakes

Researchers "proving severity" by downloading data. The extra records add nothing to the technical case, multiply the company's notification burden, and turn a § 1030(a)(2) question into a potential § 1030(a)(7)(B) one.
Holding back the proof of concept as leverage. It is the single fact that most often converts a disclosure into a demand.
Mentioning "the regulator" in the same message as a price. Even framed helpfully, it reads as the threat that § 875(d) and § 873 describe.
Companies firing off an accusatory letter before verifying. It is often wrong on the facts and almost always worse on the optics.
Companies treating a payment as the end of the notification analysis. It is not; the clocks were already running.
Routing a payment to an intruder through the bounty program. This is the Uber fact pattern, and the label invites the inference of concealment.
Lawyers drafting the demand without first learning what was accessed. The lawyer's letter becomes the government's exhibit, and the privilege may not hold.

Frequently asked questions

Is it illegal to ask a company for a bug bounty when it does not have a bounty program? No. Asking for compensation is lawful. What matters is whether the request is conditioned on silence, tied to a threat, or framed as payment for value delivered after unconditional disclosure.

Does the DOJ good-faith research policy protect me if I get sued? No. It is a federal charging policy. It does not bind state prosecutors, does not bind civil plaintiffs, and expressly excludes research conducted to extort the system owner.

Did Van Buren make all security research legal? No. It held that someone authorized to access particular information does not "exceed authorized access" by using it for an improper purpose. It did not address access "without authorization," which covers most exploitation of authentication or access-control flaws.

Can a company retroactively authorize my access by paying a bounty? Do not count on it. In the Uber case the Ninth Circuit held that post hoc authorization through a nondisclosure agreement could not launder the intruders' unauthorized access.

Is a 90-day disclosure deadline a threat? Not if it is a fixed coordinated-disclosure timeline that runs regardless of payment and can be extended for remediation. It becomes leverage when it is shortened, lengthened, or otherwise tied to the money.

Can my lawyer keep my identity secret? Counsel can negotiate without naming you, but identity is generally not privileged, and the crime-fraud exception can open the file if the demand is treated as extortion. Plan for identity to become an issue at the release stage.

If a researcher accessed our customers' data, do we have to notify? Possibly. State breach statutes, sectoral rules, contracts, and securities rules each have their own triggers and clocks. A researcher's good intentions do not change whether personal information was acquired by an unauthorized person.

Should we pay someone who stole our data and is calling it a bounty? Treat it as an extortion event, not a bounty. Involve counsel, law enforcement, and your insurer, run a sanctions screen, and analyze notification separately. A payment does not end the legal analysis.

The uncomfortable middle

I want to close by acknowledging something the tidy version of this article obscures.

The law here is genuinely bad. It criminalizes conduct that improves security, it turns on a word Congress never defined, and it leaves the people doing socially useful work dependent on prosecutorial discretion and a charging policy that any administration can revise. Researchers who follow every rule can still be sued. Companies that respond reasonably can still find themselves in a regulatory mess. The DOJ policy helped and did not fix it. Reform proposals have been circulating for a decade without result.

Within that mess, the practical advice is nevertheless stable, because the things that make conduct look like extortion are consistent and largely within a researcher's control. Disclose regardless of payment. Ask for compensation tied to value. Do not use the timeline as a lever. Take as little data as possible. Write the first email as though a prosecutor will read it, because if things go wrong that is exactly who will read it.

And for companies: publish a policy, respond like adults, and never try to make a reportable incident disappear with a payment and a nondisclosure agreement. The most expensive outcome in this entire area of law was not caused by a hacker. It was caused by the response.

Key takeaways

The access question (CFAA, state statutes, § 1201) and the demand question (Hobbs Act, § 875(d), § 1030(a)(7), § 873, state extortion law) are separate. A clean finding can be ruined by a bad email, and a careful email cannot cure unlawful access.
Deliver the technical detail unconditionally, then discuss compensation separately, for hours, a release, a covenant, and retest help.
Fix the disclosure timeline at the outset and never move it in response to money.
Keep regulators, press, and customers out of any message that mentions payment.
Companies should verify before characterizing, run notification analysis on its own clock, screen and document any payment, and never use an NDA or bounty label to make an incident disappear.
Publish a VDP with a real safe harbor. It is the cheapest way to make the second email rarer.

Working through one of these

This is the kind of matter I handle, and the engineering background is usually why people call. Assessing whether a particular access was authorized, whether the data retrieved crosses a notification threshold, or whether a report describes a real vulnerability at the severity claimed requires reading the technical material directly rather than through someone else's summary.

If you are a researcher deciding how to make first contact, the time to get advice is before you send anything. If you are a company holding a message you cannot categorize, the first question is not what to pay. It is what actually happened, and whether you have obligations that started running the moment you read it. For the first hours of that analysis, see Responding to a Data Breach: The First Seventy-Two Hours.

This document is general information about the law, current as of its last modification date, not legal advice for any particular situation, and reading it does not create an attorney-client relationship. Computer crime law is unsettled, varies significantly by state, and turns heavily on specific facts.