# Hardening checklist

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/hardening-checklist

## Quick definition

A hardening checklist is like a safety inspection for your computer or network. It lists specific actions you take to lock down settings, remove unnecessary software, and close security gaps. Following this list helps make your system much harder for attackers to break into.

## Simple meaning

Think of a hardening checklist like the pre-flight checklist a pilot uses before taking off. A pilot doesn’t just hope the plane is safe. They go through a list of items: check the fuel, check the flaps, check the instruments, check the doors. Each item is a small but important step that, together, make the flight safe. A hardening checklist works the same way for computers and networks. It is a list of security tasks that you must perform to make a system more secure. Instead of checking fuel and flaps, you check things like: are all default passwords changed? Is the firewall turned on? Are unnecessary programs removed? Is encryption enabled? Are software updates installed? Each task reduces a specific risk. For example, changing the default password on a router stops someone who knows the factory password from logging in. Removing unused software means there are fewer programs that could have bugs or security holes. Turning on a firewall blocks unwanted traffic from reaching your computer. The checklist ensures you don’t forget any of these steps. In IT, organizations use hardening checklists as standard procedure. When a new server is set up, the IT team runs through the checklist before connecting it to the network. This way, they know the server meets the company’s security baseline. Without a checklist, it is easy to miss a critical setting. A hardening checklist is not a one-time thing. It should be updated as new threats appear and as systems change. It is a living document that helps keep systems secure over time.

## Technical definition

A hardening checklist is a formal security documentation tool used in IT operations to systematically reduce the attack surface of a system, device, or application. It is typically composed of a series of configuration guidelines, remediation steps, and verification procedures derived from industry security benchmarks such as the Center for Internet Security (CIS) Benchmarks, the National Institute of Standards and Technology (NIST) Special Publication 800-53, the Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs), and vendor-specific hardening guides from Microsoft, Red Hat, Cisco, and others. The checklist often covers multiple security domains: account management (disabling unused accounts, enforcing password policies), patch management (ensuring latest security updates are installed), service management (stopping and disabling unnecessary services), port and protocol control (closing unused ports, disabling weak protocols like Telnet or SMBv1), file system permissions (setting least privilege access), audit logging (enabling logging for security events, setting log retention), encryption (enforcing HTTPS, enabling disk encryption, configuring TLS versions), and network security (firewall rules, disabling unnecessary network features). In a real IT environment, a hardening checklist is applied during the initial system deployment (often called baseline hardening), after major updates, and periodically as part of security audits. The process is often automated using configuration management tools like Ansible, Puppet, Chef, or PowerShell DSC, which can apply the checklist settings across hundreds of servers consistently. For compliance-driven industries like finance or healthcare, the checklist also serves as evidence that due diligence was performed to protect sensitive data. The checklist may be versioned and reviewed annually to incorporate new vulnerabilities and best practices. Failure to follow a hardening checklist can result in security breaches, failed compliance audits, and certification penalties. In exam contexts, understanding hardening checklists requires knowing which specific setting applies to which risk, such as disabling SNMP if not needed to prevent information leakage, or enabling Secure Boot to prevent rootkits from loading before the OS.

## Real-life example

Imagine you just moved into a new apartment. The building manager gives you the keys and says you are all set. But are you really safe? You would probably go through your own security checklist. First, you check that all the windows lock properly. You change the locks or get a deadbolt installed because you know the previous tenant might have made copies of the keys. You make sure the door chain works. You check that the peephole is not blocked. You remove any furniture left outside that someone could stand on to reach a window. You set up a timer for your lights so it looks like someone is home when you are away. You register your address with the neighborhood watch program. You check that your smoke detector has a fresh battery. Each of these actions is a step on your personal apartment hardening checklist. Now map that to IT. The new apartment is a new server. The default password is like the key from the building manager. Anyone who knows it can get in. So you change it immediately (change default credentials). The unused windows are like unnecessary network ports. You close them so nobody can climb in. The door chain is like a firewall rule that only allows trusted traffic. The peephole is like an audit log that lets you see who knocked. The timer for lights is like a scheduled security scan that keeps checking the system. The smoke detector battery is like having up-to-date antivirus software. By following this checklist, you reduce the chance of a break-in. In IT, the checklist is written down, tested, and shared with the whole team. It is not just common sense. It is a standardized procedure that ensures every new system meets the same security baseline.

## Why it matters

