Category: Passwords & Hashing

Compromised Credential Check

Also known as: Breached Password Detection, Compromised Credentials Detection, Credential Checker

Simply put

A compromised credential check is a security control that compares a user's credentials, most commonly a password, against collections of credentials known to have been exposed in data breaches. If a match is found, the service can respond by blocking the account, requiring a password reset, or preventing the credential from being used. The goal is to stop attackers from reusing stolen passwords that circulate publicly or on the dark web.

Formal definition

A compromised credential check is an authentication-time (and sometimes sign-up or password-change-time) control that evaluates a submitted or stored credential against corpora of breached credentials, such as Have I Been Pwned's Pwned Passwords dataset. Detection typically triggers on the knowledge factor (the password), not on possession or inherence factors, and it verifies exposure status rather than verifying identity itself. Depending on the platform and configuration, providers expose different response actions: for example, Auth0 can block affected accounts, and Amazon Cognito can perform checks during sign-in, sign-up, and password changes with configurable actions such as allowing or blocking sign-in. Implementations vary in matching method (many use a hashed or k-anonymity style lookup to avoid transmitting full credentials), in whether they check plaintext passwords versus only email/domain exposure (as with domain-oriented tools like Outpost24's Credential Checker), and in remediation behavior. This control complements but does not replace MFA or step-up authentication; a passing check does not by itself authenticate the user, and the specific scope, data sources, and enforcement actions are deployment- and vendor-dependent.

Why it matters

Credential reuse is one of the most reliable techniques available to attackers. Because many people reuse the same password across multiple services, a password exposed in one breach can be replayed against unrelated accounts in credential-stuffing attacks. A compromised credential check directly targets this pattern by treating any password that appears in a known breach corpus as untrustworthy, regardless of whether the current account itself was ever breached.

The control matters because it addresses a weakness in the knowledge factor that stronger password composition rules alone cannot fix: a password can be long, complex, and unique-looking yet still be publicly circulating because it was exposed elsewhere. Services such as Have I Been Pwned's Pwned Passwords dataset make large corpora of previously breached passwords freely available specifically so that platforms can block their reuse. Identity platforms build on datasets like these to detect exposure at authentication, sign-up, or password-change time and to enforce remediation.

It is important to be clear about scope. A compromised credential check verifies exposure status, not identity, so a password that passes the check has not thereby been authenticated as belonging to the legitimate user. In most deployments this control is layered with MFA or step-up authentication rather than used as a substitute for them, and the specific data sources, matching methods, and enforcement actions vary by vendor and configuration.

Who it's relevant to

IAM Engineers and Authentication Architects

Engineers configuring authentication flows decide where a compromised credential check fires (sign-in, sign-up, or password change) and what remediation action follows, such as blocking the account or requiring a reset. They must account for vendor differences, for example Auth0's account-blocking behavior versus Amazon Cognito's configurable allow or block actions, and ensure the control is layered with MFA rather than treated as a standalone authentication decision.

Security Operations and Fraud Teams

SecOps teams use exposure detection to reduce the success rate of credential-stuffing and account-takeover attempts that rely on reused passwords. They benefit from understanding that a match signals prior exposure in a breach corpus rather than an active compromise of the specific account, which affects how alerts are triaged and how aggressive automated remediation should be.

Compliance and Identity Governance Leads

Governance and compliance stakeholders may point to compromised credential checks when demonstrating that weak or exposed passwords are actively prevented. They should document the specific data sources, matching method, and enforcement actions in use, since scope and behavior are deployment- and vendor-dependent, and note that this control governs credential quality at authentication time rather than access lifecycle concerns such as provisioning or certification.

System Administrators

Administrators operating identity platforms manage the day-to-day consequences of the control, including handling accounts that are blocked or forced into password resets after a match. They also weigh domain-oriented tools such as Outpost24's Credential Checker, which check whether an organization's email domain is linked to leaked credentials, against per-password checks performed inside the authentication flow.

Inside Compromised Credential Check

Breached Credential Corpus

A dataset of known-exposed username/password pairs or password hashes aggregated from public breaches and leak sources, against which submitted credentials are compared. In most deployments this is maintained by a third-party service or an internal repository that is periodically updated.

Comparison Mechanism

The matching logic that evaluates a submitted credential against the corpus, typically at authentication time or during credential registration/reset. The check verifies whether a specific credential value is known to be compromised; it is not itself an authentication decision but an input to authentication or password policy enforcement.

Privacy-Preserving Query Model

A technique such as k-anonymity range querying (for example, submitting a partial hash prefix) used so that the full credential or its complete hash is not transmitted to an external service. The exact protection depends on the provider and configuration.

