CIS Control 4 Secure Configuration Guide: Safeguards

Most systems arrive configured for ease of use rather than security, and CIS Control 4 is where that gap is closed and kept closed. This guide is the implementation page for Control 4 of the CIS Critical Security Controls v8.1: what each of its 12 Safeguards requires, which Implementation Group (IG1, IG2 or IG3) introduces it, the thresholds CIS writes into the text, and the evidence an assessor will ask for. It is written for engineers, IT managers and GRC leads who have chosen the CIS Controls and now need Control 4 to stand up in an assessment. For the programme view (all 18 Controls, IG selection, CIS tools) read the CIS Controls Guide first; this page goes deeper on one Control and does not repeat it.

Key takeaways

Seven of twelve Safeguards are IG1. Safeguards 4.1 to 4.7 (configuration process, network configuration process, session locking, server and endpoint firewalls, secure management, default accounts) are essential hygiene for every organisation; 4.8 to 4.11 arrive at IG2 and 4.12 at IG3.
The process Safeguard carries the weight. Safeguard 4.1, a documented and annually reviewed secure configuration process, fails outright in the CIS Controls Assessment Specification if the standard does not exist or was last reviewed more than 12 months ago.
CIS writes hard numbers into the text. Session lock at no more than 15 minutes for general purpose operating systems and 2 minutes for mobile devices; device lockout after no more than 20 failed attempts on laptops and 10 on tablets and phones.
Baselines are bought, not invented. Start from CIS Benchmarks, DISA STIGs or vendor baselines such as Microsoft security baselines, then record every approved deviation; the deviations list is part of the evidence.
Default accounts are an identity problem. Safeguard 4.7 (root, administrator and vendor accounts) sits inside a configuration Control, but it is where many breaches start, so treat it with Control 5 and your privileged access programme.

What it is and who it applies to

CIS describes Control 4 as establishing and maintaining the secure configuration of enterprise assets (end-user devices including portable and mobile, network devices, non-computing and IoT devices, and servers) and software (operating systems and applications). The CIS rationale is that default configurations favour ease of deployment, leaving open services and ports, default accounts and passwords, pre-configured DNS settings, older protocols and unnecessary software, and that configuration must be managed over the whole life cycle through a tracked and approved change process. That scope explicitly covers on-premises, remote, network and cloud environments.

Control 4 depends on the inventories. The Assessment Specification lists Safeguard 2.1 (software inventory) as the dependency for 4.1, and its inputs are the enterprise asset inventory and the authorised software inventory. If you cannot enumerate assets and software you cannot measure configuration coverage; see the CIS Control 1 Inventory and Control of Enterprise Assets Guide and the CIS Control 2 Inventory and Control of Software Assets Guide.

Small organisations (IG1): the seven IG1 Safeguards are achievable with built-in tools: Intune or Group Policy security baselines, operating system firewalls, a password manager or LAPS for local administrator accounts, and SSH or HTTPS for administration.
Mid-sized organisations (IG2): add service reduction, trusted DNS, device lockout and remote wipe, which in practice means a mobile device management (MDM) platform and a protective DNS resolver.
Regulated or high-risk organisations (IG3): add separate enterprise workspaces on mobile devices, and in practice move from scheduled scans to continuous drift detection.

Version 8.1 (June 2024) was an iterative update: CIS added a Govern security function, revised asset classes and clarified wording. CIS has stated that Implementation Group assignments did not change, so the IG levels below apply to both v8 and v8.1.

Structure and key requirements

The Safeguard titles below are as CIS publishes them; the requirement column summarises the Safeguard text and the thresholds in the Controls Assessment Specification. The IG column shows the lowest group that includes the Safeguard (groups are cumulative).

