Endpoint Hardening Checklist

Most endpoint compromises exploit settings that were never changed from the default: local admin rights, unencrypted disks, disabled logging and unrestricted USB or remote access. This template gives you an endpoint hardening standard and checklist for Windows, macOS and Linux workstations and laptops, built on published baselines (CIS Benchmarks, Microsoft security baselines and the macOS Security Compliance Project) rather than settings invented in-house. Every requirement has a verification method, so the checklist works for build sign-off, audit and drift reviews. Adapt the values, roles and tools in square brackets to your organisation and approve it through your normal policy process.

How to use this template

• Replace text in square brackets, such as [Organisation], [X days] and [Endpoint engineering], with your own terms and values.
• "Must" is mandatory; "should" is recommended, with exceptions handled under section 8.
• Copy the checklist tables in section 6 into your tracker and add a status column (Met, Not met, Exception) per device build or golden image.
• Use the "Verify" column as the test: a requirement is met only when the check passes on a sample device or in the management console report, not when a policy has been assigned.
• CIS Controls v8.1 safeguard numbers are given in brackets so the standard maps straight into audits.
• Servers are out of scope; use the Linux Server Hardening Guide and your server baseline.

1. Purpose

This standard sets the minimum secure configuration for end-user devices at [Organisation]. It reduces the attack surface of endpoints, limits what an attacker can do with a compromised user session, and ensures every device produces the evidence needed to detect and investigate an incident. It implements the secure configuration process required by CIS Control 4 (safeguard 4.1) and the security-focused configuration management approach described in NIST SP 800-128.

2. Scope

This standard applies to:

• All desktops and laptops running Windows, macOS or Linux that are owned by [Organisation] or access [Organisation] data, including virtual desktops and the golden images used to build them.
• Devices used by employees, contractors and third parties, wherever they are located.
• Personally owned devices only where [BYOD policy] requires them to meet this standard.

Mobile devices are covered by [Mobile Device Standard]. See the Mobile Device Security Guide.

3. Roles and responsibilities

• [Chief Information Security Officer]: owns this standard and approves exceptions above [risk threshold].
• [Endpoint engineering]: implements baselines in [Intune / Jamf / configuration management tool], maintains golden images and reports compliance.
• [Security operations]: monitors EDR and log coverage and investigates tamper alerts.
• [IAM team]: manages local administrator accounts, privileged access and remote access groups.
• Device users: must not disable, bypass or tamper with security controls.

4. Definitions

• Baseline: a published, versioned set of configuration settings adopted as the starting point for each platform.
• CIS Level 1: in CIS's words, "a base recommendation that can be implemented fairly promptly" and "designed to not have an extensive performance impact".
• CIS Level 2: "defense in depth", "intended for environments where security is paramount". Level 2 settings are more likely to break applications.
• Golden image: the approved build from which devices are provisioned or reimaged.
• Drift: any difference between a device's configuration and its assigned baseline that has no approved exception.

5. Baseline selection

1. [Organisation] must adopt a published baseline per platform rather than create one from scratch. Microsoft gives the same advice: implement "an industry-standard configuration that is broadly known and well-tested".
2. Standard devices must meet [CIS Level 1]. Devices used by [privileged administrators, finance approvers, high-risk roles] should meet [CIS Level 2] or the equivalent stricter baseline.
3. Baselines must be reviewed within [90 days] of a new major OS release or baseline version.

6. Hardening checklist

Each requirement must be met on every in-scope device unless an exception is approved. W, M and L mark Windows, macOS and Linux settings.

6.1 Accounts and local administrators

Local administrator accounts are shared machine credentials: one reused password lets an attacker move from device to device. See the Endpoint Privilege Management Guide.

6.2 Application control

See the Application Allowlisting Guide.

6.3 Patching

See the Patch Management Guide.

6.4 Disk encryption

6.5 Host firewall and network

6.6 Logging

See the Sysmon Guide and the Windows Event Log Guide.

6.7 EDR and anti-malware

