Back to Blog
Guides11 min readAug 25, 2026

Is OSINT Legal? What Open-Source Intelligence Can and Can't Do

OSINT is legal in most jurisdictions when you collect public information without bypassing access controls. Here are the boundaries that actually matter.

R

Revealer Intelligence Team

Revealer.US

Yes, OSINT is legal in most jurisdictions. Open-source intelligence collects information that is already publicly available or lawfully accessible without defeating an access control. The legal risk almost never comes from looking. It comes from how you obtain data (bypassing authentication, scraping in breach of contract), what you do with it (employment or tenant decisions, stalking, harassment), and whose data it is (EU residents, minors, protected categories). Practical rule: if you had to log into someone else's account, guess a password, or defeat a technical barrier to get it, you have left OSINT and entered unauthorized access.

Do not hunt for a single OSINT statute. There isn't one. You are stacking computer-misuse law, contract, consumer-reporting rules, data-protection regulation, and sector licensing. A collection step can be lawful under four of those and unlawful under the fifth.

What "open source" actually means legally

"Open source" in OSINT does not mean open-source software, and it does not mean "found on the internet." Investigators treat it as information that is:

  • Publicly available: published, broadcast, filed, or otherwise made accessible to the general public without restriction.
  • Lawfully accessible: obtainable through normal use of a system, without credentials you were not given and without circumventing a technical barrier.
  • Obtained without deception that carries independent legal weight: no impersonating law enforcement, no pretexting for financial records, no false statements to a government agency.

Court filings, corporate registries, property deeds, licensing boards, domain registration data, published social profiles, archived pages, job listings, and press coverage all sit inside that definition. So do commercial data aggregators operating on lawfully sourced records.

What sits outside it: content behind an authentication wall you do not have rights to, data obtained by exploiting a vulnerability, and information gathered by intruding on someone's private space. The line is access control, not sensitivity. A home address in a county property record is open source even though it feels private. A grocery list in private cloud storage is not, even though it feels trivial.

The five legal regimes that actually constrain OSINT

Most of the "is this legal?" argument goes away once you split the regimes. They answer different questions and can bind at the same time.

Regime Core question it answers Typical trigger Practical consequence
Computer-misuse law (CFAA in the US, Computer Misuse Act in the UK, similar elsewhere) Did you access a system without authorization? Credential use, bypassing a technical barrier, exceeding granted access Criminal exposure; the hardest line in OSINT
Contract / terms of service Did you agree not to do this? Scraping, automated collection, account creation under false details Civil claims, account termination; generally not criminal on its own in the US after Van Buren / hiQ
Consumer reporting (FCRA in the US) Are you using data for an eligibility decision? Employment, tenancy, credit, insurance screening Statutory liability regardless of how lawfully the data was collected
Data protection (GDPR, UK GDPR, state privacy laws) Do you have a lawful basis to process personal data? Any processing of identifiable EU/UK data; some US state regimes Regulatory fines, deletion and disclosure obligations
Purpose-based criminal law Why are you doing this? Stalking, harassment, intimidation, doxxing campaigns Criminal exposure independent of collection method

The last row is the one people forget. Every element of a collection can be lawful while the campaign built on it is a crime. Intent is not a technicality in stalking and harassment statutes; it is the offense.

CFAA and the access-control line

The Computer Fraud and Abuse Act is where a research question becomes a criminal one. Two US cases did most of the narrowing.

In Van Buren v. United States (2021), the Supreme Court rejected the broad reading of "exceeds authorized access." The Court adopted a "gates-up-or-down" approach: liability attaches when you access areas of a system you are not entitled to reach, not when you misuse information you were entitled to access. That decision substantially reduced the risk that violating a website's terms of use is, by itself, a federal crime.

In the hiQ Labs v. LinkedIn litigation, the Ninth Circuit held that scraping publicly available profile data (pages viewable without logging in) did not constitute access "without authorization" under the CFAA. Read the limits. The case concerned public pages, the litigation still ended badly for hiQ on contract grounds, and it binds only within that circuit. Scraping public pages is not a CFAA problem in most readings. It can still be a breach-of-contract problem, a trespass-to-chattels problem, and a copyright problem.

Work to this: do not authenticate into systems you do not have rights to, and do not defeat technical barriers. Rate limiting, IP blocks, CAPTCHAs, and login walls are all signals that the gate is down. Routing around them moves you from the civil column to the criminal one.

Terms of service: real, but a different kind of risk

