CMMC Level 2 Password and Lockout Policy in Microsoft 365, exact settings, common fails, and evidence screenshots

Passwords are still the front door key for most Microsoft 365 tenants. In a CMMC Level 2 assessment, that key has to be strong, monitored, and backed by proof.

I work with teams that live in Small Business IT, often mid-Office 365 Migration, with mixed needs across Cloud Infrastructure, legacy servers, and remote users. When CUI enters the picture, “we use MFA” isn’t the whole story. Assessors want to see a real CMMC level 2 password policy, lockout protections, and clean evidence.

This guide is how I set it up in Microsoft Entra ID (and where I can’t), what assessors flag most, and the screenshots I capture so the review stays calm.

What CMMC Level 2 actually tests for (and where Microsoft 365 fits)

CMMC Level 2 maps to NIST SP 800-171 practices. For passwords and lockouts, the pressure usually lands on:

• IA.L2-3.5.7 (password complexity and change of characters)
• IA.L2-3.5.9 (temporary passwords must change immediately)
• AC.L2-3.1.8 (limit unsuccessful logon attempts, lockouts or delay)

If you want the assessor’s “source of truth” language, I keep the official guide handy and cite it in my SSP (it also helps settle debates about “must rotate every 60 days”). See the DoD CMMC Level 2 Assessment Guide (PDF).

Microsoft also publishes CMMC mappings for Entra controls. I reference it when I’m writing control responses and attaching evidence: Microsoft guidance for CMMC Level 2 IA controls.

Here’s the key reality check for admins: Entra ID does not let you set a custom minimum password length for cloud-only users. It enforces Microsoft’s built-in password rules, then lets you add protections (banned passwords and Smart Lockout). So, if your internal policy says “15 characters minimum,” you must enforce that somewhere else (on-prem AD, a third-party IdP, or an enforced password filter upstream).

Auditor expects to see: a written policy that matches what your identity provider can actually enforce, plus evidence from the tenant that proves enforcement.

Microsoft Entra ID password protection and Smart Lockout, the exact settings I document

When I’m configuring a cloud-first tenant, I focus on two areas: Password protection and Smart Lockout. In February 2026, I still find these in the Entra admin center under the Authentication methods area in most tenants, but I always verify using the portal search because Microsoft moves blades.

Menu path (what I screenshot)

In Microsoft Entra admin center (entra.microsoft.com):

1. Microsoft Entra ID
2. Security
3. Authentication methods
4. Password protection

Microsoft’s reference for the combined password policy (including weak-password checks) is useful for both design and evidence language: combined password policy in Microsoft Entra ID.

Baseline I recommend for CMMC Level 2 in M365

This is the concise baseline I use, then tune based on scope and user risk. I document the tenant’s actual values, even when I keep defaults.

Control area	Entra setting name (as shown)	Recommended baseline for CUI tenants
Weak password blocking	Enable password protection	On
Org-specific risky terms	Custom banned password list	Add company name, brand, location, year patterns
Password spray resistance	Smart lockout	On (use Entra defaults unless risk dictates change)
Lockout tuning	Lockout threshold, Lockout duration in seconds	Start with tenant default, document rationale for any change

Smart Lockout behavior and configuration are described here: Prevent attacks using smart lockout. What matters for assessments is simple: you can show it’s enabled, show the threshold and duration values, and show how you monitor sign-in failures.

Photo by Markus Spiske

Pass/Fail test I run before I claim “enforced”

• Fail test: Attempt to set a weak password that matches your banned terms or common patterns. Confirm it’s rejected.
• Pass test: Confirm a strong passphrase works, then confirm sign-in protection reacts to repeated bad attempts (Smart Lockout events show in sign-in logs).

Also, I don’t let MFA become an excuse to ignore passwords. MFA reduces the risk of password theft, but it doesn’t replace password rules or lockout controls. Conditional Access helps prove consistent enforcement, which ties into Cybersecurity Services, Endpoint Security, and Device Hardening outcomes.

Hybrid AD or third-party IdP: what you can’t set in Entra, and where you must set it instead

