System and device hardening in 2026: secure configuration, CIS, STIG, and configuration drift control

Hardening, patching, and detection answer different questions

Hardening is not the same as software updating. An update fixes a known vulnerability in a specific product version. Hardening reduces exposed functionality and abuse paths, and makes some configuration weaknesses and vulnerabilities harder to exploit. It does not provide absolute protection and does not replace vulnerability management, EDR, segmentation, backups, or monitoring.

Patching asks whether known defects have been fixed. Hardening asks whether the system exposes only the functions it needs and enforces the intended security rules. Detection asks whether the organisation can notice adversary activity or another event that requires a response.

A simple example illustrates the distinction. A fully patched server may still permit administrative logon from the entire network, run an unused service, and retain a shared account with excessive privileges. There may be no CVE to patch, yet the attack surface remains unnecessarily large. Conversely, a carefully configured server that is not updated may contain a critical remote-code-execution vulnerability. Both processes are necessary.

Hardening should not be positioned against EDR or a SOC either. Restricting unauthorised program execution, separating administrative identities, and disabling obsolete protocols can make certain adversary techniques harder to use. Monitoring is still required because not every technique can be prevented through configuration. MITRE ATT&CK v19.2, current from 6 August 2026, is a useful catalogue of adversary behaviour, but it is neither a hardening checklist nor proof that controls are effective.^[8]

Choosing a reference point: CIS Benchmarks

CIS Benchmarks are consensus-based configuration recommendations for many operating systems, cloud platforms, databases, network devices, and container platforms.^[1] Most benchmarks include Level 1 and Level 2 profiles. CIS describes Level 1 as a baseline set of recommendations intended to reduce attack surface while preserving usability, and Level 2 as a more stringent defence-in-depth profile that requires more careful testing and may affect the environment.^[2] This does not mean Level 1 is always safe for production or that Level 2 is always better.

The benchmark must match the exact technology and version. The CIS library continues to change rapidly in 2026: new releases have included benchmarks for Windows Server 2025, Windows Server 2019, Ubuntu 24.04 LTS, Microsoft 365, and Kubernetes.^[1][15] Saying that an organisation once implemented CIS is therefore insufficient. The report should identify the benchmark version, profile, and date on which the organisation's own baseline was adopted.

STIG, NIST, Microsoft, and industrial environments

DISA Security Technical Implementation Guides are detailed configuration guidance developed for U.S. Department of Defense environments.^[3] Outside that context they can be a valuable technical reference, but they do not thereby become a Polish legal requirement. Their level of strictness may also be unsuitable for a civilian system's function.

NIST SP 800-53 Rev. 5 operates at a different level. It is a catalogue of security and privacy controls, with Configuration Management forming the CM control family.^[4] It does not provide a ready-made product setting for every technology, so it is more often used to design process requirements than to configure a system directly. The older NIST SP 800-123 from 2008 remains a published guide to general server security, but its age should be considered when relying on technical detail.^[5]

For Microsoft environments, an organisation should also compare its own baseline with current Microsoft security baselines and the modern privileged-access model. In 2026 Microsoft describes the Enterprise Access Model as an evolution of the former Active Directory tier model for on-premises, cloud, and hybrid environments.^[6] This is a better reference than mechanically applying historical tier structures to every organisation.

There is no single benchmark for an entire organisation. A domain controller, developer workstation, web server, switch, Microsoft 365 tenant, and industrial controller require different baselines. In OT environments, the IEC 62443 family provides a framework for industrial automation and control system security, but detailed safeguards must be selected according to architecture, technological process, and safety requirements.^[9]

What to harden: systems, identity, network, and workstations

Operating system

A typical server or workstation baseline covers minimisation of services and packages, protection of local accounts, authentication policy, host firewall, logging configuration, cryptographic settings, memory and application protection mechanisms, and user rights. A setting must be justified by the system's purpose. Disabling a mechanism only because a benchmark recommends it, without checking application dependencies, is not professional hardening.

Identity and privileged access

In a Windows environment, one of the primary objectives is to break escalation paths toward highly privileged identities. This includes separating standard and administrative accounts, restricting where administration may be performed, controlling delegation, protecting service accounts, reducing shared accounts, and using strong authentication where technically feasible.

Local administrator passwords should not be shared across multiple devices. Windows LAPS provides centralised management of randomised, unique passwords for such accounts and is one component of reducing lateral-movement risk.^[7] It does not replace management of the broader privileged-account class or control of administrative sessions. In hybrid environments, separating control, management, and data planes and protecting devices used for administration are important.^[6] The higher the privilege, the fewer locations should be able to receive it.

Network

Network-device hardening includes limiting management to dedicated sources, strong administrator authentication, disabling unused management services, encrypted administration protocols, restricting access to management interfaces, centralised logging, and change control. Segmentation and a default-deny rule can materially reduce lateral movement, but they require knowledge of actual application flows.

Workstations

Important controls on workstations include disk encryption, restriction of local administrative privileges, application control, secure browser and office-suite configuration, credential protection, host firewall, and EDR policy. A developer workstation may require different exceptions from an administrative employee's computer. Each exception should still have an owner, justification, and review date.