Terms of service are contracts. Breaching one exposes you to civil claims and account loss. After Van Buren, that is generally not federal criminal liability on that basis alone in the US. Other jurisdictions treat it differently, and the EU's approach to database rights adds another layer for bulk collection.

For working investigators this produces a hierarchy of caution:

  1. Manual review of public pages. Lowest risk anywhere.
  2. Automated collection of public pages at modest rates. Generally defensible; respect robots.txt, throttle, identify your traffic honestly.
  3. Automated collection behind a login. Contract breach at minimum, and depending on how the account was obtained, potentially much worse.
  4. Creating fake accounts to reach restricted content. Combines contract breach with misrepresentation, and in some contexts touches fraud statutes.

Law enforcement and licensed investigators sometimes operate under authorities that change this calculus. Commercial and journalistic researchers usually do not.

FCRA: the trap that catches lawful data

More people get into trouble here than with the CFAA, because the collection is entirely lawful and the use creates the liability.

In the United States, the Fair Credit Reporting Act regulates "consumer reports": information used or expected to be used for decisions about employment, housing, credit, insurance, or similar eligibility determinations. If you assemble information for those purposes and furnish it to a third party, you may be operating as a consumer reporting agency, which brings accuracy requirements, dispute procedures, permissible-purpose restrictions, and adverse-action notice obligations.

Keep these two uses apart:

  • Public-records and OSINT search answers "what is publicly known about this identifier?" It supports due diligence, fraud investigation, journalism, security research, skip tracing, and threat assessment.
  • An FCRA-compliant background check answers "is this person eligible for this job, apartment, or loan?" It must come from a consumer reporting agency operating under the statute.

The same underlying record can appear in both, and that similarity is exactly why the misuse happens. A hiring manager who runs a people-search query and declines a candidate on what it returns has created an FCRA problem even though every record involved was public.

Revealer.US is not a consumer reporting agency. Its results are not consumer reports and may not be used for employment, tenant, credit, insurance, or other FCRA-covered eligibility decisions.

We say this on the background check and people search pages for a reason: the boundary is a product boundary, not a disclaimer we bolted on. If your use case is eligibility screening, you need a CRA, not an OSINT platform.

GDPR and processing personal data about EU residents

If you process personal data relating to people in the EU or UK, GDPR applies regardless of where you sit. "Publicly available" is not a lawful basis under GDPR. It is a mitigating fact, not an exemption.

The bases most relevant to investigative work are legitimate interests (Article 6(1)(f)) and, less commonly, legal claims. Legitimate interests requires a documented balancing test: your purpose, the necessity of the processing, and the impact on the data subject. Fraud investigation, anti-money-laundering work, security research, and establishing or defending legal claims can support legitimate interests. Idle curiosity about a private individual cannot.

A few obligations catch people out:

  • Special-category data (health, sexuality, religion, political opinion, biometrics, trade union membership) needs an Article 9 condition on top of your Article 6 basis. Inferring these from social media does not exempt you.
  • Transparency normally requires notifying the data subject, with a narrow exemption where notification would prejudice the purpose. Assess that exemption. Do not assume it.
  • Retention must be limited. Holding an investigative dossier indefinitely because storage is cheap is a compliance failure.
  • Data subject rights (access, erasure, objection) attach to what you hold.

Journalism, academic research, and artistic expression have their own exemptions under Article 85 and member-state implementations. Those exemptions are genuinely broad, but they attach to the activity, not to the person doing it.

Breach data and infostealer logs: the honest answer

Searching whether an identifier appears in a known breach corpus (the model used by breach-notification services and by our data breach lookup and stealer logs tools) is a defensive and investigative practice with a long, established history. Security teams, incident responders, and fraud investigators use exposure checks to determine what an attacker plausibly already knows, to prioritize credential resets, and to attribute activity.

The distinctions that matter:

  • Checking exposure for an identifier you have a legitimate interest in is different from bulk-harvesting credential dumps.
  • Knowing a credential was exposed is different from using it. Using a leaked credential to log into an account is unauthorized access, full stop, no matter how the credential reached you.
  • Jurisdiction matters. Some countries treat possession of stolen credential data as an offense in its own right, with narrow research exemptions. Check local law rather than assuming the US or UK position generalizes.
  • Data-protection duties still apply. Breach-derived personal data is personal data. GDPR does not stop applying because a criminal published it first.

