How to Harden Windows Server 2022 with Baseline Security Settings

Quick baseline first

The operational problem is straightforward: a default or inconsistently configured Windows Server 2022 instance is usually more exposed than the workload requires. That increases the chance of credential abuse, unnecessary remote access, noisy logs that hide real events, and configuration drift that makes incidents harder to investigate. This guide shows you how to apply a practical baseline security setup so you can reduce the attack surface, verify the changes, and decide whether the server is ready for production use.

Use this approach when you need a defensible baseline that is safe to deploy in most server environments. If your environment already follows a formal baseline, compare your settings against it rather than layering controls blindly. For ransomware-oriented environments, it can help to pair this baseline with Windows Server 2022 Security Baseline Hardening for Ransomware Defense after the fundamentals below are in place.

Apply the following in order:

1. Remove local accounts and privileges you do not need.
2. Enforce secure authentication and lockout controls.
3. Restrict inbound management access to trusted admin networks only.
4. Turn on the logging and auditing you will actually review.
5. Validate the result with commands and evidence before production rollout.

If you only have time for the highest-value changes, start with identity, remote access, and logging. Those three areas usually deliver the fastest risk reduction with the least operational disruption.

Prerequisites and safe boundaries

Before changing policy, make sure you have a recoverable path back into the server. Hardening can lock you out if you apply it without a console path, a second admin account, or documented rollback access.

You should have:

• Local or out-of-band console access, or a tested virtual machine console.
• A known-good administrative account separate from your normal daily account.
• A change window and a rollback plan.
• A way to export policy and capture current settings before modification.
• A clear list of server roles so you do not disable a required service.

Also define the operational boundary up front. This baseline is meant to reduce unnecessary exposure, not to replace role-specific requirements. A domain controller, file server, remote desktop host, or application server may require additional settings or exceptions.

1. Establish a known-good starting point

Start by recording the current state. That gives you a way to compare changes and revert selectively if a control breaks a dependency.

Capture local security policy and key system information:

secedit /export /cfg C:\Temp\secpol-backup.inf
systeminfo > C:\Temp\systeminfo-before.txt
Get-LocalUser | Select-Object Name,Enabled,LastLogon | Format-Table -Auto
Get-LocalGroupMember -Group 'Administrators' | Format-Table -Auto

Expected output:

• An exported security policy file you can keep with your change record.
• A list of local users and local administrators.
• A baseline snapshot of the host build and configuration.

If the server is domain-joined, also record which settings are expected to come from local policy and which are expected to come from domain policy. Local changes that conflict with centrally managed policy often create drift and confusion later.

2. Reduce account and privilege exposure

Administrative control is the first place to tighten. If an attacker gains a privileged token, other controls matter much less.

Disable or rename unused local accounts

Review every local account and disable anything that is not required:

Get-LocalUser | Where-Object { $_.Enabled -eq $true }
Disable-LocalUser -Name 'Guest'

Expected output:

• The Guest account is disabled if it exists.
• Only approved local accounts remain enabled.

Avoid deleting accounts immediately unless you have confirmed they are not used by a service. Disabling is the safer first step because it is reversible.

Minimize local administrators

Check who is in the local Administrators group and remove accounts that do not need full control:

Get-LocalGroupMember -Group 'Administrators'

Typical acceptable members are a break-glass local admin account, the built-in Administrator if your policy requires it, and any explicitly approved management groups or service accounts.

If your environment uses domain groups, ensure the membership is narrow and intentional. A common hardening mistake is leaving broad helpdesk or legacy support groups with local admin rights on every server.

Protect the built-in Administrator account

Do not leave the built-in Administrator account in an ambiguous state. Either manage it explicitly or disable it if your recovery model allows that. If it must remain enabled, use a strong password, store it securely, and ensure you can access the server through another approved route.

3. Enforce secure password and lockout policy

Local account controls matter because they slow down brute-force attempts and make misuse more visible. Apply these settings through the local security policy or, if applicable, through domain policy.

Recommended baseline targets:

• Minimum password length: at least 14 characters where operationally feasible.
• Password history: enough to prevent simple reuse.
• Maximum password age: align with your organization’s rotation standard, if one exists.
• Account lockout threshold: set low enough to slow attacks, but high enough to avoid unnecessary lockouts.
• Account lockout duration and reset counter: define both together so they are operationally reasonable.

If you use domain accounts for administration, test these values with your identity team before rollout. Overly aggressive lockout settings can create self-inflicted outages during maintenance windows.

Validate with a policy export rather than assumption:

secedit /export /cfg C:\Temp\secpol-current.inf
Select-String -Path C:\Temp\secpol-current.inf -Pattern 'MinimumPasswordLength|PasswordHistorySize|LockoutBadCount|LockoutDuration|ResetLockoutCount'

Expected output:

• The exported file shows the configured values.
• The values match your approved baseline.

4. Restrict remote administration paths

Most server compromise paths include remote access. You want management channels to be limited, logged, and reachable only from trusted admin locations.

Limit RDP exposure

If Remote Desktop is required, restrict it to a management subnet, not the whole network. Prefer firewall rules over broad network exposure.

Check the current RDP state:

Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server' | Select-Object fDenyTSConnections

A value of 0 means RDP is enabled; 1 means it is disabled.

Then verify the Windows Firewall scope for Remote Desktop. Your goal is to allow the port only from trusted administrative IP ranges. If your environment uses jump hosts, limit access to those hosts instead of allowing broad access.

Disable unused remote services

Turn off any service you do not need, such as older management protocols or application-specific remote access features. Every extra listener increases the chance of exposure and complicates incident response.

