What is the single most important Windows Server hardening step?

Multi-factor authentication on every account with remote access. Compromises of internet-facing Windows servers begin with valid credentials far more often than with an unpatched vulnerability, and MFA makes a guessed, sprayed or leaked password worthless on its own. If you can only do one thing this week, do that.

Should I disable the built-in Administrator account?

Yes, on an internet-facing server. It is the first account name every attack list tries, and its well-known SID means renaming it does not hide it from a determined attacker. Create a separate named administrator account, verify you can use it, then disable the built-in one.

Does Windows have anything built in to block repeated failed logins?

No. Windows records failures as event 4625 and includes a capable firewall, but nothing that connects them — there is no built-in fail2ban equivalent. Account lockout is not that mechanism: it disables the account rather than the source, which on an exposed host lets anyone lock out your accounts at will.

How large should the Windows Security log be on an exposed server?

Large enough that it holds several days rather than several hours. The 20 MB default fills quickly at thousands of events a day, so raise it substantially — a few hundred megabytes is not unreasonable — and forward events off the host as well, so that a compromised machine's local log is not your only copy.

Windows Server hardening checklist for internet-facing hosts

An ordered checklist for a Windows server that has to be reachable from the internet — what to do first, what most lists get wrong, and what you can safely leave until later.

9 min readUpdated 2026-08-26

How to use this list

Hardening checklists usually fail for one reason: they are alphabetical rather than ordered by risk, so people work down them and run out of time somewhere around the screensaver policy, having never got to remote access.

This one is ordered. The first section removes the ways servers actually get compromised. The last one is worth doing and will not save you on its own. If you only have an afternoon, do sections 2 and 3 and stop.

It assumes a server that must remain reachable from the internet. If yours does not have to be, section 3 collapses into a single line and you should read that as good news.

1. Accounts and authentication

Almost every compromise of an internet-facing Windows server begins with valid credentials — guessed, sprayed, reused from another breach, or phished. This is where the effort belongs.

Disable or rename the built-in Administrator account. It is the first name every attack list tries, and its well-known SID means renaming alone is not a defence — prefer disabled, with a separate named admin account.
Require multi-factor authentication for every account that can log in remotely. This is the single highest-value control on this list; a guessed password is worth nothing without the second factor.
Enforce long passwords — a 15-character minimum resists offline cracking far better than complexity rules on a shorter one — and ban known-breached passwords if your tooling supports it.
Audit who actually has remote access. Remove accounts belonging to people who left, contractors whose work finished, and services that no longer exist. Every dormant account is an attack surface with no owner watching it.
Give service accounts their own identities, no interactive logon rights, and passwords that are not shared with anything else.
Treat account lockout with care. On an internet-facing host it lets anyone disable your accounts on demand; keep it modest if you use it, and never rely on it as your defence against guessing.

2. Network exposure

The second question after 'who can log in' is 'from where'. Every port reachable from the internet is a service somebody is testing right now.

Inventory what is actually listening, from outside. Get-NetTCPConnection -State Listen on the host, then verify from another network which of those answer.
Close SMB (445) at the perimeter. It should essentially never face the internet, and it is a frequent second finding on servers that were only meant to expose RDP.
Do the same for WinRM (5985/5986), MS SQL (1433) and any management interface. If a service does not need to be internet-reachable, that is the whole fix.
For RDP itself, restrict the source addresses if you can. If you cannot, keep reading — section 3 is the compensating control.
Turn on Network Level Authentication so an unauthenticated client never gets a session created for it.
Check the cloud security group as well as the Windows firewall. Two layers means two places to get it wrong, and an allow-all group in front of a careful host firewall is a common mismatch.

3. Automatic blocking of failed logins

This is the section most checklists omit, and it is the one that changes the daily reality of running an exposed server.

Windows records every failed authentication as event 4625 and has a perfectly capable firewall, but ships nothing that connects the two. Left alone, a server absorbs thousands of guesses a day: CPU spent, audit log churned, and no upper bound on how long an attacker gets to keep trying.

What you need is the equivalent of fail2ban: watch the failure stream, and when a source crosses a threshold, drop it at the firewall. Three properties separate a working implementation from one that leaks — ban the subnet rather than the single address, make bans permanent and reboot-proof, and whitelist your own access before anything else is switched on.

You can build it as a scheduled PowerShell task, and for a single server you watch daily that is a reasonable choice. Budget a day, and know that its failure mode is silence: scheduled tasks stop after reboots and password changes without telling anyone. RDP Protector is the same logic as a managed agent, with the whitelist, subnet handling, port detection and a health view included.

4. Patching and attack surface

Credentials are the usual way in; unpatched services are the memorable one.

Enable automatic updates, or run a patch cycle you actually adhere to. RDP has had pre-authentication remote-code-execution vulnerabilities and will have more.
Remove roles and features you do not use. An IIS installation nobody remembers enabling is a service somebody else will find.
Uninstall software that came with the image and is not needed. Every agent, toolbar and vendor updater is code running with privileges on your host.
Keep the agent software you do run current, including whatever handles your monitoring and backups.
Turn off legacy protocols — SMBv1, TLS 1.0 and 1.1, NTLMv1 — unless something genuinely requires them, in which case write down what and revisit it.

5. Logging and detection

You cannot investigate what you did not record, and the default configuration records less than you think for less time than you expect.

Confirm logon auditing captures failures, not just successes: auditpol /get /subcategory:"Logon" must show both.
Raise the Security log's maximum size. The default fills in hours on an exposed host, and the events you need age out before you look.
Forward events off the host. A compromised machine's local log is evidence an attacker can edit; a copy elsewhere is one they cannot.
Alert on the things that matter rather than on volume: a successful login from a new country, a new local administrator, a service installed, the audit log being cleared (event 1102).
Review who logged in successfully, occasionally and deliberately. Failed logins are noise; a successful one you cannot account for is the whole game.

6. Backups you have actually restored

The reason this section is last is not that it matters least. It is that it is the control that assumes the others failed — and on that day, only one property of your backups matters.

Keep at least one copy that the server itself cannot reach or delete. Ransomware operators look for the backup target before they encrypt anything, and a share the compromised host can write to is not a backup, it is a second copy waiting to be destroyed.

Then restore one. A backup that has never been restored is a hypothesis. Test it on a schedule, write down how long it took, and make sure more than one person knows the procedure.

FAQ

What is the single most important Windows Server hardening step?: Multi-factor authentication on every account with remote access. Compromises of internet-facing Windows servers begin with valid credentials far more often than with an unpatched vulnerability, and MFA makes a guessed, sprayed or leaked password worthless on its own. If you can only do one thing this week, do that.
Should I disable the built-in Administrator account?: Yes, on an internet-facing server. It is the first account name every attack list tries, and its well-known SID means renaming it does not hide it from a determined attacker. Create a separate named administrator account, verify you can use it, then disable the built-in one.
Does Windows have anything built in to block repeated failed logins?: No. Windows records failures as event 4625 and includes a capable firewall, but nothing that connects them — there is no built-in fail2ban equivalent. Account lockout is not that mechanism: it disables the account rather than the source, which on an exposed host lets anyone lock out your accounts at will.
How large should the Windows Security log be on an exposed server?: Large enough that it holds several days rather than several hours. The 20 MB default fills quickly at thousands of events a day, so raise it substantially — a few hundred megabytes is not unreasonable — and forward events off the host as well, so that a compromised machine's local log is not your only copy.