The Complete Guide to System Hardening: Checklist and Best Practices

Your security is only as strong as your weakest link, or in this case, your weakest configuration.

A system hardening checklist gives IT teams a practical, repeatable way to close the gaps attackers target: default credentials, open ports, unnecessary services, and misconfigured permissions. It's one of the most foundational elements of good cyber hygiene, and one of the most common oversights when teams are stretched thin.

The problem is that hardening isn't a one-time task. Configurations drift, new systems get added, and exceptions pile up. This guide walks through every major category of hardening, from user accounts and network configuration to logging and physical security controls, so you have a clear starting point and a process you can actually maintain. 

What is system hardening?

System hardening is the process of configuring systems to reduce the ways an attacker can get in or move around once they're inside. Think open ports, default accounts, unused services, or weak settings. Every one of those is a potential entry point, and hardening closes them off before someone can take advantage.

It's also worth distinguishing between hardening and patching, because the two are often confused: 

• Patching fixes known vulnerabilities in software 

• Hardening changes how a system is configured, making those vulnerabilities harder to reach or exploit in the first place 

Both are important parts of vulnerability management, and neither one substitutes for the other. 

Why system hardening matters

Out-of-the-box systems aren't built with security as the priority. They're built for ease of use, which means they often ship with open ports, enabled services, and default credentials that attackers actively scan for. Misconfigurations consistently rank among the top causes of breaches, and default settings are one of the most common culprits.

There's also a compliance angle worth noting. Cybersecurity frameworks like CIS Benchmarks, NIST SP 800-53, and DISA STIGs all include hardening requirements, and organizations subject to HIPAA, PCI DSS, or CMMC need documented hardening practices to pass audits. Essentially, you need to meet a baseline of protections so that if a cyber event happens, you can clearly show that you've done your due diligence.

Ultimately, a hardened system is tougher to compromise, cheaper to defend, and less likely to become the entry point for a ransomware attack or data breach. The work you put in up front pays off every time an attacker moves on to an easier target.

The complete system hardening checklist

This is the practical core of system hardening: A step-by-step checklist organized by category that IT admins can work through systematically. Not every item will apply to every environment, so use this as a starting point and adapt it to the systems you're hardening. 

For the most detailed guidance, cross-reference the relevant CIS Benchmark for your specific OS or platform.

1. User account and access controls

The default accounts that ship with most systems are some of the first things attackers go after. Disabling or renaming the built-in Administrator account on Windows and creating named admin accounts in its place gives you accountability and removes an obvious target. On Linux, disable direct root login over SSH and require users to escalate with sudo instead.

From there, you should also:

• Enforce a password policy with a minimum of 12 to 16 characters and complexity requirements

• Enable multi-factor authentication for all privileged accounts and remote access

• Apply least privilege across the board: users and service accounts should only have the permissions they need to do their job, nothing more

• Audit accounts regularly, disable anything inactive, restrict who can add accounts to privileged groups, and disable guest accounts on all systems

2. Network configuration

Start by closing or blocking any ports your systems don't actually need, and write down which ones you've left open and why. That documentation will save you later. From there, go through your protocols and disable anything insecure. Telnet, FTP, SNMPv1/v2, and older SSL/TLS versions (TLS 1.0 and 1.1) have no business being on by default in 2026.

Next:

• Segment your network so a compromised system isn't open to the rest of the network. Isolate servers from workstations and keep OT/IoT devices off corporate networks.

• Restrict management interface access (RDP, SSH, web admin consoles) to specific IP ranges or management VLANs

• Disable IP source routing and ICMP redirects on servers and network devices

• Configure DNS to prevent zone transfers to unauthorized hosts

• Log all inbound and outbound traffic so you have a record to work from if something goes wrong, or when it's time for incident response planning

3. Firewall configuration

A perimeter firewall isn't enough. Enable the host-based firewall on every system and treat each one as its own line of defense. Set default-deny rules for both inbound and outbound traffic, then explicitly allow only what's needed.

