Entra ID password protection: what it does not block

Entra ID password protection stops a user setting a password that scores badly against a banned list, and most tenants switch it on believing it blocks the passwords an attacker would actually try. It does not. The custom list caps at 1,000 terms, the scoring algorithm accepts anything reaching five points, and a domain controller that cannot reach its policy accepts every password put to it. Here is what the feature checks, what those numbers mean in practice, and the failure that fails open.

This is a control on what a password may be, not on what a sign-in may do. It runs at the moment a password is set or changed and has no opinion about anything afterwards. Everything that happens at sign-in time, including whether a correct password is enough on its own, belongs to the Conditional Access policy design guide. Treating a banned password list as a substitute for that layer is the most common mistake in this area.

One disclosure. My tenant is a lab with no enrolled devices and no on-premises forest carrying real accounts, so I have not watched a fleet of domain controller agents process production password changes. What follows is documented behaviour, verified against Microsoft Learn on 5 September 2026, plus the places where I would expect it to hurt.

What Entra ID password protection actually scores

The check is not a string comparison against a blocklist. Microsoft normalises the candidate password first, then scores what is left.

Normalisation does two things. Every uppercase letter is lowered, and common character substitutions are collapsed: 0 becomes o, 1 becomes l, $ becomes s, @ becomes a. By the time scoring starts, P@ssw0rd and password are the same string. That part works well, and it catches the substitution habits users believe are clever.

Scoring is where the design shows itself. Each banned term found inside the normalised password is worth one point. Each remaining character that is not part of a banned term is also worth one point. A password needs at least five points to be accepted. Microsoft’s own worked example on the password protection reference is ContoS0Bl@nkf9!, which scores [contoso] + [blank] + [f] + [9] + [!], reaches exactly five points, and is accepted.

Read that example again. Fifteen characters, two banned terms, and it passes with nothing to spare. A password built from one banned word plus four unrelated characters clears the bar. That is intended behaviour rather than a defect: the feature is a floor under the worst passwords, not a measure of strength. Anyone selling it internally as protection against credential stuffing has misread it.

You also cannot audit what the global list covers. Microsoft states plainly that it does not publish the contents of the global banned password list, so there is no way to demonstrate that a particular password is caught except by trying to set it.

The licence line that catches hybrid tenants

The second row is the one people miss. The global list is free for cloud only users and licensed for synchronised users, so a hybrid tenant on free licensing gets nothing from this feature at all, including the part everybody assumes is included. Microsoft adds that on-premises accounts which are not synchronised still benefit, based on the existing licensing for the accounts that are, which is a generous reading and worth knowing before a licensing conversation. If you are still weighing the two identity tiers, the Entra ID P1 and P2 comparison puts this alongside the other P1 gates rather than treating it as a standalone purchase.

The custom banned list and its ceilings

The list lives in the Microsoft Entra admin center under Entra ID > Authentication methods > Password protection. The constraints on it are tighter than most deployment plans assume.

The four character minimum has a consequence nobody puts in a deployment guide. If your organisation is known internally by a three letter acronym, that acronym cannot be banned as a substring. The short name people actually use in passwords is the one the list cannot reach.

The propagation delay is the second trap and it produces a predictable false alarm. An administrator adds a term, tests it against their own account within the minute, watches the password be accepted, and reports the feature as broken. It is not broken. It has not applied yet. Microsoft’s custom banned password list tutorial says updates may take several hours, so build that into the test plan rather than the incident queue.

The on-premises agent, and the part that fails open

Extending enforcement to Active Directory needs two components. A proxy service forwards policy download requests to Entra ID and returns the responses, and it is stateless: it caches nothing. A DC agent runs on each domain controller, receives validation requests from its password filter DLL, and answers pass or fail from the policy it holds locally. The agent requests a policy when the service starts, then checks the age of the local copy hourly and downloads a replacement if the copy is older than an hour.

The prerequisites are modest. No AD DS schema change is required, since the software reuses the existing container and serviceConnectionPoint objects, and any supported domain or forest functional level works. Both components need Windows Server 2012 R2 or later and .NET 4.7.2. Installing or removing the DC agent requires a restart, because password filter DLLs are only loaded and unloaded at boot, which means the rollout is a reboot campaign across every domain controller rather than a quiet software push. If your hybrid identity plumbing is still under review, the Entra Cloud Sync and Connect Sync comparison covers which components you are committing to alongside it.

