Hardening systems and devices in 2026: CIS, STIG and defence in depth

Hardening: what it is and what it is not

Several misunderstandings have grown up around the term, and each leads to a different kind of wasted effort, so they are worth disarming at the outset.

Hardening is not a project with an end date. Configuration drifts away from the reference on its own, with nobody acting in bad faith: a temporary exception is made during an incident and never reversed, a new service appears, somebody changes a setting in a hurry. Without measuring that drift, after a year the organisation is in a state it knows nothing about.

Nor is it a synonym for patching or a substitute for threat detection software. An EDR works inside the system and reacts to what is already happening; hardening reduces what an attacker can act on at all. The two complement each other rather than replacing each other.

Finally, it has nothing to do with security through obscurity. Moving SSH from port 22 to port 2222 reduces the number of automated-scanning entries in the log and nothing else - an attacker who spends a minute on reconnaissance will find it just the same.

So what is it? A continuous process resting on three elements: a documented point of reference, regular measurement of deviations from it, and a formal path for approving exceptions. To that add standardised system images, so that every new server starts in the target state instead of being brought to it by hand.

Hardening and detection complement each other. Some techniques in the MITRE ATT&CK ^[5] matrix - T1059 command and scripting interpreter, T1543 create or modify system process, T1547 boot or logon autostart execution - can be cut off by configuration alone, before an EDR has anything to detect. Every such case is an alert that never happens, and one fewer analyst decision.

Standards: CIS, STIG, NIST and when to use each

The point of reference does not have to be invented, because three recognised libraries exist, differing in detail and purpose.

CIS Benchmarks ^[1] are the most common choice outside the defence sector. The Center for Internet Security publishes configuration recommendations for more than 25 product families, from operating systems through databases and application servers to cloud, network devices and containers. Each benchmark has two levels: L1 covers settings that can be deployed without risk of disrupting work, while L2 goes further at the cost of convenience and application compatibility.

DISA STIG ^[2] comes from the United States Department of Defense and is markedly more rigorous. In Polish conditions it is used mainly in the defence sector and wherever a contracting party requires it.

NIST SP 800-53 ^[3] operates at a different level: it is a control catalogue in which configuration falls under the CM family. It is far less detailed than CIS or STIG, but it maps directly onto the NIST CSF ^[6], so it is useful as a connecting layer. For servers specifically, the older but still sensible NIST SP 800-123 ^[7] guide is a practical supplement.

For a typical local authority with a few dozen workstations and a handful of servers, a sensible set looks like this: workstations at L1 with selected L2 settings for disk encryption and remote access, servers and domain controllers at L1 with L2 wherever the applications allow it, network devices to the benchmark for the relevant vendor, and Active Directory to Microsoft's configuration tooling supplemented by local account password rotation and a tiered administration model.

The choice of level is a risk decision, not a matter of ambition. Applying L2 everywhere usually ends the same way: the business reports that something has stopped working, the hardening is rolled back in full, and the organisation ends up below where it started.

What specifically gets hardened

There are seven layers, and each has a different owner and different typical gaps.

1. The operating system. Disabling unnecessary services, tightening authentication - including multi-factor authentication for administrative accounts - retiring obsolete protocols such as SMBv1 and NTLMv1, password policy, and restricting local administrator rights.
2. Active Directory, most often the weakest link in Polish public sector estates. Four things, in this order: a tiered administration model (domain controllers and critical systems, application servers, workstations, with administrative accounts never crossing a tier boundary), local administrator password rotation, restriction of default permissions for ordinary users, particularly the Authenticated Users group on the DNS partitions and in SYSVOL, and tightened Kerberos settings: no accounts with pre-authentication disabled, short ticket lifetimes, AES only.
3. The network. Segmentation into zones, default-deny firewall rules, isolation of workstations from each other, 802.1X authentication on wired and wireless networks, and separation of management interfaces from production traffic, with no protocols that carry passwords in clear text.
4. Workstations. Application control, disk encryption, exploit mitigation, and threat detection software configured to block rather than merely report.
5. Applications. On the web server side: current TLS versions, security headers and reduced information disclosure. On the database side: minimal privileges for application accounts and access logging. In front of both, usually an intermediary layer with rate limiting.
6. Cloud and external services. CIS Benchmarks for the individual providers, multi-factor authentication, administrative event logging, least privilege in identity management, encryption by default, and conditional access rules.
7. Industrial systems. Following IEC 62443 ^[4]: separation from the office network by an intermediate zone, a strict allow list of permitted traffic, passive monitoring instead of active scanning, and an unambiguous procedure for remote access through a jump server.

