A banned password list is a curated set of passwords that users are not allowed to choose because they are common, predictable, or already exposed in breaches. In practice, it is used during password creation and reset to block unsafe secrets before they enter the environment.
Expanded Definition
A banned password list is a preventive control that blocks known-bad passwords before they are accepted during enrollment, rotation, or reset. In NHI security, the idea extends beyond human user accounts because service accounts, shared automation accounts, and admin consoles often inherit the same weak secret patterns, especially when teams reuse names, product terms, or predictable variants. The control is strongest when paired with password-length rules, breach corpus screening, and checks for organisation-specific terms that attackers can guess from public sources.
Definitions vary across vendors on how aggressively the list should be maintained. Some implementations rely on a static dictionary, while others compare candidate passwords against breached-password datasets and contextual terms from the organisation. For governance, the practical question is not whether a password looks complex, but whether it is resistant to guessing, replay, and credential stuffing. That is why a banned password list should be treated as part of broader identity hygiene, not as a standalone substitute for authentication policy. The most common misapplication is using a short, generic dictionary, which occurs when organisations fail to include breached passwords and context-specific terms.
Examples and Use Cases
Implementing a banned password list rigorously often introduces some friction at password creation, requiring organisations to weigh stronger resistance to guessing against occasional user and operator inconvenience.
- Blocking common passwords such as seasonal words, keyboard patterns, and simple substitutions during account creation.
- Rejecting secrets that appear in breach datasets so reused credentials never enter service account workflows.
- Preventing administrators from setting predictable passwords for break-glass or recovery accounts.
- Filtering passwords that contain the organisation name, product name, or environment labels that attackers can infer.
- Using the same screening logic for human accounts and privileged automation accounts so policy is consistent.
For teams building NHI governance, this matters because weak credential choices often become the first link in a larger compromise chain. The Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. External guidance such as the NIST Cybersecurity Framework 2.0 reinforces the need for defensive identity controls that reduce exposure before access is granted.
Why It Matters in NHI Security
Banned password lists matter because non-human identities are often targeted through weak, guessed, or recycled credentials rather than sophisticated exploitation. If a password policy allows obvious choices, attackers can move quickly from exposure to access, especially where service accounts have elevated privileges or broad trust relationships. This becomes even more important in environments where secrets are stored in CI/CD systems, code repositories, or config files, because a predictable password can turn a single mistake into repeated compromise across pipelines and services.
NHIMG research shows that 97% of NHIs carry excessive privileges, which means a weak password on the wrong account can magnify impact far beyond the initial foothold. A banned password list is therefore not just a compliance detail; it is a practical barrier against credential guessing and reuse in a domain where identities outnumber human users by a wide margin. The Ultimate Guide to NHIs also reports that only 20% of organisations have formal offboarding and revocation processes for API keys, which makes prevention at password set time even more valuable. Organisations typically encounter the need for strict banned-password controls only after a secret is reused in an incident, at which point the policy 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 and NIST SP 800-63 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 handling and blocking unsafe credential choices for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access protection includes rejecting weak credentials at set or reset time. |
| NIST SP 800-63 | 5.1.1.2 | Password-based authenticator guidance includes screening against commonly used and compromised passwords. |
Screen all passwords and secrets against banned terms and breached lists before acceptance.
