Windows 11 Hardening Guide for Enterprise Fleets

Windows 11 hardening fails when teams confuse a policy assignment with a protected endpoint.

The problem is not finding settings. Microsoft, CIS, and government agencies publish hundreds. The problem is deciding which ones fit each device group, testing the applications people use, deploying through one authority, and proving the setting took effect after sync, restart, upgrade, and policy conflict.

Enterprise fleets need a hardening process that preserves work while removing avoidable paths. That means a current baseline, representative pilot devices, audit before block, owned exceptions, fresh endpoint evidence, and a rollback plan with a real trigger. Restriction without observation is guesswork.

What belongs in a Windows 11 hardening baseline?

A useful baseline covers device trust, identity, privilege, encryption, endpoint protection, application execution, browser and Office behavior, network protocols, local services, removable media, logging, recovery, updates, and management. It also records supported Windows builds, required licensing, hardware assumptions, policy source, exceptions, and how each setting is verified.

Start with Microsoft Security Baselines for the deployed Windows release. Compare the matching CIS Windows 11 Benchmark when you need recommendation detail, independent profiles, and assessment structure. Add regulatory or government guidance where it applies. Then produce one local profile per meaningful device role. Executives, developers, call center devices, kiosks, and privileged access workstations should not all inherit one blunt template.

Keep policy intent separate from delivery. “Credential Guard must run on supported managed devices” is stable intent. An Intune setting, Group Policy path, or configuration service provider value is an implementation. When Microsoft changes the delivery surface, the security reason should survive.

Which devices are ready for Windows 11 hardening?

Inventory build, edition, hardware security capability, ownership, user role, installed applications, device management state, encryption, Defender mode, local administrators, security services, policy sources, and last check time. A baseline cannot compensate for devices that are unsupported, unmanaged, or missing from inventory.

Hardware matters. Secure Boot, Trusted Platform Module support, virtualization based security, memory integrity, and kernel protections depend on firmware, processors, and drivers. Label incompatible hardware before enabling a blocking policy. Otherwise the rollout team learns about the dependency from a failed boot or a flood of help desk calls.

Evidence age belongs in the inventory. A device that reported encryption and protection last month did not pass today's check. Track devices that missed expected sync or observation windows. Unknown is operational risk, not a green square.

How should Windows 11 identity and privilege be hardened?

Remove routine local administration. Separate administrator identities, use phishing resistant authentication where supported, manage the local account with Windows LAPS, and expire temporary elevation. Protect the Local Security Authority with LSA protection and Credential Guard on compatible devices.

Microsoft says Credential Guard is enabled by default on eligible Windows 11 22H2 devices and later. Explicit policy still matters because a prior disable setting can survive an upgrade. The official Credential Guard configuration guide warns that Task Manager is not the recommended verification method. Use System Information, events, or the documented PowerShell query:

A result of 1 means Credential Guard is running. A configured policy with a warning event is not the same result. This is the pattern for the rest of the baseline: read the effective state, inspect errors, and test the boundary.

The least privilege guide covers the workflow around elevation. Users will find a path around policy if ordinary support work requires permanent admin rights. Fix that process before declaring the endpoint hardened.

How should data, boot, and recovery be protected?

Use BitLocker on operating system and fixed data volumes, escrow recovery material in an approved directory, restrict who can retrieve it, and test recovery. Confirm that protection is on, not merely that encryption once reached 100 percent. A suspended protector leaves encrypted blocks without the expected boot boundary.

Secure Boot and measured boot help protect startup. Memory integrity and other virtualization protections reduce what kernel code can do. Roll out by hardware cohort because firmware and driver quality differ. Keep recovery instructions available when the device cannot reach the ordinary management service.

Recovery is a security control. If a baseline change causes a boot failure and only one engineer knows the recovery process, the fleet is not ready. Test a recovery key retrieval, startup repair, device reset, and user data restoration before the broad wave.

Which execution controls deserve the most attention?

Application control, Attack Surface Reduction rules, macro policy, script policy, Office child process rules, browser settings, and protection from malicious drivers carry more consequence than many cosmetic settings. They also create more compatibility risk. Start in audit mode, collect the actual events, identify required software, remove bad dependencies, and move tested groups to block. The enterprise browser hardening guide maps Chrome and Edge updates, profiles, extensions, and warning controls to this process.

The Australian Cyber Security Centre updated its Windows 11 workstation hardening guidance on January 23, 2026 for Windows 11 25H2. Its high priority configuration lists 16 ASR rule identifiers and recommends testing to reduce unintended business impact. The number is useful because it shows why a single “enable ASR” ticket is not a rollout plan. Sixteen behaviors can touch different applications.

Do not create broad exclusions to clear audit noise. An excluded folder or process can become the path malware uses. Tie each exclusion to a named application, device group, event evidence, owner, compensating control, and expiry. Retest when the application or Defender platform changes.

What Windows 11 network and service settings should change?

