Configure a custom banned password list by adding organisation-specific words, names, brands, and other predictable terms that users should not use in passwords. Keep the list focused on terms attackers can guess, review it regularly, and test that your password policy still allows strong passphrases while rejecting common variations and substitutions.
What a custom banned password list actually does in Entra ID
A custom banned password list is the part of microsoft entra id password protection that rejects organisation-specific passwords before they can be set. It works best when you treat it as a targeted blocklist for predictable terms, not as a general password policy. The goal is to stop users from turning company names, product names, or internal jargon into weak passwords.
The list is most effective when it complements, rather than replaces, strong password length and passphrase guidance. Entra ID should still allow long, unique passphrases, while blocking easy guesses and obvious variants such as swapped characters, added numbers, or punctuation. That balance matters because a broad blocklist can frustrate users without materially improving resistance to guessing.
Administratively, the question is not just what to block, but what attackers are likely to try first. Names of the organisation, brands, executive names, internal systems, seasonal themes, and commonly repeated slogans are all good candidates if they are predictable and widely known. Keep the list tight enough to remain maintainable, but broad enough to catch obvious mutation patterns.
How to build the list so it is useful instead of noisy
Start with terms that are highly visible outside the company and easy to derive from public information or social media. Add words that users naturally anchor to when inventing passwords, especially company branding and business-unit names. Avoid overfilling the list with obscure internal terms that attackers are unlikely to guess and users are unlikely to choose.
It also helps to think in terms of patterns, not just exact strings. Users often try leetspeak, added years, repeated symbols, or plural forms. A good list therefore targets the root word and enough predictable variants to block the common bypasses, while still allowing strong passphrases that are unrelated to the organisation.
For password hygiene programmes, this is where governance matters. Review the list after brand changes, mergers, major product launches, and public incidents, because those events change what users may be tempted to include and what attackers may now know. The Password Security and Password Manager Guide is useful background for deciding how a blocklist fits into a broader password strategy.
Where custom banned passwords fit in an Entra ID hardening plan
A custom banned password list is a defensive control, but it only works well when paired with other identity hardening measures. If users can still reuse passwords across systems, fall for phishing, or enroll weak recovery options, the blocklist only reduces one avenue of guessing. It should sit alongside passwordless adoption, stronger authentication, and account protection for privileged access.
In Microsoft environments, the control is also most valuable when the tenant has a clear boundary between ordinary user accounts and high-value administrative access. The Active Directory and Entra ID Hardening Guide covers the surrounding controls that make password protection more meaningful, especially where identity compromise would have broader tenant impact.
If your environment still relies heavily on passwords, do not treat the banned list as a one-time setup task. Tune it after testing, monitor helpdesk friction, and watch for repeated attempts to use the same blocked themes. That feedback tells you whether the list is catching realistic guesses or just adding noise.
Risk and Threat Considerations
Custom banned password lists reduce the chance that users will choose passwords based on public or organisation-specific information, but they do not stop credential stuffing, phishing, or weak passwords chosen outside the blocklist. The main risk is false confidence: a good list can block obvious guesses while leaving the account still vulnerable to password reuse or compromise.
Failure mechanism: Users often substitute characters, add digits, or append years to a blocked word, and attackers already test those variants automatically. If the list is too narrow, predictable passwords still get through; if it is too broad, users may respond by choosing awkward but still guessable patterns.
Impact: Weak or predictable passwords increase successful guessing, reuse, and targeted account compromise, especially for common organisation names and internal terms. Poor tuning can also create user workarounds, which weakens adoption and makes the policy harder to enforce consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Guides password blocklists and strong authenticators for identity assurance. |
| Recommendation — Align password policy with phishing-resistant authenticators and targeted password screening. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers password lifecycle and screening controls for authenticators. |
| Recommendation — Apply password screening and lifecycle controls to reject predictable credentials. | ||
| CIS Controls v8 | 5 — Account Management | Supports enforcing strong account credential practices across users. |
| Recommendation — Use account management safeguards to reduce weak password selection and reuse. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supports governing access with appropriate authentication rules and password policy. |
| Recommendation — Define and enforce access control rules that include password protection requirements. | ||
Practitioner Guidance
What to prioritise: Build the list from terms that are both public and guessable, then test it against obvious variants before rollout. Focus on names and brands users are most likely to choose, not on exhaustive internal vocabulary.
What to verify: Confirm that the policy blocks predictable organisation-specific passwords while still allowing long passphrases that are unrelated to the company. If users start complaining that strong passphrases are being rejected, the list is probably too aggressive or poorly curated.
Decision rule: If a candidate word would be easy for an attacker to infer from public information, add it; if it is only known internally and unlikely to appear in password choice, leave it out unless testing shows people actually use it.
Practitioner takeaway: The best custom banned password list is small, current, and attacker-minded, because its job is to stop predictable choices without turning password creation into a guessing game for legitimate users.