Order matters. Hardening workstations while leaving an unpatched edge device in place changes nothing - the attacker will come in that way, and all the work inside the network will be irrelevant.

Automation: without it nothing lasts

After a few months configuration drifts away from the reference, and again without anybody acting in bad faith: temporary exceptions made during an incident, new services, changes made in a hurry. Without measurement, nobody even knows how far.

Holding the state rests on three mechanisms. The first is configuration as code, in Ansible, Puppet, Chef or in the mechanisms native to Windows. It gives reproducibility, a change history in a repository, and the ability to compare the actual state with the intended one.

The second is continuous compliance measurement - daily or weekly scanning that identifies which machines have departed from the reference. Scanners with built-in audit profiles and open implementations of the SCAP protocol serve this purpose.

The third is building system images reproducibly, so that every new deployment starts in the target state. This is the most effective approach, because it eliminates drift at source instead of correcting it after the fact.

Without these three elements hardening is a one-off exercise whose effect decays at a rate governed solely by how much the environment changes.

The most common mistakes

Several patterns recur in our audit practice.

1. No drift measurement. The configuration was set at some point and nobody has checked it since. This is the commonest and costliest mistake, because it invalidates all the earlier work.
2. The highest level everywhere. Applying L2 regardless of context leads to conflicts with applications and, in consequence, to the hardening being rolled back in full.
3. No formal exceptions. The goal is not 100 per cent compliance but documented deviations. If a particular server cannot meet a requirement, that should be recorded together with a compensating control and a review date.
4. A hardened interior and an open edge. Workstations and servers compliant with the benchmark, and at the internet boundary a device that has not been updated for several years. Edge devices are an attractive target precisely because they rarely make it into a maintenance window.
5. Active Directory with no tier model. The same account is used for work on a workstation and for administering a domain controller. One successful credential phish is enough to take over the whole estate. Without that separation the path from the first compromised workstation to the domain controller is short, because there is no privilege boundary along it.
6. Hardening without monitoring. Integrity checking and policy enforcement mechanisms generate events that nobody receives. See SOC 24/7.

Where the obligation comes from

No Polish rule uses the word "hardening", but several require exactly what it means.

The Polish national cybersecurity system act ^[14], following the amendment transposing NIS2 and in force since 3 April 2026, addresses its requirements not to operators of essential services but to essential and important entities. They implement an information security management system and, within it - article 8(1)(2) - technical and organisational measures appropriate and proportionate to the assessed risk. Hardening attaches to several points at once: (b) on security in the acquisition, development, maintenance and operation of systems including testing, (j) on basic cyber hygiene practices, (k) on cryptography and encryption, and (n) on access control policies. Point 5(b) and (c) add regular software updates and protection against unauthorised modification. Part of the public sector follows its own path: an important entity that is a public body applies the requirements of annex 4 instead of paragraph 1 (article 8(3)).

The NIS2 directive ^[8] is the source of those requirements. Closest to hardening are article 21(2)(e), covering security in the acquisition, development and maintenance of network and information systems including vulnerability handling, and (g) on basic cyber hygiene practices and training. Watch out for a frequent citation error: the supply chain is (d), and (h) concerns cryptography, not cyber hygiene.

The Polish KRI regulation ^[11] covers entities performing public tasks. Closest to hardening is § 19(2)(7)(c), on measures preventing unauthorised access at the level of operating systems, network services and applications. It is supplemented by point 12(e) on the security of system files and (h) on checking the conformity of ICT systems with the relevant standards and security policies - which is, directly, drift measurement against a reference. See the article on KRI.

Beyond that, DORA ^[9] imposes protection and prevention duties on financial sector entities in article 9, the GDPR ^[10] lists pseudonymisation and encryption among the technical measures in article 32(1)(a), and IEC 62443-3-3 ^[4] sets system requirements for industrial environments. On the documentary side, ISO/IEC 27001 ^[12] often supplements them, with deviations from the reference recorded in the statement of applicability.

Where the field is going

Three developments are changing the scope of the term today.

Zero trust architecture, described in NIST SP 800-207, is a natural extension: instead of hardening individual systems, it verifies every request regardless of where it comes from. It does not replace hardening, though - it presupposes it. A zero trust model built on devices in their default configuration has nothing to verify.

Hardening machine learning environments is an area that did not exist in the previous decade. It adds protection of training data against poisoning, protection of the model-serving layer against prompt manipulation, and control over the model repository. Some of this falls within the duties of the AI Act ^[13].

Confidential computing, built on isolation mechanisms in the processor, extends protection to data in use - until now it was protected at rest and in transit. This matters above all where sensitive data is processed in an environment the organisation does not fully control.