See the Endpoint Security Guide and the EDR Evasion and Defence Guide.

6.8 Browser

See the Enterprise Browser and Browser Security Guide.

6.9 Removable media and peripherals

6.10 Remote access and boot

See the Remote Access Identity Guide and the Firmware and Boot Security Guide.

7. Golden images and build verification

1. Golden images must apply the baseline at build time and be rebuilt at least [monthly] with current patches.
2. Every new image must pass the section 6 checks and a baseline scan before release, with results stored in [change record].
3. Images must not contain stored credentials, enrolment tokens with long lifetimes or personal data.
4. Devices must enrol into [MDM / configuration management] automatically at first boot so the baseline is enforced, not just applied once.

8. Exceptions

Exceptions must be requested by the device or application owner, risk assessed by [Security team], approved by [approver], recorded with compensating controls and an expiry date of no more than [12 months], and reviewed before expiry. Settings excluded from a baseline for application compatibility must be recorded per setting, not per device.

9. Compliance and measurement

[Endpoint engineering] must report monthly to [governance forum] on:

• Baseline compliance: percentage of devices passing every mandatory check, by platform (target [95]%).
• Coverage: devices in inventory with EDR, encryption and log forwarding all reporting (target [99]%).
• Local admin exposure: number of users with standing local administrator rights.
• Patch latency: median days from release to install for critical OS updates.
• Drift: new deviations detected and time to remediate.
• Open exceptions: count, age and number past expiry.

Non-compliant devices may be blocked from [Organisation] resources through device compliance policies. See the Device Trust and Posture Guide.

10. Related documents and review

• [Information Security Policy], [Acceptable Use Policy], [Privileged Access Standard], [Vulnerability Management Standard], [Logging and Monitoring Standard], [BYOD Policy].
• This standard is owned by [policy owner] and must be reviewed at least annually, and within [90 days] of a major baseline or OS release.

11. Source baselines

• CIS: CIS Benchmarks and CIS Benchmarks FAQ (Level 1, Level 2 and STIG profiles)
• Microsoft Learn: Windows security baselines
• NIST: macOS Security Compliance Project (mSCP)
• NIST: SP 800-128, Guide for Security-Focused Configuration Management of Information Systems
• Microsoft Learn: Windows LAPS overview
• Microsoft Learn: Attack surface reduction rules reference
• NCSC: Device Security Guidance, Using peripherals securely
• Canonical: Ubuntu Security Guide

Implementation guidance

Roll the standard out in phases so that hardening does not break the business:

1. Measure first: scan a representative sample of each platform against the chosen baseline to find the gap, before changing anything.
2. Quick wins: encryption with escrowed keys, firewall, EDR with tamper protection, automatic updates and LAPS rarely break applications; deploy them first.
3. Audit mode: run application control and ASR rules in audit for [30 days], and review events to build allow rules.
4. Pilot ring: apply the full baseline to IT and security staff, then [5]% of users across departments, for [2 weeks] each.
5. Broad rollout: deploy by ring, watching help desk tickets and compliance reports between rings.
6. Rollback: keep every baseline version in source control or as a versioned MDM profile, so a ring can revert to the previous version in one assignment change.
7. Remove local admin last: once elevation tooling is in place, so users are not left unable to work.

Small organisations can usually deploy the Intune security baseline, an mSCP-generated profile and a CIS Level 1 build script with little tailoring. Large organisations should version baselines per business unit and automate drift reporting into the CMDB. Each area is covered in more depth in NHI Mgmt Group guides:

• Windows settings in depth: Windows Endpoint Hardening Guide
• macOS: macOS Security Guide for Enterprises
• Linux: Linux Server Hardening Guide
• Application control: Application Allowlisting Guide
• Local admin removal: Endpoint Privilege Management Guide
• Telemetry: Sysmon Guide

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Endpoint Security Guide · Windows Endpoint Hardening Guide · macOS Security Guide for Enterprises · Essential Eight Guide