Safeguard	Title	IG	What it requires in practice
4.1	Establish and Maintain a Secure Configuration Process	IG1	A documented configuration standard for end-user, mobile, IoT and server assets and their operating systems and applications, reviewed annually or after significant change
4.2	Establish and Maintain a Secure Configuration Process for Network Infrastructure	IG1	The same for network devices (switches, routers, firewalls, wireless controllers), reviewed annually
4.3	Configure Automatic Session Locking on Enterprise Assets	IG1	Lock after inactivity: no more than 15 minutes on general purpose operating systems, no more than 2 minutes on mobile end-user devices
4.4	Implement and Manage a Firewall on Servers	IG1	A virtual, operating system or third-party firewall on servers, where supported
4.5	Implement and Manage a Firewall on End-User Devices	IG1	A host-based firewall or port filter with a default-deny rule, allowing only explicitly permitted services and ports
4.6	Securely Manage Enterprise Assets and Software	IG1	Manage configuration through version-controlled infrastructure as code; administer over SSH and HTTPS; no Telnet or HTTP unless operationally essential
4.7	Manage Default Accounts on Enterprise Assets and Software	IG1	Disable root, administrator and pre-configured vendor accounts or make them unusable
4.8	Uninstall or Disable Unnecessary Services on Enterprise Assets and Software	IG2	Remove unused services such as file sharing, web application modules or service functions
4.9	Configure Trusted DNS Servers on Enterprise Assets	IG2	Point assets at enterprise-controlled or reputable external DNS resolvers
4.10	Enforce Automatic Device Lockout on Portable End-User Devices	IG2	Lock out after no more than 20 failed local attempts on laptops and 10 on tablets and smartphones (for example Intune device lock, Apple maxFailedAttempts)
4.11	Enforce Remote Wipe Capability on Portable End-User Devices	IG2	Ability to wipe enterprise data from enterprise-owned portable devices when lost, stolen or when the user leaves
4.12	Separate Enterprise Workspaces on Mobile End-User Devices	IG3	Separate enterprise apps and data from personal ones, for example Apple configuration profiles or Android Work Profile

Choosing a baseline source

The Assessment Specification expects the configuration standard to record "enterprise approved deviations" from an industry baseline and names CIS Benchmarks, DISA STIGs and USGCB as examples. Most organisations mix sources by platform.

Baseline source	Strength	Trade-off	Typical fit
CIS Benchmarks (Level 1, Level 2)	Consensus-developed, broad product coverage, assessable with CIS-CAT	Level 2 settings can break applications; tailoring needs effort	Default for most operating systems, cloud accounts, databases and containers
Vendor baselines (for example Microsoft security baselines via the Security Compliance Toolkit or Intune)	Deployable as GPO backups or MDM profiles, versioned with the product	Vendor scope only; may differ from CIS values	Windows, Microsoft 365 Apps and Edge estates managed by Intune or Group Policy
DISA STIGs	Prescriptive, audited in US defence contexts, SCAP content available	Strict; heavier operational impact	US federal and defence suppliers
Own standard	Fits unusual platforms	No external benchmark; harder to defend to an assessor	Only where no published baseline exists, such as niche OT or appliances

Microsoft notes that its baselines are designed for well-managed organisations where standard users do not hold administrative rights, and that a setting is enforced only when it mitigates a contemporary threat without causing worse operational problems. In Intune, a newer baseline version makes profiles on older versions read-only for settings, and baselines can conflict with other configuration profiles, so per-setting status reports matter. For platform detail see the Windows Endpoint Hardening Guide, the Windows Server Hardening Guide and the Linux Server Hardening Guide.

Identity and NHI requirements

Three Control 4 Safeguards are identity controls in configuration clothing, and assessors increasingly read them that way.

