Is Ethical Hacking Legal? Authorisation, 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 authorised. 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 authorisation. 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 offence. 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 authorisation or exceeding authorised access — and that second phrase is the one that catches security people. You can be authorised to test one system and commit an offence 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 offence is unauthorised 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 authorised to access is the offence.

This is why the “I was only looking” defence fails in the UK. It is also why the UK security industry has campaigned for years for a statutory defence 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 offence, 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 unauthorised 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 organisation 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. Authorisation 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 authorisation to touch.

White hat, grey hat, black hat

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

The row worth staring at is the middle one. Grey-hat hacking is not a lesser offence — legally it sits with black hat. Finding a flaw in a stranger’s system and reporting it kindly is still unauthorised 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 offence 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 authorised. Authorisation 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 authorised to find that exposure is not authorisation 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 authorisation — and impairing data or operations is a separate, more serious offence 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 unauthorised access, whatever it was during it. Forgetting is not a defence, and “I meant to clean it up” is a description of the offence 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 grey 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 unauthorised access. Organisations 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 authorisation — if it does not, you have none.
• Out-of-scope bug bounty testing. A programme’s scope document is a legal boundary. Assets outside it are not covered by the programme’s authorisation, 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 authorised access” language in the statute. Stop and get the scope extended in writing.
• Testing your employer without sign-off. Working in IT is not authorisation to test security. Get it from someone with authority to give it, in writing, before you scan anything.
• Authorisation 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 practise 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 authorised to attack, both with free tiers.
• In-scope bug bounty programmes. Real systems, real authorisation — strictly within the published scope.
• Capture-the-flag competitions. Authorised 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 programme. Any of these is an invitation, and its terms are your authorisation. A published policy typically also commits the organisation 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 licence 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 unauthorised 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 organisation 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 offence at most organisations 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 organisation 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 organisations authorise 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 authorising. 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 authorise 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 authorised. 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 authorisation, the same actions are offences 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 defence to unauthorised access. Under the UK Computer Misuse Act the offence 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 grey-hat hacking illegal?

Yes. Grey hat describes intent, not a legal status. Testing a system without authorisation 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 offence was committed.

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

Check whether the organisation publishes a vulnerability disclosure policy or a security.txt file — if so, that is your route and, within its terms, your authorisation. If it does not, understand that any testing you did was unauthorised 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 programme make testing legal?

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

Can I test my employer’s systems?

Only with written authorisation from someone with authority to grant it. Employment, and even administrator access, is not authorisation to conduct security testing. This is a common and career-ending mistake — the fact that you had credentials makes the “exceeding authorised 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 offences relating to supplying or possessing tools with intent that they be used in an offence, 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 licence requirement for penetration testing in the US or UK, and no certification makes unauthorised testing lawful. Certifications such as OSCP+ and Security+ affect employability, not legality. Authorisation is the only thing that changes your legal position.

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