In short
Windows Server hardening is the work you do before a VPS becomes production. Start with the controls that reduce the most risk: audit local administrators, enforce account lockout policy, keep Windows Firewall enabled, limit RDP exposure, confirm Microsoft Defender is active, enable useful audit logging, and remove unused services. This checklist is built for practical SMB Windows VPS workloads, not regulated enterprise environments with hundreds of compliance controls.
Quick checklist
| Area | Minimum production check |
|---|---|
| Accounts | Review local users and local Administrators group |
| Passwords | Enforce account lockout and strong password policy |
| RDP | Keep RDP limited to admins and restrict source IPs where possible |
| Firewall | Keep Windows Firewall enabled on all profiles |
| Defender | Confirm real-time, behavior, and script scanning are active |
| Updates | Patch on a controlled schedule with snapshots |
| Auditing | Enable logon, account lockout, user management, and process creation auditing |
| Services | Disable services you do not need |
| Backups | Snapshot before major changes |
| Documentation | Record what you changed and why |
Do not apply every hardening setting blindly. Some controls can break applications, RDP access, authentication, printing, or management workflows. Snapshot first, then change one area at a time.
What we tested on Raff
We tested the audit and verification commands on a Raff Windows VPS running Windows Server 2025 Datacenter Evaluation.
Test environment:
| Item | Value |
|---|---|
| Provider | Raff Technologies |
| OS | Windows Server 2025 Datacenter Evaluation |
| Build | 26100 |
| CPU | 4 vCPU |
| RAM | Approximately 8 GB |
| Test date | 2026-05-24 |
| Tester | Serdar Tekin |
On this VM, we verified:
- Windows Server version and hardware details
- Local users and Administrators group audit commands
- Account policy status with
net accounts - Firewall profile and RDP rule inspection
- Microsoft Defender preference checks
- Audit policy checks for logon, account lockout, user management, and process creation
We did not apply every hardening change on this test VM. Some changes should be applied only after taking a snapshot and confirming workload compatibility.
What you'll need
- A Raff Windows VPS running Windows Server 2022 or Windows Server 2025
- Local administrator access through RDP
- A fresh snapshot before making hardening changes
- 1-3 hours, depending on how many controls you apply
- A maintenance window if the server is already in production
Before changing authentication, firewall, RDP, or service settings, take a snapshot from the Raff dashboard. Some changes are easy to undo. Some are not.
Apply hardening in this order
Use this order:
- Accounts and authentication
- RDP and firewall exposure
- Windows Update and Defender
- Auditing and logs
- Services and installed roles
- Final verification
This order matters. Account, RDP, and firewall mistakes create the fastest path to compromise. Audit and logging controls help you detect problems after the fact.
1. Audit local users and administrators
Start by reviewing who can sign in locally and who has administrator rights.
Run PowerShell as Administrator:
Get-LocalUser | Select-Object Name, Enabled, LastLogon
Then check the local Administrators group:
Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass
What to look for:
| Finding | Action |
|---|---|
| Unknown local admin account | Investigate before disabling |
| Old test user | Disable or remove |
| Guest account enabled | Disable it |
| Shared admin account | Replace with named accounts |
| No recent logon data | Verify whether the account is still needed |
For production, every admin account should have a reason to exist.
2. Disable the Guest account
The Guest account should not be enabled on a production Windows VPS.
Check it:
Get-LocalUser Guest | Select-Object Name, Enabled
Disable it:
Disable-LocalUser -Name "Guest"
This is safe for most VPS workloads. If an application depends on Guest access, that application design needs review.
3. Review the built-in Administrator account
The built-in Administrator account is a common brute-force target because attackers know the username.
You have two practical options:
| Option | When to use |
|---|---|
| Keep it but use a strong password | Simple environments with limited admins |
| Rename it and document the new name | Better for production servers exposed to RDP |
To rename it:
Rename-LocalUser -Name "Administrator" -NewName "RaffAdmin01"
Do not run this casually on a production server unless your team knows the new admin username. Update documentation and password vault entries first.
4. Enforce account lockout policy
Account lockout slows down brute-force attempts against RDP and local accounts.
Check the current policy:
net accounts
A practical baseline for many SMB servers:
net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30
This means:
| Setting | Value |
|---|---|
| Failed attempts before lockout | 5 |
| Lockout duration | 30 minutes |
| Observation window | 30 minutes |
Do not set the threshold too low. You can lock out real admins during busy support work.
5. Use a non-admin daily account
Do not use an administrator account for routine browsing, downloads, or daily work inside the server.
Create a standard user:
$pw = Read-Host "Daily-user password" -AsSecureString New-LocalUser -Name "user.daily" -Password $pw -PasswordNeverExpires:$false
Use administrator rights only when needed. For servers used by multiple staff, pair this with RDS Session Host planning and proper user access design.
6. Keep Windows Firewall enabled
Windows Firewall should stay enabled on a VPS.
Check firewall profiles:
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
Check RDP rules:
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object DisplayName, Enabled, Direction, Action, Profile | Format-Table -AutoSize
Windows Firewall is a host-based firewall included with Windows and enabled by default on Windows editions. It helps filter traffic by profile, rule, application, port, and other conditions.
For production, keep the firewall enabled and open only the ports your workload needs.
7. Restrict RDP where possible
RDP is useful, but it should not be treated as a public front door.
If your office has a fixed IP, restrict RDP to that IP:
Set-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)" -RemoteAddress "203.0.113.10/32"
Replace 203.0.113.10 with your actual office or VPN IP.
Before applying this, confirm your current public IP. If you set the wrong address, you can lock yourself out of RDP.
Safer options:
- Restrict RDP to office IPs
- Use a VPN or private access layer
- Use named admin accounts
- Use strong passwords
- Monitor failed logons
- Disable old test accounts
If you cannot restrict RDP by IP, at least keep the firewall enabled, use strong passwords, and review failed logon events.