Now the sentence that should shape the whole deployment. Microsoft states on the on-premises architecture page that if no password policy is available on the local DC, the password is automatically accepted, and an event is logged to warn the administrator. That event is ID 30001. Entra ID password protection fails open, by design, on any domain controller that has never obtained a policy.

Follow that through. A domain controller promoted after the rollout, or one that has never reached the proxy service, accepts anything until it gets a policy. So does a controller whose proxy path is broken and whose cached copy has been lost, for instance after a rebuild. The rest of the forest carries on enforcing. The reporting looks healthy, because the failure is silent unless somebody is reading the right event channel. Password changes are not distributed evenly across domain controllers, so one machine in this state is a real hole rather than a theoretical one.

The failure modes

Six things go wrong in practice, and each has a specific signal.

1. Audit mode is still on. Audit is the default initial setting after installation, and passwords that would be blocked are only written to the event log. Two settings both have to be right: Enable password protection on Windows Server Active Directory set to Yes, and Mode set to Enforced. With the first set to No, Microsoft documents that every deployed DC agent goes into a quiescent mode where all passwords are accepted as they are, no validation happens, and audit events are not generated either. A tenant in that state produces neither blocks nor evidence.
2. Event 30001 on a domain controller. No policy is available locally, so the password was accepted. This is the fail open case above and it is the single most important thing to alert on.
3. Nothing appears in the logs at all. Check the channel before concluding the agent is idle. The DC agent writes to Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin, with Operational and Trace channels beside it, and the proxy service writes to the matching ProxyService channels.
4. Smart lockout is mistaken for password protection. They share a portal blade and do different jobs. Smart lockout defaults to 10 failed attempts and a 60 second lockout that lengthens on repeated lockouts, except in Azure US Government tenants where the threshold is three. Customising those values requires Microsoft Entra ID P1 or higher. It also tracks the last three bad password hashes so that re-entering the same wrong password does not advance the counter, and Microsoft notes that this hash tracking is unavailable when pass-through authentication is enabled, because the authentication happens on-premises.
5. Hybrid lockout thresholds set the wrong way round. With pass-through authentication, Microsoft’s smart lockout guidance requires the Entra threshold to be lower than the AD DS threshold and the Entra duration to be longer than the AD DS duration. The units differ, seconds in Entra and minutes in AD DS, which is how the comparison gets inverted on a whiteboard.
6. The audit evidence is never read. In enforced mode a rejected password change logs event 10016 and a rejected password set logs 10017, each with a companion event naming which policy did the rejecting. In audit mode the equivalents are 10024 and 10025. Those two audit events are the only honest estimate of what enforcement will cost you, and they exist precisely so the decision is not a guess.

1# Ships with the DC agent under
2# %ProgramFiles%\WindowsPowerShell\Modules\AzureADPasswordProtection\
3# Summarises agent activity instead of reading raw event channels by hand.
4Get-AzureADPasswordProtectionSummaryReport

What I would do differently

Run audit mode for a full password expiry cycle before enforcing, not a fortnight. The population that changes a password in any two week window is not representative, and the 10024 and 10025 events are worthless as a sample if most accounts never appeared in them.

Keep the custom list to nouns that belong to the organisation: the company name and its abbreviations, product names, site names, the local sports team. Do not spend the 1,000 terms reproducing a public weak password dictionary. The global list already does that job, better, and it updates without you.

Alert on event 30001 as a monitoring rule rather than something you find during an investigation. Every other failure in this feature is visible as a user complaint. That one is visible as nothing at all.

Do not buy Microsoft Entra ID P1 for this alone. If P1 is already in the tenant for Conditional Access, Entra ID password protection is included and there is no argument to have. If it is not, the comparison to make is against a third party password filter with a published dictionary and breached credential checking, because the honest description of the Microsoft feature is a floor, not a screen.

Finally, be clear internally about what a banned list cannot do. It has no view on a password that is strong and stolen, and phishing takes the strong ones first. That is the job of the controls at sign-in: authentication strength to require a phishing resistant method, and named locations to narrow where a credential is usable at all. Password quality is the cheapest of the three and the least load bearing.

Last verified: 5 September 2026.