Blocklist screening checks a chosen password against known-bad values before it is accepted. The list should include breached passwords, common patterns, and organisation-specific terms that attackers can guess quickly, making it a preventive control at creation and reset time.
Expanded Definition
Blocklist screening is the control that rejects a password if it matches a known-bad value before the credential is accepted. In NHI and IAM programs, that screening usually happens at account creation, password reset, or forced rotation, and it should cover breached passwords, predictable patterns, organisation-specific terms, and other values attackers can guess quickly.
Definitions vary across vendors on whether a blocklist is only a strict exact-match list or a broader rule set that also catches variants, leetspeak substitutions, and contextual terms. In practice, the strongest implementations treat it as part of a layered password quality check rather than a standalone denial list. That matters because a password can be technically unique yet still remain guessable if it is derived from the system name, environment label, or a reused organisational phrase. The NIST Cybersecurity Framework 2.0 reinforces the need for identity controls that reduce predictable access paths, while NHI governance extends that logic to service accounts and automation secrets as well as human users.
The most common misapplication is treating blocklist screening as a one-time UI validation, which occurs when organisations fail to apply the same check consistently across resets, APIs, and identity workflows.
Examples and Use Cases
Implementing blocklist screening rigorously often introduces user friction, requiring organisations to weigh faster enrolment against the cost of rejecting weak but memorable passwords.
- A developer is blocked from using a password that includes the company name plus a year, because attackers can predict that pattern during credential stuffing.
- An identity platform rejects a reset attempt when the proposed password appears in a breached-password corpus, even if it meets length and complexity rules.
- A help desk workflow screens new passwords for environment-specific terms such as project codes, app names, or regional office labels that appear in internal documentation.
- A privileged service portal applies the same screening logic at rotation time so that an operator cannot reintroduce an easily guessed secret during a routine change.
For NHI programs, this matters alongside broader lifecycle controls described in the Ultimate Guide to NHIs, especially where shared patterns or naming conventions make credentials easier to guess. Screening should also align with guidance from NIST Cybersecurity Framework 2.0 so the control is applied consistently across identity processes rather than only at initial registration.
Common use cases include protecting administrator logins, enforcing safe password resets, and preventing recurring weak choices after credential expiration or offboarding events.
Why It Matters in NHI Security
Blocklist screening is more than a password hygiene feature because predictable credentials are often the easiest path into automation, orchestration, and privileged machine access. When this control is weak, attackers do not need to defeat cryptography, they only need to guess what a team will accept. That is especially dangerous in NHI environments where service accounts, API-facing portals, and operational consoles may share naming patterns or internal jargon that are easy to infer.
NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which shows how quickly weak credential selection can become an operational incident. The same research notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which compounds the risk when predictable passwords or passphrases are allowed to persist. A mature blocklist should therefore be updated with breached-password intelligence, local naming conventions, and terms attackers can derive from public artifacts and internal documentation. The control also supports stronger posture across Ultimate Guide to NHIs guidance on secret handling and identity lifecycle discipline.
Organisations typically encounter the business impact only after a credential stuffing event or unauthorized access attempt, at which point blocklist screening becomes operationally unavoidable to address.
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-02 | Covers weak secret selection and secret reuse risk in NHI environments. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control support rejecting weak credentials at enrollment. |
| NIST SP 800-63 | 5.1.1.2 | Password verifiers should compare against compromised and commonly used values. |
| NIST Zero Trust (SP 800-207) | Zero Trust relies on strong identity controls to reduce easy initial compromise paths. | |
| NIST AI RMF | GOVERN | Risk governance should address predictable credential selection as an avoidable hazard. |
Document screening rules, test them routinely, and update blocklists from threat intelligence.
Related resources from NHI Mgmt Group
- What breaks when background screening relies too heavily on manual review?
- How should organisations implement continuous PEP screening without overwhelming compliance teams?
- What breaks when fraud screening and payment approval are managed separately?
- How should teams govern BYOK credentials in compliance screening workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
