Locking Down Windows Devices With Password and Screensaver Policies via Hexnode

TL;DR. A sane Windows password and screensaver policy via Hexnode in 2026 means a 14-character minimum, no forced rotation unless a credential is compromised, no enforced complexity rules, screen lock at five to ten minutes idle, password required on resume, and a lockout threshold around 10 failed attempts. Push it from Hexnode, not from a half-remembered GPO, and audit the overlap before you ship. The default Windows baseline is older than half your staff.

What does a password and screensaver policy actually do?

Two jobs, sitting on top of each other.

The password policy is the compliance baseline. It sets the floor for every interactive logon on the device: minimum length, allowed characters, change frequency, what happens after too many bad attempts. Auditors and cyber-insurance underwriters ask for this in writing, and they ask for proof it is enforced, not just documented. A password policy in a Word doc is not a password policy. One pushed from an MDM and reported on a dashboard is.

The screensaver lock is the insider-risk reduction. It assumes the user has walked away from a logged-in machine. Gone for coffee, gone to a meeting, gone home without locking. After N minutes idle the screen locks, the password is required to come back in, and whoever wandered up to the desk gets nothing. It is the cheapest control in security and the one most often left at “Windows default”, which depending on the build can be never.

Together they answer two questions a forensic investigator will ask after an incident: could a stolen credential have been brute-forced, and could an unauthorised person have walked up to a logged-in session? If both answers are no, the rest of the investigation gets easier. If either is yes, the conversation gets long.

What does Hexnode let you set on Windows?

The named policy fields in the Hexnode Windows policy catalogue, the ones we actually configure on every rollout:

• Minimum password length. Numeric, in characters. Hexnode pushes this through Windows’ configuration service provider; the device enforces it on next password change.
• Password complexity. A boolean: require a mix of upper, lower, numeric, and non-alphanumeric. Off by default in our deployments (see the next section for why).
• Password history. How many previous passwords the device remembers and refuses to reuse. Windows default is 24, which is sane.
• Maximum password age. Days before the user is forced to change. Windows default is 42; modern guidance says set it to zero (“never expire” unless something forces a change).
• Minimum password age. Days the password must be kept before it can be changed again. Stops the “cycle through 24 dummy passwords to get back to the favourite” trick.
• Account lockout threshold. Failed attempts before the account locks.
• Account lockout duration. Minutes the account stays locked after threshold is hit.
• Reset lockout counter after. Minutes of clean attempts before the failed-attempt count resets to zero.
• Screen-lock idle time (sometimes labelled Maximum Inactivity Before Lock). Seconds of inactivity before Windows locks the workstation.
• Require password on wake/resume. Boolean. Should be on. Always.
• Require password on lid close (laptops). Boolean. Should be on. Always.
• Screensaver enforcement. Force a specific screensaver, prevent the user disabling it, lock on screensaver start.

