Azure AD Password Protection: Microsoft Entra Banned Password Lists Explained

Azure AD Password Protection: Microsoft Entra Banned Password Lists Explained

Originally published 16 October 2020 · Reviewed 5 November 2026

Microsoft Entra password protection, which was called Azure AD Password Protection until 2023, stops users choosing passwords that attackers guess first. It checks new passwords against a banned list when people change or reset them, in the cloud and optionally in on-premises Active Directory. It does not replace MFA, but it closes a gap that complexity rules leave open: "Summer2026!" meets most complexity rules and is still a bad password.

The two banned lists

The global banned password list. Microsoft maintains this list. It is not published, and Microsoft updates it based on what its security analysis finds in real attacks, so it improves without work from you. Every password change or reset in a tenant is checked against it.

The custom banned password list. You can add terms specific to your organisation, such as brand and product names, office locations, internal project names or abbreviations that outsiders could guess. Microsoft documents these limits: up to 1,000 terms, case-insensitive, with a minimum length of 4 characters and a maximum of 16. You do not need to add every variant, because the evaluation allows for common character substitutions.

How a password is evaluated

Microsoft describes a short process. First the password is normalised: letters are converted to lower case and common substitutions are mapped back, so that characters such as "0" and "@" are treated as letters they imitate. Then the service looks for banned terms in the normalised password, using fuzzy and substring matching rather than only exact matches. Finally the password is scored: each banned term found counts for one point, and each remaining unique character counts for one point. Microsoft states that a password needs a minimum score of five points to be accepted.

The consequence is that adding a digit or symbol to a banned word is not enough, and that a long passphrase with several unrelated words can pass, while a banned word padded with a few characters will not. Users who are rejected see a message that the password is easily guessable or blocked by the administrator.

Cloud and on-premises

For cloud accounts, the feature needs no extra infrastructure. In the Microsoft Entra admin center you add your custom terms and choose whether the policy is enforced or in audit mode.

For on-premises Active Directory, Microsoft provides two components. A proxy service runs on a member server and talks to Microsoft Entra ID to download the policy. A domain controller agent is installed on each domain controller and applies the policy when passwords are set. You can start in audit mode to see what would be rejected before you enforce it. This extends the same checks to passwords changed on the domain, so attackers cannot rely on the on-premises path being weaker. Microsoft's documentation lists the supported operating systems and the Active Directory requirements, which change with releases, so read them before you design.

Licensing

Microsoft's guidance is that the global banned list applies to all Microsoft Entra users, and that custom banned lists and on-premises protection need Microsoft Entra ID P1 or higher. Check the current licensing page for the final word. Microsoft 365 Business Premium and E3 include P1.

Rollout steps

1. Choose your custom terms. Start with company, product and place names. Do not put real passwords in the list.
2. Start in audit mode, especially for on-premises domain controllers, and review how many changes would have been rejected.
3. Tell users what is changing. Give examples of good passphrases and explain that rejection is about guessability, not about complexity.
4. Deploy the on-premises components to all domain controllers. A domain controller without the agent will accept passwords the policy would reject.
5. Switch to enforce mode after a few weeks, and keep an eye on help desk contacts.
6. Combine with MFA and self-service reset so that an accepted password is also protected by a second factor.

What it does not do

Password protection does not detect leaked passwords for existing accounts; it only checks new ones. It does not remove the need for multifactor authentication, and it cannot stop users reusing a password they chose elsewhere unless the banned list happens to include it. Treat it as one layer in addition to MFA, Conditional Access and sign-in monitoring. Over time, move people to passwordless methods, which remove this problem at the source.

Choosing good custom terms

A short, well chosen list works better than a long one. Include the trading name, the short form that staff use in conversation, product and service names, the city or office names, and the names of internal systems that appear in emails and signatures. Leave out generic words that the global list already covers, because they use up your 1,000 slots without adding value. Review the list when the company launches a product or opens an office, and keep a note of who owns it. Remember that the list is not secret from administrators, so it should hold guessable words, never real passwords or anything personal.

Microsoft references

• Eliminate bad passwords using Microsoft Entra Password Protection, reviewed 5 November 2026.
• Enforce on-premises Microsoft Entra Password Protection for Active Directory Domain Services, reviewed 5 November 2026.
• Microsoft Entra licensing, reviewed 5 November 2026.

This article was first published on 16 October 2020. It was rewritten on 5 November 2026 with current product names. Microsoft's live documentation takes precedence if it has changed.