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.
Why This Matters for Security Teams
Rejecting compromised passwords is not just a hygiene control. It is a live risk-reduction measure that blocks attackers from turning a single leaked secret into account takeover, privilege escalation, or downstream lateral movement. The strongest programs check passwords at creation and reset time, not only during periodic audits, because a password can be safe today and appear in breach data tomorrow. Current guidance also treats password controls as part of a broader identity strategy, not a standalone fix.
For NHI Management Group, the same logic applies across identities: secrets fail when they are long-lived, reused, or exposed in places security teams do not continuously inspect. The The 52 NHI breaches Report and the Ultimate Guide to NHIs — Why NHI Security Matters Now both show why secret exposure becomes operational debt when identity controls lag behind attacker automation. In practice, many security teams only discover the problem after a reset flood, credential stuffing wave, or breach notification has already forced emergency action.
How It Works in Practice
The control should sit inside the identity workflow so that every password create or reset request is evaluated in real time. At minimum, the IAM or password service should compare the candidate secret against breached-password intelligence, deny known-compromised values, and record the decision for audit and incident review. Best practice is evolving, but most mature programs also add length, complexity, and phishing-resistant recovery controls so users are less likely to recycle weak patterns.
This is most effective when paired with federation and strong recovery paths. If users can sign in through SSO or passkeys, the organisation reduces how often passwords are even needed. That matters because password policy alone cannot stop reuse across sites or stop an attacker from testing a stolen secret at scale. For related identity risk patterns, the Ultimate Guide to NHIs — Why NHI Security Matters Now shows how long-lived secrets amplify exposure across the estate. External guidance from the Anthropic — first AI-orchestrated cyber espionage campaign report also reinforces that automated abuse scales quickly once attackers obtain valid credentials.
- Check passwords at create and reset time, not only on a schedule.
- Block known-breached secrets before the account is activated.
- Log rejections with enough context for audit and detection tuning.
- Reduce password dependence with SSO, federation, and phishing-resistant recovery.
- Review exception handling so admins cannot bypass the check without oversight.
These controls tend to break down in legacy applications that only support local password stores, because identity teams cannot enforce a consistent real-time check at the actual point of credential issuance.
Common Variations and Edge Cases
Tighter password screening often increases user friction and support load, requiring organisations to balance stronger prevention against login and reset delays. There is no universal standard for exactly how much breach-intelligence coverage is enough, so teams usually define an acceptable source set and update it as their threat model matures.
Some environments need additional nuance. Shared-admin accounts, offline systems, and emergency break-glass credentials may require separate policy paths, but they should still be monitored for reuse and exposure. Password screening also does not solve weak recovery design: if attackers can reset accounts through low-assurance email or help desk workflows, the check at password creation only narrows one avenue of abuse. The strongest programs treat compromised-password rejection as one layer inside a broader identity assurance model, not as a substitute for MFA, federation, or privileged access management.
For organisations extending the same discipline to machine identities, the lesson is consistent: long-lived secrets create recurring exposure. That is why NHI governance increasingly focuses on rotation, revocation, and short-lived credential use rather than relying on a single static secret forever.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and exposure risk, which is adjacent to rejected compromised passwords. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control support rejecting weak or compromised credentials. |
| NIST SP 800-63 | 5.1.1.2 | Password verifier guidance addresses blocked compromised passwords during authentication lifecycle. |
| NIST Zero Trust (SP 800-207) | PA-2 | Zero Trust requires continuous verification rather than trusting a password once accepted. |
| NIST AI RMF | GOVERN | Governance is needed to define password-risk policy, exceptions, and auditability. |
Embed breached-password checks into account creation and reset workflows under access control governance.