Keep Windows Firewall enabled for domain, private, and public profiles. Allow inbound traffic only where the device role requires it and restrict the sources. Disable SMBv1, insecure guest logons, LLMNR, NetBIOS name resolution, Remote Assistance, and unnecessary discovery or sharing. Require SMB signing on modern fleets.

Windows 11 24H2 and later requires inbound and outbound SMB signing by default. That change can expose old storage and multifunction devices that never implemented signing correctly. Inventory those dependencies before enforcement, then replace or isolate them. Turning signing off across the fleet because one appliance failed is an expensive exception disguised as troubleshooting.

Remote Desktop should be off unless the role needs it. Where it remains, require Network Level Authentication, restrict sources, deny saved passwords, limit redirection, and monitor logon events. Management paths deserve stronger controls than ordinary user traffic because they carry higher privilege.

What evidence should a hardened Windows 11 device produce?

Capture account, logon, privilege, process creation, policy change, Defender, application control, firewall, removable media, and system integrity events. Include command lines in process creation events under an approved privacy policy. Forward events before local retention rolls them out, and alert when forwarding stops.

The January 2026 Australian guidance recommends a 2,097,152 KB maximum Security log and 65,536 KB Application and System logs. That Security log is 2 GB. At 8,000 devices, allocating the full local maximum would represent 16 TB of possible endpoint Security log capacity. This is not a storage forecast. It shows why teams must measure actual event volume, collector delay, and retention instead of copying a number without operating it.

Pair setting evidence with behavior. Prove that BitLocker protection is active, Credential Guard is running, an unapproved application is denied, a standard user cannot elevate without approval, and a blocked inbound path fails. A policy assignment screenshot proves intent. Endpoint behavior proves the control.

How should a Windows 11 hardening rollout be staged?

Use rings based on risk and representativeness, not whoever volunteered first. Start with lab devices, then IT, then a small group from every important hardware and application cohort. Expand only when service health, authentication, application launch, boot, update, recovery, and support measures stay inside agreed limits.

Set halt conditions before deployment. Examples include a defined increase in startup repair, application failure, authentication failure, or help desk demand. Make rollback available through the same management path and verify it on a pilot device. A rollback document nobody has executed is a theory.

One authority should own each setting. Intune, Group Policy, local scripts, security products, and provisioning packages can all write overlapping values. Record precedence and remove duplicate ownership. Repeated flip flops create drift, extra events, and confusing evidence.

Why does Windows 11 hardening need risk based priority?

Five thousand devices checked against 140 automated settings create 700,000 results. A 98 percent pass rate leaves 14,000 failures. At three minutes each, manual review would cost 700 hours. The queue has to be grouped before an analyst touches it.

Rank differences by privilege, exposure, execution opportunity, data, control failure, fleet reach, and repair source. Disabled protection on a privileged workstation outranks a low impact setting on an isolated training laptop. Thousands of failures from one stale profile become one profile repair followed by thousands of checks.

Use the older Windows misconfiguration guide to connect a failed value with the local service, user, and network context. Severity without endpoint context creates a long queue and weak judgment.

What changed in Windows 11 hardening during the last year?

Microsoft released the Windows 11 25H2 security baseline on September 30, 2025. It added NTLM auditing, process command line capture, a new ASR rule in audit mode for PSExec and WMI process creation, and disabled NetBIOS name resolution. It also removed obsolete settings such as WDigest policy because modern Windows already disables the behavior. The changes are documented in the Windows 11 25H2 baseline announcement.

A June 2026 Intune service update added the setting that blocks Internet Explorer 11 launch through COM automation to the existing 25H2 profile. Microsoft's current Intune baseline reference says profiles created earlier do not receive it until an administrator edits and saves the profile. The source baseline changed. Existing deployment did not.

That update is the operational lesson for 2026. Track baseline versions and service changes, compare deployed profiles, and verify old assignments. “Using the 25H2 baseline” is incomplete if two profiles with that label apply different settings.

Frequently asked questions

Is the Microsoft security baseline enough for Windows 11?

It is a sound starting point, not the entire program. Add role specific application, identity, network, data, recovery, and evidence requirements. Compare CIS or government guidance where it fits your obligations.

Should every ASR rule start in block mode?

No. Use audit mode to observe real application behavior, investigate events, fix dependencies, and move tested cohorts to block. Keep exclusions narrow and owned.

Can Windows 11 hardening hurt performance?

Some virtualization, scanning, logging, and application controls can affect performance or compatibility. Measure representative devices before and after the change, then tune only with evidence.

How often should Windows 11 hardening be verified?

Verify before production use, after policy or feature updates, after material application or hardware change, and on a cadence tied to device role. Monitor high consequence settings and missing evidence more often.

The executive takeaway

Choose one representative device group and one current baseline. Capture its present state, remove routine administration, protect credentials and storage, put execution controls in audit, test real work, and stage enforcement with halt conditions. Then read the effective state from the device. Deep endpoint context with AI driven analysis can group causes and draft repairs, but the fleet owner still decides what work must remain.