Cloud, containers, and OT environments

Cloud and SaaS

In cloud environments, hardening shifts from operating-system settings toward identity, roles, networking, logging, managed-service configuration, keys, secrets, and organisational policies. Auditors should examine both individual-resource configuration and policy inheritance at organisation or tenant level. Enabling MFA does not fix excessive roles or unmanaged OAuth applications.

Containers and Kubernetes

A baseline needs to cover images, hosts, runtime, orchestrator, network policies, secrets, workload privileges, and CI/CD. CIS publishes separate benchmarks for Kubernetes and selected container environments.^[1] One of the most common mistakes is treating a secure container image as equivalent to a secure cluster.

OT and embedded systems

An office-server baseline should not be applied to OT without impact analysis. Process availability, vendor requirements, long life cycles, and limited maintenance windows change how safeguards are deployed. Segmentation, control of remote access, restriction of allowed communications, monitoring, and formal change management may be more important than enforcing a single setting.^[9]

Automation and configuration drift control

Hardening performed manually across dozens of devices quickly loses consistency. Automation can use GPO, Intune, Ansible, Puppet, Chef, cloud-native mechanisms, policy-as-code, or custom scripts. The particular tool matters less than the ability to reproduce configuration and detect drift.

A mature process has at least six elements:

1. a versioned baseline with an owner and identified source;
2. a test environment or sample where a change is validated before broad deployment;
3. an automated or regular mechanism for measuring compliance;
4. a formal exception register with justification, risk, and reassessment date;
5. a rollback plan if configuration disrupts the service;
6. deployment evidence: configuration-scan results, policy exports, change logs, and device samples.

"100% CIS compliance" should not be a goal in itself. Some recommendations may be inappropriate; others may be replaced by equivalent controls. A conscious, documented decision is more valuable than an artificially increased compliance percentage.

Common mistakes

1. Deploying a benchmark without testing. A baseline is a source of recommendations; it does not know the dependencies of a specific application. Changes to TLS, permissions, encryption, or application-control rules can interrupt service.
2. Lack of versioning. "We use CIS Level 1" says very little without the product name, benchmark version, profile, and accepted exceptions.
3. Hardening only servers. An attacker may need only one weak point in identity, an administrative workstation, an edge device, cloud configuration, or a management platform to bypass a well-hardened server.
4. Lack of drift control. Without comparing actual state against the baseline, the organisation does not know whether the safeguard still exists.
5. Treating every deviation as a vulnerability of equal severity. A deviation must be evaluated in the context of the asset's function, exposure, and possible impact.
6. An exception without an owner. A temporary deviation without a deadline and risk decision becomes permanent configuration.

Where the obligation comes from

Polish law does not impose a general requirement to implement CIS Benchmarks. It does, however, require outcomes for which secure configuration may be an appropriate measure.

Following the amendment effective from 3 April 2026, the National Cybersecurity System Act requires essential and important entities to apply proportionate cybersecurity risk-management measures. These include, among other things, security in acquisition, development and maintenance of systems, vulnerability management, access control, supply-chain security, cryptography, and evaluation of control effectiveness.^[10][11] The Act does not designate CIS or STIG as a mandatory profile, which also matters in a KSC/NIS2 audit.

The KRI regulation of 21 May 2024 requires covered entities to maintain an information security management system, current internal rules, measures addressing risks from vulnerabilities, access management, and protection of systems appropriate to risk.^[12] Hardening is a natural way to support some of these requirements, but it is not the only way.

DORA goes further for financial entities. Commission Delegated Regulation (EU) 2024/1774 requires secure configuration baselines for ICT assets that minimise exposure to cyber threats and regular verification that those baselines have been effectively implemented.^[13] This is a direct basis for a secure-configuration process, but not a mandate to use a specific benchmark.

GDPR Article 32 requires measures appropriate to the risk to personal data. It does not prescribe a configuration checklist or hardening profile.^[14] A misconfiguration may be one factor leading to a personal-data breach, but the selected safeguard must still be justified by risk.

ISO/IEC 27001:2022 remains a voluntary management-system standard unless its use is required by contract or a specific regulatory regime. Its controls include configuration management, but conformity with the standard does not automatically mean conformity with every benchmark.^[16]

How to assess hardening maturity

A programme can be assessed with straightforward questions:

• Does every material system type have an identified, versioned baseline?
• Is it known which settings were intentionally changed from the external benchmark?
• Does a new device receive secure configuration automatically or through a repeatable process?
• Are deviations detected after deployment rather than only during an audit?
• Does every exception have an owner, justification, risk, and reassessment date?
• Are changes tested first, with a safe rollback mechanism available?
• Is privileged access separated from ordinary user activity?
• Does the baseline include cloud platforms, network devices, and management systems, not only operating systems?
• When a benchmark is updated, does the organisation perform a gap analysis instead of blindly applying every new setting?
• Do hardening results feed into the audit, risk-management, and monitoring processes?

In 4crypto audit and hardening projects, it is usually more useful to present the result as a map of deviations, risks, decisions, and evidence than as a single CIS compliance percentage. This separates a technical weakness from a consciously accepted exception.