A checklist that says “disable SMBv1, enforce NTLMv2, disable the guest account” and stops there works for a single flat fleet. It stops working the moment the same environment runs a domain controller, a file server carrying a legacy line-of-business share, an IIS host facing the internet, and a SQL Server instance behind it. Each role tolerates a different amount of restriction before something breaks, and both Windows Server 2022 and Windows Server 2025 ship defaults that assume per-role tuning rather than one policy pushed everywhere. This checklist is organized the way hardening actually gets done: scope by role first, then work through identity, network surface, audit policy, deployment mechanism, and the recheck cycle that keeps a baseline from rotting after the first patch cycle.
Scope the baseline by role before touching a single setting
Start from a role inventory, not a settings list. A domain controller, a member file server, an IIS front end and a SQL host share maybe sixty percent of their hardening requirements; the other forty percent is where blanket application does damage. CIS Benchmarks for Windows Server ship two levels for exactly this reason: Level 1 is the baseline every role should reach with minimal application impact, Level 2 is defense-in-depth that assumes a controlled environment and higher tolerance for breakage. Treat Level 2 as opt-in per role, not a default.
| Role | Non-negotiable | Apply with caution |
|---|---|---|
| Domain controller | LDAP signing, Protected Users group for tier-0 accounts, Kerberos delegation review | Aggressive NTLM blocking (breaks legacy trusts and print servers) |
| File server | SMB signing, disable SMBv1, restrict anonymous enumeration | SMB encryption on shares consumed by old NAS backup agents |
| IIS host | TLS 1.2 minimum, remove unused modules, disable directory browsing | Removing legacy TLS entirely before checking client and load balancer compatibility |
| SQL Server host | Disable mixed-mode auth where not required, restrict sysadmin membership | Blanket “deny logon locally” that also catches the SQL Agent service account |
Build the role list before you open a single GPO. Everything downstream in this checklist assumes you know which servers can absorb the stricter setting and which need a documented exception.
Identity and authentication settings
Local administrator accounts are the first thing to fix because they are the easiest to fix. Deploy Windows LAPS (built into Server 2019 and later, with the policy templates under Computer Configuration, Administrative Templates, System, LAPS) so every local administrator password is unique per host, rotated on a fixed age, and readable only by an authorized AD group. A 30-day rotation with complexity enforced is a reasonable default; shorten it for internet-facing tiers.
Next, remove LM hash storage and cap NTLM at a modern level:
- Set HKLMSYSTEMCurrentControlSetControlLsaNoLMHash to 1 so new passwords never generate an LM hash.
- Set “Network security: LAN Manager authentication level” to Send NTLMv2 response only. Refuse LM & NTLM (LmCompatibilityLevel = 5), but only after confirming no legacy Samba or embedded appliance still authenticates with LM.
- Before blocking NTLM outright, enable “Network security: Restrict NTLM: Audit NTLM authentication in this domain.” It writes event ID 8004 to the Microsoft-Windows-NTLM operational log and tells you exactly which service accounts and applications still depend on it, so you block with evidence instead of guessing.
Logon rights are the setting most teams skip. On member servers, add administrative accounts to “Deny log on through Remote Desktop Services” unless they are the specific jump-host or PAM accounts meant to use it, and restrict “Access this computer from the network” so only expected service and management accounts can reach a host over SMB or RPC. This single change closes a large share of lateral movement paths that a flat password policy never touches.
Network surface: legacy protocols, SMB, WinRM, RDP, unused roles
Remove SMBv1 rather than just disabling it, since the feature binary carries its own risk if re-enabled by accident:
- Remove-WindowsFeature FS-SMB1 removes the server-side feature.
- Set-SmbServerConfiguration -RequireSecuritySignature $true -EncryptData $true enforces signing and, where the workload allows the overhead, encryption on SMB3 traffic. Windows Server 2025 requires signing by default for workgroup-joined servers; domain-joined fleets still need the GPO setting applied explicitly.
For WinRM, run winrm quickconfig -transport:https so remote management traffic is encrypted at the transport layer, disable Basic authentication with Set-Item WSMan:localhostServiceAuthBasic $false, and scope the Windows Firewall rule for the WinRM listener to the management subnet rather than leaving it open to Any. For RDP, require Network Level Authentication (Remote Desktop Session Host, Security, “Require user authentication for remote connections by using Network Level Authentication”), and where a server does not need interactive human logon at all, disable the Remote Desktop Services listener entirely and route administration through a bastion or PAM session recorder instead. An RDP listener reachable from a broad internal range is one of the most common findings that attack surface mapping turns up on internal networks, not just on the perimeter.
Finally, audit installed roles and features with Get-WindowsFeature | Where-Object Installed and remove what is not in active use. Print Spooler is the standing example: unless the host is genuinely a print server, stop and disable it (Stop-Service Spooler; Set-Service Spooler -StartupType Disabled) since it has been the entry point for multiple privilege escalation and remote code execution advisories, PrintNightmare being the one that made every hardening list afterward.
Audit policy subcategories that must be on before anything else
Turn on logging before you turn off anything else, because you need a baseline to diff against once restrictions start breaking things. The nine legacy audit categories are too coarse; use the subcategories:
| Subcategory | Command | Why it matters first |
|---|---|---|
| Credential Validation | auditpol /set /subcategory:”Credential Validation” /success:enable /failure:enable | Catches NTLM authentication attempts you are about to restrict |
| Kerberos Authentication Service | auditpol /set /subcategory:”Kerberos Authentication Service” /success:enable /failure:enable | Baseline for domain controller authentication before delegation changes |
| Logon and Special Logon | auditpol /set /subcategory:”Logon” /success:enable /failure:enable | Surfaces the logon-rights changes made in the identity section |
| Security and User Account Management | auditpol /set /subcategory:”Security Group Management” /success:enable /failure:enable | Detects privilege escalation via group membership |
| Process Creation | auditpol /set /subcategory:”Process Creation” /success:enable | Needs the command-line switch below to be useful |
Process Creation auditing is close to useless without command-line capture. Set HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemAuditProcessCreationIncludeCmdLine_Enabled to 1 so event ID 4688 records the full command line, not just the executable name. Forward all of this to a SIEM or log collector before you start disabling protocols; a restriction rollout without a log trail to check against is a rollback waiting to happen. This is also the telemetry that a continuous validation pipeline consumes: platforms that automate discovery and triage, SITEY among them, correlate authentication and process-creation events against known exposures instead of treating a scan result as standalone evidence.
Applying the list: GPO vs local policy, and what tends to break
For a domain-joined fleet, apply hardening through Group Policy, scoped to an OU per role from the table above, not to the domain root. Export a snapshot before you start with secedit /export /cfg baseline.inf so you can diff against it later. For workgroup servers, edge appliances, or a golden image you bake once and clone, use LGPO.exe to convert the Microsoft Security Compliance Toolkit baseline into local policy rather than maintaining settings by hand across machines that never see a domain controller.
The settings that break production most often, in order of how frequently they show up in rollback tickets:
- NTLM restriction blocking a legacy application or backup agent that was never audited first.
- SMB signing required breaking an older NAS, tape library, or scanner appliance that does not support it.
- LmCompatibilityLevel 5 breaking a Linux Samba client still on an old protocol version.
- Deny “access this computer from the network” catching a service account nobody remembered was using interactive-style authentication.
- Disabling SMBv1 breaking a print device or scanner that only speaks the legacy dialect.
Roll out in audit mode on a pilot OU first, watch the log subcategories above for a full patch cycle, then move to enforcement. Treat any exception as a documented, time-boxed compensating control tied to a specific asset, not a silent skip.
Continuous verification: re-checking the baseline after patches, role changes and rebuilds
A hardening baseline is not a one-time project. Cumulative updates occasionally reset a registry-backed default back to its out-of-box value, a new role installed six months later opens a listener nobody scoped, and a rebuilt server pulled from an aging golden image silently reintroduces settings the original hardening pass removed. Re-run the compliance check on a fixed cadence rather than relying on memory:
- After every Patch Tuesday cycle, diff the current state against the secedit baseline export.
- After any new Windows feature or role installation, re-run Get-WindowsFeature and re-scope firewall rules for anything new that started listening.
- On a monthly schedule regardless of change activity, re-map the live configuration against the CIS or Microsoft Security Baseline being used as the reference, and file any drift as a tracked finding rather than a silent fix.
This is where a checklist stops being a document and starts being a process with an owner. Mapping the same evidence to ISO 27001, PCI DSS or SOC 2 control language at the same time removes the second pass most teams end up doing manually before an audit; that mapping is the specific job of a compliance mapping layer sitting on top of the raw configuration data. Patch cycles are also the moment settings regress most often, which is why closing the loop between a config check and the patch management pipeline that shipped the update matters more than the initial hardening pass itself. An autonomous platform such as SITEY treats this recheck as a standing pipeline phase rather than a quarterly spreadsheet exercise, re-scanning role-scoped baselines automatically after each patch window and flagging drift the same way it flags a newly discovered vulnerability.
The list above will get you to a defensible baseline on both Windows Server 2022 and Windows Server 2025. The part that actually determines whether that baseline holds for the life of the server is the recheck cadence, not the initial configuration pass.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.