Keep the custom banned-password list small, local, and testable

Bottom line: Microsoft Entra provides a global banned-password list and an optional custom list for locally meaningful terms such as brand names, products, locations, and abbreviations. Microsoft says the custom list is not designed to hold a large list of passwords. Build a focused control that can be explained, tested, and maintained.

Source fact: what Microsoft documents

Microsoft’s custom password-protection tutorial explains that the custom list works alongside Microsoft’s global banned-password list. A password-change or reset request is rejected when the candidate password matches the evaluation performed against these lists.

The documentation describes concrete boundaries: the custom list supports up to 1,000 terms, treats entries case-insensitively, considers common character substitutions, and accepts terms from four through sixteen characters. Microsoft explicitly says it is not designed for blocking large password lists. Updates can take time to apply. The tutorial also lists tenant, role, and license prerequisites and notes that its web reset test assumes self-service password reset is configured.

What the source does not establish

The list does not detect every compromised, reused, predictable, or contextually weak password. It does not evaluate passwords until a change or reset operation occurs, and it does not force existing users to choose a new password merely because a term was added. It is not a substitute for MFA, phishing-resistant authentication, monitoring, recovery design, or on-premises deployment components where those are needed.

Applicability questions

• Are the users cloud-only, synchronized, or on-premises AD DS users, and where is the password set or changed?
• Which organization-specific words are genuinely predictable to an attacker?
• Could a proposed term create excessive false rejections because it is short, common, or part of ordinary language?
• Are the required licenses, administrator role, SSPR configuration, and any on-premises agents present?
• Who will review the list after rebranding, mergers, new products, or location changes?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Start with a small list derived from public organization names, common abbreviations, prominent products, locations, and campaigns. Do not paste a breached-password dump into this feature.
2. Assign an owner and record the rationale for every term. Review for duplication, unintended language impact, and predictable variants.
3. Test password changes and resets with allowed and blocked examples across the actual cloud and hybrid paths.
4. Communicate useful guidance without publishing the complete control list. Give helpdesk staff a safe troubleshooting and escalation process.
5. Review the list at least after material naming changes and alongside the wider authentication strategy.

Verification and evidence

• Preserve the approved term list, rationale, owner, change date, and policy configuration.
• Record successful tests for exact terms, case changes, common substitutions, permitted passwords, and applicable on-premises paths.
• Monitor password-change and reset support issues after rollout without collecting user passwords.
• Confirm the global and custom protections are supplemented by the intended MFA and recovery controls.

Official references

• Configure custom Microsoft Entra password protection lists — Microsoft