In addition:

• Restrict outbound traffic from servers. Servers generally shouldn't be initiating connections to arbitrary internet destinations

• Log firewall rule matches, especially denied connections, and review them regularly

• Test firewall rules after any configuration change to confirm they behave as expected

4. Patch management and updates

Establish a patch cadence: Critical patches within 24 to 72 hours of release, high-severity patches within 7 to 14 days, and other patches within 30 days. Adjust based on your risk tolerance and environment. Enable automatic updates where appropriate, but test patches in a staging environment before pushing them to production servers.

Don't limit this to the OS. Browsers, Java, PDF readers, and other third-party applications are frequent attack vectors and need to be patched regularly. Track end-of-life software and hardware, too, since those systems no longer receive security updates and should be replaced or isolated.

As part of your patch management strategy, you should also maintain a full inventory of everything installed on each system, ensuring nothing is missed.

5. Windows-specific hardening

Start by disabling Windows features and roles that aren't in use. Common candidates include PowerShell v2, SMBv1, LLMNR, NetBIOS over TCP/IP, and Windows Script Host if your environment doesn't rely on it. Enable Windows Defender or an equivalent endpoint protection solution, and keep definitions up to date.

Configure AppLocker or Windows Defender Application Control (WDAC) to restrict which applications can run, and enable Credential Guard and Device Guard on supported hardware to protect against credential theft.

From there:

• Disable autorun and autoplay for removable media

• Configure User Account Control (UAC) to prompt for credentials on all admin actions

• Enable BitLocker for full-disk encryption on workstations and laptops

• Restrict access to the registry and sensitive file paths using ACLs

• Disable Remote Desktop Protocol (RDP) on systems that don't need it; where RDP is required, restrict it to specific users and source IPs

6. Linux-specific hardening

Start by disabling root login via SSH and requiring users to log in as themselves, then escalate with sudo for privileged commands. Configure SSH to use key-based authentication, disable password authentication, and restrict which users can connect. Set SSH to use a non-default port if practical.

Next: 

• Enable and configure a host-based firewall (iptables or nftables) with default-deny rules

• Remove or disable unused packages and services using the package manager

• Set file permissions correctly, as world-writable files and directories are a common misconfiguration

• Enable SELinux or AppArmor and set it to enforcing mode

• Configure auditd to log privileged command execution, file access changes, and authentication events

• Disable USB storage if removable media isn't needed in your environment

• Set a GRUB bootloader password to prevent unauthorized boot options

7. Service and application configuration

Every service running on a system that doesn't need it is an unnecessary risk. Audit what's running and disable or uninstall anything not required for the system's function. Run services under dedicated, low-privilege service accounts rather than SYSTEM or root, and configure application whitelisting where possible to prevent unauthorized executables from running.

On the application side, remove sample files, default web pages, and documentation that ships with server software like IIS, Apache, or Nginx. Disable debugging and verbose error messages in production environments, since those can expose system information to attackers.

8. Logging and monitoring

Logging is only useful if it's configured correctly and someone is actually looking at it. At minimum, enable audit logging on all systems for authentication events (success and failure), privilege escalation, account changes, and policy changes. Centralize logs in a SIEM or log management platform so they can't be tampered with locally and can be correlated across your environment.

Next steps should be:

• Set log retention to meet your compliance requirements; many frameworks require 90 days to one year

• Configure alerts for high-priority events: multiple failed logins, new local admin accounts created, services installed outside of change windows

• Sync all systems to a reliable NTP source so log timestamps are consistent and usable for forensic investigation

9. Physical security controls

Physical access is an attack vector that's easy to overlook when you're focused on the network. Restrict access to servers and network equipment to authorized personnel only, and enable BIOS/UEFI passwords to prevent unauthorized changes to boot configuration. Configure systems to boot only from the primary drive and disable booting from USB or optical media in the BIOS.

