Block attacker passwords

Prerequisites and plan required

Use an organization with Professional or Enterprise access and an identity policy owner who can review changes. Credential Intelligence beta is included with Professional during beta; Enterprise has the same access. Public and Researcher Console views show broad/high counts, while values and downloads require the paid entitlement. Have a private backup of your existing policy and dedicated test accounts ready.

Expected result: a reviewed set of attacker dictionary terms added to your password screening policy, with a tested rollback. This feed describes words repeatedly used by attackers, not a victim credential list or proof that any employee's password has been exposed.

1. Review broad and high-confidence entries

Open Console → Blocklist. Begin with High confidence for a narrower review and compare it with Broad. Broad contains qualifying dictionary terms seen across at least five distinct masked source networks in 30 days and with at least two usernames. High requires at least 20 source networks. These are the published feed criteria, not claims about an individual account.

Use the search and leaked-only controls to review the subset you intend to deploy. The beta leaked flag has three states: true means a checked match in the upstream breach corpus, false means checked and absent there, and null means not yet checked. Neither false nor null means a password is safe. Upstream coverage is not the entire password population, and a leaked match does not establish who used that term.

2. Download the policy format

Choose the Entra ID download for Microsoft's custom list. The output contains at most 1,000 terms, each 4–16 characters. TXT and JSON downloads are available for other reviewed workflows. JSON retains aggregate context for inspection. Keep terms and downloads private and out of ordinary logs. Session downloads use the active organization's entitlement and daily row budget.

For an approved automated collector, the equivalent API request uses a dedicated key:

3. Update Microsoft Entra ID

Back up your existing custom terms privately. Merge the reviewed feed with organization-specific terms, deduplicate case-insensitively, and verify that the combined list stays within 1,000 entries. Do not silently truncate the policy or overwrite unrelated terms. An empty feed is not an instruction to erase your policy.

In Microsoft Entra admin center, open Entra ID → Authentication methods → Password protection. Enable the custom banned password list, paste the reviewed terms one per line, and save. This is a reviewed manual update, not a URL subscription. Confirm Microsoft's current licensing and administrator requirements using the sources in the v1 identity workflow.

4. Test and extend to on-premises AD

Test password set/change with dedicated accounts. Microsoft's normalization and scoring may reject variants, so test more than exact strings. Changes apply at password set/change and do not retroactively reject all existing passwords.

For AD DS, deploy and register Microsoft's Entra Password Protection proxy service and domain controller agents following the linked Microsoft procedure. Start on-premises in Audit mode, verify policy downloads and logs across writable domain controllers, then pilot Enforced mode with identity-owner approval. Audit mode is an on-premises setting; it is not a cloud custom-list dry run. Review redundancy, deployment restarts and rollback before rollout.

Troubleshooting and upkeep

A small high-confidence feed can reflect a young observation window; do not fill it with invented terms. No Entra output may mean entries do not meet its length limits. A 403 indicates missing entitlement; 429 can indicate the daily row budget. Review policy updates weekly, preserve organization-specific terms when feed entries retire, and record only review dates, term counts and policy versions in ordinary change records. Use FAQ for key issues and SIEM enrichment for the separate IP workflow.