A hardening checklist matters because it turns good intentions into repeatable, verifiable actions. Without a checklist, IT professionals rely on memory, which is unreliable. A single forgotten setting can leave a system vulnerable to attack. For example, leaving the default Simple Network Management Protocol (SNMP) community string “public” enabled on a network device allows anyone on the network to read configuration data. That one oversight can lead to a data breach. A hardening checklist prevents such oversights by providing a step-by-step guide that must be completed and signed off. In a business context, hardening checklists are critical for regulatory compliance. Regulations like PCI DSS, HIPAA, GDPR, and SOC 2 require organizations to implement security baseline configurations. An auditor will ask to see the hardening checklists and evidence that they were applied. If you cannot produce these, you risk failing the audit, which can result in fines, loss of certification, or loss of business. Hardening checklists also save time and money. Instead of researching the best security settings for every new server, an IT team can use a pre-approved checklist. This ensures consistency across the environment, making it easier to manage and maintain security. When a new vulnerability (like Log4Shell or EternalBlue) is discovered, the checklist can be updated, and all systems can be re-hardened quickly using the updated list. In short, the hardening checklist is the cornerstone of proactive security. It moves an organization from reactive patching to systematic risk management. For IT certifications, knowing how to apply and interpret a hardening checklist is a foundational skill tested in many exams, from CompTIA Security+ to Cisco CCNA to (ISC)2 CISSP.

## Why it matters in exams

Hardening checklists appear frequently in IT certification exams because they test a candidate’s understanding of security best practices and their ability to apply them in a structured way. In CompTIA Security+ (SY0-601 and SY0-701), the exam objectives under Domain 3 (Implementation) explicitly require you to know about secure baseline configurations and hardening. You may be asked to select the correct step from a hardening checklist for a given scenario, such as disabling unnecessary services on a web server or changing default credentials on a network router. In CompTIA Network+ (N10-008), hardening checklists are part of network security concepts, particularly for wireless access points, switches, and routers. Questions may ask which setting to change on a switch to prevent VLAN hopping or which protocols to disable for secure management (e.g., disable Telnet, enable SSH). In Cisco CCNA (200-301), you need to know device hardening commands for routers and switches, such as setting enable secret passwords, disabling unused ports, configuring port security, and using SSH instead of Telnet. These are often presented as configuration steps that form a hardening checklist. In the (ISC)2 CISSP exam, hardening checklists fall under the Asset Security and Software Development Security domains. You must know the process of creating, applying, and auditing baseline configurations. Questions can be scenario-based, such as: An organization deploys 100 new servers. The security policy requires all servers to be hardened before connecting to the network. Which document ensures consistency? Answer: a hardening checklist. In Microsoft Azure and AWS certification exams, hardening checklists are embedded in services like Azure Security Center or AWS Security Hub. They are referenced as security baselines or compliance packs. For example, in AZ-900 or SC-900, you may need to understand that a hardening checklist helps maintain a secure posture. In all these exams, the key is to recognize that a hardening checklist is not a single technology but a process. Exam questions may test your knowledge of specific items on the checklist for a particular operating system or device, or they may ask you to identify the purpose of the checklist itself. You must also understand the difference between a hardening checklist and a vulnerability scan: a checklist is proactive and preventive, while a scan is detective. Expect multiple-choice questions, scenario-based questions, and even drag-and-drop ordering questions where you arrange the steps of a hardening procedure correctly.

## How it appears in exam questions

Hardening checklist questions typically appear in one of three formats: scenario-based, configuration-based, and troubleshooting-based. In scenario-based questions, you are given a situation where a system has been compromised or needs to be secured. The question may ask: After installing a new Linux web server, which three steps from a hardening checklist should you perform first? The correct answers might include: update the operating system, disable the root account for SSH, and change the default SSH port. These questions test your understanding of prioritization. Configuration-based questions present a partial command or a list of settings and ask you to choose the correct hardening step. For example: Which command should be added to a Cisco switch configuration to secure unused ports? The answer could be “shutdown” or “switchport port-security” depending on the context. You may also see output from a system and be asked which hardening step was missed. For instance, a server is running an outdated version of OpenSSL, and the question asks: Which item on the hardening checklist would have prevented this vulnerability? Answer: Installing security patches or running a vulnerability scan after hardening. Troubleshooting-based questions present a problem that arose because a hardening step was applied incorrectly. For example: After applying a hardening checklist to a database server, users cannot connect to the database. Which setting on the checklist most likely caused the issue? Answer: The firewall rule that blocks the database port. These questions test your ability to understand the impact of each hardening action. Some questions present a list of hardening steps and ask you to identify which step is out of order or which step is unnecessary. For example: Which of the following is NOT a typical item on a server hardening checklist? Options might include: enable DHCP, disable unused accounts, remove unnecessary software, enforce password complexity. The correct answer is “enable DHCP” because DHCP is a service, not a hardening step. Another common pattern is to provide a scenario with a default configuration and ask which changes from a hardening checklist should be applied. For example: A Windows server has Default Domain Policy with no password requirements. Which two changes should you make? Correct: enable password length and enable account lockout. To answer these questions correctly, you must memorize common hardening items for the specific exam’s focus (OS, network device, cloud service). Repetition with practice tests and hands-on lab experience is very helpful.