For portable devices, enable full-disk encryption on laptops to protect data if the device is lost or stolen. Use cable locks or physical security mounts for workstations in accessible areas.

Types of system hardening

System hardening isn't a single thing applied to a single place. It's a set of practices that apply across every layer of your environment, each with its own considerations and attack surface.

Operating system hardening

OS hardening locks down the base layer: disabling unused services, removing default accounts, enforcing password policies, and applying security configurations at the OS level. It applies to both Windows and Linux environments and is typically the starting point for any hardening program.

Network hardening

Network hardening controls what traffic is allowed in and out: firewall rules, port restrictions, disabling unused protocols, and segmenting networks to limit lateral movement. It also covers securing management interfaces and replacing insecure protocols like Telnet or FTP with encrypted alternatives.

Application hardening

Applications often ship with debug features, default admin accounts, or overly permissive settings. Application hardening means stripping out unnecessary components and configuring apps to run with least privilege, such as disabling unused modules in a web server, removing sample files, and enforcing TLS.

Server hardening

Server hardening applies OS and application hardening principles to server environments, with a particular focus on roles and features. Only install what the server actually needs to do its job. Both Windows Server and Linux have specific benchmarks (CIS, DISA STIG) that define what hardened means.

Database hardening

Databases are high-value targets and frequently misconfigured. Default admin accounts get left enabled, unnecessary stored procedures stay active, and data sits unencrypted. Key controls include disabling default accounts, restricting network access to the database port, enabling auditing, and encrypting sensitive data.

Cloud hardening

Cloud security challenges include things like misconfigured storage buckets, overly permissive IAM roles, and publicly exposed management consoles are common attack vectors. The same principles apply (least privilege, disable unused services, audit logging), but cloud hardening requires cloud-specific tools and benchmarks. CIS publishes benchmarks for AWS, Azure, and Google Cloud.

System hardening standards and frameworks

You don't have to build a hardening baseline from scratch. Established frameworks give IT teams a documented, tested starting point and make compliance audits easier as auditors widely accept CIS and NIST alignment as evidence of due diligence.

CIS Benchmarks

CIS Benchmarks are consensus-developed configuration guidelines published by the Center for Internet Security that cover operating systems, cloud platforms, network devices, and more. They come in two levels: 

• Level 1 covers practical controls with minimal performance impact, suitable for most environments

• Level 2 is more aggressive and designed for high-security environments where usability trade-offs are acceptable

CIS also publishes Hardened Images, pre-configured virtual machine images built to Benchmark specs, for teams that want a faster starting point.

NIST guidelines

NIST SP 800-123 and NIST SP 800-70 give federal agencies and contractors a structured hardening baseline. NIST alignment is often required for organizations pursuing FedRAMP authorization or working with US government contracts.

DISA STIGs

DISA STIGs (Security Technical Implementation Guides) are the Department of Defense's hardening requirements, more prescriptive than CIS Benchmarks and mandatory for DoD systems. STIGs are publicly available and used outside of DoD by organizations that want a rigorous, well-documented hardening standard.

HIPAA, PCI DSS, and other compliance frameworks

HIPAA and PCI DSS don't mandate specific hardening configurations, but both require documented security controls and auditors expect to see hardening evidence. Aligning to CIS or NIST is widely accepted as sufficient. Defense contractors should also be aware of CMMC, which includes its own hardening requirements.

How to build a system hardening process (not just a one-time checklist)

Running through a checklist once isn't enough. Hardening needs to be a repeatable process that's applied to new systems and maintained over time.

1. Start with an asset inventory: You can't harden what you don't know about. Document every device, server, and cloud instance in your environment before anything else.

2. Define your baseline configuration: Choose a framework (CIS Benchmarks are a good starting point) and use it to establish a documented standard that all systems are expected to meet.

3. Apply hardening to new systems before deployment: New systems should be hardened before they go live, not after. Building this into your provisioning process keeps your baseline consistent from day one.

