What this check looks at
Checks that Entra password protection enforces a custom list of banned words, such as the company, product and place names people base passwords on.
Microsoft Entra Password Protection checks every new or reset password against a global list of banned passwords and their variations, which Microsoft maintains and which needs no set-up. Tenants with Entra ID P1 can add a custom list of up to 1,000 words specific to them: the company name, its brands and products, the town, local sports teams. The custom list has no effect until Enforce custom list is set to Yes.
The check, for tenants with Entra ID P1, passes when a custom list is enforced and holds at least one word. It fails when a list exists but is not enforced, or when there is no custom list at all.
Password guessing works best with words that mean something to the target. Attackers spraying a company’s accounts try its name, brand names and locations, with the current year and a symbol, first, because that is what people choose. Microsoft’s global list cannot know that the client’s office is on Harbourside Road; a custom list can.
Why it matters
Attackers guess passwords built on the company’s own name, products and town first. Microsoft’s global list does not know those words; a short custom list stops them being used.
A password-spray attack against a firm called Northgate Joinery tries Northgate1!, Northgate2026 and Joinery123 against every account. In a firm of forty people there is often at least one such password. With a custom list, Entra ID refuses those passwords whenever someone tries to set them, so the guess has nothing to find.
Writing the list takes a few minutes and costs nothing beyond the P1 licence. Entra’s matching also catches common variations, such as character substitutions and added numbers, so a short list covers a lot.
The CIS Microsoft 365 Foundations Benchmark (5.2.3.2) asks for a custom banned password list, and NCSC password guidance and Cyber Essentials both point to blocking common and predictable passwords with a deny list. The rule maps to NIST CSF 2.0 PR.AA-01.
How to fix it
Where: Entra admin centre → Protection → Authentication methods → Password protection
Before you start
- Collect the words people base passwords on: company and product names, local places and sports teams. Up to 1,000 entries; Entra already blocks common passwords.
Step by step
- Collect the words. With the client, list the words people base passwords on: the company name and abbreviations, brand and product names, office towns and streets, local sports teams and well-known internal terms. Each term must be 4 to 16 characters. Variations with numbers or symbols are not needed; Entra’s matching handles those.
- Enforce the custom list. In the Microsoft Entra admin centre, go to Entra ID > Authentication methods > Password protection. Set Enforce custom list to Yes, enter one word per line in Custom banned password list, and select Save.
- Review the lockout settings while you are there. On the same page, check Lockout threshold and Lockout duration in seconds are sensible; Microsoft’s defaults of 10 attempts and 60 seconds suit most clients. They are not part of this check.
- Cover on-premises passwords in a synchronised tenant. The list applies to passwords changed in the cloud. Passwords set in Active Directory are checked only once the Entra Password Protection DC agent is installed and enforcing; see the on-premises password protection finding.
- Confirm. Reopen Password protection and check Enforce custom list shows Yes and the list holds the agreed words. Changing a test account’s password to one built on a listed word should be refused. Re-run the assessment to confirm.
What users will notice
People changing or resetting a password cannot use one built on the listed words. Existing passwords keep working until they next change.
How to confirm it worked
Entra admin centre, Authentication methods, Password protection: "Enforce custom list" is Yes and the list holds the agreed words.
Frameworks and controls
This check maps to controls in 14 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.a Identity verification, authentication and authorisation |
| DSPT | Standard 4: Managing data access |
| NIS2 | Art. 21(2)(i) Access control and asset management |
| Microsoft Cloud Security Benchmark | IM-6 Use strong authentication controls |
| Zero Trust | Identities |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| PCI DSS 4.0.1 | 8.3.1 All user access is authenticated |
| NIST SP 800-171 | 3.5.2 Authenticate users, processes and devices |
| CMMC Level 2 | IA.L2-3.5.2 Authentication |
| ISO 27001:2022 | A.5.17 Authentication information |
| CIS M365 | 5.2.3.2 Ensure custom banned passwords lists are used |
| CIS Controls v8.1 | 5.2 Use unique passwords (IG1) |
| NIST CSF 2.0 | PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Custom banned password lists (Microsoft Learn)