Is Ethical Hacking Legal? Authorization, the CFAA and 3 Ways It Is Not

Last updated: August 2026. Written by Josh Hutcheson, OnlineCourseing editor. See our review methodology.

QUICK ANSWER

The short answer

Ethical hacking is legal when it is authorized. That sounds circular, and it is worth sitting with, because it is the whole of the answer: there is no technical act that is inherently “ethical hacking” rather than “hacking”. Running a port scan, exploiting a vulnerability, extracting credentials — the actions are identical whoever performs them. The law does not distinguish between them on the basis of your skill, your intentions, or what you planned to do with the findings.

It distinguishes on authorization. A penetration tester with a signed statement of work is doing their job. The same person doing the same things to the same systems the week before the contract was signed has committed an offense. The paperwork is not bureaucracy around the work — it is the thing that makes the work lawful.

The laws that actually apply

Most articles on this topic gesture at “computer crime laws” without naming them. Here are the two that matter most for English-speaking readers, with links so you can read the text rather than take anyone’s summary.

United States: the Computer Fraud and Abuse Act

The CFAA is codified at 18 U.S.C. § 1030, titled “Fraud and related activity in connection with computers”. Its core concepts are accessing a computer without authorization or exceeding authorized access — and that second phrase is the one that catches security people. You can be authorized to test one system and commit an offense by pivoting to another.

The Department of Justice’s own guidance for prosecutors lives at Justice Manual 9-48.000. It is readable, and it is the closest thing to an official statement of how the CFAA is actually enforced.

Note also that the CFAA is federal. US states have their own computer-crime statutes, and conduct declined for federal prosecution can still be charged at state level — a distinction that catches people who read only about the CFAA.

United Kingdom: the Computer Misuse Act 1990

The Computer Misuse Act 1990 is stricter than many people expect. Its first offense is unauthorized access to computer material — and it is committed on access alone. You do not need to have caused damage, extracted data, or intended anything further. Simply accessing a system you were not authorized to access is the offense.

This is why the “I was only looking” defense fails in the UK. It is also why the UK security industry has campaigned for years for a statutory defense for legitimate research — the Act predates the profession it now governs.

Elsewhere

Most jurisdictions have close analogues, and the Council of Europe’s Budapest Convention on Cybercrime has driven a good deal of similarity across signatory countries. Data-protection law is a second, separate layer: if your testing touches personal data, regimes such as the GDPR apply independently of any computer-misuse offense, and your engagement paperwork should say how that data is handled.

The DOJ good-faith security research policy — and its limits

This is the part most guides to this question miss entirely, and it matters if you do security research in the United States. The Justice Manual instructs federal prosecutors, in its own words:

The Manual then adopts a specific definition. Good-faith security research means “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 systems concerned or their users.

And it draws the boundary explicitly. Research conducted “for the purpose of discovering security holes in devices, machines, or services in order to extort the owners”, the Manual says, “might be called ‘research,’ but is not in good faith.”

Now the limits, which matter more than the policy itself. This is a charging policy, not a legal exemption. It directs the discretion of federal prosecutors; it does not make unauthorized access lawful, and it does not amend the statute. Three consequences follow, and none of them is optional reading:

• It does not bind state prosecutors. State computer-crime laws are separate and are enforced separately.
• It does not prevent civil action. An organization can sue you regardless of whether anyone charges you, and defending a civil claim is ruinous even when you win.
• Policy can change. A charging policy is an internal instruction that a future administration can revise. Authorization is durable in a way that discretion is not.

Read the policy as meaningful reassurance that the federal government does not want to prosecute genuine researchers — and not at all as permission to test systems you have no authorization to touch.

White hat, gray hat, black hat

The color-coded categories are useful shorthand, but only one of the three lines is a legal line. The distinction that matters is authorization, and gray is not a legal status — it is a description of intent that the law does not recognize.

The row worth staring at is the middle one. Gray-hat hacking is not a lesser offense — legally it sits with black hat. Finding a flaw in a stranger’s system and reporting it kindly is still unauthorized access under both the CFAA and the Computer Misuse Act. Intent may influence a charging decision or a sentence; it does not change whether an offense occurred. We look at the categories more fully in hacking vs ethical hacking.

Three situations where “ethical” hacking is still illegal

These are the cases that surprise people, because in all three the tester genuinely was authorized. Authorization is not a blanket permission — it is bounded, and stepping outside the bounds ends the protection it gave you.

1. You expose confidential information

Testing frequently gives you access to customer records, credentials, financial data or internal documents. Being authorized to find that exposure is not authorization to retain it, publish it, discuss it publicly, or extract more than you needed to demonstrate the finding. Data-protection law applies independently here, and a breach of confidentiality can be a contractual and a regulatory matter as well as a criminal one.

In practice: extract the minimum needed to prove the vulnerability, store evidence per the engagement’s data-handling terms, and destroy it when the engagement ends.

2. You alter, destroy or misuse data

