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

At a glance

What this is: This is an IAM-focused argument for checking passwords against breached-credential intelligence at reset and creation time to reduce credential stuffing and password reuse risk.

Why it matters: It matters because password integrity controls sit at the boundary between human identity governance, authentication hygiene, and broader access-risk reduction across IAM programmes.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Fischer Identity’s blog on strengthening password integrity with Have I Been Pwned

Context

Password reuse is a human identity problem, but it becomes an enterprise access problem as soon as a breached password is accepted anywhere in the authentication stack. The article’s core point is straightforward: checking new and reset passwords against breach intelligence reduces the chance that a known-compromised credential is still treated as valid.

For IAM teams, this is less about a single API integration and more about how identity governance enforces password quality at the point of change. The control belongs in the same operational family as authentication policy, reset workflow design, and audit evidence for regulated environments.

Key questions

Q: How should security teams stop users from setting compromised passwords?

A: Security teams should enforce breach-intelligence checks at the exact moment a password is created or reset. The IAM system should reject any secret that appears in known breach data and log the rejection for audit. This works best when paired with strong recovery controls and federation, so fewer passwords are used for direct access in the first place.

Q: Why does password reuse still create enterprise risk after a breach?

A: Password reuse turns a single exposed secret into a multi-system access problem. If users reuse the same password across services, attackers can attempt credential stuffing against enterprise accounts long after the original breach. Breach-aware password screening reduces that risk by refusing secrets that already circulate in the wild.

Q: What do security teams get wrong about password complexity?

A: They often treat complexity as a proxy for security. A password can be long and varied while still being exposed in public breach data or predictable enough to crack quickly. Effective policy must block known bad passwords, not just enforce character rules.

Q: Who is accountable when a compromised password cannot be reset quickly enough?

A: Accountability should sit with the identity governance and incident response functions together, because password recovery is both a security control and an operational response. If reset ownership is split across help desk, platform teams, and security without a single governance model, delays are predictable and the blast radius grows.

Technical breakdown

Breach-intelligence password checks in reset workflows

A breached-password check compares a candidate password against a database of known compromised credentials before the password is accepted. In practice, the check happens at password creation or reset, so the user never moves into an authenticated state with a known-bad secret. This is different from detecting reuse after the fact. The control only works if the IAM platform can invoke the check synchronously and block the transaction when the password appears in breach data. That makes the reset workflow part of the control plane, not just a user convenience layer.

Practical implication: enforce breach checks at the moment of password creation or reset, not in a later audit sweep.

Why password reuse turns one breach into enterprise access risk

Password reuse collapses the value of perimeter separation. If the same password appears on multiple external services, one compromise can create a credential-stuffing path into internal systems that still accept the same secret. The real danger is not only the original leak but the long tail of reuse across applications, users, and time. IAM policy therefore has to treat password choice as a control over downstream access exposure, not merely a password-strength exercise. That is why breach-derived deny lists are more effective than complexity rules alone.

Practical implication: pair compromised-password blocking with reuse-aware password policy and SSO wherever possible.

Compliance evidence from authentication controls

Compromised-password rejection can support compliance because it creates a measurable control outcome. Auditors do not only ask whether a policy exists; they look for evidence that the policy is enforced consistently and that risky credentials are prevented from entering the environment. In IAM terms, that means the organisation can show that password governance is tied to active breach intelligence, policy enforcement, and workflow logging. This matters most where regulators expect demonstrable due diligence around access control and authentication assurance.

Practical implication: retain logs showing rejected compromised passwords and the policy path that enforced the block.

Threat narrative

Attacker objective: The attacker aims to turn one exposed password into repeatable account access across multiple services and users.

1. entry via reused or previously breached passwords that remain acceptable in downstream services.
2. credential access through credential stuffing attempts that succeed because the password is already known to attackers.
3. impact through unauthorised account access, lateral access to other services, and avoidable incident response effort.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Breached-password screening is a governance control, not a user-experience feature. The article frames Have I Been Pwned as a practical check inside password workflows, but the deeper point is that IAM is deciding whether a secret has already lost trust outside the organisation. That is a governance decision about identity integrity, not just a convenience enhancement. Teams should treat the control as part of their authentication assurance model, not as an optional add-on.

Password reuse remains the weakest link between consumer breach data and enterprise identity risk. Once a password has appeared in a breach corpus, the enterprise no longer owns the full risk picture if that password can still be accepted internally. This is where human identity governance and breach intelligence intersect: the same credential can be harmless in one system and catastrophic in another. Practitioners should recognise that password policy without breach intelligence is incomplete.

