Ethical hacking is legal in the United States when the person doing it has written permission from someone with authority over the target systems and stays inside the boundaries that permission sets. Everything else — your intentions, your skills, your certifications, the fact that the company would probably thank you if you found something — is legally beside the point. The Computer Fraud and Abuse Act treats unauthorized access as a federal crime whether you meant harm or not, so the question of when ethical hacking is legal comes down to three things: documented authorization, a defined scope, and conduct that stays inside both.
The Federal Law That Draws the Line
The Computer Fraud and Abuse Act, codified at 18 U.S.C. § 1030, is the statute that governs computer access in the United States. It criminalizes intentionally accessing a computer without authorization and intentionally exceeding the authorization you were given.1Office of the Law Revision Counsel. 18 USC 1030 – Fraud and Related Activity in Connection With Computers
The reach is enormous. A “protected computer” under the statute is any computer used in or affecting interstate or foreign commerce, which in practice means every internet-connected device in the country.1Office of the Law Revision Counsel. 18 USC 1030 – Fraud and Related Activity in Connection With Computers Scanning a company’s servers, probing a web application, mapping a network — all of it falls inside the CFAA’s scope. Intent is not a defense. A well-meaning test on a system you weren’t invited onto is still a federal offense.
What Real Authorization Looks Like
Authorization is the single thing that separates a legitimate security engagement from a crime. The same person running the same scans on the same systems is either doing legal work or committing a federal offense depending on whether the paperwork exists.
In practice, authorization means a written penetration testing agreement, sometimes called a rules-of-engagement document. A workable agreement identifies which systems, networks, and applications are in scope, which testing methods are permitted, the timeframe of the engagement, and how discovered vulnerabilities will be reported. Those details are not administrative window dressing. They are the legal boundary of the engagement, and anything you do outside them counts as unauthorized access.
Permission also has to come from someone who can actually give it. A department manager who signs off on testing infrastructure they don’t control has not given valid authorization. If the target uses third-party services — cloud providers, hosted applications, content delivery networks — you may need separate permission from each of them before touching that portion of the environment. Engagements get complicated fast at these seams, and skipping the paperwork here is where ethical hackers most often cross into criminal territory.
Scope and the Meaning of “Exceeds Authorized Access”
The CFAA covers two kinds of conduct: accessing a computer without authorization at all, and exceeding the access you were given. The second category is the one that most often catches security testers, and the Supreme Court sharpened its meaning in 2021.
In Van Buren v. United States, the Court held that someone exceeds authorized access when they enter areas of a computer that are off-limits to them — specific files, folders, or databases they were not supposed to reach — rather than when they misuse information they were entitled to see in the first place.2Supreme Court of the United States. Van Buren v. United States, 593 U.S. 374 (2021) The Court described this as a “gates-up-or-down” framework: either you were allowed into a given part of the system or you weren’t.
For ethical hackers, the practical implication is straightforward. Van Buren narrowed the government’s ability to argue that a tester “exceeded” access simply by using a system in an unintended way. It did not eliminate the risk. If your agreement authorizes testing a company’s public web application and you pivot into an internal database that was never in scope, you have walked through a gate that was down. That still violates the statute.
What the Penalties Look Like
CFAA penalties scale with the severity of the conduct and whether the defendant has prior convictions. A first offense for accessing a protected computer without authorization and obtaining information carries up to one year in prison.1Office of the Law Revision Counsel. 18 USC 1030 – Fraud and Related Activity in Connection With Computers That ceiling rises to five years if the access was for commercial gain, furthered another crime, or involved information worth more than $5,000. A second conviction for the same category of offense doubles the maximum to ten years.
More serious conduct carries steeper exposure:
- Accessing a computer to further fraud: up to five years for a first offense, ten for a repeat.
- Intentionally damaging a computer: up to ten years for a first offense, twenty for a repeat.
- Accessing national security information: up to ten years for a first offense, twenty for a subsequent conviction.
Federal charges are only part of the picture. Most states have their own computer crime statutes, and the CFAA itself lets private parties sue for damages when they suffer loss from unauthorized access.1Office of the Law Revision Counsel. 18 USC 1030 – Fraud and Related Activity in Connection With Computers A tester who avoids criminal prosecution can still be dragged into civil court by the company whose systems they touched.
The DOJ’s Good-Faith Security Research Policy
In May 2022, the Department of Justice revised its CFAA charging policy to address ethical hacking directly. The policy tells federal prosecutors to decline prosecution when the available evidence shows the conduct consisted of, and was intended as, good-faith security research.3U.S. Department of Justice. 9-48.000 – Computer Fraud and Abuse Act
The DOJ defines good-faith security research as accessing a computer solely to test, investigate, or correct a security flaw, in a manner designed to avoid harm to individuals or the public, with the findings used primarily to improve the security of the devices or services involved.3U.S. Department of Justice. 9-48.000 – Computer Fraud and Abuse Act Discovering vulnerabilities to extort a system owner does not qualify, whatever label the person attaches to it.
Two limits matter. First, this is a prosecutorial guideline, not a change to the statute. The CFAA still reads the way it always did, and a prosecutor who disagrees with your characterization of your work can still bring charges. Second, the policy does nothing to stop private civil lawsuits under the same statute. Treat it as a meaningful layer of protection, not a shield.
Bug Bounty Programs
Bug bounty programs are one of the cleanest legal frameworks for security testing. A company publishes a vulnerability disclosure policy inviting researchers to test named systems and report flaws, usually in exchange for payment. Platforms like HackerOne and Bugcrowd formalize the arrangement, but the legal protection turns on the specific terms of each program.
Typical program rules require researchers to stay within the published scope, avoid causing damage to systems or data, avoid social engineering and physical attacks, and keep discovered vulnerabilities confidential until they are fixed. Break any of those conditions and you can lose the protection the program was supposed to provide.
Some companies include explicit safe harbor language in their disclosure policies, promising not to pursue legal action against researchers who follow the rules. That language matters because it operates as a contractual defense on top of the DOJ’s prosecutorial discretion. Only a small fraction of bug bounty programs currently include safe harbor terms that align with DOJ guidelines and cover both the CFAA and the DMCA. Without that language, you are relying on goodwill and prosecutorial restraint.
The DMCA Runs Alongside the CFAA
The Digital Millennium Copyright Act creates a second, independent legal risk. Section 1201 of the DMCA prohibits circumventing technological measures that control access to copyrighted works, and software is copyrighted. Testing that involves bypassing DRM, access controls, or authentication mechanisms protecting software can trigger DMCA liability on top of any CFAA exposure.
Section 1201(j) provides a narrow exemption for security testing. To qualify, the testing must be done solely to conduct good-faith investigation or correction of a security flaw, and it must be authorized by the owner or operator of the computer. Any information uncovered has to be used to promote security, not to enable copyright infringement.4Office of the Law Revision Counsel. 17 USC 1201 – Circumvention of Copyright Protection Systems
The Copyright Office has issued a broader rulemaking exemption allowing circumvention on lawfully acquired devices, or on computer systems with the owner’s authorization, solely for good-faith security research conducted in a way that avoids harm to individuals or the public.5Federal Register. Exemption to Prohibition on Circumvention of Copyright Protection Systems for Access Control The rulemaking is explicit that qualifying for the DMCA exemption does not protect you from liability under other laws, including the CFAA. The two statutes operate independently, and lawful testing has to satisfy both.
How to Keep an Engagement Legal
The legal protections that make ethical hacking possible are real but conditional. Every one of them depends on getting the paperwork right and staying inside its boundaries.
- Get written authorization before you touch anything. A verbal go-ahead from your contact is not enough. The contract should name the parties, describe the systems in scope, list permitted methods, and set a timeframe.
- Define the scope precisely. Ambiguity in a testing agreement is a legal risk, not a creative opportunity. If a system is not listed as in scope, treat it as off-limits.
- Confirm who has authority to authorize. The signer needs actual legal control over the systems being tested. If third-party hosting or cloud services are involved, check whether separate authorization is required from those providers.
- Document what you do. Keep detailed logs of what you tested, when, using which methods, and what you found. If anyone later questions whether you stayed in scope, those logs are your defense.
- Report through the channels the agreement specifies. Publicly disclosing a vulnerability before the owner has had time to fix it can dissolve the legal protection your engagement provided.
- Stop the moment you realize you are out of scope. Notify the client, document the incident, and wait for updated authorization before continuing. Testing systems you know you were not authorized to touch is the fastest route from a lawful engagement to a criminal one.
The distance between ethical hacking and a federal crime is narrower than most people assume. Written authorization, a defined scope, and careful documentation are the entire legal foundation the work rests on.