System hardening with CIS Benchmarks: factory settings are open doors

2026-08-07 · by SECURITYSQUAD

Many successful attacks need no sophisticated zero-day. A server left as delivered, a default password, or a service listening although nobody uses it will do. Factory settings are optimised for rapid commissioning, not for security. Hardening closes those doors before somebody finds them – and it is one of the few measures that works before a single euro goes into detection technology.

Why default configurations are a risk

A freshly installed operating system, a new database or a cloud service arrives with settings that enable as much as possible: sample services running, generous permissions, outdated protocols, verbose error messages. Convenient for commissioning; for an attacker it is a map. Automated scanners look for exactly these patterns around the clock – a newly exposed server is found within minutes, not weeks.

CIS Benchmarks: hardening to measure

The CIS Benchmarks from the Center for Internet Security are a globally established, vendor-neutral catalogue of concrete hardening specifications – for Windows and Linux, for Microsoft 365 and Azure, for databases, containers and network components. Instead of vague recommendations they give testable individual measures: which service to disable, which policy to set, which protocol to switch off. Each item comes with a rationale, an audit step and remediation guidance.

Two levels are available. Level 1 covers measures that can be implemented with reasonable effort and without noticeably constraining operations – the baseline practically every system should tolerate. Level 2 targets elevated protection requirements and deliberately accepts constraints. That way hardening matches the protection need instead of turning everything off wholesale.

Benchmarks, Controls and Grundschutz – which does what?

Three terms get confused regularly:

| | What it provides | |---|---| | CIS Benchmarks | Concrete settings per system – "this policy to this value" | | CIS Controls v8.1 | Higher-level measure groups for the organisation – what must be done at all | | BSI IT-Grundschutz | Modules and requirements inside a management system to ISO 27001 |

They do not contradict one another. The Controls say you need secure configurations; the Benchmarks say what they look like; IT-Grundschutz anchors the recurring check in an ISMS.

Where to start

Implementing every benchmark at once overwhelms any team. The order by effect per unit of effort:

Active Directory and identities – this decides how far an attacker gets once inside.
Internet-facing systems – web servers, VPN gateways, mail gateways. What sits outside is tried first.
Microsoft 365 or your cloud environment – that is where the data lives today, and the defaults are optimised for collaboration, not containment.
Servers – those holding data worth protecting first.
Clients – at scale via group policy or Intune.

After the first two points you have addressed most of the realistic risk.

From benchmark to operations

A benchmark is not a switch you flip once. The route runs through four steps:

Measure. How far is a system from the target state? Tools such as CIS-CAT provide a reproducible gap analysis; if you want to start without extra tooling, the Microsoft Security Baselines and group policy reporting get you surprisingly far.

Prioritise. Not every deviation weighs the same. A disableable legacy service on an internet-facing server counts differently from a logging setting on a test box.

Roll out. Ideally automated through configuration management – group policy, Intune, Ansible. Manual hardening lasts exactly until somebody rebuilds a system.

Document exceptions. If an application cannot tolerate a setting, that is legitimate. Not writing it down is not. Every exception needs a rationale, a compensating control and a review date.

And test it in practice: hardening that cripples core functions gets worked around in daily life – and then does more harm than good. Hardening means weighing up, not maximising blindly. Test environment first, then breadth.

The most dangerous fallacy: once and done

Systems change. Updates reset settings, new software brings its own defaults, somebody opens a port to debug something and forgets it. This creeping configuration drift eats the security gain if nobody re-measures.

Only repetition helps: a regular target-versus-actual comparison, ideally automated and with a metric you can track – for example the share of compliant systems per benchmark. That figure also works for management, because it shows progress without becoming technical.

This repetition is exactly what ISO 27001 and IT-Grundschutz require. If you run an ISMS you have the cycle already – hardening hooks into it instead of sitting beside it as a project.

What hardening does not replace

It reduces the attack surface, but it detects nothing. A hardened system that somebody enters with valid credentials is just as quiet as an unhardened one. Hardening, vulnerability management and attack detection are three different jobs; the first is merely the cheapest.

As at August 2026. CIS Controls in version 8.1; the CIS Benchmarks are updated continuously per system – always check the current edition for your version before use.