Microsoft Entra password protection

Microsoft Entra password protection evaluates user passwords against a banned-password list during password creation and reset, blocking weak and easily-guessable choices. It runs in two places: on cloud-only accounts (just enabled and works) and on on-premises Active Directory (via deployed agents).

Banned-password enforcement sits alongside self-service password reset and passwordless authentication in the identity baseline described in What is Microsoft Entra ID; for hybrid tenants the on-premises agents depend on a healthy Entra Connect.

What's blocked

Entra password protection blocks:

• Microsoft's global banned-password list — passwords known to be common, frequently used in brute-force lists, or appearing in major breaches. Updated continuously by Microsoft.
• Your custom banned-password list (up to 1,000 entries) — words specific to your organisation that shouldn't be in passwords: your company name, products, executives, locations, sports teams, the city you're in.
• Common substitutions — Password1 and P@ssw0rd1 both blocked; PaS$word1 blocked. The fuzzy-match engine catches the obvious tricks.
• Common-word patterns — repeated characters, sequential numbers, keyboard walks.

The result is dramatically stronger user-chosen passwords without requiring complex composition rules that users hate.

Cloud accounts

For cloud-only accounts, password protection runs in Entra ID automatically — no configuration required. The custom banned-password list is configured in Entra admin center → Identity → Protection → Authentication methods → Password protection.

On-premises AD

For hybrid-identity organisations using on-premises AD, password protection requires deploying agents:

• Entra Password Protection DC Agent — installed on domain controllers. Validates password changes against the policy.
• Entra Password Protection Proxy — installed on a separate server (or multiple for HA). The proxy connects to Entra to fetch the policy; DC agents fetch from the proxy locally.

Once deployed, every password change on AD is validated against Entra's policy — including your custom banned list. Users get instant feedback if their chosen password is blocked.

Two enforcement modes:

• Audit — log but don't block. Used during initial rollout to understand impact.
• Enforced — block bad passwords. The right end state.

Smart Lockout

Password protection stops attackers from choosing a bad password in the first place; Smart Lockout is the sibling control for the case where an attacker is trying passwords against an account regardless. It tracks failed sign-in attempts by source — the combination of IP address and device/user-agent fingerprint — rather than by the account alone, and distinguishes familiar sign-in patterns (a location and device this account has used successfully before) from unfamiliar ones. After a threshold of failed attempts from an unfamiliar source (10 attempts by default, locking that source out for 60 seconds, with the threshold and duration configurable in the on-premises AD case), further attempts from it are blocked — while the legitimate user, signing in from their normal device and location, is tracked separately and unaffected by the attacker's failures against the same username. This defeats both classic brute-force against one account and password-spray campaigns that deliberately keep the per-account attempt count low specifically to dodge simple lockout counters. In hybrid environments, Smart Lockout's cloud-side thresholds and on-premises Active Directory's own account-lockout policy are separate settings that can produce confusing results if left unreconciled — worth checking both sides rather than assuming the cloud configuration is the whole picture.

Why this matters

Password complexity rules (length, character classes) are a poor proxy for password strength. Summer2024! passes most complexity rules but is trivially guessable. Password protection blocks specifically the predictably-bad passwords, regardless of whether they meet complexity rules.

For tenants moving toward passwordless authentication (Microsoft Authenticator, FIDO2, passkeys), password protection is still important — even with passwordless, users need a password for fallback, and that password should be strong.

Licensing

Cloud-only password protection requires Entra ID Free (any tenant has it). Custom banned-password list and on-premises AD enforcement require Entra ID P1 (included with Microsoft 365 Business Premium, E3, E5).

For organisations still running on-premises AD with synced identities, deploying the password-protection agents is a one-time effort with permanent benefit. Combined with Microsoft Defender for Identity for compromised-credential detection and Identity Protection for risky-sign-in response, it forms the password-side defence baseline.