System Hardening ServicesCIS Benchmarks, DISA STIGs, Security Baselines, and Drift Detection for Servers, Workstations, Network Devices, and Cloud

What Is System Hardening?

System hardening is the practice of configuring a computer system, device, or cloud service to reduce its vulnerability to attack. It has two halves. The first is reducing attack surface: removing or disabling software, services, network ports, protocols, features, and accounts that the system does not need to perform its role. The second is secure configuration: setting the options that remain (authentication, logging, encryption, permissions, update behavior, and network exposure) to values that resist misuse. The result is a system whose behavior is known, whose exposed functions are the minimum required, and whose configuration can be compared against a written standard.

The written standard is the security baseline, and it is usually derived from a published hardening benchmark. The Center for Internet Security publishes CIS Benchmarks for operating systems, cloud platforms, network devices, browsers, and server software, each a consensus-developed list of recommended settings with a rationale and an audit procedure. The Defense Information Systems Agency publishes Security Technical Implementation Guides, or STIGs, for products used in Department of Defense environments. Microsoft, Amazon, Google, and other vendors publish their own security baselines for their platforms. NIST maintains the National Checklist Program described in NIST SP 800-70, a repository of these checklists, and its older Guide to General Server Security, NIST SP 800-123, still describes the hardening life cycle accurately: plan, install, configure, test, and maintain.

Hardening is not a one-time event. NIST SP 800-171 Revision 2 treats it as three connected requirements in the configuration management family: control 3.4.1 requires baseline configurations to be established and maintained, control 3.4.2 requires security configuration settings to be established and enforced, and controls 3.4.6 and 3.4.7 require least functionality and the restriction of nonessential programs, functions, ports, protocols, and services. A system that was hardened once and never re-checked satisfies none of these on the day of the assessment; a system that is hardened, recorded, scanned, and corrected does.

