Credential Exposure Monitoring: Have I Been Pwned

What the service actually does

Have I Been Pwned aggregates publicly disclosed breach data and lets anyone query an email address or domain against that corpus. The site returns the name of each breach, the approximate date, and the data classes exposed such as passwords, names, phone numbers, or physical addresses. It does not store the raw credentials. It does not scan the live dark web. It does not tell you whether the exposed password is still valid on any of your systems.

For a regulated practice the distinction matters. A green result means the address has not appeared in any breach the service has indexed. A red result means it has appeared in at least one. Neither result proves that your current credentials are safe or compromised. Both results require the same baseline hygiene.

Why the legacy description was incomplete

The 2017 post attributed the database to a Paris-based researcher named Benkow and framed the service as a dark-web compilation brought to the light web. The service is in fact maintained by Troy Hunt, a Microsoft Regional Director and security educator, and its sources are public breach disclosures, not live dark-web scraping. The Experian breach reference in the original post was a timely distinction that has since faded but the underlying point remains: a single high-profile breach is not the same as the ongoing accumulation of credential dumps that Have I Been Pwned tracks.

Interpreting a hit in a regulated context

When a partner's email or a practice-wide alias returns a hit, the immediate question is not whether the password from that breach still works. The question is whether that password or a close variant is currently active on any system that touches client data, patient records, or trust accounts. The breach metadata tells you what was exposed. Your identity provider logs tell you what is in use.

If the breached data includes a password hash, assume the plaintext is recoverable. If it includes only an email and name, the risk shifts to credential stuffing and targeted phishing. In either case the response is the same: rotate the secret, revoke any sessions tied to it, and verify that multi-factor authentication is enforced on every access path.

From point-in-time check to continuous control

A manual query is a snapshot. A domain-level subscription or API integration turns the signal into a control. Have I Been Pwned offers a domain search feature that notifies you when any address on your domain appears in a new breach. The API can feed a SIEM or a SOAR playbook that automatically forces a password reset and flags the account for review.

For firms using Microsoft Entra ID, Okta, or similar identity platforms, the native compromised-credential detection often ingests the same breach corpus. Enable those features. They close the loop between public exposure and internal enforcement without a separate dashboard.

Dark-web monitoring versus breach notification

Breach notification services index data that has already been published. Dark-web monitoring services claim to scan forums, marketplaces, and paste sites for data that has not yet been disclosed. The coverage claims are difficult to verify. The signal-to-noise ratio is low. For most regulated practices the higher-leverage investment is hardening the identity layer: phishing-resistant MFA, conditional access, and passwordless options where the platform supports them.

If you maintain a dark-web monitoring subscription, treat its alerts as supplementary. They do not replace breach notification. They do not replace MFA. They do not replace a tested incident-response plan.

Regulatory implications

State bar ethics opinions and HIPAA security rule guidance both expect reasonable safeguards for confidential information. A documented process for monitoring credential exposure, responding to hits, and evidencing the response satisfies the reasonableness standard more reliably than an ad-hoc check by a partner who remembers the site exists.

Document the following: the monitoring method (domain subscription, API feed, identity-provider native detection), the triage playbook (who reviews, what triggers a forced reset, what triggers a broader investigation), and the evidence retention (alert logs, reset confirmations, review notes). The artifact is the control.

Practical rollout for a small practice

  1. Run a one-time domain search on Have I Been Pwned. Export the results.
  2. For each unique address that appears, verify current MFA status in your identity provider.
  3. Force a password reset for any account where MFA is not yet enforced or where the breached password may have been reused.
  4. Enable the domain monitoring feature so new breaches generate an email to your security alias.
  5. If you use Microsoft 365 or Google Workspace, turn on the built-in compromised-credential detection and link it to conditional access policies that block sign-in until reset.
  6. Add a quarterly review of the alert log to your existing security committee agenda.

The entire sequence takes hours, not weeks. The ongoing cost is near zero.

What to tell clients who ask

Clients increasingly ask whether their data was exposed in a breach that made headlines. Have I Been Pwned lets you answer with precision: the client's email appears or does not appear in the indexed breaches. It does not let you answer whether their specific matter file was accessed. That question belongs to your incident-response process, not to a public breach index.

Offer the domain-monitoring link as a self-service tool. Explain the limits. Position the conversation around the controls you maintain: MFA everywhere, passwordless where available, conditional access, and a tested response plan. The tool is a signal. The controls are the answer.

Back to the blog index