What's legal. What is not.
The single difference between a paid security professional and someone with a federal indictment is authorization. Read this page before you touch any computer that isn't yours.
None of what follows is legal advice. It is publicly documented context. If you have a specific situation, talk to a lawyer · the Electronic Frontier Foundation has a referral list at eff.org.
The Computer Fraud and Abuse Act · in 60 seconds
The CFAA (18 U.S.C. § 1030) is the main US federal anti-hacking statute, passed 1986 and amended multiple times since. The core prohibition is accessing a “protected computer” (interpreted very broadly · almost any computer connected to the internet) without authorization or exceeding authorized access.
Penalties range from misdemeanor up to 20 years federal prison (and life in limited cases involving threats to national security or causing death). The statute is also used to bring civil suits.
The federal courts have read the “authorization” concept differently across circuits for two decades. The 2021 Supreme Court decision in van Buren v United Statesnarrowed the “exceeds authorized access” reading — the Court held that you don't exceed authorized access just because you misuse data you were authorized to view (the case involved a police officer running a license-plate lookup for personal reasons). But the “without authorization” prong remains broad, and bypassing technical access controls — even trivially — is squarely covered.
Three real cases · learn from them
van Buren v United States (2021)
Police officer used his authorized access to a license-plate database to look up a plate in exchange for money. The Supreme Court reversed his CFAA conviction · ruled that misusing data you're authorized to access is not “exceeding authorized access.” This is the most security-research- friendly CFAA ruling in decades. It does NOT legalize accessing things you weren't authorized to access in the first place.
Marcus Hutchins (2017-2019)
The security researcher who accidentally stopped the WannaCry ransomware outbreak in 2017 was arrested by the FBI at DEF CON months later for the pre-2015 creation of two banking malware tools. He pled guilty to two CFAA counts in 2019 and received time served + supervised release. The lesson: what you wrote when you were 17 follows you forever in this field. The FBI archives.
Aaron Swartz (2013)
Programmer and activist who downloaded ~5 million academic articles from JSTOR through MIT's network. Charged under CFAA (and wire fraud) with potential 35 years prison + $1M fine. Died by suicide before trial in 2013. His case became the canonical example of CFAA overreach against activist / researcher conduct and led to the 2013-2024 reform debate.
The DOJ's 2022 charging policy update
In May 2022, the US Department of Justice announced a policy revision: federal prosecutors would no longer charge good-faith security research under the CFAA. The policy defines good-faith security research as accessing a computer solely for purposes of good-faith testing, investigation, or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid harm to individuals or the public, and where the information derived is used primarily to promote the security or safety of the class of devices, machines, or services to which the accessed computer belongs.
This is a charging-discretion policy, not a change in the statute itself. Civil suits and state-level prosecutions are not affected by it. State computer-crime statutes (like California Penal Code 502) are still in play.
Read it yourself: DOJ press release · 2022-05-19.
How to stay clearly inside the line
- 01Only attack what you're explicitly authorized to attack.“Authorized” means: you own it, or you have written permission from the owner, or the system is a designated lab / CTF / bug-bounty-scope target with a published authorization document.
- 02Read the scope every single time. A bug bounty program's scope is a binding document. If it says “in scope: *.example.com except for example.com/admin” then example.com/admin is not authorized. Hitting it is a CFAA violation even if you reported the bug.
- 03Stay within your test plan. Authorization to test for one thing is not authorization to test for everything. If you find a vuln in a system you weren't supposed to be on, stop, document, report through the proper channel · do not pivot.
- 04Don't exfiltrate data you don't need.Proof of access is generally fine (a screenshot of the admin page, the database schema). Downloading the actual customer records is not fine. The closer your proof-of-concept stays to “here's the vulnerability,” the safer you are.
- 05Document everything in real time. Date · time · scope you were testing · steps you took · what you found · what you did with it. If a question comes up six months later, this notebook is your defense.
- 06If a company doesn't have a vulnerability disclosure program, ask before you test. Email
security@the domain. Save the email. If they don't respond, do not proceed. - 07Hire a lawyer before you ever talk to federal investigators. If the FBI contacts you for any reason related to your security work · do not answer questions, even friendly ones. Get an attorney. The Electronic Frontier Foundation maintains a list of security-research-friendly lawyers.
Things people think are legal but aren't
- ○Port-scanning your neighbor's router because their wifi is open. Their open wifi is not your authorization.
- ○Using a default password to log into something. Even if the password is “admin/admin” — bypassing access control is unauthorized access. You have to be authorized to use the credential.
- ○“Borrowing” your school's wifi to scan internal hosts. Schools tend to have explicit acceptable-use policies that this violates, and the state computer-crime statutes apply on top of FERPA.
- ○Continuing to test a bug bounty target after the company has revoked your access. Companies can withdraw authorization at any time. The moment your account is banned, your authorization is gone.
- ○Posting credentials or token dumps you found in a public S3 bucket. Even if the bucket was publicly readable, posting the credentials is a separate criminal exposure under federal and state law.
- ○“Pen-testing” an ex's social media account. This is unauthorized access regardless of relationship history. Don't.
Safe harbor: the Vulnerability Disclosure Policy
The single best tool to operate safely is a published Vulnerability Disclosure Policy (VDP). If a target organization publishes a VDP, they've effectively pre-authorized good-faith research within the scope of the VDP.
The Cybersecurity and Infrastructure Security Agency (CISA) requires every US federal civilian agency to maintain a VDP (per Binding Operational Directive 20-01). The Department of Defense maintains a VDP at hackerone.com/deptofdefense. You can legally find and report vulnerabilities in DoD-controlled .mil systems within that scope. People have built careers off DoD VDP submissions.
CISA publishes a model VDP template at cisa.gov that companies can adopt. If you're testing a company without a published VDP, you have less legal cover · proceed only with explicit written permission.
Resources to keep on hand
- · EFF · Coders' Rights Project — legal resources for researchers
- · disclose.io — open-source VDP templates and a directory of organizations that publish them
- · CISA Binding Operational Directive 20-01 — what US federal agencies must publish
- · DOJ Computer Crime and Intellectual Property Section — the federal prosecutors who would handle a CFAA case
- · State law varies a lot. California Penal Code 502, Texas 33.02, NY Penal Law 156, etc. Look up your state.
The career path is real. It is well-paid. It is increasingly important to the country. It is also one of the few professional fields where a single bad weekend when you are 19 can become a federal indictment that follows you into your 40s. The rule is simple: stay inside authorization, keep documentation, never assume friendliness from federal investigators, and ask first when in doubt.