## Example scenario

A small company called GreenTech Solutions just bought a new Windows Server to host their internal file shares. The IT intern, Jamal, is tasked with setting it up. His manager gives him a hardening checklist and says, “Follow this exactly. Do not connect it to the network until the checklist is complete.” The first item on the checklist is: “Change the default Administrator password.” Jamal logs in with the default password “Passw0rd” and changes it to a long, complex password he writes down. Next, the checklist says: “Rename the built-in Administrator account.” He renames it to “GTSAdmin” so attackers cannot guess the username. The third item is: “Create a separate standard user account for daily tasks.” He creates a user named “Jamal_Standard” with limited permissions. The fourth item: “Enable Windows Firewall and restrict inbound ports to only SMB (445) and Remote Desktop (3389) from the internal IP range.” Jamal configures the firewall rules. The fifth item: “Enable BitLocker drive encryption for the system and data drives.” He turns on BitLocker. The sixth item: “Install all critical Windows updates from Microsoft.” He runs Windows Update and installs 14 updates. The seventh item: “Disable unnecessary services: print spooler, Windows Media Player sharing, and Simple TCP/IP services.” He stops and disables them. The eighth item: “Enable audit policy to log failed login attempts.” He turns on auditing. After completing all 20 items, Jamal signs the checklist and asks his manager to verify. The manager reviews the log files, checks the firewall rules, and confirms all steps are complete. Only then does he allow Jamal to connect the server to the company network. This scenario shows exactly how a hardening checklist is used in real IT: to ensure every security step is done before the system goes live. Because of this checklist, the server is much less likely to be compromised by common attacks like brute-force login, malware, or scanning for open services.

## Common mistakes

- **Mistake:** Only applying a hardening checklist once and never updating it.
  - Why it is wrong: Threats and software versions change quickly. A checklist from 2019 may not include patches for vulnerabilities discovered in 2023, leaving systems exposed.
  - Fix: Schedule a review and update of the hardening checklist at least every six months, or whenever a major vulnerability is announced.
- **Mistake:** Using the same checklist for every type of system without customization.
  - Why it is wrong: A web server needs different hardening (e.g., disable directory listing, enable SSL) than a database server (e.g., restrict port 1433, disable xp_cmdshell). Using a generic checklist can miss critical settings or break functionality.
  - Fix: Maintain separate hardening checklists for different system roles (web server, database server, workstation, network device).
- **Mistake:** Skipping the verification step after following the checklist.
  - Why it is wrong: Just because you performed the steps does not mean they are all working correctly. For example, you might think you disabled anonymous FTP access, but a misconfigured FTP server still allows it. Without verification, the system may still be vulnerable.
  - Fix: After applying the checklist, run a vulnerability scanner or manual tests to confirm each hardening measure is active.
- **Mistake:** Hardening a system to a point where it becomes unusable for legitimate users.
  - Why it is wrong: Overly aggressive hardening can block necessary services, causing business disruption. For example, disabling all TCP ports except 80 and 443 on a file server will make it impossible to access file shares.
  - Fix: Test the hardened system with a small group of users first. Only deploy to production after confirming essential functions still work.
- **Mistake:** Not documenting exceptions or deviations from the checklist.
  - Why it is wrong: If a specific hardening step cannot be applied due to a business requirement (e.g., must use Telnet for legacy equipment), not documenting the exception leaves a known risk unmanaged. Auditors will flag this during a compliance review.
  - Fix: Create an exception log that records the reason for the deviation, who approved it, and the compensating controls in place.

## Exam trap

{"trap":"The exam question asks: Which of the following is the FIRST step in a hardening checklist for a new server? Option A: Install antivirus software. Option B: Change default administrator password. Option C: Apply security patches. Option D: Enable the firewall.","why_learners_choose_it":"Learners often choose option C (Apply security patches) or option A (Install antivirus) because they think those are the most important for security.","how_to_avoid_it":"The correct answer is B: Change default administrator password. The reasoning is that the system should be under your control before connecting it to the network to download patches. If the default password is still set, an attacker on the same network could take control before you even install updates. Always secure administrative access first."}

