CIS Hardening in Practice: A Nine-Check Windows Server Audit
A default Windows Server install is built for compatibility, not defence. Here is how to audit one against the CIS Benchmark in nine checks, with the exact commands, and how the results become evidence for ISO/IEC 27001 and PCI DSS v4.0.1.

Every server starts life insecure. Not because anyone did anything wrong, but because a fresh Windows install is tuned for compatibility, not for defence. Legacy protocols are available, permissions are broad and logging is minimal. Log into a brand-new Windows Server 2022 machine and everything works: RDP answers, file shares respond, services start on cue. That is exactly the problem.
Hardening is the deliberate process of walking that default build back to a known, defensible baseline, and then being able to prove, on screen, that you did it. This guide shows how to audit a Windows Server against the CIS Benchmark in nine checks, with the exact commands to run, and how the results become evidence for ISO/IEC 27001 and PCI DSS v4.0.1.
What hardening actually means
Hardening reduces a system’s attack surface, so there is less for an attacker to reach and exploit. Strip away the jargon and it comes down to four repeatable moves:
- Remove what you do not need. Uninstall unused roles, disable unused services and switch off legacy protocols such as SMBv1.
- Tighten what remains. Enforce a strong password and lockout policy, require Network Level Authentication on RDP and require SMB signing.
- Watch everything left running. Turn on the audit categories that matter and forward logs somewhere tamper-resistant.
- Prove the state. Capture evidence of the configuration, so an assessor, or you at 2am during an incident, can verify it.
Many breaches never need a zero-day. Weak passwords, internet-facing RDP and legacy SMB remain everyday ways into corporate networks, and none of them requires a sophisticated exploit. They only require a default left in place and nobody checking it.
The CIS Benchmarks: a baseline you do not have to invent
Rather than inventing your own baseline and defending it in every design review, adopt a recognised one and measure against it. The CIS Benchmarks, published by the Center for Internet Security, are the most widely used starting point. They are consensus-built configuration guides written by practitioners, vendors and academics, with hundreds of numbered recommendations per operating system. Each recommendation names a setting, explains why it matters, and tells you how to audit it and how to fix it.
Separate benchmarks exist for Windows Server 2016, 2019, 2022 and 2025, so always match the version in front of you. Every benchmark offers two profiles:
Level 1
Practical hardening that rarely breaks applications. Start here, and start in a test environment.
Level 2
Stricter settings for high-security environments that may affect functionality. Move here only after testing.
One more decision comes before any command: is this a member server or a domain controller? Domain controllers carry extra recommendations, and their settings are normally driven by domain Group Policy rather than local policy. The first command in the audit section below tells you which.
How to read a CIS recommendation
Every CIS recommendation has the same shape. Once you can see the pattern, the benchmark stops feeling like a wall of text. Take recommendation 1.1.2 from the Windows Server benchmark:
1.1.2 (L1) Ensure 'Maximum password age' is set to '365 or fewer days, but not 0'
Profile : Level 1 - Domain Controller, Level 1 - Member Server
Audit : Compare the effective policy value with the target
Remediate : Computer Configuration\Policies\Windows Settings\Security Settings\
Account Policies\Password Policy\Maximum password age
Four parts, every time
An ID number, a profile level, an exact target value and the policy path where the setting lives. Your job is to turn the audit step into one command that prints the server’s current value, then compare it with the target. Every command in this guide does exactly that.
Section numbers in this guide follow the CIS Microsoft Windows Server 2022 Benchmark. Sub-numbers can move between benchmark releases, so confirm them against the version you download.
Audit first, remediate second
You cannot claim a server is hardened until you can show the evidence. The most valuable habit in this discipline is to read the current state before you change anything. Reading is non-destructive, it tells you exactly where you stand, and it gives you a before-and-after record that an assessor will trust.
Set the stage first:
# Open PowerShell as Administrator, then confirm the environment
$PSVersionTable.PSVersion
Get-ComputerInfo -Property OsName, OsVersion, WindowsProductName
(Get-CimInstance Win32_ComputerSystem).DomainRole
# 2 = standalone server, 3 = member server, 4 or 5 = domain controller
# Create a folder for the evidence this guide produces
New-Item -Path C:\audit -ItemType Directory -Force | Out-Null
Before you start
Work on a test VM or a snapshot. Run the shell elevated, because several of these audits return errors or nothing at all without administrator rights. Check the domain role before anything else: domain controllers carry extra recommendations and take most of their settings from domain policy.
Six command families answer almost every question a CIS audit asks:
| Command | What it tells you |
|---|---|
secedit /export | Exports password, lockout and user rights policy to a text file. |
auditpol /get | Shows which security events are actually being logged. |
Get-NetFirewallProfile | Reports firewall state for the Domain, Private and Public profiles. |
Get-ItemProperty | Reads any hardening setting stored in the registry. |
Get-Service and Get-WindowsFeature | Reveal running services and installed roles. |
Get-LocalUser and net accounts | List local accounts and the effective password policy. |
The nine-check audit
Nine checks, each mapped to a CIS section, each with the command to run and the result that tells you whether you passed. Run them in order, in an elevated PowerShell prompt, on a test machine first.
CIS section 1.1 · Password policy
Check 1: Password policy
# Quick view (works in PowerShell and cmd.exe)
net accounts
# Full policy export, then read the password settings
secedit /export /cfg C:\audit\pol.cfg /quiet
Select-String -Path C:\audit\pol.cfg -Pattern 'Password'What this checks
Password length, age, history and complexity: the first controls any assessor looks at, and a finding that can undermine an otherwise solid audit.
Compliant if
MinimumPasswordLength is 14 or more, PasswordHistorySize is 24 or more, MaximumPasswordAge is 365 or fewer (never 0) and PasswordComplexity is 1.
CIS section 1.2 · Account lockout policy
Check 2: Account lockout policy
# Read the lockout values from the policy export
Select-String -Path C:\audit\pol.cfg -Pattern 'Lockout'
# Same information without an export
net accounts | findstr /i "lockout"What this checks
Whether repeated failed logons actually lock an account, and for how long. This is your brute-force defence, and it is easy to leave switched off.
Compliant if
LockoutBadCount is 5 or fewer but not 0, and the lockout duration and reset counter are each 15 minutes or more.
Systems in scope for PCI DSS need a longer lockout duration than this. See the PCI DSS mapping below.
CIS section 2.3 · Security options: accounts
Check 3: Local accounts
Get-LocalUser | Select-Object Name, Enabled, PasswordExpires, LastLogon
# Who holds local administrator rights?
Get-LocalGroupMember -Group 'Administrators'
# Guest account state (cmd.exe alternative)
net user guest | findstr /i "active"What this checks
Dormant, unexpected or over-privileged local accounts, plus the built-in Guest account that nobody remembers enabling.
Compliant if
Guest is disabled, the built-in Administrator account has been renamed, and every member of the Administrators group has a documented reason to be there.
Domain controllers have no local accounts, so on a domain controller review the domain groups instead.
CIS section 17 · Advanced audit policy
Check 4: Audit policy
# Full picture of what is being logged
auditpol /get /category:*
# Subcategories CIS cares about most
auditpol /get /subcategory:"Logon,Special Logon,Security Group Management"
# Security log maximum size
Get-WinEvent -ListLog Security | Select-Object LogName, MaximumSizeInBytesWhat this checks
Whether security-relevant events are recorded at all. Without logs there is no investigation, and this is the check that decides whether you can answer “what happened?” six months from now.
Compliant if
Each subcategory matches its CIS target (for example Logon: Success and Failure; Special Logon: Success; Security Group Management: Success) and the Security log is 196,608 KB or larger.
The log size recommendation sits under section 18 (Administrative Templates), but it belongs with this check.
CIS section 9 · Windows Defender Firewall
Check 5: Windows Firewall
# Effective settings, including those applied by Group Policy
Get-NetFirewallProfile -PolicyStore ActiveStore |
Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
# cmd.exe equivalent
netsh advfirewall show allprofilesWhat this checks
That the firewall is on for all three profiles and blocks inbound traffic by default. A firewall that is on but permissive is barely a firewall.
Compliant if
Enabled is True for Domain, Private and Public, DefaultInboundAction is Block, and dropped packets are logged.
Without -PolicyStore ActiveStore, values set by Group Policy can show as NotConfigured, which is a common source of false findings.
CIS sections 2.3 and 18.4 · Legacy protocols
Check 6: Legacy protocols
# SMBv1 should be disabled or absent
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol |
Select-Object FeatureName, State
Get-SmbServerConfiguration |
Select-Object EnableSMB1Protocol, RequireSecuritySignature
# LAN Manager authentication level
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevelWhat this checks
Outdated file-sharing and authentication protocols that attackers, including ransomware operators, look for as soon as they land on a network.
Compliant if
SMBv1 is disabled or absent, EnableSMB1Protocol is False, RequireSecuritySignature is True and LmCompatibilityLevel is 5 (NTLMv2 only).
If the registry value does not exist, the setting has not been configured, which counts as a fail against CIS.
CIS section 18 · Remote Desktop Services
Check 7: Remote Desktop settings
# Is RDP enabled? 1 means connections are denied
Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
# Policy settings for Network Level Authentication and encryption
$rdp = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
Get-ItemProperty $rdp -Name UserAuthentication, MinEncryptionLevelWhat this checks
Whether remote desktop is exposed at all, and whether it demands authentication before a session is even built.
Compliant if
UserAuthentication is 1 (NLA required) and MinEncryptionLevel is 3 (High). If fDenyTSConnections is 1, RDP is off: keep it that way unless the server’s role requires it.
CIS section 5 · System services
Check 8: Services and attack surface
# Services running and set to start automatically
Get-Service | Where-Object { $_.Status -eq 'Running' -and $_.StartType -eq 'Automatic' } |
Select-Object Name, DisplayName
# Installed roles and features (Windows Server only)
Get-WindowsFeature | Where-Object InstalledWhat this checks
Every running service and installed role is code an attacker can reach once they are on the machine. Fewer moving parts is simply safer.
Compliant if
Nothing runs that the server’s documented purpose does not require: no Print Spooler on a web server, no web server role on a file server.
CIS section 18 · Defender and Windows Update
Check 9: Patch level and malware protection
# Ten most recent updates and their install dates
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10
# Antivirus and real-time protection status
Get-MpComputerStatus |
Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdatedWhat this checks
How current the server is, and whether malware protection is running with up-to-date signatures.
Compliant if
The latest cumulative update is installed within your defined patch window, real-time protection is enabled and signatures are no more than a few days old.
If a third-party endpoint product is installed, Defender may run in passive mode, so check that product’s console instead. Patch timing is set by your own policy and by standards such as PCI DSS rather than by the benchmark.
Put it together: a five-minute evidence pack
On their own, the nine checks are simple. Run together, they become an audit trail: a dated folder of files an assessor can open, and that you can compare with last quarter’s run.
$out = "C:\audit\$env:COMPUTERNAME-$(Get-Date -Format yyyyMMdd)"
New-Item -Path $out -ItemType Directory -Force | Out-Null
secedit /export /cfg "$out\policy.cfg" /quiet
auditpol /get /category:* | Out-File "$out\auditpol.txt"
Get-NetFirewallProfile -PolicyStore ActiveStore | Out-File "$out\firewall.txt"
Get-LocalUser | Out-File "$out\users.txt"
Get-SmbServerConfiguration | Out-File "$out\smb.txt"
Get-HotFix | Out-File "$out\patches.txt"
Get-MpComputerStatus | Out-File "$out\defender.txt"
# Then compare each file with the CIS target values
Mark it honestly
A documented failure with a remediation plan is worth more than an unexplained pass. Score every check Pass, Fail or Not Applicable, and record what you will change and by when. That table is the real deliverable, not the files behind it.
Mapping the checks to ISO/IEC 27001
ISO/IEC 27001:2022 does not require the CIS Benchmarks. It does require you to define, apply and maintain secure configurations (control A.8.9), and a recognised benchmark is one of the most defensible ways to do that. The same nine checks then provide evidence for several Annex A controls at once. Annex A groups its 93 controls into four themes, and hardening sits almost entirely in the Technological theme.
| CIS check | Annex A control(s) | Why it matters for ISO/IEC 27001 |
|---|---|---|
| Password policy | A.5.17 Authentication information | Authentication information must be allocated and managed under a defined process. Password length, complexity and lifecycle are the textbook example. |
| Account lockout | A.8.5 Secure authentication | Secure log-on procedures should resist brute-force and credential-stuffing attempts, which is what a lockout threshold enforces. |
| Local accounts | A.5.15 Access control, A.5.18 Access rights, A.8.2 Privileged access rights | Access rights must be provisioned, reviewed and removed in line with policy. Dormant or over-privileged administrator accounts are a classic finding. |
| Audit policy | A.8.15 Logging, A.8.16 Monitoring activities | Logs must record activities and security events, be protected from tampering, and actually be reviewed. |
| Windows Firewall | A.8.20 Networks security | Networks and connected systems must be secured, with controls that restrict traffic to what is needed. |
| Legacy protocols | A.8.9 Configuration management, A.8.24 Use of cryptography | Configurations must follow a defined baseline. SMB signing is a cryptographic control that protects the integrity of data in transit. |
| Remote Desktop | A.8.5 Secure authentication, A.8.20 Networks security | Remote access is a network security control in its own right, and strong authentication is expected before a session is established. |
| Services and attack surface | A.8.9 Configuration management | Systems must be configured and maintained against an approved baseline. An unneeded service is a deviation from that baseline. |
| Patch level and malware protection | A.8.7 Protection against malware, A.8.8 Management of technical vulnerabilities | Vulnerabilities must be identified and addressed in a timely way, and malware protection must be implemented and kept current. |
Evidence for the ISMS, not just the server
In a certification audit, the question is whether a control operates consistently over time, not whether it passed once. Run the evidence pack on a schedule, keep the results with your ISMS records, and you will have the operating evidence ready when the auditor asks for it.
Mapping the checks to PCI DSS v4.0.1
If the server stores, processes or transmits cardholder data, or can affect the security of systems that do, these checks become assessment evidence. Requirement 2.2.1 requires configuration standards that are consistent with industry-accepted system hardening standards or vendor hardening recommendations, and the CIS Benchmarks are among the most widely used of those standards.
| CIS check | PCI DSS v4.0.1 | What the requirement expects |
|---|---|---|
| Password policy | 8.3.6, 8.3.9 | At least 12 characters with numeric and alphabetic characters. Where a password is the only factor, it is changed at least every 90 days or security posture is analysed dynamically. The CIS minimum of 14 characters already clears the length requirement. |
| Account lockout | 8.3.4 | Lock out after no more than 10 invalid attempts, for at least 30 minutes or until identity is confirmed. The CIS 15-minute duration is shorter than this, so set 30 minutes or more on in-scope systems. |
| Local accounts | 2.2.2, 7.2.2, 8.2.2 | Vendor default accounts are removed, disabled or secured; access follows least privilege; shared and generic accounts are used only by exception. |
| Audit policy | 10.2.1, 10.2.1.4, 10.5.1 | Audit logs are enabled, capture invalid access attempts, and are retained for 12 months with the most recent three months immediately available. |
| Windows Firewall | 1.2.1, 1.3.1 | Where a host firewall is one of your network security controls, its rules are covered by configuration standards and inbound traffic is limited to what is necessary. |
| Legacy protocols | 2.2.4, 2.2.5 | Only necessary services and protocols are enabled. Any insecure protocol that remains has a documented business justification and extra security measures. |
| Remote Desktop | 2.2.7, 8.4.1 | All non-console administrative access is encrypted with strong cryptography, and MFA is required for administrative non-console access into the CDE. |
| Services and attack surface | 2.2.1, 2.2.4 | Configuration standards cover all system components, and unnecessary functionality is removed or disabled. |
| Patch level and malware protection | 5.2.1, 5.3.1, 5.3.2, 6.3.3 | Anti-malware is deployed, kept current and actively scanning. Critical patches are installed within one month of release. |
A working map, not a compliance determination
Whether a finding affects your assessment depends on your scope, on the role each system plays in the cardholder data environment and on the evidence behind each control. Use this table to prepare, and confirm the detail with your assessor.
A hardening checklist that holds up
Whatever the platform, the same categories come back. Treat this as a standing checklist, not a one-off project plan.
1. Accounts and authentication
- Minimum password length of 14 or more, complexity on, history of 24 and a maximum age of 365 days or fewer (never 0).
- Lock accounts after 5 or fewer failed attempts, with a lockout and reset window of at least 15 minutes, and at least 30 minutes on PCI DSS in-scope systems.
- Disable the Guest account, rename the built-in Administrator and review who holds local administrator rights.
2. Services, protocols and roles
- Remove or disable SMBv1, require SMB signing and restrict LAN Manager authentication to NTLMv2.
- Disable every service and role the server’s documented purpose does not require.
- Where remote access is needed, keep it behind NLA and high encryption, ideally through a VPN or bastion host rather than open RDP.
3. Logging and monitoring
- Enable the audit subcategories CIS recommends, such as Logon, Special Logon and account management events.
- Size the Security log appropriately and forward logs to a central, tamper-resistant platform such as a SIEM.
- Log dropped firewall connections so you can investigate later.
4. Patching and endpoint protection
- Apply updates on a defined schedule, with critical patches inside an agreed window.
- Run endpoint protection with real-time protection and current signatures.
- Encrypt disks, and in cloud environments use hardened images and least-privilege security groups.
Hardening is a state you maintain
Configuration drifts. New software relaxes a setting, an engineer opens a port for troubleshooting and forgets to close it, a policy is overridden somewhere upstream. A server hardened last quarter is only still hardened if you keep checking.
Build re-auditing into a schedule and automate the comparison where you can. Tools such as CIS-CAT score a system against the benchmark and produce a report. Most importantly, track every finding through to remediation, not just into a spreadsheet nobody reopens.
The takeaway
Hardening is rarely glamorous, and it is rarely about exotic threats. It is the disciplined work of turning off what you do not need, tightening what you keep, watching what remains and proving the result. Start from a recognised baseline, audit before you change anything, fix the basics first and re-check on a schedule.
Do that consistently and a default install, which is a liability, becomes a server you can defend, both on the network and on paper when the auditor arrives.
Further reading: the CIS Benchmarks are free to download after registration; always match the benchmark to your exact operating system version. For how these controls are examined in practice, see our ISO/IEC 27001 certification audits and PCI DSS assessments.
Talk to Cianaa Technologies
Talk to Cianaa Technologies for independent, evidence-based compliance assurance across the Australasian region.
Book a discovery callGet the next one in your inbox
One email when we publish. Written by named auditors, never by a marketing robot. Unsubscribe anytime with one click.



