Pwned email results guide application and login decisions
You type your work email into the lookup because you need to see what an onboarding rule would do in practice. It is the address you have used for well over a decade, the one attached to meetings, account registrations and the ordinary work of keeping a business running. The response arrives as a list of breach entries. Beside it, your draft says that an applicant whose email appears in a breach should be referred. For a moment, the policy is no longer an abstract condition in a decision flow. It is sitting on your own desk, attached to an address you know well.
Long use can explain a high breach count
A long breach history can be normal for a long-used address. You entered the work email from your draft rule and got a list of records. The first question is whether that list marks unusual risk or reflects years of use.
In our checks, every made-up address came back clean, while 30 of 31 long-used addresses were found. One address had eleven records. The groups show how lookup results differ between made-up and long-used addresses.
That result changes what the count can tell you: a match can support that an address existed and was in use over time. Referring every match sends many established addresses to review, using capacity and adding friction to onboarding. For your rule, the count shows how long and widely the address has been used, and the breach details show what leaked.
Read the records before deciding what action they support.
Breach dates and exposed data shape risk assessment
Use breach dates to assess address history and exposed data to assess possible misuse. The earliest verified record on the work address is from 2012, and later records include passwords, profile details and a stealer log.
| Breach | Year | What leaked | Kind |
|---|---|---|---|
| 2012 | email, password | verified | |
| Artsy | 2018 | email, IP address, name, password | verified |
| Kayo.moe Credential Stuffing List | 2018 | email, password | unverified |
| You've Been Scraped | 2018 | email, employer, location, job title, name, social profiles | verified scrape |
| Collection #1 | 2019 | email, password | unverified |
| PDL | 2019 | email, employer, location, job title, name, phone, social profiles | verified scrape |
| Cit0day | 2020 | email, password | unverified |
| LinkedIn Scraped Data (2021) | 2021 | education, email, gender, location, job title, name, social profiles | verified scrape |
| The Post Millennial | 2024 | email, gender, IP address, name, password, phone, physical address, username | verified |
| ALIEN TXTBASE Stealer Logs | 2025 | email, password | stealer log |
| Synthient Credential Stuffing Threat Data | 2025 | email, password | verified |
LinkedIn’s 2012 row is a breach of a service, with an email and password someone can try on other services if reused. PDL and LinkedIn Scraped Data (2021) are scrapes of public profiles. PDL exposed an employer and phone number, and both rows include a name and other profile details that can help someone impersonate the owner. Collection #1 and Cit0day are compilations of leaked email and password pairs, which can support attempts to reuse those passwords. ALIEN TXTBASE Stealer Logs is a stealer log, indicating malware captured information on a device the owner used and supporting a password reset if it was added after the last password change. For a separate check of whether a submitted password has appeared in a breach, see the breached-password check.
Of the 309 records on the role addresses, 42 were spam lists and 49 were unverified. For four addresses, every hit was one of those weaker kinds, so a total alone can make weak evidence look like a meaningful exposure.
Use verified breach records, filtering out spam lists and fabricated entries, to support address history. Treat the breach date as a guide to when the address existed.
Address age requires a separate history signal
A clean lookup reports HaveIBeenPwned’s record status at the time of the request. A separate history signal tells you whether the address has been seen over time.
Breach records can arrive months or years after the breach, so a clean result reflects only the records available at lookup time and leaves address age to a separate history signal. Repeated sightings support a history of use. Little or no history leaves address age unestablished, so use other identity evidence to corroborate it and assess the application on the full evidence.
Give a clean lookup no weight either way, and use a separate history signal to assess the address’s age.
Applications verify control and logins address exposure
At application, check control of the email before relying on its history. When an old, verified breach exposed names, phone numbers or employers, send a one-time code to the address. If the applicant completes the check, you have evidence they control it now, and can weigh its history alongside the other application evidence.
At login, act on exposure that points to account takeover. A recent password exposure or a stealer log can justify step-up authentication or a password reset. A challenge adds friction, but ignoring a relevant exposure can leave a reused credential available to someone else. Use the wider login rules for junk logins and bot attacks to assess the attempt in context.
One email lookup can support two different decisions, so keep the application control check separate from the login response.
API settings and capacity shape usable evidence
Request the full breach model so your rules can read breach details rather than breach names alone.
Treat an HTTP 404 as no breach on record. Route a timeout or HTTP 429 rate-limit response as an error, rather than as a clean result. In Decisimo, keep the API key in Admin Center, Credentials, and reference it from the data source.
Choose a plan against your peak lookup demand, because the subscription sets the request limit and an over-limit call returns an error.
| Plan | Requests per minute |
|---|---|
| Core 1 | 10 |
| Core 2 | 50 |
| Core 3 | 100 |
| Core 4 | 500 |
| Core 5 | 1,000 |
Subscriptions are billed annually. Pro and High RPM plans add k-anonymity search and stealer log data. See HaveIBeenPwned’s subscription page for current prices. Several sources in one data source step run together, and the step waits for the slowest response. Choose capacity for peak demand, then place the call alongside the other checks that use that step.
Onboarding rules should weigh breach evidence
Return to the draft rule and the work address with eleven breaches. The 2012 LinkedIn breach shows the address existed in 2012. Profile scrapes exposed a name, employer and phone, so ask an applicant using it for a one-time code before its history counts. At login, the 2025 stealer log and password breaches call for a reset if they were added after the last password change.
- Look up the email with the full breach model. Treat an HTTP 404 as no breach on record, and handle timeouts and rate-limit responses as errors.
- Use verified breaches that are neither spam lists nor fabricated as evidence of address history. Treat the earliest breach date as a guide to when the address existed.
- Give no breach on record no weight either way. Check address age separately: repeated sightings at real services support a history of use, while little or no history leaves age unestablished and calls for corroboration.
- At application, if an old, verified breach exposed names, phone numbers or employers, send a one-time code. Rely on the address history only after the applicant demonstrates current control.
- At login, treat a password breach or stealer log added after the account’s last password change as a reason for a password reset. If it was added before the last password change, do not reset on that basis.
- Choose the plan for peak lookups per minute, and place the call in the same data source step as the other checks.
Questions about pwned email checks
What does a pwned result tell a fraud team?
It means the address appeared in a data set from a breached service, a scrape, a spam list or malware on a device. The record establishes that the address appeared in that data set on the stated date. Read the breach type and exposed data to decide what action it supports.
Should an applicant be declined when their email appears in data breaches?
No. A match alone does not establish that an applicant is risky. Our checks found most long-used addresses and none of the made-up test addresses. Assess what was exposed and when, and verify control if you rely on address history.
What does it mean when an email is not found in any breach?
It means HaveIBeenPwned has no breach on record for that address at the time of the lookup. Made-up addresses can be clean, and breach records can arrive late. Give the result no weight either way and assess address age separately.
Which breaches show that an email address is real and old?
Verified breaches that are neither spam lists nor fabricated can support that the address existed by the breach date. Treat that date as a guide, then assess the exposed data separately.
How should a breached email change a login decision?
A recent password exposure or a stealer log can justify step-up authentication or a password reset. Reset after a password breach or stealer log added after the account’s last password change. If it was added before then, do not reset on that basis. Apply the action according to the exposure and its timing.
What does the HaveIBeenPwned API cost?
The cost depends on your peak lookup demand, measured in requests per minute, and is billed as a subscription. See HaveIBeenPwned’s subscription page for current prices.