Default accounts (4.7): covers root and built-in administrator accounts on servers, network devices and appliances, plus vendor accounts in software such as databases, Git servers and management consoles. Disable them, or where they cannot be disabled set a unique random password held in a vault and remove interactive login. The Windows local administrator is the classic case: see the LAPS Guide. The Nissan source code leak began with an internet-facing Git server still on admin/admin.
Secure management (4.6): management planes are privileged infrastructure. Infrastructure-as-code pipelines, configuration management agents and MDM connectors all authenticate with service accounts, tokens or certificates; those identities can change every asset they touch. Inventory them under Safeguard 5.5 and scope them tightly. See the Service Account Security Guide.
Remote wipe and lockout (4.10, 4.11): these are protective, but the same capability in the wrong hands is destructive. In the Stryker 2026 attack an administrator account was used to create a new Global Administrator and issue Intune remote wipe commands at scale. Require multi-administrator approval for bulk destructive actions and scope MDM roles.
Cloud configuration: cloud baselines (for example the CIS AWS Foundations Benchmark) contain many identity settings: root account MFA, no root access keys, key rotation. Workload identities and their keys are configuration too; see the OWASP NHI Top 10 NHI6 Insecure Cloud Deployment Configurations Guide.

Implementation steps

Confirm the denominator. Pull the asset and software inventories from Controls 1 and 2 and group assets into configuration classes: Windows endpoints, macOS, Linux servers, Windows servers, mobile, network devices, cloud accounts, databases, containers.
Pick a baseline per class (4.1, 4.2). Default to CIS Benchmark Level 1 or the vendor baseline. Record the benchmark name and version, the owner and the review date in the configuration standard.
Tailor in a test group. Apply the baseline to a lab or test ring in audit mode where the tool supports it (CIS-CAT or a compliance scanner reporting only). Record every setting you will not apply, with a reason and a compensating control. This deviation register is the evidence the Assessment Specification asks for.
Fix IG1 quick wins first. Session lock (15 minutes desktops, 2 minutes mobile), host firewalls on with default-deny inbound on endpoints, Telnet and HTTP management disabled, default accounts disabled or randomised. These rarely break applications and close common attack paths.
Roll out in rings. Pilot to about 5 to 10 per cent of each class, watch helpdesk tickets and application logs for a defined period, then deploy broadly. Store baselines as code or as versioned GPO and MDM profiles so rollback means reapplying the previous version.
Add IG2 Safeguards. Remove unnecessary services and roles (4.8) using the benchmark's service sections; push trusted DNS resolvers by DHCP, MDM or GPO and block direct outbound DNS at the perimeter (4.9); enforce device lockout and remote wipe through MDM (4.10, 4.11). See the Mobile Device Management Security Guide.
Bring network devices under the same discipline (4.2). Store running configurations in a version-controlled repository, compare daily against the golden configuration, and require change tickets for differences.
Control change. Route baseline changes through change management, so each deviation has an approver and an expiry date. Unapproved drift becomes an incident, not a surprise in next year's audit.
Measure continuously. Schedule compliance scans at least weekly (daily for internet-facing assets) and report conformance per class against the tailored profile.
Review annually. Re-baseline when a new benchmark or vendor baseline version ships, and record the review date to keep 4.1 and 4.2 from failing on age.

Evidence and assessment

The CIS Controls Assessment Specification defines measures for each Safeguard. For 4.1 the core metric is the percentage of authorised software with a documented, maintained configuration standard, and the Safeguard fails if no standard exists or if it has not been reviewed for over 12 months. For 4.6 the metric is the percentage of assets with properly configured management software; for 4.7 it is the percentage of default accounts rendered unusable.

Safeguard	Evidence an assessor expects	Useful KPI
4.1, 4.2	Configuration standard naming baseline source and version, deviation register, owner, last review date	Share of asset classes with a current standard (target 100 per cent); months since last review (under 12)
4.3	GPO, MDM or configuration profile showing the inactivity timeout values, plus compliance report	Devices compliant with 15 and 2 minute limits
4.4, 4.5	Firewall policy, compliance report showing firewall enabled per profile, default inbound action	Servers and endpoints with firewall on (target above 98 per cent)
4.6	Infrastructure-as-code repository history, scan showing Telnet and HTTP management disabled	Assets administered only over SSH or HTTPS
4.7	List of default accounts per platform with status (disabled, renamed and randomised, vaulted)	Default accounts rendered unusable (target 100 per cent)
4.8, 4.9	Service inventory against baseline, DNS settings report, firewall rule blocking outbound port 53 except approved resolvers	Assets using approved resolvers
4.10 to 4.12	MDM policy exports, test record of a remote wipe, work profile enrolment report	Portable devices enrolled with lockout and wipe enforced

