Password integrity controls for IAM: what Have I Been Pwned adds

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Fischer Identity's blog post: Have I Been Pwned checks can stop breached passwords from being accepted in IAM workflows while strengthening governance and compliance evidence.

Why it matters: It matters because IAM teams still rely on password rules that do not detect known-compromised credentials, leaving reset and enrollment paths open to reuse-driven account takeover.

Context

Password integrity is the governance problem here, not password complexity alone. If an IAM programme accepts a password without checking whether it already appears in breach data, it can enforce policy on paper while still admitting a known-compromised credential into production.

The article focuses on a practical control point inside reset and creation workflows. That is where identity teams can intercept reuse before it becomes an authentication risk, an audit finding, or a downstream incident tied to credential stuffing.

For IAM and IGA teams, the key question is whether password policy is measured against live threat intelligence or against a static rule set that attackers already understand.

Key questions

Q: What breaks when IAM lets users set passwords without breach screening?

A: The policy breaks at the point of acceptance, because a password can satisfy local complexity rules and still be known-compromised. That creates a gap between written control and real credential risk. The result is repeat exposure through reused passwords, support resets, and account takeover attempts that start outside the organisation but land inside it.

Q: Why do breached-password checks reduce credential stuffing risk?

A: They reduce risk by removing the attacker’s cheapest input: a password already proven to work somewhere else. Credential stuffing depends on reuse and scale, so every rejected compromised password cuts off one path into the enterprise. The control does not stop all attacks, but it materially lowers the number of credentials available for automated abuse.

Q: How can organisations tell whether password governance is working?

A: They should measure ticket reduction, reset completion time, audit trail quality, and whether emergency recovery works across all connected identity systems. A good programme shortens recovery without creating uncontrolled privilege, inconsistent policy enforcement, or gaps in post-incident review.

Q: Should organisations use breached-password checks in addition to MFA?

A: Yes, because they address different problems. MFA reduces the value of a stolen password, while breached-password screening reduces the chance that a stolen password is accepted in the first place. Organisations that treat them as substitutes leave a gap between authentication hardening and credential quality control.

Technical breakdown

How breached-password screening works inside IAM workflows

Have I Been Pwned screening is a credential validation step that compares a proposed password against a breach corpus before the password is accepted. In practice, the control belongs at creation and reset time, because that is when the organisation still has leverage over credential quality. The security value is not the API call itself. It is the ability to stop a known-bad secret from entering the identity estate in the first place. That makes the check a preventative IAM control, not a detective one.

Practical implication: place breached-password screening in the password issuance path, not as a post-facto review.

Why password reuse turns one breach into enterprise-wide exposure

Password reuse creates an identity translation problem for defenders. A password exposed in one breach can be tried against unrelated services, which is why credential stuffing remains effective even when individual applications enforce their own login protections. IAM teams should treat reuse as a lifecycle issue, because the risk starts when the password is chosen and persists until it is changed everywhere it is used. Live breach checking narrows that window by preventing the same credential from re-entering the organisation after it has already failed elsewhere.

Practical implication: treat password reuse as a lifecycle governance issue that belongs in joiner, mover, and reset flows.

Password integrity controls as an audit and compliance signal

A breached-password check is also an evidence mechanism. Auditors care less about whether a password policy exists than whether the control actually prevents known-compromised credentials from being accepted. That is why live breach intelligence is more defensible than static minimum-length rules alone. The governance signal is simple: the organisation is enforcing password integrity against current breach data, not merely documenting policy language. In mature programmes, that creates a measurable control point for compliance, exception handling, and exception closure.

Practical implication: capture rejected compromised-password events as audit evidence for password governance and control effectiveness.

Threat narrative

Attacker objective: The attacker wants to turn one exposed password into repeatable access across multiple accounts and services.

1. Entry occurs when a reused password that has already appeared in breach data is accepted into an IAM workflow or reused across another service.
2. Credential access follows because attackers can test that reused password against other accounts through credential stuffing and similar automated attempts.
3. Impact is unauthorized account access that can cascade into data exposure, privilege misuse, or broader identity compromise.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Breach-intelligence checks are now a password governance control, not a convenience feature. Static complexity rules tell you almost nothing about whether a password has already been exposed elsewhere. Once IAM workflows can reject known-bad passwords at the moment of creation or reset, password policy becomes enforceable against current threat data. The practitioner conclusion is that password governance should be measured by breach-aware enforcement, not by length and character mix alone.

Password reuse is the real control failure, because it links external exposure to internal authentication risk. A single compromised password can move from one environment to many when users repeat it. That means the governance problem is not just user behaviour, but the absence of a control that can recognize a credential as already burned. The practitioner conclusion is that password policy must assume external compromise has already happened.

Compromised-password screening creates a named concept we should treat explicitly: credential integrity validation. This is the discipline of validating a proposed secret against live breach intelligence before the identity system accepts it. It sits between password policy and authentication assurance, and it closes the gap between written standards and real-world credential risk. The practitioner conclusion is that identity programmes need this as a control objective, not a feature request.

The compliance value comes from demonstrable prevention, not retrospective reporting. Audit teams do not gain much from a policy that merely says compromised passwords are prohibited. They gain from evidence that the IAM platform actively blocks them and records the attempt. The practitioner conclusion is that password governance should produce verifiable control events, not just policy statements.

This is a lifecycle problem as much as an authentication problem. If a compromised password can be set during onboarding, reset during support, or reintroduced after an incident, the organisation has not governed the credential lifecycle. The practitioner conclusion is that identity teams should place breach-intelligence checks at every credential issuance point that matters.

What this signals

Credential integrity validation: IAM programmes need a control that judges a proposed password against live breach intelligence before it is accepted. That shifts password governance from static rules to real-world credential risk, which is where account takeover pressure actually begins.

Breach-aware password enforcement also changes how teams think about evidence. A blocked compromised password is not just a security event, it is proof that the control operated at the moment it mattered, which strengthens audit readiness and exception management.

For practitioners

• Implement breached-password screening at reset and creation time Make password acceptance conditional on live breach-data checks so known-compromised passwords are rejected before they enter production identity flows.
• Log rejected passwords as governance evidence Retain event records for blocked compromised-password attempts so security, audit, and compliance teams can demonstrate control operation.
• Apply the same control to self-service and help desk resets Ensure both user-driven and support-driven password changes use the same breach-checking logic, because bypass paths are where governance drift appears.
• Review exception handling for legacy reset flows Identify any password change path that can still accept a credential without breach screening, then remove or tightly govern that exception.

Key takeaways

• Breach-intelligence checks change password policy from a static rule set into a control that can reject known-compromised credentials at the point of use.
• Password reuse remains the key enterprise risk because one exposed password can fuel repeat access attempts across multiple services.
• IAM teams should treat blocked compromised-password events as governance evidence and apply the same enforcement across every reset path.

Key terms

• Breach Intelligence: Breach intelligence is data about identities or credentials that have appeared in known security incidents. It helps teams determine whether an email address, username, phone number, or password has been exposed, so onboarding and access decisions can account for preexisting risk instead of assuming the identity is clean.
• Credential Stuffing: Credential stuffing is an attack that uses stolen username and password pairs from previous breaches to try logging into other services. It works because many people reuse credentials, and because the login attempt uses valid information, it can look ordinary until the surrounding behavior gives it away.
• Password Integrity: Password integrity is the degree to which a password is both policy-compliant and not already known to be compromised. It is stronger than complexity alone because it measures real-world trustworthiness, not just formatting or length requirements.
• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.