"Isn't port scanning illegal?" is one of the most common questions from anyone starting out in network security — and the honest answer is: it depends entirely on one thing, and it isn't the tool you're using.
Same tools, opposite outcomes
A port scanner, a vulnerability scanner, a packet sniffer — the exact same software runs in a Fortune 500 company's authorized annual security assessment and in an attacker's reconnaissance before a breach. Nmap doesn't know or care whether you're allowed to be scanning what you're scanning. Neither does LANsentry, or any other network tool. The software is neutral; what makes an action legal or illegal is who authorized it.
The one thing that actually matters: authorization
A penetration test is legal when — and only when — the owner of the system or network being tested has given clear, documented permission for exactly that testing, within an agreed scope, for an agreed time window. This is usually formalized in a signed "Rules of Engagement" or "Authorization to Test" document before a single scan is run, specifying:
- Exactly which systems, IP ranges, or applications are in scope (and explicitly which are not)
- What testing techniques are permitted (e.g. is denial-of-service testing allowed, or explicitly excluded)
- The time window the testing is authorized for
- Who to contact if something goes wrong during testing
- What happens to any data accessed during the test
Without this, running the exact same scan against the exact same target is not a "gray area" — it's unauthorized access, full stop, regardless of your intentions.
"I was just curious" or "I was going to tell them about the vulnerability anyway" is not a legal defense. Good intentions do not retroactively create authorization. Get permission in writing before you scan, not after.
What the law actually says
The specific statutes vary by country, but the underlying principle — unauthorized access to a computer system is a criminal offense — is consistent across most jurisdictions:
| Region | Relevant law |
|---|---|
| Germany | § 202a–c StGB (Ausspähen von Daten, Hacking-Paragraph) — criminalizes unauthorized access to protected data/systems. |
| European Union | Directive 2013/40/EU on attacks against information systems — sets a baseline that EU member states implement in national law. |
| United States | Computer Fraud and Abuse Act (CFAA) — criminalizes accessing a computer "without authorization or exceeding authorized access." |
| United Kingdom | Computer Misuse Act 1990 — criminalizes unauthorized access to computer material. |
This is general information, not legal advice — if you're planning professional security testing work, involve a lawyer familiar with your jurisdiction to review your engagement contracts.
Testing your own network
Scanning, port-checking and vulnerability-assessing a network you own outright — your home network, your own company's infrastructure that you have the authority to test — is unambiguously fine, and honestly one of the best ways to learn. This is exactly the use case tools like LANsentry are built for: understanding what's actually running and exposed on your own network.
One nuance worth knowing: on a shared network (a flat, an office, a dorm), "your network" often isn't fully yours. Scanning a landlord's or employer's network, even the parts your own devices sit on, can still require their sign-off — ask first if there's any doubt.
Testing someone else's — the right way
If you want to test or assess a network, system, or application that belongs to someone else — a client, an employer, a friend's small business — the process is straightforward:
- Get it in writing before doing anything, even a "quick look."
- Define scope precisely. "Test our network" is dangerously vague — pin down IP ranges, domains, and explicitly excluded systems (production databases, third-party services you don't have authority over).
- Agree on technique boundaries. Some organizations exclude denial-of-service testing, social engineering, or physical access from scope.
- Keep the authorization documentation for the duration of the engagement and afterward — it's your proof of legitimacy if anything is ever questioned.
Where to practice legally
You don't need someone else's network to build real skills. Purpose-built legal practice environments exist specifically so beginners can learn without any authorization ambiguity:
- Your own home lab — spin up virtual machines with intentionally vulnerable software (e.g. Metasploitable) on an isolated virtual network.
- Dedicated legal practice platforms — Hack The Box, TryHackMe, PortSwigger's Web Security Academy, OverTheWire — all explicitly designed and authorized for this.
- Capture-the-flag (CTF) competitions — structured, explicitly authorized environments with clear rules and scope.
Red flags you're crossing a line
If any of these apply, stop and get explicit written authorization before continuing:
- You don't have written permission and are "planning to ask" or "will explain later if asked"
- You're testing systems outside a scope you were actually given
- You're accessing, downloading, or modifying data beyond what's needed to demonstrate a finding
- You're targeting a network you have no ownership or contractual relationship with at all — curiosity is not authorization
Practice on the network you're authorized for — your own
LANsentry gives you a full, legal picture of your own network: every device, every open port, every known vulnerability — no ambiguity about authorization.