Permission to test is rarely permission to modify. Deleting records to prove you could, taking a production service down to demonstrate a denial-of-service condition, or writing files to a host beyond what the scope allows can all exceed your authorization — and impairing data or operations is a separate, more serious offense under the Computer Misuse Act.

In practice: this is why rules of engagement specify destructive testing explicitly, and why tools with aggressive options need their flags understood before they are pointed at anything.

3. You leave access behind

Establishing persistence is a normal part of a red-team engagement — and every implant, account and backdoor must be documented and removed at the end. Access retained past the testing window is unauthorized access, whatever it was during it. Forgetting is not a defense, and “I meant to clean it up” is a description of the offense rather than an excuse for it.

In practice: keep a written inventory of everything you place on a client system, and reconcile it to zero before you sign off.

The gray areas people actually get caught by

• Unsolicited disclosure. You noticed a flaw in a company’s site and want to tell them. Reporting it is decent; the testing that found it was unauthorized access. Organizations have prosecuted people who reported in good faith, and a disclosure email is an admission with a timestamp. If a company publishes a vulnerability disclosure policy, that policy is your authorization — if it does not, you have none.
• Out-of-scope bug bounty testing. A program’s scope document is a legal boundary. Assets outside it are not covered by the program’s authorization, and “it was on the same domain” is not a scope definition.
• Scope drift mid-engagement. You find a route from an in-scope host into an out-of-scope one. That pivot is exactly the “exceeding authorized access” language in the statute. Stop and get the scope extended in writing.
• Testing your employer without sign-off. Working in IT is not authorization to test security. Get it from someone with authority to give it, in writing, before you scan anything.
• Authorization from the wrong person. A manager who does not own the system, or a client who does not own the infrastructure they asked you to test — cloud and hosted environments frequently belong to a third party whose own testing policy applies.

What a lawful engagement looks like

Before any tool runs, a professional engagement has all of this in writing:

• A signed statement of work naming the client and the engagement.
• A scope document listing exactly which IP ranges, domains, applications and accounts are in and out of bounds.
• An agreed testing window.
• Named emergency contacts on both sides, reachable during that window.
• Explicit rules on destructive testing, social engineering and physical access.
• Data-handling terms: what you may extract, how it is stored, when it is destroyed.
• Confirmation that the signatory has authority over the assets — including any hosting provider’s testing policy.

Insisting on that paperwork is part of the craft, not an obstacle to it. Our penetration testing methodology guide covers how the frameworks structure an engagement around it.

How to practice legally

You never need to touch a system you do not have permission to touch, at any point in learning this field. The lawful options are good ones:

• Your own lab. A few virtual machines on an isolated virtual network. Free, unlimited, and building it teaches you as much as attacking it.
• TryHackMe and Hack The Box. Purpose-built targets you are explicitly authorized to attack, both with free tiers.
• In-scope bug bounty programs. Real systems, real authorization — strictly within the published scope.
• Capture-the-flag competitions. Authorized by design, and good for building a public record of ability.

If you are starting out, our guides to ethical hacking courses and penetration testing courses cover the training, and ethical hacking tools and Kali Linux tools cover the kit.

Reporting a flaw without exposing yourself

This is the situation readers actually find themselves in, and it deserves more than a warning. You have noticed something — an exposed directory, an error message leaking internals, a login that behaves oddly — and you want to do the right thing. The uncomfortable truth is that doing the right thing carries risk, and the sequence you follow changes how much.

First, check whether they have invited you. Look for a vulnerability disclosure policy (often at /security or linked from the footer), a /.well-known/security.txt file — the conventional location for a machine-readable security contact — or a listed bug bounty program. Any of these is an invitation, and its terms are your authorization. A published policy typically also commits the organization not to pursue researchers who follow it, which is precisely the protection you want in writing before you send anything.

If there is no policy, stop and think before you probe further. The single biggest mistake is treating an accidental discovery as a license to investigate it properly. Confirming the extent of a flaw — enumerating what else is exposed, testing whether you can go deeper — converts an accident into deliberate unauthorized access, and it is the step that turns a sympathetic story into a chargeable one.

If you do report without a policy in place, keep it minimal and factual: what you observed, when, and the least detail necessary for them to reproduce it. Do not include data you extracted. Do not attach a screenshot of someone else’s records. Do not follow up with a request for a reward — the DOJ’s own definition explicitly carves out research done in order to extort, and a payment request after an unsolicited disclosure can be read that way even when nothing of the sort was meant.

And if the flaw is serious, involves personal data, or the organization reacts badly — take legal advice before saying anything further. That is not paranoia; researchers who reported in good faith have been threatened, and the moment to get advice is before the second email rather than after.

What happens if you get it wrong

People imagine the risk is prosecution. Prosecution is the least likely and least common outcome — and concentrating on it obscures the three consequences that actually befall people:

