Most small and mid-sized businesses run their identity system on Microsoft Entra ID (formerly Azure AD), the identity platform behind Microsoft 365. This article covers how Microsoft's own published guidance for Entra ID environments aligns with — and in a few places differs from — the general NIST recommendations covered in NIST Password Guidelines, and how to configure the specific controls available in a Microsoft 365 tenant.
In short
Microsoft's guidance mirrors NIST: disable calendar-based password expiration for cloud-only accounts, raise the minimum length, enable Entra Password Protection with a custom banned list, and enforce MFA via Conditional Access rather than relying on Security Defaults alone. Hybrid tenants must align the on-premises Active Directory policy layer too — see the M365 Governance Assessment to check your tenant's actual configuration.
Microsoft's published position on passwords
Microsoft's own security guidance, published through Microsoft Learn and Microsoft Security documentation, aligns closely with NIST's current direction: it recommends against mandatory periodic password expiration for cloud-only accounts, and explicitly states that length is a more effective control than forced complexity or rotation. Microsoft's guidance also emphasizes a point NIST's document treats as an underlying assumption: password strength matters far less once multi-factor authentication (MFA) is properly enforced, because the password alone stops being the sole barrier to account access.
Cloud-only vs. hybrid identity
Microsoft's specific rotation recommendation applies most directly to cloud-only Entra ID accounts. Organizations running hybrid identity (on-premises Active Directory synced to Entra ID via Entra Connect) are still governed by whatever password policy is set at the on-premises Active Directory level — changing the cloud-side default does not override an on-premises Group Policy Object still enforcing expiration. Both layers need to be checked and aligned.
Entra ID password policy defaults and what to change
| Setting | Typical Default | Recommended Change |
|---|---|---|
| Password expiration (cloud-only accounts) | Off by default in current tenants (varies by tenant creation date) | Confirm it is disabled; do not re-enable calendar-based expiration without a specific compliance requirement |
| Minimum password length | 8 characters | Raise to at least 12 through Entra ID password policy or Conditional Access-adjacent controls |
| Banned password list (global + custom) | Microsoft's global list is on by default | Add a custom banned-password list covering your organization name, product names, and locally common terms |
| Multi-factor authentication | Security defaults enable it broadly, but enforcement gaps are common in older or customized tenants | Enforce MFA for all users via Conditional Access, not just security defaults, and eliminate any legacy authentication exclusions |
| Self-service password reset (SSPR) | Off by default | Enable with strong authentication methods for reset (not just security questions) |
| Legacy authentication protocols | Often still enabled in older tenants | Block legacy authentication entirely — it does not support MFA and is a common bypass path |
Entra Password Protection and custom banned lists
Entra Password Protection screens password changes and resets against Microsoft's global banned-password list plus an optional custom banned-password list the organization defines. This is the practical mechanism for implementing the breached/predictable-password screening NIST guidance calls for (see NIST Password Guidelines) inside a Microsoft 365 environment.
A custom banned list should include: the organization's name and common abbreviations, product or brand names, the city/region the business operates in, and any terms specific to the industry that would be an obvious first guess (a clinic's specialty, a manufacturer's product line). Entra Password Protection can also be extended to on-premises Active Directory via the Entra Password Protection agent for hybrid environments, so the same custom list protects both layers.
MFA is the control that changes the risk calculus
Microsoft's telemetry, published in its own security research, has repeatedly found that MFA blocks the overwhelming majority of account-compromise attempts, even against fairly weak passwords — and that legacy authentication protocols (which don't support modern MFA) account for a disproportionate share of successful compromises specifically because they bypass MFA enforcement. This is the core reason Microsoft's own guidance treats password rotation as a lower-priority control than it once was: MFA enforcement and legacy-auth elimination close far more real attack paths than a rotation policy does.
MFA enforcement gaps are common
Security Defaults provide a reasonable MFA baseline, but many tenants have legacy Conditional Access policies, break-glass accounts, or service accounts explicitly excluded from MFA that were never revisited after initial setup. A password policy update should be paired with a review of actual MFA coverage, not an assumption that "MFA is on" based on a setting toggled once at tenant creation.
Practical configuration checklist for a Microsoft 365 tenant
- Confirm cloud-side password expiration is disabled (or aligned with on-premises AD if hybrid).
- Raise minimum password length beyond the 8-character default.
- Enable Entra Password Protection with a custom banned-password list specific to the organization.
- Enforce MFA for all users via Conditional Access — not relying solely on Security Defaults — with no standing exclusions beyond documented, monitored break-glass accounts.
- Block legacy authentication protocols entirely.
- Enable Self-Service Password Reset with strong reset-authentication methods.
- Review Conditional Access policies for coverage gaps (admin roles, guest accounts, service accounts) at least annually, or after any significant staffing or licensing change.
Entra ID's Smart Lockout feature is specifically designed to defend against the low-and-slow attack pattern below, distinct from a traditional single-account brute-force attempt:
Common mistakes
- Assuming Security Defaults alone provide full MFA coverage, without reviewing Conditional Access policies for exclusions added over time.
- Leaving legacy authentication enabled "for compatibility," which quietly defeats MFA enforcement for any application still using it.
- Turning off password expiration without confirming hybrid identity alignment, leaving an on-premises Group Policy still forcing rotation while the cloud-side setting says otherwise.
- Never customizing the banned-password list, relying solely on Microsoft's global list and missing organization-specific predictable passwords.
FAQ
Does Microsoft recommend the same password guidance as NIST? Yes, in substance — Microsoft's own published security guidance for Entra ID aligns with NIST's move away from mandatory rotation and composition rules in favor of length, breached-password screening, and MFA. See NIST Password Guidelines for the underlying framework.
If we disable password expiration, do we need to do anything else? Yes — disabling expiration should be paired with enabling breached-password screening (Entra Password Protection) and confirming MFA is genuinely enforced across all users and applications, not just toggled on for the tenant in general.
Does this guidance apply the same way to hybrid (on-premises + cloud) identity environments? The principles are the same, but hybrid environments have two policy layers to align — on-premises Active Directory Group Policy and Entra ID cloud settings — and the Entra Password Protection agent must be separately deployed on-premises to extend banned-password screening to that layer.
What's a reasonable custom banned-password list to start with? The organization's name and common abbreviations, product/brand names, the city or region of operation, and any obvious industry-specific terms (a clinic's specialty, a manufacturer's flagship product line) — these are exactly the words an attacker familiar with the organization would guess first, and they're not on Microsoft's generic global list.
Related reading
- NIST Password Guidelines
- Password Manager Guide
- HIPAA Password Guidance
- Password Generator — generate compliant passwords for manual provisioning
- Download: Administrator Implementation Guide