Windows Server Hardening Checklist: Secure Your VPS Before Production

Windows Server hardening reduces the attack surface of a VPS before it becomes a production system. The goal is not to apply hundreds of settings blindly. It is to start with high-impact controls, preserve a recovery path, verify each change, and then move toward Microsoft’s supported security baseline for the server version and role you actually run.

For Windows Server 2025, Microsoft now provides a role-aware OSConfig security baseline with more than 300 settings. That baseline covers network exposure, credentials, auditing, Defender, SMB, log retention, and other controls that are broader than this SMB-focused checklist.

In short

Before production, audit administrator access, keep Windows Firewall enabled, reduce RDP exposure, require Network Level Authentication, keep Microsoft Defender active, remove SMBv1, review SMB signing, enable useful security auditing, patch on a controlled schedule, and document every change. On Windows Server 2025, use Microsoft’s official security baseline as the long-term reference instead of treating a manual checklist as a complete compliance standard.

The production hardening checklist starts with risk reduction

Do not apply security changes in bulk to a remote server without a recovery path. Authentication, firewall, RDP, SMB, Defender, and service changes can lock out administrators or break production software.

Microsoft’s Windows Server 2025 baseline is the reference point

Windows Server 2025 has an official Microsoft security baseline delivered through OSConfig. Microsoft describes it as a role-aware baseline with more than 300 settings and recommends testing and customizing the baseline for the server role rather than manually configuring hundreds of controls one by one.

The current baseline includes controls that:

• keep Windows Firewall enabled with a default-deny inbound posture;
• disable SMBv1 and legacy name-resolution protocols such as LLMNR;
• strengthen SMB signing and authentication behavior;
• reduce anonymous and guest access;
• strengthen credential protections;
• enable broad advanced auditing;
• capture process creation with command-line data;
• increase Security log capacity;
• harden Defender and exploit protections.

For Windows Server 2022 and older supported releases, Microsoft’s Security Compliance Toolkit remains the practical source for Microsoft-recommended Group Policy baselines.

This Raff checklist focuses on the controls that are easiest to understand and validate on a standalone or small-business VPS. It is not a replacement for Microsoft’s complete baseline, CIS Benchmarks, DISA STIGs, or a formal security program.

The original Raff lab evidence remains useful

The existing screenshots in this article were captured during a Raff Windows Server 2025 Datacenter Evaluation lab on May 24, 2026.

That lab verified the inspection commands for local users, administrators, account policy, Windows Firewall, RDP rules, Microsoft Defender preferences, and audit policy. It did not apply every hardening control in this article, and this August update does not claim a fresh end-to-end hardening test.

Administrator access should be reviewed before anything else

Run PowerShell as Administrator and inventory local users:

Get-LocalUser | Select-Object Name, Enabled, LastLogon

Then inspect the local Administrators group:

Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass

Investigate unknown accounts before removing them. Disable obsolete test users, keep the Guest account disabled, and avoid shared administrator credentials.

Check the Guest account:

Get-LocalUser Guest | Select-Object Name, Enabled

If it is enabled and no legacy application explicitly requires it:

Disable-LocalUser -Name "Guest"

For routine work inside the server, use a non-administrator account and elevate only when administrative rights are required.

Renaming the built-in Administrator account can be part of a managed security baseline, but it is not a substitute for strong credentials, restricted RDP exposure, monitoring, and least privilege. If you rename it, document the new identity and recovery process first.

Account lockout should follow a deliberate baseline

Check the current local account policy:

net accounts

Do not treat one lockout threshold as universally correct. Microsoft’s current Windows Server 2025 OSConfig baseline uses a three-attempt threshold with a 15-minute duration and reset window, while other Microsoft baseline guidance can use different values depending on the product and management model.

A stricter threshold slows password guessing but also increases the risk of denial-of-service through deliberate lockouts. For domain environments, configure the policy centrally. For standalone VPS deployments, document the chosen threshold and test administrative recovery before enforcing it.

The important production checks are:

• lockout is intentionally configured rather than left to chance;
• recovery access exists if the primary admin is locked out;
• failed logons are monitored;
• local administrator passwords are unique;
• shared admin accounts are avoided.

Windows Firewall and RDP should reduce public exposure

Keep Windows Firewall enabled on all profiles:

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Inspect the current Remote Desktop rule group:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName, Enabled, Direction, Action, Profile |
Format-Table -AutoSize

Microsoft recommends keeping Windows Firewall enabled and using explicit allow rules for required traffic. For a VPS, start from the rule that inbound access should exist only when the workload needs it.

For RDP administration:

• restrict source IPs where operationally possible;
• prefer a VPN or private administrative path when available;
• keep RDP limited to named administrators or intended RDS users;
• do not expose SMB, SQL Server, WinRM, or management ports broadly to the internet;
• keep a recovery path available before changing remote-access rules.