Most real environments aren’t pure cloud. I see hybrid identities tied to legacy apps, Data Center Technology, and line-of-business systems, including Restaurant POS Support and Kitchen Technology Solutions where uptime matters.

Here’s the clean separation I put in the SSP so nobody confuses “Entra settings” with domain policy.

What Entra can and can’t do (practical boundary line)

• Entra can: block weak passwords (banned list), apply Smart Lockout, enforce MFA with Conditional Access, and log sign-in risk signals.
• Entra can’t (cloud-only accounts): set a custom minimum length like 12 or 15, or force classic “must change every X days” in a way that’s consistent across all auth flows.

Where to enforce minimum length and history for hybrid

If users authenticate with on-prem Active Directory (synced to Entra), I enforce the stricter items in AD GPO, then layer Entra protections on top. In that case, my policy and evidence usually include:

• Minimum password length (set your org baseline, commonly 12 to 15)
• Password complexity enabled
• Enforce password history (so reuse is blocked)
• Account lockout policy (threshold, duration, reset counter)

If you use a third-party IdP (Okta, Ping, Duo, etc.), that IdP becomes the enforcement point for minimum length and reuse rules. Then I treat Entra as the authorization and logging layer.

For lockout intent and assessor language, this control explanation helps: AC.L2-3.1.8 limit unsuccessful logon attempts.

Finally, I align all of this with broader Cloud Management, Secure Cloud Architecture, and IT Strategy for SMBs goals, because identity breaks often turn into outages.

Common assessment findings and my evidence screenshot package

Common assessment findings I keep seeing

Relying on defaults without proof: The tenant might be fine, but there’s no screenshot trail or export.

Confusing “password expiration” with CMMC need: Forced rotation without cause can backfire. Assessors care more about enforcement and monitoring than a random 60-day rule.

No break-glass story: Admin emergency accounts exist, but nobody documents where they’re excluded from Conditional Access, how they’re protected, or who reviews them.

Hybrid inconsistency: Cloud accounts follow one standard, domain accounts follow another, and the written policy matches neither.

MFA scope gaps: MFA is on for users, but not for admins, not for legacy protocols, or not for high-risk apps.

Auditor expects to see: one consistent story across Entra, AD GPO (if used), Conditional Access, and your written policy.

Evidence package (screenshots and artifacts I attach)

1. Screenshot: Authentication methods > Password protection showing Enable password protection, Custom banned password list status, and Smart lockout values.
2. Screenshot: Custom banned password list page showing your org-specific terms (redact the exact words if needed).
3. Screenshot: Conditional Access policy requiring MFA for CUI apps and admin roles (show assignments and grant controls).
4. Screenshot: Sign-in logs filtered to failed sign-ins, showing lockout-related activity over a date range.
5. Screenshot: User account view for a test user showing authentication methods and last sign-in.
6. Artifact: Exported Conditional Access policy JSON (or your policy documentation output).
7. Artifact: Written CMMC level 2 password policy and lockout standard (approved version, with review date).
8. Artifact (hybrid): Screenshot of Default Domain Policy (or Fine-Grained Password Policy) showing minimum length, history, lockout threshold.
9. Artifact (hybrid): Evidence that Entra Password Protection is deployed on-prem if used (install/config proof).
10. Artifact: Admin account inventory, including break-glass accounts, owner, and review cadence.

For redaction, I blur usernames, tenant IDs, and IPs, but I leave menu paths and setting values readable. That keeps the package useful while protecting CUI-adjacent details.

Conclusion

A clean CMMC Level 2 review depends on two things: controls that actually enforce your intent, and evidence that tells the same story. When I build a Business Continuity & Security package, I treat identity like the main lock on the building, not a checkbox.

If you want this tightened into a repeatable standard across apps, endpoints, and locations, that’s where I bring Technology Consulting, Infrastructure Optimization, and Tailored Technology Services together as a long-term Business Technology Partner. The result is Managed IT for Small Business that supports real operations and real audits, not just Digital Transformation slideware and “Innovative IT Solutions” slogans.