4. Audit and validate regularly: Quarterly audits serve as a baseline, with additional reviews after major changes. Automated configuration assessment tools make this practical even for lean IT teams.

5. Document everything: Record your baseline, any exceptions, and the reasons for them. Undocumented exceptions become invisible risks that no one remembers to revisit, and they're the first thing auditors ask about.

System hardening tools that aren't hard to implement

The right tool depends on your environment size, OS mix, and whether you need automated remediation or just assessment. Here's a practical overview of what's available across each category.

Configuration assessment tools

These tools scan your systems against a known standard and tell you where you stand. They're a good starting point for any hardening program.

• CIS-CAT Pro scans systems against CIS Benchmarks and produces a scored report showing what passes, what fails, and what needs attention. CIS-CAT Lite is a free version with limited benchmark coverage.

• OpenSCAP is an open-source option that assesses systems against SCAP-formatted content, including DISA STIGs and NIST checklists. Commonly used in Linux and government environments.

• Microsoft Security Compliance Toolkit is Microsoft's free toolkit for applying and auditing security baselines on Windows systems, including GPOs aligned to Microsoft's security recommendations.

Configuration management and automation tools

Once you know what needs to change, these tools help you apply and enforce those changes at scale across your environment.

• Ansible is an agentless automation tool that applies hardening configurations across Linux and Windows systems using playbooks. The community maintains CIS Benchmark hardening roles via dev-sec.io.

• Puppet and Chef are solid alternatives for teams already using these platforms for infrastructure management, with hardening automation supported through community modules.

• Group Policy is the native way to enforce hardening settings across domain-joined Windows systems at scale, with no additional tooling required.

Vulnerability scanners

Vulnerability scanners complement hardening by identifying known CVEs, but they're not the same as configuration assessment. A scanner finds vulnerabilities; it doesn't evaluate how a system is configured. Nessus (Tenable) and Qualys are widely used options that include policy compliance scanning alongside vulnerability detection, and some incorporate CIS Benchmark checks.

Endpoint detection and response (EDR)

Hardening reduces the attack surface, but EDR catches what gets through. The two work together, not as substitutes for each other. Huntress gives IT teams and MSPs fully managed EDR with 24/7 monitoring by SOC analysts who investigate alerts and tell you what actually needs attention, so you're not drowning in noise.

Common system hardening mistakes to avoid

Every hardening program runs into the same pitfalls. Most aren't technical failures; they're process failures that compound over time and quietly erode the security posture you worked to build.

• Hardening once and forgetting it: As systems and threats change, your protections need to as well. Hardening is a process, not a project with an end date.

• Skipping the asset inventory: Teams often harden the systems they know about and miss the ones they don't. Shadow IT, forgotten test servers, and unmanaged devices are common blind spots.

• Treating all systems the same: A domain controller and a developer workstation have different risk profiles and different hardening requirements. A one-size-fits-all approach either over-restricts low-risk systems or under-protects high-risk ones.

• Disabling logging to improve performance: Audit logging has a performance cost, but disabling it means you lose visibility into what's happening on the system. When something goes wrong, you'll have nothing to investigate. A managed SIEM can help make logging more sustainable for lean teams. 

• Not testing hardening changes before production: Aggressive hardening settings can break applications and services. Always test in a staging environment first, especially for servers running critical workloads.

• Ignoring third-party software: OS hardening is well-understood, but the applications running on top of the OS are often overlooked. Outdated plugins, default credentials in web apps, and unpatched libraries are common attack vectors.

• Leaving exceptions undocumented: Every environment has legitimate reasons to deviate from the baseline, but undocumented exceptions become invisible risks that no one remembers to revisit.

Cybersecurity that goes beyond hardening

Working through a system hardening checklist is one of the most practical steps your team can take to reduce risk across your environment. Pairing a solid hardening program with vulnerability management and continuous monitoring gives you a much stronger foundation to work from. That's where we come in. 

Schedule a demo to see how Huntress can help your organization.