For the detailed firewall workflow, see Configure Windows Firewall on a Windows VPS.

Network Level Authentication should remain enabled for RDP

Network Level Authentication requires the user to authenticate before Windows creates a full remote desktop session. Microsoft recommends NLA for most environments because it reduces the resources exposed to unauthenticated connections.

Check the RDP NLA policy value:

Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name UserAuthentication

A UserAuthentication value of 1 means NLA is required.

Do not disable NLA simply to make an old RDP client connect. Upgrade the client or document the compatibility exception and its risk.

SMBv1 should stay removed and SMB signing should be reviewed

SMBv1 has significant security weaknesses and is not installed by default on Windows Server 2019 and later. Verify that the server is not relying on it:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

If an old application requires SMBv1, upgrading or replacing that dependency is safer than re-enabling the protocol.

Windows Server 2025 also strengthens SMB signing defaults, and Microsoft’s Server 2025 security baseline requires signing on the client and server sides. Review the effective settings:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature

If you enforce SMB signing on an environment that uses old NAS devices or third-party SMB servers, test compatibility first. Do not disable signing merely to make unauthenticated guest access work.

Keep TCP 445 off the public internet. If users need file access across locations, use a private network, VPN, or another controlled access design.

Microsoft Defender should remain an active security layer

Verify Defender’s main protection settings:

Get-MpPreference | Select-Object DisableRealtimeMonitoring, DisableBehaviorMonitoring, DisableScriptScanning

For a normal protected baseline, these values should not show Defender’s real-time, behavior, or script scanning as disabled.

Update signatures with:

Update-MpSignature -Verbose

Attack Surface Reduction rules and Controlled Folder Access can add meaningful protection, but they can also interfere with ERP clients, Office automation, scripts, installers, and legacy applications. Test them in audit or controlled rollout modes before enforcing them on a production workload.

Do not disable antivirus globally to solve an application problem. Use vendor-documented exclusions only when they are necessary and narrowly scoped.

Audit policy should capture the events you will actually investigate

Check the audit state for high-value categories:

auditpol /get /subcategory:"Logon"
auditpol /get /subcategory:"Account Lockout"
auditpol /get /subcategory:"User Account Management"
auditpol /get /subcategory:"Process Creation"

Microsoft’s Server 2025 baseline enables broad advanced auditing and includes process creation with command-line capture. For a smaller VPS, at minimum make sure you can investigate:

• successful and failed logons;
• account lockouts;
• user-account changes;
• administrator and privilege changes;
• process creation;
• firewall activity relevant to exposed services.

Example audit-policy commands:

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable

For complete production policy, use Microsoft’s advanced audit recommendations or the official baseline rather than stopping at these five categories.

Security logs need enough retention to be useful

A Security log that rolls over too quickly can erase the exact events needed during an incident review. Microsoft’s Server 2025 baseline increases Security log capacity; its baseline documentation references at least 192 MB.

Check the current maximum size:

wevtutil gl Security | Select-String maxSize

For a production VPS, choose a log size based on event volume and retention needs rather than an arbitrary number. If the server generates many RDP, authentication, file-share, or application events, increase the Security log and monitor rollover behavior.

Also consider sending critical logs to a separate logging or monitoring system so compromise of the server does not remove the only copy of the evidence.

Failed logons should be monitored, not merely recorded

Windows Security event ID 4625 records failed logon attempts. Review recent failures:

Get-WinEvent -FilterHashtable @{
  LogName='Security'
  Id=4625
  StartTime=(Get-Date).AddHours(-24)
}

A spike in failed RDP logons should trigger a review of:

• RDP exposure;
• source-IP restrictions;
• administrator usernames;
• password policy;
• stale accounts;
• patch state;
• whether the server should be reachable directly from the internet at all.

Do not rely on lockout policy alone as an anti-brute-force control.

PowerShell logging improves incident visibility

PowerShell script block logging records the content of processed script blocks in the Microsoft-Windows-PowerShell/Operational log, including event ID 4104.

Enable it through Group Policy when possible. A registry-based configuration is also available:

$basePath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
New-Item -Path $basePath -Force | Out-Null
Set-ItemProperty -Path $basePath -Name EnableScriptBlockLogging -Value 1

PowerShell logs can contain sensitive values such as tokens, connection strings, or credentials accidentally placed in scripts. Microsoft recommends considering Protected Event Logging when Script Block Logging is used beyond diagnostics.

Unused services and roles should be removed carefully

Reducing unnecessary services lowers attack surface, but randomly disabling services can break applications or management functions.

List running services:

Get-Service | Where-Object Status -eq 'Running' | Sort-Object Name |
Format-Table Name, DisplayName

Use this process before disabling anything:

