# Keep the custom banned-password list small, local, and testable > Microsoft Entra custom banned passwords are intended for organization-specific terms, not for importing a large breached-password corpus or replacing layered authentication controls. - Canonical URL: https://update.dsesecurity.com/updates/entra-custom-banned-password-list-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:28+00:00 - Modified: 2026-08-25T21:36:18+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft Entra custom banned passwords are intended for organization-specific terms, not for importing a large breached-password corpus or replacing layered authentication controls. ## Potentially affected Microsoft Entra tenants considering a custom banned-password list for cloud users or a broader password-protection deployment. ## DSE recommendation Use a short owned list of organization-specific terms, test realistic variants and user impact, and combine it with stronger authentication and account-recovery controls. ## Article 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](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection) 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. - 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. - Assign an owner and record the rationale for every term. Review for duplication, unintended language impact, and predictable variants. - Test password changes and resets with allowed and blocked examples across the actual cloud and hybrid paths. - Communicate useful guidance without publishing the complete control list. Give helpdesk staff a safe troubleshooting and escalation process. - 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](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection) — Microsoft ## Primary reference - Name: Configure custom Microsoft Entra password protection lists - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep the custom banned-password list small, local, and testable,” DSE Security, https://update.dsesecurity.com/updates/entra-custom-banned-password-list-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.