First, start with a pilot OU, and then roll out these 20 Windows 11 GPOs in three waves: first, protect credentials (Credential Guard, LSA protection); next, block common attack chains (ASR, SmartScreen, CFA, PUA); and finally, harden the network surface (SMB signing, disable SMBv1, NTLMv2-only, firewall, RDP NLA). In addition, add strong auditing and PowerShell logging so investigations don’t stall; consequently, responders pivot faster and, therefore, contain incidents earlier.
Why GPO hardening still matters in 2025
However attackers operate, they exploit defaults. Although Windows 11 improves the baseline, several protections still require explicit policy. Because Group Policy scales, you stabilize configurations; moreover, you reduce drift and, consequently, keep evidence for audits. Furthermore, a short list of high-impact controls stops most commodity tradecraft while, at the same time, giving your IR team the visibility it needs.
Before you start: scope, testing, and version notes
First, confirm the Windows 11 build (22H2/23H2/24H2+). Next, refresh ADMX and then import the latest security baseline templates before you change anything. After that, create a “Win11-Hardening-Pilot” OU and, subsequently, link these GPOs there first. After validation, expand to a “Ring 2” OU and, thereafter, to the rest of the estate. Finally, use gpresult /h and Event Viewer to verify effective settings; additionally, document exceptions with owners and expiry dates.
The 20 GPOs (each entry includes path, recommended setting, why it matters, and a quick test)
Turn On Virtualization-Based Security with Credential Guard
Path: Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security
Setting: Enabled; enable Credential Guard with Secure Launch where supported
Why: LSASS secrets stay isolated; credential theft gets dramatically harder.
Quick test: On a pilot device, check System Information → Device Guard or run msinfo32 and confirm “Credential Guard: Running.”
LSA Protection (Run LSASS as a Protected Process)
Path: Computer Configuration → Administrative Templates → System → Local Security Authority → Configure LSASS to run as a protected process
Setting: Enabled (prefer “Enabled with UEFI Lock” on modern hardware)
Why: Blocks unsigned code from hooking LSASS.
Quick test: Check Event Viewer for LSA protection status on boot; monitor for driver conflicts during the pilot.
Microsoft Defender SmartScreen — block, don’t just warn
Paths: File Explorer and Microsoft Edge SmartScreen policies under Administrative Templates
Setting: Enabled; “Warn and prevent bypass” where available
Why: Cuts malware delivery and reputation-based phishing across the OS and browser.
Quick test: Use a known test URL (harmless) to confirm block behavior; verify users can’t bypass.
Attack Surface Reduction (ASR) rules — Block mode
Path: Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack Surface Reduction
Setting: Enabled; set recommended ASR rules to Block (begin in Audit if you must)
Why: Stops macro abuse, script droppers, and LOLBIN chains before EDR escalates.
Quick test: Trigger a benign test that would normally fire “Office spawning child process” and verify a block event.
Controlled Folder Access (CFA)
Path: …Exploit Guard → Controlled folder access → Configure controlled folder access
Setting: Enabled; Block (pilot in Audit for noisy apps)
Why: Mitigates ransomware by protecting designated folders from unauthorized writes.
Quick test: Attempt a non-privileged write to a protected folder from a non-allowed app; confirm block.
Defender Cloud Protection (“Block at First Sight”)
Path: Microsoft Defender Antivirus → MAPS/MpEngine
Setting: Enabled; High cloud protection level; automatic sample submission on
Why: Gets faster verdicts and stops new malware families quickly.
Quick test: Confirm “Cloud protection” is On in Windows Security; review Defender events for cloud lookups.
Potentially Unwanted Applications (PUA) protection
Path: Microsoft Defender Antivirus → Configure detection for potentially unwanted applications
Setting: Enabled; Block (not Audit)
Why: Removes adware, bundlers, and nuisance installers that degrade security.
Quick test: Download a harmless PUA test sample; verify quarantine and alert.
BitLocker (OS and fixed drives)
Path: Windows Components → BitLocker Drive Encryption
Setting: Require TPM; XTS-AES (128 for performance or 256 if your policy requires); disallow clear key; back up recovery keys to AD DS/Entra ID; consider pre-boot PIN for high-risk roles
Why: Protects data at rest and stolen devices without daily friction.
Quick test: Confirm drive status with manage-bde -status; verify recovery key escrow in directory.
Enforce SMB signing (client and server)
Path: Security Options → Microsoft network client/server: Digitally sign communications (always)
Setting: Enabled for both client and server
Why: Reduces relay/MITM risk on file shares; plan for older NAS quirks.
Quick test: Use a test share; verify signed negotiation in logs; watch for legacy device errors.
You Should Disable SMBv1 everywhere
Path: via baseline/feature removal and policy (per environment)
Setting: Remove SMBv1; ensure clients can’t re-enable
Why: Legacy, insecure protocol—turn it off to avoid attacks that still hunt SMBv1.
Quick test: Attempt SMB1 negotiation to a test host; confirm failure and SMB2/3 use elsewhere.
Disable insecure guest logons
Path: Administrative Templates → Network → Lanman Workstation → Enable insecure guest logons
Setting: Disabled
Why: Prevents anonymous share access that bypasses authentication and signing.
Quick test: Try accessing a test share configured for guest; confirm access is denied.
Mostly Disable LLMNR
Path: Administrative Templates → Network → DNS Client → Turn off multicast name resolution
Setting: Enabled
Why: Stops responder-style spoofing on local segments.
Quick test: Use a responder lab and attempt LLMNR poisoning; confirm no responses from hardened hosts.
NTLM hardening (prefer NTLMv2 only; audit and restrict)
Paths: Security Options → LAN Manager authentication level = “Send NTLMv2 response only; refuse LM & NTLM”; plus “Restrict NTLM” policies (audit first)
Setting: NTLMv2 only; phase out legacy dependencies
Why: Cuts downgrade and relay exposure.
Quick test: Review domain controllers for NTLM usage; remediate legacy apps before enforcing.
Windows Defender Firewall — on for all profiles; block inbound; limit rule merging
Path: Windows Firewall with Advanced Security
Setting: Enable Domain/Private/Public; Block inbound by default; disable local rule merging where appropriate; scope RDP and management rules tightly
Why: Prevents lateral movement and keeps local exceptions from undermining policy.
Quick test: From a test subnet, verify that only approved ports allow inbound; check the effective rules pane.
RDP hardening — require NLA
Path: Remote Desktop Services → Remote Desktop Session Host → Security → Require user authentication for remote connections by using NLA
Setting: Enabled
Why: Removes pre-auth attack surface and reduces brute-force attempts.
Quick test: Attempt an RDP connection with an older client lacking NLA; confirm failure.
Advanced Audit Policy — include command line and core coverage
Path: Security Settings → Advanced Audit Policy Configuration
Setting: Audit Process Creation (Success) and “Include command line in process creation events”; plus coverage for Credential Validation, Logon/Logoff, Policy Change, Object Access
Why: Gives incident responders the fidelity needed to see what truly ran.
Quick test: Launch a known command with parameters; verify Event ID 4688 with full command line.
PowerShell logging — Script Block + Module logging
Path: Administrative Templates → Windows Components → Windows PowerShell
Setting: Turn on Script Block Logging = Enabled; Turn on Module Logging = Enabled
Why: Illuminates script-based attacks and admin misuse.
Quick test: Run a harmless script; confirm events under Microsoft-Windows-PowerShell/Operational.
Removable Storage Access — deny all (scope exceptions if necessary)
Path: Administrative Templates → System → Removable Storage Access
Setting: “All Removable Storage classes: Deny all access” = Enabled (then permit specific roles if policy requires)
Why: Prevents USB-borne malware and unsanctioned exfiltration.
Quick test: Insert a USB drive on a pilot device; confirm deny events and user notification.
On Windows Disable AutoPlay/AutoRun
Path: Administrative Templates → Windows Components → AutoPlay Policies
Setting: Turn off AutoPlay = Enabled (All drives); Set Default Behavior for AutoRun = Do not execute any AutoRun commands
Why: Blocks drive-by execution from removable media.
Quick test: Insert a media device; confirm no automatic prompts or execution.
Print Spooler hardening
Path: Administrative Templates → Printers → Allow Print Spooler to accept client connections
Setting: Disabled on endpoints that are not print servers; leave enabled only where required and compensated
Why: Reduces PrintNightmare-style exposure and narrows remote attack surface.
Quick test: Attempt to connect to the endpoint’s spooler remotely; confirm it’s blocked while local printing still works.
Rollout plan (pilot → audit → block)
Start with three waves. First, turn on SmartScreen, cloud-delivered protection, PUA blocking, and firewall enforcement; meanwhile, keep ASR and Controlled Folder Access in Audit within a small pilot OU. Next, flip ASR and CFA to Block, add Credential Guard and LSA protection on modern hardware, and enforce SMB signing across tested shares. Then, remove SMBv1, restrict NTLM to NTLMv2 only, require RDP NLA, and apply removable-media and print-spooler hardening.
In parallel, announce each change window, and schedule reboots where required. Additionally, track Event IDs mapped to each control. As you scale, measure help-desk tickets and performance counters; consequently, you can adjust thresholds and exceptions quickly.
Troubleshooting and exceptions
If a legacy app breaks under ASR or CFA, first capture exact process details from events; then create a narrow exception and finally set an expiry date. Alternatively, if SMB signing disrupts an older NAS, isolate that share on its own VLAN or gateway and, meanwhile, plan a replacement.
For NTLM hardening, start in Audit; then remediate; thereafter enforce. Also, keep a single exception register: system, owner, reason, scope, expiry, and review date. When exceptions expire, remove them unless the business case still stands.
Conclusion and next steps
Overall, these 20 GPOs push Windows 11 toward a Zero Trust posture without boiling the ocean. As a result, you keep credentials safer, you reduce ransomware paths, you shrink the RDP and SMB blast radius, and you collect the logs that matter. Next, align with your EDR playbooks, enforce MFA on privileged accounts, and automate baseline drift checks monthly. Finally, review metrics quarterly and, if necessary, iterate.
FAQs
Do I need 256-bit XTS for BitLocker?
Use XTS-AES 128-bit for most endpoints to balance performance and assurance. If policy or regulation demands 256-bit, test performance on older hardware, then apply by role.
Will SMB signing break my NAS?
Some older appliances struggle. Plan a test window, enable signing on a pilot share, and monitor throughput. If it fails, isolate that NAS and prioritize a firmware update or replacement.
Should I set ASR to Block immediately?
If you have tight software inventories, yes. Otherwise, run Audit for a week, review detections, adjust, and then flip to Block. Don’t leave Audit on indefinitely.
How do I test GPOs safely?
Use a dedicated pilot OU and two rings of users. Validate with gpresult /h, Device Security statuses, and targeted functional tests (printing, line-of-business apps, mapped drives).
What about WDAC or AppLocker?
They’re powerful but operationally heavier. Start with these 20 controls, then consider WDAC/AppLocker for high-risk roles or kiosks after you stabilize.
Will these GPOs slow devices?
Defender’s features run efficiently on modern hardware. BitLocker adds slight overhead; ASR and CFA affect specific behaviors. Pilot first, then deploy broadly.
2 thoughts on “Windows 11 Hardening Guide: 20 Must-Have GPO Settings”