## Commonly confused with

- **Hardening checklist vs Vulnerability scan:** A vulnerability scan is a detective process that identifies existing weaknesses in a system, while a hardening checklist is a preventive process that applies security configurations to reduce those weaknesses. The two are complementary: you harden first, then scan to verify. (Example: A vulnerability scan might report that port 23 (Telnet) is open. The hardening checklist would include a step to disable Telnet and close that port.)
- **Hardening checklist vs Baseline configuration:** A baseline configuration is a set of consistent settings applied to all systems of a type, such as the minimum security settings for a Windows 10 workstation. A hardening checklist is a more detailed, step-by-step procedure used to achieve and verify that baseline. The checklist is the “how,” while the baseline is the “what.” (Example: Your baseline configuration says “Windows Firewall must be enabled.” Your hardening checklist has the step: “Enable Windows Firewall using Group Policy.”)
- **Hardening checklist vs Security policy:** A security policy is a high-level document that states an organization’s security goals and rules (e.g., “All servers must be hardened before deployment”). A hardening checklist is a lower-level operational tool that specifies the exact technical steps to achieve that policy. The policy sets the requirement; the checklist fulfills it. (Example: A security policy might say “Passwords must be strong.” The hardening checklist includes the specific settings: minimum password length of 12 characters, complexity enabled, and password history of 24.)

## Step-by-step breakdown

1. **Plan and prepare** — Before touching the system, you must identify its role (web server, database, workstation) and the relevant compliance requirements (PCI DSS, HIPAA, etc.). You select the appropriate baseline standard (e.g., CIS Benchmark for Windows Server 2022) and tailor the checklist to your environment. This step ensures you know exactly what you are hardening and why.
2. **Install the operating system and apply updates** — Install the OS using a clean, trusted image. Immediately apply all security patches, including critical and important updates. Outdated software is a primary vector for exploits. This step should be done offline or on an isolated network segment to avoid exposure during installation.
3. **Change default credentials and disable default accounts** — Default usernames and passwords are publicly known. Change the built-in administrator/root password to a strong, unique password. Rename default administrative accounts if possible. Disable or delete unnecessary built-in accounts like Guest. This prevents easy initial access.
4. **Disable unnecessary services and remove unnecessary software** — Every running service and installed program is a potential attack point. Review the services list and stop/disable any that are not needed (e.g., Print Spooler on a web server, Telnet Server, SNMP if not monitored). Remove any pre-installed software like games, media players, or demo apps. This reduces the attack surface.
5. **Configure the firewall and network services** — Enable the host-based firewall. Create inbound rules to allow only necessary traffic (e.g., port 80/443 for web, port 22 for SSH). Outbound rules can also restrict malicious comms. Disable unnecessary network protocols (e.g., IPv6 if not used, NetBIOS over TCP/IP). This controls what traffic can reach the system.
6. **Configure user accounts, permissions, and password policies** — Enforce least privilege: users get only the permissions they need. Set password policies (length, complexity, history, lockout thresholds). Enable account lockout after a set number of failed attempts. Disable anonymous access. This reduces the risk of unauthorized access through weak credentials.
7. **Enable audit logging and security monitoring** — Turn on auditing for critical events: logon/logoff, account management, policy changes, system events. Configure logs to be sent to a central SIEM or at least stored with sufficient retention. Log size should be managed to avoid overwriting old data. This provides visibility into security incidents.
8. **Apply file system and registry hardening** — Set NTFS permissions or Linux file permissions to restrict access to sensitive files (e.g., SAM database, password files). Disable autorun on drives. Set secure permissions on Windows registry keys. This prevents local privilege escalation and data leakage.
9. **Enable encryption and secure protocols** — Enable disk encryption (BitLocker, LUKS) to protect data at rest. Use only secure protocols for remote management (SSH instead of Telnet, RDP with Network Level Authentication, HTTPS instead of HTTP). Disable older TLS/SSL versions and enable strong cipher suites. This protects data in transit and at rest.
10. **Verify and document** — Run a vulnerability scanner or security audit tool to confirm all hardening steps are in place. Review logs and test each service from a secure client. Document the date of hardening, the version of the checklist used, who performed it, and any exceptions. This provides audit evidence and a baseline for future changes.

## Practical mini-lesson

