๐ŸŽ New User? Get 20% off your first purchase with code NEWUSER20 ยท โšก Instant download ยท ๐Ÿ”’ Secure checkout Register Now โ†’
Menu

Categories

Windows Server 2025 Security Baseline: A Production Rollout (2026)

Windows Server 2025 Security Baseline: A Production Rollout (2026)
Windows Server 2025 security baseline - Dargslan 2026

Windows Server 2025 is the first Windows Server release in a decade with security as the headline change rather than a parallel track. SMB 3.1.1 is the only SMB dialect on by default, NTLM is on the deprecation path, Credential Guard is on for every supported edition, signed builds are required for kernel drivers without exception, and dozens of policy defaults moved one notch tighter. On top of all that, the Microsoft Security Compliance Toolkit (SCT) ships an updated Security Baseline GPO pack that flips another hundred-odd settings to the recommended posture. The combined effect is meaningful: a fresh Server 2025 with the baseline applied is the most defensible Windows Server you have ever deployed. The rollout, however, has real edges - some legacy clients break on the SMB hardening, some applications break on the NTLM disablement, some monitoring agents break on Credential Guard. This guide walks the production rollout that captures the security wins without making service owners angry. It ships a free PDF cheat sheet of the exact GPOs, registry keys and verification commands.

Why Server 2025 baseline is worth the rollout

The Windows Server hardening story before 2025 was "spend two days editing GPOs, then re-spend that time after every cumulative update". The CIS Benchmark and Microsoft's own baseline drifted, the registry keys were obscure, and the verification was per-host. Server 2025 narrows the gap: the OS defaults moved closer to the baseline, the baseline GPO pack matches the OS version, and PowerShell DSC + the new WindowsHardening module make compliance auditable. The rollout is one well-documented project rather than a years-long erosion battle.

What is new and on by default

The headline default changes in Server 2025:

  • SMB 3.1.1 only - SMB1 is removed entirely, SMB2 disabled by default. Negotiation, signing, encryption follow the most-modern defaults.
  • SMB signing required for both client and server. No more anonymous SMB-relay attacks against unsigned traffic.
  • NTLM auditing on by default. Use of NTLM is logged in Security Event 8004 / 8001; the deprecation toggle is one policy away.
  • Credential Guard on by default for Datacenter and Standard editions on capable hardware. LSA secrets, Kerberos TGTs, NTLM hashes live in a VBS-isolated container.
  • HVCI (Memory Integrity) enforced for kernel-mode code; unsigned drivers do not load.
  • LDAP signing and channel binding required by default on AD DS roles.
  • WDigest, NTLMv1, RC4 in Kerberos all disabled by default.

Many of these were available in 2022 as opt-in; in 2025 they are opt-out. The baseline GPO pack closes the remaining handful of defaults that did not move (event-log sizing, audit categories, scheduled-task hardening, RDP NLA enforcement).

Security Compliance Toolkit and the baseline GPOs

Download the SCT from the Microsoft Download Center; the Server 2025 pack ships as a ZIP with three folders:

  • GPOs - importable Group Policy Objects (Domain, Member Server, Domain Controller variants).
  • Templates - the underlying ADMX files for any Server 2025-only settings.
  • Documentation - delta from Server 2022 baseline, and from Microsoft "ideal" defaults to "compatible" defaults.

Importing into a clean lab is one PowerShell call:

cd "WS2025-Baseline\\Scripts"
.\\Baseline-ADImport.ps1 -SourceLocation ..\\GPOs -OUList @(
    "OU=Member Servers,OU=Production,DC=contoso,DC=local",
    "OU=Domain Controllers,DC=contoso,DC=local"
)
gpresult /h baseline-applied.html /scope computer

The script creates the GPOs, links them to the OUs, and reports the link order. The gpresult output is the per-host verification.

Credential Guard and LSA protection

Credential Guard moves credential secrets into a Hyper-V-isolated container. Mimikatz against an LSASS process protected by Credential Guard returns nothing useful. The defaults in 2025 enable it on capable hardware (UEFI + TPM 2.0 + VBS-supported CPU), but a few settings are worth setting explicitly:

Computer Configuration > Administrative Templates > System >
  Device Guard > Turn On Virtualization Based Security
    - Platform Security Level: Secure Boot and DMA Protection
    - Virtualization Based Protection of Code Integrity: Enabled with UEFI lock
    - Credential Guard: Enabled with UEFI lock
    - Secure Launch Configuration: Enabled
    - Kernel-mode Hardware-enforced Stack Protection: Enabled in enforcement

UEFI lock means the setting cannot be disabled by editing the policy back - you have to physically interact with the firmware. That is the right setting for production; the wrong setting if you are still in pilot.

LSA Protection (RunAsPPL) makes the LSA process protected by the kernel, blocking the common credential-dumping techniques even on hosts that cannot run Credential Guard. Set it via HKLM\System\CurrentControlSet\Control\Lsa\RunAsPPL = 2 (boot-time enforcement).

SMB hardening

The SMB-relay attack is a perennial favourite of red teams. Server 2025 closes it by requiring signing and by removing the legacy dialects. Verify on the server:

Get-SmbServerConfiguration | Format-List EnableSMB1Protocol,EnableSMB2Protocol,RequireSecuritySignature,EnableSecuritySignature
# EnableSMB1Protocol      : False
# EnableSMB2Protocol      : True   (this is SMB 2.x and 3.x, both)
# RequireSecuritySignature: True
# EnableSecuritySignature : True
Get-SmbClientConfiguration | Format-List RequireSecuritySignature

If a legacy NAS or printer requires SMB1, do not flip it back globally. Carve a single host (the print server, or a tiny relay) that speaks SMB1 to that one device, scope the firewall, and document the exception. Re-enabling SMB1 globally on a 2025 server defeats most of what the baseline gave you.