If you are unsure whether a service is still required, change it to manual first, observe behavior through a maintenance cycle, and only then disable it if safe.

Confirm firewall posture

Inspect active firewall profiles and inbound rules:

Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction
Get-NetFirewallRule -Enabled True | Where-Object { $_.Direction -eq 'Inbound' } | Select-Object DisplayName,Profile,Action

Expected output:

• Firewall profiles are enabled.
• Inbound rules are limited to required services.
• Administrative access is scoped tightly.

If you are building a broader endpoint security standard, the control model often aligns well with Windows 11 Hardening Checklist for Secure Enterprise Deployment for the client-side management principles, even though the server settings and exemptions will differ.

5. Turn on practical auditing and logging

Hardening without visibility is only partial hardening. You need enough logging to answer basic questions after a security event: who logged on, what changed, and which service failed.

Enable security-relevant audit categories

Focus on categories that support admin and access investigations:

• Logon and logoff events.
• Account management changes.
• Privilege use.
• Policy changes.
• Process creation, if your storage and review workflow can handle it.

Check the current audit policy:

auditing /get /category:*

If you prefer the built-in command-line interface, auditpol can show the current state in detail:

auditpol /get /category:*

Expected output:

• Audit categories show success and/or failure tracking where configured.
• The enabled categories match your review process and log retention capacity.

Increase event log size where justified

Default log sizes may be too small for busy servers. Resize logs based on the expected event volume and storage policy so they do not overwrite important evidence too quickly.

Review current sizes:

Get-WinEvent -ListLog Security,System,Application | Select-Object LogName,MaximumSizeInBytes,RecordCount

If the security log is too small for your environment, increase it carefully and confirm your log retention and forwarding process can handle the added volume.

Check that time sync is correct

Event correlation depends on accurate time. Confirm the system clock and time source are healthy before you rely on logs for investigation:

w32tm /query /status
w32tm /query /source

Expected output:

• A valid time source.
• No obvious time drift or synchronization failure.

6. Remove unnecessary features and attack surface

Every installed feature is another place to misconfigure or attack. Remove what you do not need, but only after confirming the role will still function.

Review installed roles and features

Get-WindowsFeature | Where-Object { $_.InstallState -eq 'Installed' } | Select-Object Name,DisplayName

Use the result to identify features you can remove or disable. Common examples include legacy compatibility components, unneeded management tools, or role services no longer used by the application.

Disable obsolete protocols where the workload allows it

If the application and dependencies support it, disable older protocols and features that are no longer required. This is especially important for remote access, file sharing, and legacy compatibility settings. Because protocol support varies by role and application version, verify compatibility first rather than assuming a safe default.

Do not disable a protocol globally just because it is considered older. Check whether a line-of-business application, backup product, or management tool still depends on it.

7. Validate the baseline with simple checks

Validation is what turns a checklist into an operational control. After applying changes, verify both configuration and behavior.

Configuration checks

Run these checks and compare the output to your approved baseline:

Get-LocalUser
Get-LocalGroupMember -Group 'Administrators'
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction
auditpol /get /category:*
secedit /export /cfg C:\Temp\secpol-verify.inf

You should confirm:

• Only approved local accounts are enabled.
• Administrative group membership is minimal.
• Firewall profiles are enabled.
• Auditing matches the baseline.
• Exported policy values match the intended settings.

Behavior checks

Validate that real management still works before you close the change window:

• Connect from the approved admin network or jump host.
• Open a management session with the intended admin account.
• Confirm the event log records the login and administrative actions.
• Restart only noncritical services to ensure the server remains reachable.

If something fails, diagnose the smallest cause first. For example, if RDP no longer works, check firewall scope before changing authentication settings.

8. Roll back safely if a change breaks the server

Rollback should be specific, not dramatic. Restore only the control that caused the problem, then re-test.

Common rollback actions include:

• Re-enabling a disabled local account temporarily.
• Restoring previous firewall rule scope for management access.
• Reverting a security policy export with secedit.
• Re-enabling a feature that a dependent service requires.

Example policy restore:

secedit /configure /db C:\Windows\security\local.sdb /cfg C:\Temp\secpol-backup.inf /areas SECURITYPOLICY

Use rollback carefully. If you revert multiple changes at once, you lose the ability to identify which control caused the issue.

9. Optional improvements after the baseline is stable

Once the core hardening is stable, you can raise the bar further without making the initial rollout risky.

Consider these improvements only after the baseline is validated:

• Add stronger logging retention and forwarding.
• Introduce application control for high-value servers.
• Tighten service account permissions and remove interactive logon rights where possible.
• Validate recovery procedures, including backup restore and admin access recovery.
• Use configuration management so the baseline stays consistent over time.

If your server participates in a wider identity and recovery strategy, documenting those controls alongside the baseline will make later incident response much easier.

What a hardened Windows Server 2022 baseline should look like

A practical hardening baseline is not measured by how many settings you changed. It is measured by whether the server is harder to abuse, easier to audit, and still operational for its intended role.

At the end of this workflow, you should be able to say yes to these questions:

• Are only approved accounts and admins enabled?
• Is remote management restricted to trusted sources?
• Are firewall rules limited to required services?
• Can you see the logon and policy-change events you care about?
• Have you verified the server still works with the controls in place?

If the answer is yes, you have a defensible baseline security setup for Windows Server 2022. Keep the policy export, validation output, and rollback notes with the change record so the baseline can be reviewed, reproduced, or audited later.

Use this guidance together with Windows Server 2025 Failover Clustering to connect the workflow with related operational context already available on the site.