Is Subdomain Enumeration Legal? A Straight Answer

This question comes up constantly among security researchers, students, and curious developers, and the honest answer is: it depends on what you do, not just what you find. Reading public records about a domain is a very different act from sending traffic to that domain's servers. This article breaks the distinction down clearly, without pretending to be a substitute for a lawyer.

Passive vs active recon: the core distinction

Almost every legal question about subdomain enumeration collapses into one distinction: are you reading data that a third party already published, or are you sending requests directly to the target's own infrastructure? Passive reconnaissance means querying sources like Certificate Transparency logs, passive DNS aggregators, and search engine indexes, none of which involves your traffic touching the target's servers at all. Active reconnaissance means resolving DNS records directly against the target's own nameservers, brute-forcing subdomain wordlists, or scanning ports, all of which do send traffic to systems the target controls.

This distinction matters because most computer misuse laws are written around the concept of "access" to a computer system. Passive recon typically does not access the target's system in any meaningful sense: you are querying a public database run by someone else. Active recon does interact with the target's systems, which is where authorization becomes legally relevant.

CFAA, the Computer Misuse Act, and similar laws

In the United States, the Computer Fraud and Abuse Act (CFAA) criminalizes accessing a computer "without authorization" or "exceeding authorized access." The exact boundaries of those phrases have been litigated for decades, and the 2021 Supreme Court decision in Van Buren v. United States narrowed the "exceeds authorized access" clause considerably, but the statute still applies to actions that involve directly interacting with a system you were not permitted to use.

The United Kingdom's Computer Misuse Act 1990 uses similar language around unauthorized access to computer material. Most other jurisdictions, including EU member states under the Directive on attacks against information systems, follow a comparable pattern: unauthorized access to a system is the trigger, not the mere existence of information about that system somewhere on the internet.

Why reading CT logs is not "hacking"

Certificate Transparency logs exist because certificate authorities are required to publish every certificate they issue to a public, append-only ledger. That requirement exists precisely so anyone, including the domain owner, can audit which certificates were issued for their domains. Querying that public ledger through a tool like crt.sh, or through Subdomain Finder, involves no request to the target company's servers whatsoever. You are reading a record published by a certificate authority, which is a third party, not the target.

The same logic applies to passive DNS aggregators, which record historical DNS answers collected from resolvers around the internet, and to search engine caches. None of these require you to send a single packet to the domain you are researching. That is precisely why passive subdomain discovery is treated so differently, both practically and legally, from active scanning.

Bug bounty scope and authorization

Companies that run bug bounty programs publish scope documents explicitly listing which domains, subdomains, and testing methods are authorized. That document is what converts active reconnaissance, which would otherwise carry legal risk, into permitted activity. Enumerating subdomains within a program's declared scope, then testing only assets that fall inside it, is a textbook example of authorized security research.

Staying inside scope matters more than most new researchers realize. Finding a subdomain that is technically owned by the target but explicitly marked out of scope, and testing it anyway, can undo the legal protection the program otherwise provides. Read the scope document fully before testing anything active.

1. Confirm the program is currently active and accepting submissions.
2. Read the in-scope and out-of-scope asset lists carefully, including wildcard rules.
3. Check for any restrictions on testing methods, such as bans on automated scanning or denial-of-service style traffic.
4. Keep records of what you tested and when, in case questions arise later.

Responsible disclosure norms

Even outside a formal bug bounty program, a widely accepted norm exists: if passive recon surfaces something concerning, such as a subdomain that looks abandoned or a service that appears misconfigured, the responsible next step is private disclosure to the organization, not public posting or further probing. Many organizations publish a security.txt file or a dedicated contact address specifically for this purpose.

Responsible disclosure does not remove legal risk on its own, but it substantially changes how an organization is likely to respond, and it is simply the right thing to do. Give the organization reasonable time to fix the issue before any public discussion.

Frequently asked questions