Compromised-password checks expose the gap between policy intent and policy enforcement. Many organisations say they block weak passwords, but static complexity rules do not catch known-bad credentials that already circulate in the wild. The article’s model works because it tests the candidate password against external evidence at the point of enforcement. That distinction matters for compliance teams because an enforced control is evidence, while a policy document is only intent.

Credential integrity will increasingly be judged by continuous verification rather than one-time composition rules. As threat actors industrialise credential abuse, the useful question is no longer whether a password is technically complex enough, but whether it is still trustworthy given current breach data. That shifts IAM teams toward live risk signals and away from formulaic password checklists. The practitioner conclusion is clear: password governance must be dynamic if access is to remain defensible.

Breached-password screening belongs in the same lifecycle conversation as account recovery and offboarding. Password control is not isolated from the rest of IAM. If a compromised credential is accepted during recovery, reset, or exception handling, the strongest policy can still fail at the edge. Organisations should therefore judge password integrity controls as part of the full identity lifecycle, not as a single technical gate.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs , Key Challenges and Risks.
• For lifecycle and remediation context, see Ultimate Guide to NHIs for how exposure, rotation, and offboarding controls fit together.

What this signals

Password integrity controls are becoming part of the broader identity hardening conversation because breach intelligence gives IAM teams a live signal that static policy cannot provide. If organisations continue to rely only on length and composition rules, they will keep accepting secrets that attackers already own. The operational shift is toward evidence-based rejection at the point of change, supported by NIST Cybersecurity Framework 2.0 alignment and identity governance logging.

Credential trust debt: passwords accepted today can already be compromised elsewhere, which means the programme inherits hidden risk every time a reset workflow fails to screen them. That makes password governance a lifecycle issue, not a one-time authentication setting. Teams responsible for human identity, IGA, and PAM should review whether recovery, exception handling, and self-service resets are creating avoidable exposure.

For readers maturing their identity programme, the useful question is whether breach-aware password controls are embedded everywhere they should be, not just in one privileged path. The gap often appears in adjacent workflows such as help desk resets, temporary access recovery, and legacy applications. A control that is inconsistent across those paths will not materially reduce credential abuse.

For practitioners

• Enforce breached-password blocking at reset and creation Place the check directly in the password set and reset workflow so compromised credentials are rejected before they can authenticate. Use synchronous enforcement, not a later review job, and log each rejection for audit evidence.
• Treat password reuse as an identity governance issue Map password reuse risk to the same governance owners who oversee authentication policy, exception handling, and account recovery. Use breach intelligence to complement complexity rules rather than relying on length and character classes alone.
• Instrument audit evidence for rejected compromised passwords Retain workflow logs that show when a candidate password matched breached data, which policy blocked it, and which identity context triggered the decision. That evidence supports compliance review and shows the control is actually operating.
• Reduce reliance on passwords where federation is available Move users toward stronger authentication patterns where the password is not the primary secret in day-to-day access. Federation and SSO do not eliminate password risk, but they reduce the number of places where a reused password can be exploited.

Key takeaways

• Breach-aware password screening is a practical control for stopping known-compromised secrets from entering the IAM environment.
• Password reuse remains a durable access risk because one leaked credential can be reused across multiple services and attack paths.
• The governance test is enforcement, not policy wording: if the control is not embedded in reset and recovery workflows, it is not materially reducing risk.

Key terms

• Breached-Password Screening: Breached-password screening is the practice of rejecting passwords that appear in known compromise datasets. It stops reused or already exposed credentials at the moment of creation or reset, which is often the most effective place to interrupt credential-stuffing and account takeover attempts.
• 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 Reuse Risk: Password reuse risk is the tendency for a compromised credential to unlock multiple accounts or services when the same password is used in more than one place. It turns a single exposure into a broader access event and is one of the most persistent weaknesses in identity governance.

What's in the full article

Fischer Identity's full blog covers the operational detail this post intentionally leaves for the source:

• The exact workflow points where the Have I Been Pwned check is invoked during password reset and creation.
• The operational explanation of how the integration fits into a broader IAM and IGA stack.
• The compliance framing the vendor uses for auditors, policy owners, and risk teams.
• The product-specific implementation context for organisations already using Fischer Identity.

👉 The full Fischer Identity post covers the integration context, password policy implications, and compliance angle in more detail.

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 building or maturing an IAM programme, it is worth exploring.