A hardening checklist is not a one-size-fits-all document. In real IT work, you will often have to create or adapt checklists for different operating systems, applications, and devices. Let us go deeper into how professionals approach this. First, they choose a reputable source for the baseline. The CIS Benchmarks are widely used because they are vendor-neutral and detailed. For example, the CIS Benchmark for Ubuntu Linux 22.04 LTS has over 300 configuration items, organized by sections such as Initial Setup, Services, Network Configuration, Logging and Auditing, Access Control, and System Maintenance. A professional will not blindly apply all 300 settings. They will go through the checklist, mark each item as ‘applicable’ or ‘not applicable’ based on the server’s role. For a Docker host, they would keep the Docker-related recommendations and mark other items as NA. This customization is critical because applying an irrelevant step, like disabling the Apache service on a Docker host that actually runs Apache in a container, could break the service. Once the checklist is customized, the professional uses automation tools to apply the settings. For example, Ansible can run a playbook that mirrors each step of the checklist. This ensures consistency across dozens or hundreds of servers. Ansible can also report back which servers are compliant and which have drifted. Drift is a huge issue in production. A system that was hardened at deployment can become un-hardened over time if an administrator manually changes a setting or installs software that opens ports. Therefore, the hardening checklist should be tied to a continuous compliance monitoring tool. For example, using OpenSCAP on Linux or Microsoft Security Baseline Analyzer on Windows, you can schedule weekly scans that compare the current system state against the checklist. Any deviation is flagged as a finding that must be remediated. What can go wrong? The classic mistake is hardening that breaks a critical business application. For example, disabling SMBv1 on a file server might stop a legacy finance application that depends on it. In such cases, the professional must document the exception, get approval from the system owner, and implement compensating controls, like isolating the legacy app in a VLAN. Another risk is over-hardening the OS to the point where it blocks essential management traffic, such as blocking Windows Remote Management (WinRM) or SNMP, which are needed for monitoring. The key lesson for any IT professional is to always test the hardened system in a staging environment that mirrors production. Never apply a new hardening checklist directly to production without testing. This practical discipline is exactly what certification exams test: you need to know not just what to harden, but how to do it safely and verifiably.

## Memory tip

Think of hardening as “HALT”: Harden the default credentials, Audit the logs, Lock down services, Test the result.

## FAQ

**What is the purpose of a hardening checklist?**

The purpose is to provide a systematic, repeatable process for securing a system by reducing its attack surface. It ensures that all critical security settings are applied consistently.

**Who creates a hardening checklist?**

A hardening checklist is typically created by the security team, system administrators, or compliance officers. It is based on industry standards like CIS Benchmarks, vendor guides, and internal security policies.

**Is a hardening checklist only for servers?**

No. Hardening checklists exist for workstations, laptops, network devices (routers, switches, firewalls), cloud instances, database servers, and even IoT devices.

**How often should a hardening checklist be updated?**

At least once a year or whenever a major security vulnerability or OS update is released. The checklist should also be reviewed when new compliance requirements are adopted.

**Can a hardening checklist be automated?**

Yes, completely. Tools like Ansible, Chef, Puppet, and PowerShell DSC can apply hardening settings automatically. This is common in large enterprises to maintain consistency.

**What is the difference between a hardening checklist and a security baseline?**

A security baseline is the desired secure state (the goal), while a hardening checklist is the step-by-step procedure to achieve that state (the process).

**What is the first step in a typical hardening checklist?**

The first step is always to change default credentials and disable unnecessary default accounts, because these are the easiest entry points for an attacker.

## Summary

A hardening checklist is a fundamental tool in IT security that provides a structured approach to locking down systems, networks, and applications. It transforms high-level security policies into actionable, verifiable steps. By following a checklist, IT professionals ensure that every new system meets a minimum security baseline before it goes live, dramatically reducing the risk of successful attacks. The checklist covers critical areas such as default credentials, patching, service management, firewall rules, password policies, encryption, and logging. It is not a one-time exercise but a living document that must be updated as threats evolve and as systems change. For certification candidates, understanding hardening checklists is essential for exams like CompTIA Security+, Network+, Cisco CCNA, and (ISC)2 CISSP. You must know not only the common items on a checklist but also the order in which they should be applied, how to customize a checklist for different system roles, and how to avoid common mistakes like over-hardening or skipping verification. As you prepare for your exam, practice by creating a simple hardening checklist for a hypothetical server. Then run through it step by step. This hands-on approach will solidify your understanding and prepare you for scenario-based questions. Remember, a hardened system is not impenetrable, but it is far more difficult to compromise than one that was set up with default settings. The hardening checklist is your first and most effective line of defense.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/hardening-checklist