Measure against the tailored profile: score conformance against the baseline after approved deviations, otherwise real drift is hidden among accepted exceptions.
Track drift as a rate: count settings that changed from baseline per week and the median time to restore them. A falling restore time is the best signal that Control 4 is operating, not just documented.
Detect tampering: monitor for changes to firewall state, audit policy and security baselines outside change windows, and for new local accounts. Attackers disabling tools map to ATT&CK T1685 Disable or Modify Tools and T1686 Disable or Modify System Firewall; default account use maps to T1078.001 Default Accounts.

Mapping to other frameworks

The CIS Controls Navigator is the authoritative mapping source. The table gives the correspondences most assessors use for Control 4.

Control 4 area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Configuration process and baselines (4.1, 4.2)	CM-2 Baseline Configuration, CM-6 Configuration Settings, CM-3 Configuration Change Control	PR.PS-01	A.8.9 Configuration management
Least functionality (4.8)	CM-7 Least Functionality	PR.PS-01, PR.PS-02	A.8.9
Session lock and lockout (4.3, 4.10)	AC-11 Device Lock, AC-7 Unsuccessful Logon Attempts	PR.AA	A.8.1 User endpoint devices
Host firewalls (4.4, 4.5)	SC-7 Boundary Protection	PR.IR-01	A.8.20 Networks security
Mobile devices (4.10 to 4.12)	AC-19 Access Control for Mobile Devices	PR.PS	A.8.1

Regional schemes overlap heavily: secure configuration is one of the five technical controls in the UK Cyber Essentials scheme, and Microsoft Office macro settings and user application hardening appear in the ASD Essential Eight. See the Cyber Essentials Guide, the Essential Eight Guide and the Control Mapping Guide.

Common pitfalls

A standard that only exists on paper: the configuration standard is written for the audit but no scanner measures against it, so drift is invisible until the next assessment.
Applying Level 2 everywhere in one change: aggressive settings break line-of-business applications, the whole baseline is rolled back, and the organisation ends up with nothing. Ring deployment and a deviation register prevent this.
Forgetting appliances and IoT: printers, cameras, building systems and network appliances keep vendor default accounts and HTTP or Telnet management long after laptops are hardened. The Nissan Git server is the pattern: a forgotten system with a factory login.
Treating the management plane as trusted: one administrator or automation identity in Intune, Group Policy or a configuration tool can change or wipe every device. Scope roles and require approval for bulk actions, as the Stryker attack showed.
Letting the review date lapse: under the Assessment Specification a configuration standard reviewed more than 12 months ago scores zero, however good the technical controls are.
Scoring cloud posture tools as full compliance: automated checks cover only part of a benchmark; manual items and process Safeguards still need evidence. See the Cloud Misconfiguration Guide.

Practitioner checklist

Group assets into configuration classes from the Control 1 and 2 inventories and name an owner for each.
Choose a baseline per class (CIS Benchmark Level 1, vendor baseline or STIG) and record the name and version.
Keep a deviation register with reason, compensating control, approver and expiry for every setting not applied.
Enforce session lock at 15 minutes or less on desktops and servers and 2 minutes or less on mobile devices.
Turn on host firewalls everywhere, default-deny inbound on end-user devices.
Disable Telnet and HTTP management and administer through SSH, HTTPS and version-controlled code.
Disable or randomise and vault every default account, including on appliances and in software.
At IG2, remove unnecessary services, enforce trusted DNS, device lockout and remote wipe through MDM.
Scan at least weekly against the tailored profile and track drift and time to restore.
Review the configuration standards at least annually and after significant change.

CIS Control 4 Secure Configuration of Enterprise Assets and Software Guide: Safeguards, Implementation Groups and Evidence