Most of these map one-to-one with the Windows CSP fields under ./Device/Vendor/MSFT/Policy/Config/DeviceLock/*. Hexnode is giving you a friendlier console and a deployment dashboard. The mechanism underneath is Microsoft’s own.

What’s the right password policy in 2026?

Direct answer: length over complexity, no rotation unless compromised, no enforced character classes. That’s the NIST SP 800-63B position, it’s what Microsoft’s own engineers have been writing since 2019, and it’s what we configure by default.

The reasoning, briefly. Forced complexity rules (“must contain one upper, one lower, one number, one special”) produce predictable passwords. Password1!, Welcome2026!, Summer2026!. Humans are bad at random. Length, on the other hand, scales the search space exponentially. A 14-character passphrase made of memorable words beats an 8-character mixed-case-and-symbols password by orders of magnitude on every brute-force model.

Forced rotation makes it worse. Users who have to change their password every 42 days end up with Password1!, then Password2!, then Password3!. The rotation does not improve security; it just guarantees the password is sticky-noted to the monitor. NIST removed the rotation requirement years ago. Most compliance frameworks have caught up. Some auditors haven’t, and that’s a separate conversation.

The numbers we actually set on Windows via Hexnode for a typical SME:

• Minimum length: 14
• Complexity required: off
• History: 10
• Maximum age: 0 (never expires)
• Minimum age: 1 day
• Lockout threshold: 10
• Lockout duration: 15 minutes
• Reset counter after: 15 minutes

Two caveats. First, if the organisation is bound by a specific framework (PCI DSS still wants 90-day rotation in some interpretations, certain HIPAA auditors still ask), write the policy to the framework, not to NIST, and document the divergence. Second, “no rotation” only works if you also have a compromise-detection signal. Entra ID password-protection plus risk-based sign-in does that for hybrid setups. On unmanaged local accounts, you’re flying blind, and rotation becomes a less-bad alternative.

What about the screensaver lock?

Idle-lock at five to ten minutes is the right setting for almost every business context. Five minutes for finance, HR, executives, and anyone with a regulated dataset on screen. Ten minutes for general users where the friction of constant relogins outweighs the marginal risk.

Force-lock on lid close for every laptop. There is no scenario where a closed laptop should resume to an unlocked desktop. Hexnode pushes this as a power-options policy alongside the screen-lock idle.

Password required on resume. Tick it. The default Windows behaviour assumes resume is the user, and on shared or hot-desked devices that assumption breaks. If a contractor borrowed the laptop for a demo and walked away mid-resume, the wake-without-password setting is what gives the next person a logged-in session.

The screensaver itself, in 2026, is mostly cosmetic. A corporate-branded blank screen, sometimes a slow message about returning to your desk. The active control is the lock event that fires when the screensaver starts. Hexnode lets you specify Screensaver Timeout and Force Lock on Screensaver, which is the combination that matters. The timer hands off cleanly to the Windows session-lock mechanism.

A small note on kiosks. If the device is a shared-purpose kiosk (a reception sign-in machine, a warehouse scanner station, a board-room PC) the screen-lock policy needs to be different from a laptop. Locking a sign-in kiosk every five minutes makes it useless. The Hexnode kiosk-lockdown profile takes precedence and the password and screensaver fields don’t apply in the same way. Plan for the carve-out.

How does this interact with M365 / Entra ID password policies?

Entra ID has its own password policy. So does Active Directory, if you’re hybrid-joined. So does Hexnode. Three policy sources, one user, one password, and the rules of precedence are not symmetrical.

For the password itself, the Entra / AD policy wins, because the password is validated against the directory, not the local device. Hexnode’s “minimum length” setting on a hybrid-joined device is largely cosmetic. The directory will reject a too-short password regardless. Set Hexnode’s value to match the directory’s so the user-facing message is consistent, but the directory is doing the actual enforcement.

For the screen lock and lockout settings, the Hexnode policy wins on managed Windows devices, because those settings sit on the device, not in the directory. The CSP path is local. Hexnode pushes, the device enforces.

For Conditional Access and risk-based sign-in, neither policy applies. That’s an Entra ID feature evaluated at sign-in time. It’s where the real compromise-detection lives in 2026, and it’s why we recommend “no expiry” combined with strong Conditional Access rather than scheduled rotation. Read the MDM page for how the pieces sit together.

The typical hybrid-AD pattern we deploy: AD enforces the password rules (length, history, age) for domain accounts; Hexnode enforces the screen-lock and lockout rules on the device; Entra ID Conditional Access enforces the risk-and-context rules at sign-in. Three layers, no overlap, each doing what it’s best at.

How does it differ on Windows 10 vs 11?

Functionally, very little. The CSP fields are the same. The Hexnode console is the same. The defaults are the same.

Two practical differences worth naming.

Windows 11 ships with Windows Hello for Business more aggressively positioned as the default. That changes the threat model. The “password” the user types is increasingly a PIN bound to TPM-backed credentials, not a credential travelling over the network. Long passphrases still matter for fallback, but the day-to-day sign-in is biometric or PIN. Your password policy still applies; it just gets used less.

Windows 10 reached end-of-support in October 2025. If you’re reading this in May 2026 and still have Windows 10 in the fleet, the password policy is the least of your problems. Go and read the Windows update settings article and start the migration. Hexnode reports OS version per device; the dashboard makes the count obvious.

Lockout: balancing security and helpdesk pain

Lockout threshold is the field that gets argued about the most. Set it too tight and the helpdesk drowns in unlock requests; set it too loose and an attacker has all afternoon to brute-force.

Ten attempts is the usual sweet spot. The arithmetic: at ten attempts before lockout, with a 14-character password drawn from any reasonable space, online brute-force is mathematically impossible inside the lockout window. The attacker would need to be offline against a hash, at which point lockout doesn’t help anyway, and the conversation moves to credential stuffing and Conditional Access.

Five attempts feels safer but bites in the real world. Phones with cached old credentials, Outlook profiles that didn’t get the new password, an honest typo on Monday morning: all chew through the threshold fast. We’ve inherited tenants where the lockout was set to three attempts and the helpdesk burnt 40% of its capacity on unlocks. Three is theatre.

Fifteen attempts is too generous. Credential-stuffing tools spray with lists of 8 to 10 likely passwords per account. Setting the threshold higher than the stuffing list defeats the purpose.

Lockout duration of 15 minutes lets the user wait it out without calling support for routine cases, while still blocking the automated attacker for long enough to make the attack unprofitable. Reset counter after set to the same 15 minutes means an honest typo on Monday and another on Wednesday don’t compound.

One special case. Service accounts and shared mailbox credentials should never be subject to interactive lockout. They’re not interactive. Carve them out of the policy explicitly. A locked-out service account is the kind of outage that takes down a printer fleet at 4pm.

Common pitfalls

The conflicts that bite, ordered by frequency.

GPO leftover from the old domain. Hybrid-joined machines pick up Group Policy from the AD domain and configuration from Hexnode. If both define a screen-lock idle time, the device picks one, and which one isn’t always obvious. The Windows precedence rule is “MDM wins on co-managed devices for settings in the MDMWinsOverGP list,” but only if the setting is in that list, and only if co-management is configured. Audit the GPO before you push the Hexnode policy. We’ve seen clients push a 5-minute idle from Hexnode and watch the device hold at the GPO’s 30-minute setting, with nobody knowing why.

Kiosks and shared PCs. A reception sign-in PC, a board-room shared workstation, a warehouse scanner station: none of these tolerate the same password and lock policy as a personal laptop. Build a separate Hexnode device group, build a separate policy, scope it tightly. Mixing kiosk devices into the general fleet policy creates “why does the entrance PC keep locking” tickets you won’t enjoy.

Local admin accounts. The Windows password policy applies to interactive accounts. Local admin accounts and the built-in Administrator are interactive. If you’ve left those with weak or default passwords, the fleet policy doesn’t reach them until LAPS (Windows Local Administrator Password Solution) is on and rotating them. Hexnode can enforce the LAPS deployment; the policy without LAPS is incomplete.

Service accounts running interactively. A line-of-business app that “needs” a service account to log on as a user, with a password that hasn’t changed in years, breaks every assumption the policy makes. Find them, document them, plan the migration to managed service accounts or service principals. They’re the soft underbelly.

Compliance-policy theatre. A password policy that’s pushed but not audited is not enforced. Use the Hexnode compliance dashboard, build a compliance criterion that flips a device non-compliant if the password CSP fields don’t match the policy, and tie that to a Conditional Access rule that blocks non-compliant devices from mail. Otherwise the policy is a gentleman’s agreement.

Where this sits in the OSH stack

This article is part of our MDM series. The previous instalments cover managing BitLocker with Hexnode (the encryption layer underneath the lock screen) and Windows update settings via Hexnode, which keeps the OS itself current enough for the password protections to be worth anything. The MDM page is at /mdm/ and the Hexnode-specific page sits at /mdm/hexnode/.

If you’d like a second pair of eyes on your current setup, we run a 30-minute Windows policy review. We pull your current password and screen-lock state from Hexnode (or wherever it lives now), map it against compliance gaps for cyber-insurance and the relevant frameworks, and write back NIST-aligned recommendations you can actually push on Monday. No pitch, written reasoning. Book the review through our services page.