1. Identify the service or Windows role.
2. Confirm whether Windows or the application uses it.
3. Check Microsoft or vendor documentation.
4. Take a recovery snapshot if the change is material.
5. Disable only the unnecessary component.
6. Reboot if required.
7. Test the complete workload.

For example, disable Print Spooler only on servers that truly do not print and do not run PDF, accounting, ERP, or other software that depends on printing components.

IPv6 should not be disabled without a specific reason

Do not disable IPv6 as a generic hardening step. Microsoft warns that Windows components can depend on IPv6 behavior, and disabling it without a documented requirement can cause unexpected networking problems.

The safer rule is simple: leave IPv6 enabled unless the network design specifically requires a change and the workload has been tested after that change.

Patching is part of hardening

A hardened server with old security updates is still exposed.

Use a controlled patch process:

• review Microsoft release health;
• monitor actively exploited vulnerabilities;
• take a backup or snapshot before significant patch windows;
• patch during a planned maintenance window;
• reboot intentionally;
• verify both Windows and the hosted application afterward.

CISA’s Known Exploited Vulnerabilities catalog is a useful signal for vulnerabilities that are being exploited in the wild, but patch priority should also consider whether the affected feature is installed and exposed on your server.

For the full workflow, see Windows Update Strategy on Production Servers.

Backups and snapshots are recovery controls, not security substitutes

Take a snapshot before high-risk configuration changes, but do not treat snapshots as the only backup strategy.

A practical production recovery model includes:

• application-aware backups where required;
• VM or disk-level recovery points;
• at least one copy outside the live server;
• documented recovery credentials;
• periodic restore testing.

A snapshot is valuable when a hardening change breaks the server. It does not replace ransomware-resistant or off-server backups.

Every security change should have an owner and rollback plan

Keep a small hardening changelog:

This makes future troubleshooting much faster and prevents a later administrator from undoing a security control because nobody knows why it exists.

A practical SMB hardening order reduces lockout risk

Use this order for an existing Windows VPS:

1. Confirm backup/snapshot and recovery access.
2. Audit users and administrators.
3. Review account and lockout policy.
4. Confirm Windows Firewall is enabled.
5. Review RDP exposure and NLA.
6. Verify SMBv1 is disabled and review SMB signing.
7. Confirm Defender protection is active.
8. Enable useful audit policy and log retention.
9. Review PowerShell logging.
10. Patch Windows and exposed applications.
11. Remove unnecessary services and roles carefully.
12. Document and re-test the workload.
13. Compare the result with Microsoft’s official security baseline.

This sequence improves security without starting with the controls most likely to lock you out.

Common hardening mistakes create avoidable outages

Applying a baseline without testing the workload

Security baselines deliberately change authentication, SMB, RDP, auditing, credential, and protocol behavior. Test before production rollout.

Disabling Windows Firewall to fix connectivity

Fix the specific rule or application listener. Do not make the server broadly reachable because one service does not connect.

Using RDP lockout policy as the only brute-force defense

Reduce exposure first. Use NLA, source restrictions, named accounts, monitoring, and a deliberate access architecture.

Re-enabling SMBv1 for an old device

Treat the device or application as a legacy dependency that needs replacement or isolation rather than weakening the entire server.

Enforcing Defender controls without an audit period

ASR and Controlled Folder Access can block legitimate business software. Test them against the real application workflow.

Disabling services because the names look unfamiliar

Unknown does not mean unnecessary. Research, snapshot, change one item, and test.

Calling a checklist “compliant”

This article is operational guidance, not certification. Compliance frameworks require their own scope, evidence, controls, and validation.

Raff’s role is the infrastructure layer

Raff gives you control of the Windows VM and related infrastructure features; operating-system hardening inside the VM remains an administrator responsibility unless a separate managed service explicitly covers it.

For a small production Windows workload, the priority is to make secure defaults repeatable: restricted administration, host firewall, current patches, Defender, modern SMB, meaningful logs, tested backups, and documented changes.

What's next

• Configure Windows Firewall on a Windows VPS
• Windows Update Strategy on Production Servers
• Multi-User RDP: 2 Admin Sessions vs RDS Session Host
• Raff Windows Server Hub
• Raff Windows VM
• Raff Security

Sources

• Microsoft Learn — Deploy Windows Server 2025 security baselines with OSConfig
• Microsoft Learn — Microsoft Security Compliance Toolkit
• Microsoft Learn — Windows Firewall
• Microsoft Learn — Remote Desktop and Network Level Authentication
• Microsoft Learn — SMB security hardening
• Microsoft Learn — Control SMB signing behavior
• Microsoft Learn — Detect, enable, and disable SMBv1, SMBv2, and SMBv3
• Microsoft Learn — Advanced audit policy configuration
• Microsoft Learn — PowerShell logging
• CISA — Known Exploited Vulnerabilities Catalog
• Sources verified: 2026-08-08