NTLM deprecation - the audit path

Outright disabling NTLM is the goal; the path there is two months long. Run the NTLM audit settings for at least 30 days first to enumerate every NTLM use across the fleet:

Computer Configuration > Windows Settings > Security Settings >
  Local Policies > Security Options >
    Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
    Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all
    Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit all

Events land in Microsoft-Windows-NTLM/Operational (Event ID 8001-8004). Forward to the SIEM, identify the workloads, fix or replace them, then flip the policy from Audit to Deny. Do not skip the audit - flipping straight to Deny breaks file-share access for any client that has not negotiated Kerberos.

Attack-surface reduction rules for servers

ASR rules used to be a Windows-client thing; in Server 2025 they are first-class on Server too. The rules that matter on a typical server workload:

  • D4F940AB-401B-4EFC-AADC-AD5F3C50688A - Block all Office applications from creating child processes (relevant to RDS hosts).
  • 3B576869-A4EC-4529-8536-B80A7769E899 - Block Office applications from creating executable content.
  • BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550 - Block executable content from email client and webmail.
  • 9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2 - Block credential stealing from Windows local security authority subsystem (LSASS).
  • D1E49AAC-8F56-4280-B9BA-993A6D77406C - Block process creations originating from PsExec and WMI commands.

Roll out in Audit mode for two weeks per rule, mine the events for legitimate use cases (the LSASS rule will catch your monitoring agent), exempt the agent precisely, then promote to Block.

Production rollout sequence

  1. Lab validation (week 1). Spin up a representative server, apply the baseline, run the application's full integration suite. Capture every break.
  2. Pilot (week 2-3). One or two non-critical production servers. Apply the baseline, monitor for 14 days. Adjust exceptions.
  3. Wave 1 (week 4-5). A bounded role - say all build-server hosts. Apply, monitor. Document any role-specific exceptions.
  4. Wave 2-N. Subsequent roles, two waves apart. Domain controllers last - they have the most legacy assumptions.
  5. NTLM deny (month 3). After the audit period, flip from Audit to Deny on member servers, then on DCs.
  6. ASR Block (parallel). Per-rule promotion from Audit to Block as the audit period clears.

Verifying compliance

# PolicyAnalyzer (in the SCT) compares any host to the baseline GPO pack
# CLI verification:
Get-WindowsFeature | Where-Object Installed -eq $true | Select Name,DisplayName
Get-SmbServerConfiguration | fl
Get-MpComputerStatus | Select AMRunningMode,RealTimeProtectionEnabled,NISEnabled
Get-MpPreference | Select AttackSurfaceReductionRules_Ids,AttackSurfaceReductionRules_Actions
auditpol /get /category:* | findstr "No Auditing"   # everything you forgot

For ongoing compliance ship Microsoft's WindowsHardening PowerShell module to every host and run it as a scheduled task; the module returns a JSON report that drops into the SIEM and is the easiest way to track drift week to week.

Common pitfalls

  • Applying the baseline to legacy roles unchanged. Cluster nodes, Hyper-V hosts and AD CS need known exceptions; check the SCT documentation per role.
  • Skipping the NTLM audit period. Flipping straight to Deny breaks more than you expect. The 30-day audit is the cheapest investment in the rollout.
  • Enabling Credential Guard with UEFI lock in a pilot. Use the unlocked variant during pilot; the locked variant after acceptance.
  • No drift detection. The baseline degrades when individual hosts get tuned; without a weekly compliance scan, three months later you are nowhere near the baseline.
  • Treating the baseline as a one-shot. Microsoft updates the baseline GPO pack with every cumulative update wave; track the SCT release notes.

Audit checklist

  1. SCT baseline GPOs applied to every Server 2025 OU (1 pt)
  2. Credential Guard + HVCI verified on every capable host (1 pt)
  3. SMB1 removed; SMB signing required client + server (1 pt)
  4. NTLM in Audit (or Deny) with events in SIEM (1 pt)
  5. ASR rules in Audit or Block, with documented exceptions (1 pt)

5/5 = PASS, 3-4 = WARN, <3 = FAIL.

FAQ

Does the baseline apply to Server Core?

Yes - the same GPOs apply to Server Core. Many of the registry-only settings are in fact better suited to Core.

What if my application requires NTLM?

Identify it during the audit period. Most "NTLM-required" applications work with Kerberos with a small SPN registration - that is the right fix. Genuinely NTLM-only software in 2026 is a strong signal to replace it.

Does Credential Guard slow the host down?

~3-5% overhead on credential-heavy workloads; imperceptible on most servers. The trade-off is overwhelmingly worth it.

Can I use Defender for Endpoint to enforce ASR centrally?

Yes - via the security baselines profile in Intune or via the Defender ASM. Centralised enforcement is preferable to per-host GPO at scale.

Are there CIS Benchmark / DISA STIG mappings?

Yes; the SCT documentation includes a delta table to both. CIS L1 maps closely to the Microsoft baseline; CIS L2 / DISA STIG add a smaller set of more aggressive settings.

Related Dargslan resources

Share this article:
Dargslan Editorial Team (Dargslan)
About the Author

Dargslan Editorial Team (Dargslan)

Collective of Software Developers, System Administrators, DevOps Engineers, and IT Authors

Dargslan is an independent technology publishing collective formed by experienced software developers, system administrators, and IT specialists.

The Dargslan editorial team works collaboratively to create practical, hands-on technology books focused on real-world use cases. Each publication is developed, reviewed, and...

Programming Languages Linux Administration Web Development Cybersecurity Networking

Stay Updated

Subscribe to our newsletter for the latest tutorials, tips, and exclusive offers.