Windows Password Policy with Intune

A weak password or a screen left unlocked is still one of the most mundane ways in for an attacker. On managed Windows PCs, Microsoft Intune lets you enforce a consistent baseline across the entire fleet: minimum length, complexity, automatic session lock and temporary lockout after several failed attempts. Where a standalone machine depends on the goodwill of its user, an Intune policy is applied centrally, can be verified, and can be proven.

It is also a recurring requirement in security frameworks such as ISO 27001, NIS2 or GDPR, which expect written rules that are actually applied, not mere recommendations pinned to the intranet. This article is for IT leads and MSSPs who manage a Windows estate under Intune and want a password baseline that stands up to an auditor without wrecking the user experience. We will cover what to enforce, where to configure it, how to avoid conflicts, and how it fits together with MFA and BitLocker.

What a good password policy should cover

Recent guidance, notably from NIST and Microsoft, favors length and dropping systematic forced rotation over frequent changes that push people toward predictable passwords (the classic "Summer2026!" that becomes "Summer2027!"). The key is a solid floor, a quick screen lock and a lockout after several attempts, to slow down brute-force attacks and opportunistic physical access.

• A meaningful minimum length: prefer a passphrase (12 characters or more) over the classic eight.
• Complexity enabled to rule out trivial passwords and obvious sequences.
• Automatic screen lock after a few minutes of inactivity, requiring the password on resume.
• A limited number of attempts before temporary lockout, to counter local brute force.
• Password history to prevent immediate reuse of the previous one.

The case of Entra-joined PCs

A crucial point that is often misunderstood: on a machine joined to Microsoft Entra ID (Entra join), user sign-in relies on the cloud identity, not a local account. The password policy of the account itself (length, expiration, reuse) is therefore governed in Entra ID, while Intune mainly drives device behavior: lock timeout, requiring a password on wake, and the attempt threshold before the device locks. Your Intune settings should stay consistent with the Entra identity policy rather than contradict it.

Where to set these in Intune

In Intune, these settings live mainly in two places: a Configuration profile or an Endpoint security policy. Both rely on the Windows configuration service provider (CSP), in particular the DeviceLock CSP, to enforce locking and complexity requirements. Where you put it matters less than consistency: use a single source of truth per setting to avoid conflicts.

Recommended rollout steps

1. 1Create a configuration profile (or endpoint security policy) targeting your Entra-joined Windows PCs.
2. 2Set the minimum length, complexity, lock timeout and attempt threshold.
3. 3Assign first to a small, representative pilot group.
4. 4Confirm on a device that the session actually locks and that lockout triggers after the expected number of attempts.
5. 5Check the compliance state in Intune (Succeeded / Error / Conflict) before widening.
6. 6Then roll out to the whole fleet gradually, in waves.

The important part is targeting the right device type and checking there is no conflict with another policy. Two competing rules that set the same value produce a conflict status in the console, and some machines can stay silently unprotected while you assume they are covered.

Avoid the common traps

A poorly calibrated policy backfires. Too strict, it pushes users to write passwords on a sticky note or flood the help desk. Too loose, it protects nothing. The goal is to balance real security against usability, then document the choices for the audit. Here are the mistakes we see most often.

• Stacking two policies that set the same value: this creates a conflict and an error status that is hard to diagnose.
• Setting a lock timeout that is too short (30 seconds), which frustrates users and invites workarounds.
• Forgetting that the Entra account policy and the Intune device setting are two distinct layers.
• Failing to document the policy and its rationale, which stalls you on audit day.
• Deploying straight to the whole fleet with no pilot phase, and ending up with hundreds of locked-out users.

One brick among others: MFA and BitLocker

Keep in mind that the password policy is only one brick. It comes into its own combined with multi-factor authentication (MFA), through Entra Conditional Access, and disk encryption with BitLocker. A strong password protects the open session, MFA protects the identity against credential theft, and BitLocker protects the data if the machine is stolen and the drive removed. It is the coherent whole that genuinely satisfies an auditor, and above all stops a real intrusion, not an isolated setting.

A password protects the session, MFA protects the identity, BitLocker protects the data. The three together make a defense, not a checked box.

Documenting for the ISO 27001 audit

An auditor is not satisfied merely to see a setting active: they want proof that the rule is decided, applied and verified. Concretely, prepare a short file linking the framework requirement to the technical control and to the evidence of enforcement.

• The written policy (length, complexity, lock, lockout) and its rationale.
• A screenshot of the matching Intune settings and the targeted group.
• The Intune compliance report showing that devices are indeed compliant.
• A record of any exceptions and their approval.

How AuPoint helps

Turning a compliance requirement into correct Windows settings, without conflicts or surprises for users, takes time and assumes you know the right CSPs. AuPoint offers a password and lock policy already aligned with good practice, deployable in a few clicks, with no PowerShell. You get an impact preview before you apply, break-glass safety so you never lock yourself out, and fully reversible policies. All of it in plain language, built for SMBs and MSSPs.

FAQ

Do I still need to force a password change every 90 days?

No, that is no longer recommended. Both NIST and Microsoft advise against systematic periodic expiration, because it pushes people toward predictable passwords. A long passphrase, MFA, and a change only when compromise is suspected are far better. On an Entra-joined PC, this expiration rule is managed at the identity level in Entra ID.

Configuration profile or endpoint security policy: which one?

Both rely on the same Windows CSPs under the hood. Pick whichever fits your organization, but above all do not set the same value in both places for the same device: that is the number-one cause of conflict statuses. One source of truth per setting.

What happens when a user exceeds the number of attempts?

The account or device is temporarily locked for the duration you defined, which slows down a brute-force attack. Set a reasonable value (for example 10 attempts) and give the help desk a clear unlock procedure, so the security measure does not turn into a flood of tickets.

Ready to enforce a clean, defensible password baseline across your whole Windows fleet? Connect your Microsoft tenant in a few clicks at aupoint.io, preview the impact, and deploy a reversible policy. It is free to start.