Microsoft Entra Password Protection: Blocking Weak Passwords Company-Wide

“Companyname2024!” passes every classic password policy: upper case, number, special character, long enough. It is still one of the first passwords an attacker tries. Microsoft Entra Password Protection catches exactly these passwords before they are set.

How the check works

On every password change and reset, Entra ID compares the new password against two lists: a global list Microsoft maintains from real attacks, and optionally your own list. Common substitutions are normalised first, so “C0mp@nyn4me” is checked as “companyname”. You don’t have to enter every spelling.

The global list is always on for cloud accounts and costs nothing. There is nothing to configure.

Custom banned password list

The custom list requires Entra ID P1. It lives in the Entra admin center under Authentication methods → Password protection. Set “Enforce custom list” to Yes and add terms, one per line, up to 1,000.

What I add:

• Company name, short form and former names
• Town and street of the office
• Product and brand names everyone in the company knows
• The local sports club the company sponsors, if there is one

What I don’t add: long lists of generic words. The global list already covers those, and every extra entry means more users getting rejected at password change and calling support.

Smart Lockout

Smart Lockout sits in the same menu. It briefly locks an account after too many failed attempts and distinguishes between attempts from familiar and unfamiliar locations. An attacker abroad does not automatically lock out the real user in the office. The defaults are 10 failed attempts and a 60-second lockout. That usually fits small companies; changing it again requires P1.

On-prem Active Directory: audit or enforce

Out of the box the protection only applies to passwords changed in the cloud. If you still run on-prem AD, install two components: the Password Protection Proxy on a member server and the DC Agent on every domain controller. The same banned list then also applies to Ctrl+Alt+Del → Change password.

On-prem AD has two modes:

• Audit: violations are only logged, the password is still accepted.
• Enforce: passwords that match the list are rejected.

I always start with audit and check the DCs’ event logs after a week or two to see how many password changes would have been rejected. Then you know whether to warn users first.

What it doesn’t replace

Password Protection makes bad passwords rarer. It does nothing against phishing, where users hand over their good password themselves. That needs MFA, see Conditional Access baseline policies. Once set up, though, password protection needs no further work, which is rare for a security control.