• Losing your job, and the next one. Testing an employer’s systems without sign-off is a dismissal offense at most organizations regardless of what you found or intended. Security is a small industry with long memories, and this is the most common career-ending mistake in it.
• Civil liability. An organization can sue you whether or not any prosecutor is interested. Defending a civil claim is expensive even when you are entirely in the right, and the cost lands on you long before any judgment does.
• Criminal exposure. Real, but usually reserved for conduct involving damage, data theft, extortion or persistence. It is the tail risk rather than the typical one — which is exactly why people underrate the first two.

There is also a quieter professional dimension. Working testers generally operate through a firm that carries professional indemnity insurance and signs the client contract, and that structure exists because individual liability on an engagement is a genuine risk rather than a theoretical one. If you are ever asked to test something as an individual, on a handshake, understand that you are personally carrying everything the paperwork would otherwise have carried for you.

Why organizations authorize this at all

Three reasons, and they explain why the profession exists as a lawful one. First, finding flaws before an attacker does — a vulnerability discovered under contract costs a fee; the same one discovered by a criminal costs an incident. Second, assurance during development, where testing a system before it ships is far cheaper than remediating it afterwards. Third, compliance: a range of regulatory and contractual regimes require periodic independent testing, which is why “we need a pen test for our audit” is one of the commonest reasons a firm is engaged at all.

If you are commissioning a test rather than performing one

A fair number of people asking whether this is legal are on the buying side — asked to approve a penetration test and wanting to know what they are authorizing. The same principles apply in reverse, and a few checks protect you as much as they protect the tester:

• Confirm you actually have authority to authorize it. If the systems are hosted, your provider’s testing policy applies alongside your own permission, and some require advance notice. Signing for infrastructure you do not own does not make the testing lawful.
• Define scope narrowly and in writing. Vague scope is the source of nearly every dispute — and of the accidental outage that gets blamed on the tester.
• Agree data handling up front. What may be extracted, how it is stored, when it is destroyed. If personal data is in play, this is a data-protection obligation, not a preference.
• Ask about insurance. A reputable firm carries professional indemnity cover. An individual working on a handshake usually does not.
• Name contacts and a window. Your own monitoring team should know a test is happening, or you will pay for an incident response to your own engagement.

Frequently asked questions

Is ethical hacking legal?

Yes, when it is authorized. The techniques are identical to criminal hacking, so what makes it lawful is documented permission from someone with authority over the systems, and staying inside the agreed scope. Without authorization, the same actions are offenses under the Computer Fraud and Abuse Act in the US and the Computer Misuse Act 1990 in the UK.

Can I be prosecuted if I had good intentions?

Yes. Good intent is not a defense to unauthorized access. Under the UK Computer Misuse Act the offense is committed on access alone, without any damage or further intent. In the US, DOJ policy directs federal prosecutors to decline genuine good-faith security research — but that is prosecutorial discretion, not a legal exemption, and it does not bind state prosecutors or prevent civil claims.

Is gray-hat hacking illegal?

Yes. Gray hat describes intent, not a legal status. Testing a system without authorization is unlawful whether or not you plan to report what you find. Intent may affect a charging decision or a sentence; it does not change whether an offense was committed.

I found a vulnerability on a website by accident. Can I report it?

Check whether the organization publishes a vulnerability disclosure policy or a security.txt file — if so, that is your route and, within its terms, your authorization. If it does not, understand that any testing you did was unauthorized and that a disclosure is a timestamped admission. People reporting in good faith have been pursued. Take legal advice before disclosing anything sensitive.

Does a bug bounty program make testing legal?

Within its published scope, yes — that scope is the authorization. Outside it, no. Assets not listed are not covered, and testing them is unauthorized access even though the organization runs a program. Read the scope document as a legal boundary rather than a suggestion.

Can I test my employer’s systems?

Only with written authorization from someone with authority to grant it. Employment, and even administrator access, is not authorization to conduct security testing. This is a common and career-ending mistake — the fact that you had credentials makes the “exceeding authorized access” analysis worse, not better.

Is it legal to use hacking tools like Kali Linux or Metasploit?

Downloading and running them is lawful in most jurisdictions — they are standard professional software. What matters is what you point them at. Note that some jurisdictions do have offenses relating to supplying or possessing tools with intent that they be used in an offense, so intent can matter to the tooling question as well as the target.

Do I need certification to do this legally?

No. There is no license requirement for penetration testing in the US or UK, and no certification makes unauthorized testing lawful. Certifications such as OSCP+ and Security+ affect employability, not legality. Authorization is the only thing that changes your legal position.

Related: Once you have written authorization, our web application penetration testing checklist sets out what to test, area by area, following the OWASP Web Security Testing Guide.

Related guides

• Password hacking techniques — where recovering someone else’s password sits in law
• Website hacking techniques — the 15 attacks these laws actually apply to
• Hacking vs ethical hacking — the categories in full
• Penetration testing methodology — how a scoped engagement is structured
• Best ethical hacking courses and penetration testing courses — how to learn this properly
• Ethical hacking tools and Kali Linux tools — the professional toolkit
• Hacking terms — the vocabulary these legal distinctions rest on
• Best cyber security courses — the wider field
• Best cybersecurity certifications — what actually affects employability