How does Microsoft Entra ID check for weak and banned passwords?

Microsoft Entra ID checks passwords against configured protection rules that block common, easily guessed or otherwise disallowed passwords before they are accepted. This reduces password spraying and credential stuffing risk from weak choices. Keep the banned-password policy aligned with current attack patterns, and monitor password reset or failure trends that may show users trying repeatedly weak values.

How Entra ID evaluates a password before accepting it

Entra ID does not treat password acceptance as a simple length check. It evaluates the submitted password against configured protection rules that can reject common patterns, guessed combinations, and values that the tenant has explicitly disallowed. The practical goal is to stop weak choices before they become valid credentials, especially where reuse and sprayable passwords create immediate account risk.

This check happens at the point of password creation or reset, so the user gets an immediate failure rather than a later policy violation. That makes the control most effective when the banned-password list is tuned to the organisation’s current exposure, including names, brands, seasonal terms, and other patterns attackers routinely test first.

What the banned-password protection is actually looking for

The protection is designed to catch passwords that are easy to guess in bulk, not just passwords that are technically valid. That includes widely used passwords, simple variants, and strings that are poor choices because they are predictable across many users or easy to derive from public information. In practice, the value comes from reducing the success rate of password spraying and credential stuffing, where attacker effort is spread across many accounts rather than focused on one.

The strongest configuration is the one that reflects how your user base actually chooses passwords and how attackers are currently operating. A banned-password policy that is too generic can leave obvious local patterns untouched, while one that is too aggressive can frustrate users without materially improving resistance to guessing.

For broader identity hardening context, NHIMG’s Password Security and Password Manager Guide covers how modern password policy should reduce reuse, guessing and weak-secret habits at the source.

How to operationalise weak-password blocking without creating friction

In a Microsoft environment, the useful question is not whether the protection exists, but whether it matches the organisation’s real password risk. The policy should be reviewed alongside password reset volume, repeated validation failures, and helpdesk reports that show users trying weak values more than once. Those signals often reveal whether the banned-password rules are catching the right patterns or merely creating noise.

Where Entra ID is part of a larger AD estate, password protection should also be considered alongside administrator and service-account hardening, because one weak human password can still become the first step in a larger identity compromise. That is especially true when attackers can pair weak password testing with token theft, overprivileged access, or a reused secret elsewhere in the tenant.

To see how this fits into the broader Entra control surface, NHIMG’s Active Directory and Entra ID Hardening Guide places password policy in the wider context of tiering, privilege and identity attack paths.

Risk and Threat Considerations

Weak-password blocking matters because attackers do not need a perfect password to succeed, they only need one that is predictable enough to survive repeated guessing. If the banned-password policy is stale or too narrow, sprayed passwords and credential stuffing attempts remain viable against users who reuse familiar patterns.

Failure mechanism: The protection fails when the banned list does not reflect current attacker wordlists, local naming conventions, or the organisation’s own predictable password habits, allowing weak values to be accepted at creation or reset.

Impact: Accepted weak passwords increase the probability of account takeover, especially when attackers can combine guessing with reuse, spraying, or leaked credentials from other services.

For Entra-centric attack paths that start with weak credentials and then expand into tenant compromise, NHIMG’s Storm-1283 OAuth apps abuse 2023 shows how initial access and credential abuse can be chained into broader tenant misuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Passwords are evaluated as authenticators under digital identity guidance.
Recommendation — Apply current password guidance and reject weak choices at set and reset time.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Password blocking supports the lifecycle and quality of authenticators before issuance or acceptance.
Recommendation — Enforce authenticator requirements that block weak password selection.
CIS Controls v8	CIS-5 — Account Management	Weak-password checks reduce account compromise risk in account provisioning and reset flows.
Recommendation — Harden account onboarding and reset processes to prevent weak credential acceptance.
ISO/IEC 27001:2022	A.5.17 — Authentication information	Password protection governs how authentication information is created and accepted.
Recommendation — Control authentication information so weak passwords are not accepted.

Practitioner Guidance

What to verify: Confirm that blocked-password handling is happening at password set and reset time, and that the policy is rejecting the weak values your users actually try, not only a generic list of common passwords.

What to measure: Track repeated password reset failures and weak-password rejections as a signal of policy fit. A rising rejection trend can mean the control is working, but it can also mean users are attempting easily guessed values that need better guidance or stronger defaults.

Common mistake: Treating banned-password protection as a one-time tenant setting. The control is only effective when it is reviewed against evolving spray wordlists, brand references, and other context attackers are likely to test.

Practitioner takeaway: Use the banned-password control as a live guessing-resistance layer, not a static compliance setting, and tune it based on the weak-password patterns your environment is actually seeing.