What Happens When You Scan Someone’s IP Without Permission in 2026 (The Law)

What the Laws Actually Say About Scanning IPs Without Permission

Let me give you the direct answer most tutorials avoid. In most jurisdictions, port scanning almost certainly constitutes “accessing” a computer system in the legal sense. The honest answer is: probably yes, legally speaking, even though security professionals often frame it as “just looking.” The Computer Fraud and Abuse Act (CFAA) in the United States prohibits accessing a protected computer “without authorisation.” Courts have interpreted this broadly — sending packets to probe a system’s services has been treated as accessing that system in several cases, even without obtaining data or exploiting any vulnerability.

In the United Kingdom, the Computer Misuse Act 1990 Section 1 prohibits causing a computer to perform a function with intent to secure access without authorisation. Port scanning causes a computer (or its network stack) to respond to probes. The intent element is debated, but the act itself fits the statutory description. Germany is arguably the strictest jurisdiction: §202c of the Strafgesetzbuch criminalises not just unauthorised access but preparing for it — including possessing or distributing tools designed for such purposes, which has broad implications for security tool possession.

Real Prosecution Cases You Should Know

The most frequently cited case in security circles is that of a Finnish security researcher who discovered a vulnerability in a hospital’s patient data system through scanning and tried to report it responsibly. Finnish prosecutors charged him with computer break-in offences. He was ultimately convicted in 2021 despite his stated responsible disclosure intent — a case that sent shockwaves through the European security research community. The conviction stood even though he had found a real vulnerability and reported it rather than exploiting it.

In the United States, the broad reach of the CFAA has resulted in prosecution of individuals who accessed systems they had some form of prior authorisation to access but exceeded the scope of that authorisation. The Aaron Swartz case — while not purely about scanning — illustrated how aggressive CFAA prosecution can be for computer access violations. Multiple civil cases have been filed by companies against security researchers who conducted port scanning as part of vulnerability research on systems not explicitly included in the company’s bug bounty programme.

The pattern across documented cases: prosecution risk is highest when (1) the target is government, healthcare, or critical infrastructure; (2) the scanning is large-scale or automated across many IP addresses; (3) scanning is followed by any access to returned services; (4) the researcher publishes findings publicly before giving the target time to respond; or (5) the researcher has prior contact with the target organisation that could be characterised as adversarial.

What nmap Technically Does — and Why It Matters Legally

A basic nmap SYN scan sends TCP SYN packets to each probed port. The target system’s TCP stack responds — SYN-ACK for open ports, RST for closed ports. nmap does not complete the TCP handshake on a SYN scan — it sends RST immediately after receiving SYN-ACK. The target system’s logs record the incoming connection attempt and the RST. From the target system’s perspective, something probed its ports.

Service version detection (-sV) sends additional probes to open ports — banner grabs, service-specific queries. OS fingerprinting (-O) sends crafted packets designed to elicit OS-specific responses. Script scanning (-sC) may send authentication probes, web requests, and other service-specific interactions. Each of these goes further than a port scan — they interact with services, not just probe connectivity. From a legal standpoint, service version detection and script execution against systems you don’t own is materially different from a basic ping sweep in terms of the depth of system interaction.

The Grey Areas — Where Risk Is Highest

Shodan searches for vulnerabilities. Using Shodan to find exposed services is generally considered legal — Shodan’s crawlers did the scanning, not you. But following up a Shodan result by connecting to the service, even to verify the vulnerability, crosses into active access of a system you don’t own. Many researchers make this mistake: “I only verified it, I didn’t exploit it.” Verification is access.

Scanning “your own” cloud IPs. Cloud providers (AWS, GCP, Azure) have strict policies against port scanning their IP ranges even for instances you own. AWS explicitly requires pre-approval for network scanning tests against AWS-hosted instances. Scanning without their approval can result in account termination and potentially CFAA issues since AWS is the owner of the infrastructure, not just the tenant.

Bug bounty adjacent scope. A company runs a bug bounty for app.company.com. You find an interesting IP address belonging to company.com that’s not listed in scope. Scanning it feels natural — it’s the same organisation. It is out of scope. If the company decides to pursue action, the bug bounty programme’s authorisation doesn’t extend to unlisted assets regardless of the organisational relationship.

The Legal Scanning Framework — 5 Safe Options

There are exactly five ways to scan a system legally: own it, have explicit written permission from the owner, be operating within a bug bounty programme’s stated scope, be using a designated practice platform (HackTheBox, TryHackMe), or be scanning a purpose-built lab system on your own isolated network. Everything outside these five categories carries legal risk that ranges from minimal (scanning your ISP’s gateway, which most ISPs implicitly permit) to significant (scanning government infrastructure, healthcare systems, or financial institutions).

Bug Bounty Scanning Rules

Bug bounty programmes provide the most accessible path to legal security testing for researchers who don’t yet have professional penetration testing contracts. But bug bounty authorisation has precise limits that many researchers misunderstand. The authorisation extends only to assets explicitly listed in the programme’s scope section — not the company’s entire IP space, not related subsidiaries unless listed, not services running on unlisted ports on listed domains.

Many programmes explicitly restrict scanning in their rules: “no automated scanning,” “no port scanning beyond standard web ports,” “no scanning of IP addresses not in the explicit scope list.” These restrictions exist because aggressive scanning affects service availability for other users and triggers alerts that cost the company investigation time. Violating a programme’s scanning restrictions doesn’t necessarily create legal liability, but it can result in being banned from the programme and invalidation of any findings you submit.

The practical conclusion is this: if you scan an IP you don’t control, you are almost certainly committing a technical legal violation somewhere in the chain of statutes that apply — the CFAA in the US, the Computer Misuse Act in the UK, the IT Act in India. Whether that violation is prosecuted depends entirely on who you scanned, what you did with the results, and whether you caused any disruption. Prosecution of passive port scans of public internet infrastructure is rare. It happens. Know the law in your jurisdiction, get authorisation in writing for everything you test professionally, and never scan systems you don’t have explicit permission to access.