Our stance is stated in our acceptable-use terms and surfaced in the data breach lookup and stealer logs tools: exposure data exists to help defenders and lawful investigators understand risk. Accounts used for credential stuffing, account takeover, or harassment get terminated.

A workable compliance checklist

Before a collection run, write down the answers. If you cannot, that is the finding.

  1. Purpose. What decision or question does this support? Write it in one sentence. Vague purposes fail every balancing test.
  2. Basis. What is your lawful basis if personal data is involved? Legitimate interests, consent, legal claim, statutory authority?
  3. Access. Will any step require credentials you were not granted, or defeat a technical barrier? If yes, stop.
  4. Contract. Are you bound by terms that prohibit this collection method? What is your exposure if you are?
  5. Use restriction. Is this an FCRA-covered decision? If yes, route to a consumer reporting agency instead.
  6. Proportionality. Are you collecting the minimum needed? A full dossier when you needed one corporate affiliation is a bad answer to a regulator.
  7. Retention and access control. Where does this live, who can see it, and when is it deleted?
  8. Documentation. Keep a contemporaneous record of the above. Investigations get reviewed months later, by people who were not there.

Where OSINT tooling fits

A tool does not make a collection lawful. It can make the process easier to defend. A platform that queries public records, published profiles, and breach corpora through documented sources gives you provenance you can show a reviewer. Ad-hoc browser tabs rarely do.

Revealer.US runs a single search across 800+ platforms, public records, and known breach datasets from one identifier: an email, username, phone number, name, or address. AI Deep Search extends that with recursive, agent-driven pivoting. It follows identifiers it discovers across sources rather than stopping at the first result set. The API supports integrating checks into an existing investigative or security workflow, and breach monitoring covers ongoing exposure.

For a broader survey of what else belongs in a practitioner's kit, including the free and open-source options, see our OSINT tools roundup. Tools like Maltego, SpiderFoot, theHarvester, and Sherlock all operate within the same legal boundaries described above; none of them change what you are permitted to do with what they return.

Free tier to start; paid self-serve plans begin at $12.99/mo, with custom Enterprise arrangements. See pricing. Card and crypto accepted.

The short version

OSINT is lawful investigative work. It becomes unlawful at four recognizable moments: when you defeat an access control, when you use lawfully collected data for a regulated eligibility decision without the right legal wrapper, when you process personal data without a basis in a jurisdiction that requires one, and when the purpose itself is harassment. None of those are close calls in practice. If your collection plan survives the checklist above, you are on solid ground. If it does not, the problem is almost always fixable by narrowing the purpose or changing the method.

Frequently asked questions

Is OSINT legal in the United States? Yes. Collecting publicly available information is lawful. The main US constraints are the CFAA (which prohibits accessing systems without authorization), the FCRA (which regulates use of data for employment, tenant, credit, and insurance decisions), state privacy and anti-stalking laws, and contract law where terms of service apply.

Is web scraping legal? Scraping publicly accessible pages that do not require login is generally not a CFAA violation in the US, following the hiQ v. LinkedIn line of cases. It can still breach a site's terms of service, which is a contract issue, and may raise copyright or database-rights questions, particularly in the EU. Throttle your requests, do not defeat blocks, and read the terms.

Can I use OSINT to screen job applicants or tenants? Not with a general OSINT or people-search platform. Employment, tenant, and credit screening in the US falls under the FCRA and must be performed by a consumer reporting agency with permissible purpose, accuracy procedures, dispute handling, and adverse-action notices. Revealer.US is not a consumer reporting agency and must not be used for those decisions.

Is it legal to search breach data? Checking whether an identifier appears in a known breach corpus is a standard defensive and investigative practice in most jurisdictions. Using a leaked credential to access an account is unauthorized access and is illegal everywhere. Some countries also restrict possession of stolen credential data, so verify your local position.

Does GDPR apply if the data is already public? Yes. "Publicly available" is not a lawful basis under GDPR. If you process personal data about people in the EU or UK you still need an Article 6 basis (usually legitimate interests, backed by a documented balancing test), plus an Article 9 condition for special-category data. You still owe transparency, retention limits, and data subject rights.

What is the single clearest line I should not cross? Authentication. If a step requires credentials you were not given, or defeating a login wall, CAPTCHA, or block, you have left open-source intelligence and entered unauthorized access. Everything else is a risk to manage; that one is a bright line.

Get started

Ready to check your exposure?

Create a free account and search live sources and known breach datasets.

Create account