Policy Enforcement Point Integration

The point at which a positive match triggers an action, such as blocking the password choice, forcing a reset, or invoking step-up authentication. This links the check to knowledge-factor (password) hygiene rather than replacing possession or inherence factors.

Trigger Events

The lifecycle moments where the check runs, commonly password creation, password change, self-service reset, and optionally periodic re-evaluation or at sign-in. Behavior varies by vendor and configuration.

Common questions

Answers to the questions practitioners most commonly ask about Compromised Credential Check.

Does a compromised credential check verify that a password is strong or complex?

No. A compromised credential check evaluates whether a credential appears in known breach or exposure datasets, not whether it meets complexity or strength policies. A password can satisfy every strength rule your policy defines and still be flagged because it has previously appeared in a breach corpus. Strength enforcement and breach-exposure checking are separate controls that typically operate independently, though many deployments run both during registration or password reset.

Is a compromised credential check a form of multi-factor authentication or a replacement for it?

No. A compromised credential check operates within the knowledge-factor path, assessing the quality or exposure status of a single factor (typically a password). It does not add a possession or inherence factor and therefore does not constitute MFA or 2FA. In most deployments it complements MFA rather than substituting for it; a credential can pass a compromise check and still warrant additional factors, and conversely a flagged credential can trigger step-up authentication depending on configuration.

At what points in the identity lifecycle should a compromised credential check run?

Common integration points include user registration, password change and reset flows, and authentication events. Some deployments also run periodic or asynchronous checks against stored credential representations to detect credentials that became exposed after they were set. The appropriate placement depends on your risk tolerance and on whether you can perform the check without exposing plaintext credentials, which typically favors registration and reset flows where the value is transiently available.

How can a compromised credential check be performed without transmitting the full credential to an external service?

A widely used technique is a partial-hash or range-query approach, in which only a prefix of a hashed credential is sent and the service returns a set of candidate suffixes for local comparison. This lets the client determine a match without disclosing the full hash or plaintext to the provider. Implementation details, coverage, and privacy guarantees vary by provider and profile, so verify what the specific service exposes and how it handles the submitted data before relying on it.

What should happen when a credential is flagged as compromised?

Responses vary by policy and context. Typical options include blocking the credential and requiring the user to choose a different one during registration or reset, forcing a password change at next login, or triggering step-up authentication for the current session. The chosen response is an authorization and risk-policy decision; the check itself only produces a signal. Consider user-experience impact and false-positive handling, since a match indicates prior exposure of that credential value rather than confirmed account takeover.

Where does a compromised credential check fit relative to runtime enforcement components like a PDP or PEP?

The check is best understood as a signal source rather than an enforcement point. In a policy-driven architecture it can feed a decision by acting as an input comparable to a policy information point (PIP), supplying credential-exposure attributes that a policy decision point (PDP) may weigh. The actual allow, deny, or step-up outcome is enforced downstream. Whether you model it as a discrete enforcement step or as an attribute feeding a broader authentication risk decision depends on your architecture and vendor capabilities.

Common misconceptions

A compromised credential check authenticates the user or confirms an account is safe.

It only evaluates whether a knowledge factor (typically a password) appears in a known-breach dataset. It does not verify identity and does not perform authentication or authorization; it feeds into password policy or risk decisions. Absence from the corpus does not prove a credential is uncompromised, since not all breaches are known or indexed.

Running the check requires sending full passwords to a third party in plaintext.

In many deployments a privacy-preserving approach such as partial-hash range querying is used so the full credential or complete hash is not disclosed. The exact privacy guarantee depends on the service and configuration.

A compromised credential check replaces the need for MFA or passwordless authentication.

It is a password-hygiene control targeting the knowledge factor. It does not add a possession or inherence factor and does not provide the phishing resistance associated with FIDO2/WebAuthn credentials. It complements, rather than substitutes for, MFA and stronger authentication methods.

Best practices

Run the check at credential creation, change, and reset events to prevent users from selecting known-breached passwords, and consider re-evaluation at sign-in depending on risk tolerance.

Use a privacy-preserving query model such as partial-hash range querying so full credentials or complete hashes are not exposed to external services.

Treat a positive match as a trigger for defined enforcement, such as blocking the choice or forcing a reset, and document the response in policy rather than leaving it implicit.

Combine the check with MFA or phishing-resistant authenticators, since it addresses only the knowledge factor and does not verify identity or add additional factors.

Do not treat a negative (no-match) result as proof of safety, because not all breached credentials are known; keep other credential-hygiene and monitoring controls in place.

Validate the provider's coverage, update cadence, and privacy handling against your compliance requirements, and clearly scope what the check does and does not cover in operational runbooks.