Petronella Technology Group has provided cybersecurity, compliance, and managed IT services from Raleigh, North Carolina since 2002 and is a CyberAB Registered Provider Organization (RPO #1449). System hardening is one of the first engineering activities in most of our engagements because every other control depends on it: a security operations center cannot detect what an unlogged system never reports, a firewall cannot protect a service that should not be listening at all, and a compliance program cannot prove a baseline it never wrote down.

What Gets Hardened: Seven System Classes and Their Benchmarks

Hardening is organized by system class because each class has a different role, a different benchmark, and a different enforcement mechanism. The table lists the classes Petronella Technology Group hardens in a typical engagement, the benchmark source we start from, the mechanism that enforces the settings at scale, and the evidence an assessor samples afterward.

The CIS Benchmarks publish most operating system recommendations in two profiles. Level 1 settings are intended to be applied broadly with little effect on functionality; Level 2 settings are for environments where security outweighs convenience and may break some applications. Most commercial businesses apply Level 1 everywhere and Level 2 on the systems that hold their most sensitive data, and defense contractors handling controlled unclassified information are increasingly expected to explain why they did not go further. The choice is recorded in the baseline so the assessor sees a decision rather than an omission.

How to Harden a System in Eight Steps

The sequence below is the order Petronella Technology Group follows when hardening an environment for the first time. It is deliberately front-loaded with inventory and selection work, because hardening a system whose role is unknown either breaks it or leaves the dangerous parts alone.

Step 3 is the step most organizations skip, and it is the one that prevents outages. A first scan of an unhardened Windows Server against the CIS Benchmark typically fails a large share of the checks, and the failures cluster: authentication and account policies, audit policy, legacy protocols, and unnecessary services. Seeing the clusters before changing anything lets the team decide which to fix through policy and which need a conversation with an application owner. It also gives the compliance program its before-and-after numbers, which are the most persuasive evidence a hardening project ever produces.

Step 4 is where the deviations are born, and they should be born on paper. Every environment has an application that needs SMB signing relaxed, an old protocol left on, a service account with a non-expiring password, or a local administrator on one machine. The benchmark anticipates this; the CIS documents even describe the impact of each setting so the team can weigh it. What an assessor objects to is not the deviation but the absence of a record explaining it. The deviation table lives with the baseline and is reviewed on the same cadence.

Step 5 is the difference between a hardened system and a hardened fleet. Settings applied by hand to one server are undone by the next rebuild, the next administrator, or the next troubleshooting session. Settings applied through Group Policy, Intune, a configuration management tool, or infrastructure as code reapply themselves on every refresh interval and every new system. This is also how the change management process stays honest: a change to the baseline is a change to the policy object, and the policy object has a version history.

CIS Benchmarks, DISA STIGs, and Vendor Baselines: Which Standard to Harden Against

No framework that applies to commercial businesses names a single mandatory benchmark. NIST SP 800-171 control 3.4.2 requires that security configuration settings be established, documented, and enforced; NIST SP 800-53 control CM-6 says the settings should reflect "the most restrictive mode consistent with operational requirements" and points to the National Checklist Program as the source. The choice among the published standards is therefore an engineering decision that the baseline records. These are the sources Petronella Technology Group uses and when each fits.

Windows Server Hardening and Linux Hardening: What the Benchmarks Actually Change

The two most common server hardening requests are Windows Server and Linux, and the benchmarks for each concentrate on a recognizable set of settings. The lists below are not exhaustive; they are the areas where a first scan fails most often and where the security gain per setting is highest.

Network devices and cloud tenants follow the same logic with different settings. On firewalls and switches the work is disabling Telnet and unencrypted management, moving to SNMPv3, restricting the management plane to a management VLAN and an access list, enabling logging and time synchronization, disabling unused ports, and keeping firmware current. On Microsoft 365 and Entra ID it is requiring multifactor authentication for every user, blocking legacy authentication, applying conditional access, limiting global administrator roles and protecting them with privileged access controls, and turning on unified audit logging. On AWS and Azure it is protecting root and subscription owner accounts, enabling organization-wide logging, blocking public storage by default, and reviewing network security group defaults. Each of these is a benchmark recommendation with an audit procedure, and each becomes a line in the baseline.

From Default Installations to a Hardened, Documented Fleet

Where Hardening Appears in CMMC, NIST, HIPAA, PCI DSS, SOC 2, and ISO 27001

Secure configuration is one of the few controls that every major framework asks for by name, which is why a single hardening program, documented once, produces evidence for all of them. The mapping below is the one Petronella Technology Group uses when a client's evidence package has to serve more than one assessment.

Six Ways Hardening Projects Fail

These are the patterns Petronella Technology Group encounters most often when reviewing an environment that was "already hardened." Each one is a control that looked satisfied until an assessor or an attacker tested it.

How Petronella Technology Group Delivers System Hardening

Petronella Technology Group was founded in Raleigh in April 2002, has held a BBB A+ rating since 2003, and is a CyberAB Registered Provider Organization. We deliver hardening as a project for organizations preparing for an assessment and as an operated service for clients whose systems we manage, and in both cases the output is the same: hardened systems, a recorded baseline, and scan evidence that proves the two match.

For defense contractors, hardening is usually delivered inside a broader CMMC compliance effort where the baselines feed the configuration management family and the configuration management plan. For organizations without a compliance driver, a penetration test before and after hardening is the most direct demonstration of what the work changed: the paths that existed on the default build and no longer do.

Default Installation vs. One-Time Hardening vs. an Operated Hardening Program

Most environments Petronella Technology Group reviews are in the middle column: hardening was done at some point, by someone, to some of the systems. The right-hand column is what an assessor can verify and an attacker cannot easily undo.

System Hardening: Frequently Asked Questions

Related Cybersecurity and Compliance Pages

Last Updated: September 10, 2026. This page references NIST SP 800-171 Revision 2 controls 3.4.1, 3.4.2, 3.4.6, 3.4.7, and 3.4.8 and Revision 3 family 03.04, CMMC 2.0 Level 2 practices CM.L2-3.4.1 through CM.L2-3.4.8, NIST SP 800-53 Revision 5 controls CM-2, CM-6, CM-7, and CM-11, NIST SP 800-70 and SP 800-123, the CIS Benchmarks and CIS Controls v8 Control 4, the DISA STIGs, the HIPAA Security Rule at 45 CFR 164.308 and 164.312, PCI DSS v4.0 Requirement 2, the SOC 2 Trust Services Criteria CC6.1, CC6.8, and CC7.1, and ISO/IEC 27001:2022 Annex A control 8.9. Benchmark profiles, tool capabilities, and framework references are described as publicly documented at the time of writing; confirm current versions with the publisher before adopting a baseline.