Endpoint Device Security Checklist Template

Overview

“Endpoint” here means the devices your people work on — laptops, desktops, phones, tablets — not API routes. Every one of them is a way into your network, and most breaches that start on an endpoint trace back to something boring: no disk encryption, a stale OS, admin rights nobody revoked. This checklist is the minimum control set a device should meet before it touches corporate data, roughly aligned with CIS Control 4 and NIST SP 800-124. Pair it with an MDM to enforce the technical items instead of chasing them by hand.

When to Use

Reach for this template when:

• Onboarding a new employee or contractor.
• Issuing a corporate laptop or mobile device.
• Rolling out or auditing a bring-your-own-device (BYOD) policy.
• Preparing for a compliance audit or a security review.
• Investigating an endpoint compromise or a lost device.

This checklist is about user devices, full stop. If what you actually need is hardening HTTP API endpoints — auth headers, rate limiting, input validation — that’s a different problem; the HTTP security headers recipe is a better starting point.

Prerequisites

• An inventory of which device types and operating systems you support.
• An MDM or endpoint management tool — Intune, Jamf, Kandji, Fleet, whatever already exists.
• A maintained list of approved software and hardware.
• An EDR solution that actually reports somewhere central.
• Somewhere to flag a lost or stolen device that people can reach in under a minute.

The Checklist

The five groups below go from the device outward: config, identity, software, network, then monitoring. Each section ends with how to verify it at scale — the checkbox is the policy, the verify step is the evidence. The raw files (standalone checklist, osquery queries, audit scripts) live in the companion repository.

1. Device Configuration

Skip this group and nothing downstream matters — it’s the floor the rest of the checklist stands on. Every item is enforceable through an MDM profile, so none of it should depend on user goodwill.

• The OS is a supported release that still gets security patches.
• Automatic OS updates are turned on.
• Screen locks after a short period of inactivity.
• Strong password, PIN, or biometric authentication is required.
• Disk encryption covers the whole drive.
• The OS firewall runs.
• Guest and unused accounts are disabled.
• Remote wipe capability is configured.
• Device shows up in the MDM or endpoint management console.
• Location services stay off, or restricted to what the job needs.

Verify: pull the MDM compliance report — encryption state, OS version, and firewall status are all queryable per device (see the osquery section below).

2. Identity and Access

A locked-down device with a weak account behind it stays an open door. These controls limit what a stolen credential can reach.

• Every corporate account has MFA turned on.
• SSO covers whatever accounts it can.
• Local administrator privileges are restricted.
• Corporate credentials are never shared with personal accounts.
• The approved password manager is set up and in use.
• Remote access goes through the VPN or the zero-trust client.

Verify: identity provider reports (MFA enrollment per user) plus a quarterly admin-rights audit.

3. Software and Applications

Unmanaged software is where unpatched vulnerabilities live. The goal isn’t to block users — it’s to make the approved path the easy path.

• Nothing unapproved gets installed.
• Application whitelisting or store restrictions are enforced.
• Antivirus or EDR agent is installed and active.
• Browser runs the latest release with the approved security extensions.
• Unused and default applications are removed.
• Work apps self-update.

Verify: EDR agent coverage report plus a software-inventory diff against the approved list.

4. Network and Data Protection

Controls for what leaves the device — over the wire and on removable media.

• Nobody hits public Wi-Fi without the VPN on.
• Bluetooth on only when there’s a real need for it.
• USB and removable media use is restricted or monitored.
• Sensitive data is stored in approved cloud locations, not locally.
• Cloud sync limited to the approved corporate tools.
• Backups are configured and encrypted.

Verify: USB device logs (osquery usb_devices), VPN requirement in the access policy, and a restore test on a sample of machines — backups you never test are hopes, not controls.

5. Monitoring and Incident Response

The first four groups prevent; this one detects and responds. A device nobody is watching is a device nobody will notice losing.

• EDR agent is reporting to the security team.
• Device compliance status is visible in the management console.
• Alerts for lost or stolen devices are configured.
• Every user knows the route to report a lost device or a suspected compromise.
• Offboarding process revokes access and wipes corporate data.

Verify: last-seen timestamps in the EDR console, a quarterly remote-wipe drill, and an offboarding dry run.

Control-to-Threat Map

Not every control defends against the same thing. This table maps the checklist’s main controls to the threats they actually blunt — useful when someone asks “why do we need this one?”

Control	Threat it mitigates	Verify with
Full-disk encryption	Data exposure on lost/stolen devices	MDM report, osquery disk_encryption
OS auto-updates	Known-vulnerability exploitation	Patch reports, osquery os_version
MFA	Credential theft, phishing	IdP enrollment report
EDR agent	Malware, lateral movement, persistence	EDR fleet dashboard
Screen lock + strong auth	Physical access, opportunistic misuse	MDM policy state
Remote wipe	Data breach after theft/loss	Quarterly drill
USB restrictions	Data exfiltration, BadUSB malware	osquery usb_devices logs
VPN on public Wi-Fi	Traffic interception, MITM	Access policy logs
Approved software only	Supply-chain and malware installs	Software inventory diff
Offboarding revocation	Ex-employee access persistence	Access-review audit

Rolling It Out

Publishing the checklist is the easy part; making it stick takes a sequence.

1. Baseline the fleet first. Run the checklist against a sample of real devices and see how bad things are — usually encryption and admin rights are the worst offenders.
2. Pilot on IT. Enforce every control on the machines of the IT and security team first. Whatever breaks here will break tenfold on sales laptops.
3. Codify into MDM profiles. Turn each enforceable item into a profile or policy. Checklists people fill in by hand decay; policies don’t.
4. Roll out by cohort. New devices first, then existing fleets in waves. Communicate before enforcing — a surprise BitLocker prompt reads as “my laptop is doing something weird.”
5. Handle exceptions in writing. Every deviation gets a documented risk acceptance with an owner and an expiry date. An exception without an expiry is a permanent hole.
6. Review quarterly. Re-run the checklist, fold in new OS releases and threat changes, and retire controls that turned out to be theater.

Platform Notes

The checklist items are platform-agnostic; the tooling that enforces them isn’t. What “verified” looks like differs enough per OS that it’s worth spelling out.

Windows

Microsoft publishes ready-made security baselines for Intune — starting from them beats hand-building GPOs. BitLocker, Credential Guard, and SmartScreen cover most of the checklist natively; the Intune report in “Verifying Compliance” shows how to pull encryption and compliance state fleet-wide.

macOS

FileVault plus Gatekeeper plus SIP gets you most of the device-configuration section for free on managed Macs. Jamf Pro’s inventory API can pull FileVault state across the fleet (example below). Watch for developer machines where users disable SIP “temporarily” — that shows up in compliance queries.

Linux

Corporate fleets rarely give Linux endpoints a full MDM, so enforce the same controls with the tools available: LUKS at provisioning, unattended-upgrades for patching, ufw for the firewall, and osquery for compliance reporting (it runs natively — the queries below work as-is). For developer Linux boxes, add secrets-in-home-directory checks to the SSH snippet.

Mobile

Phones and tablets need MAM more than full device management — especially BYOD, where wiping personal data is both a legal and a trust problem. Enroll in the corporate profile, enforce encryption and app-level restrictions on that profile, and keep remote wipe scoped to the managed container only.

Adapting This Template

The checklist is a floor, not a ceiling. A ten-person startup and a hospital won’t harden the same way, and pretending otherwise produces either security theater or a mutiny.

• Small teams (<50 devices): skip the fleet-scan tooling at first. Intune or Kandji plus a quarterly osquery run covers the verification column well enough.
• Regulated industries: map each checkbox to the framework you answer to (CIS Control 4, ISO 27001 A.8.1, HIPAA device rules). The Control-to-Threat Map table is the place to add a “framework reference” column.
• High-risk roles: don’t harden harder — harden differently. Executive and admin devices should get the variant checklist plus hardware keys, not extra items on the general one.
• Cut deliberately, not silently. If a control doesn’t apply — say, no BYOD phones exist — write “N/A: no BYOD fleet” next to it and date it. Removing items quietly is how checklists stop meaning anything.

Metrics That Matter

Track a handful of numbers to prove the checklist works — and to catch it slipping:

• % of devices encrypted: should sit at ~100%; anything below 95% means provisioning is leaking.
• % of devices on a supported OS: flag anything more than one major version behind.
• EDR coverage: devices with a live, reporting agent ÷ total devices. Gaps here are invisible endpoints.
• Mean time to patch: days from patch release to deployment across the fleet; a rising trend usually means users are deferring restarts.
• Exceptions older than their expiry date: should always be zero.

Variants

• Remote worker checklist: adds VPN, home router security, and webcam privacy checks.
• BYOD checklist: corporate data lives in its own container, walled off from personal apps.
• Executive device checklist: adds higher security layers, travel precautions, and dedicated support.
• Developer endpoint checklist: adds secure code signing, container runtime security, and secrets management.
• Mobile-only checklist: a trimmed control set aimed at phones and tablets, enforced at the app layer.

What Works

• Apply the checklist before the device is used for work — retrofitting is harder than provisioning.
• Let MDM and EDR policies check compliance continuously; manual audits go stale the day they’re run.
• Review and update the checklist quarterly; OS vendors change defaults constantly.
• Train users to recognize phishing and report suspicious activity — the checklist assumes a cooperative user.
• Encrypt everything that touches sensitive data — seniority buys nobody a pass.
• Maintain an asset inventory linked to users and risk levels.
• Write exceptions down with a named owner, a risk acceptance, and the date they die.

Zero-trust network access for high-risk roles

Traditional VPN grants a compliant device broad network reach. For admins, finance, and production-access users, gate access on device posture instead — a device that fails compliance checks gets blocked before it sees the app:

# ZTNA policy: Block non-compliant devices
access_policy:
  name: "Endpoint compliance gate"
  conditions:
    - device.compliance_status == "compliant"
    - device.encryption_enabled == true
    - device.edr_reporting == true
  action: "allow"
  fallback_action: "block"
  fallback_message: "Device not compliant. Contact IT."

Hardware security keys for privileged users

SMS and TOTP MFA can still be phished. FIDO2 security keys (YubiKey, Titan) can’t — enforce them for admins and developers with production access:

# Enforce security key requirement via Okta API
curl -X POST "https://yourorg.okta.com/api/v1/policies" \
  -H "Authorization: SSWS $OKTA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "MFA_ENROLL",
    "name": "Security Key Required for Admins",
    "status": "ACTIVE",
    "priority": 1,
    "conditions": {
      "people": {
        "groups": {"include": ["admin-group-id"]}
      }
    },
    "settings": {
      "factors": [{"factorType": "security_key"}]
    }
  }'

Common Mistakes

• Allowing local administrator rights on all devices.
• Leaving encryption off any device that touches customer data.
• Not updating the checklist for new operating system versions.
• Relying on antivirus alone without behavioral EDR monitoring.
• Ignoring personal devices that access corporate email.
• Not testing remote wipe procedures before an incident.
• Failing to revoke access during offboarding.

Developer workstations held to a lower bar

Developer machines usually hold SSH keys, cloud credentials, and production access — they’re the highest-value endpoints in the fleet and often the least managed. Apply the same EDR, encryption, and MFA requirements, plus secrets hygiene checks:

# Find SSH private keys without a passphrase
for key in ~/.ssh/id_*; do
  case "$key" in *.pub) continue ;; esac
  if ssh-keygen -y -P "" -f "$key" &>/dev/null; then
    echo "WARNING: $key has no passphrase"
  fi
done

# Lock down plaintext credential files
find ~/.aws ~/.config/gcloud -name "credentials" -exec chmod 600 {} \; 2>/dev/null

IoT and smart devices on the corporate network

Smart TVs, conference-room devices, and printers run unpatched firmware and rarely support agents. They don’t belong on the same VLAN as laptops — segment them with restricted access:

# Example: VLAN segmentation for IoT devices
# Switch configuration snippet
interface vlan 50
  description "IoT Devices - Restricted"
  ip access-group IoT_RESTRICTED in
!
ip access-list extended IoT_RESTRICTED
  permit tcp any any eq 443
  permit tcp any any eq 80
  deny ip any 10.0.0.0 0.255.255.255
  permit ip any any

Verifying Compliance at Scale

A checklist you can’t verify is a wishlist. These snippets pull real compliance state from each platform’s tooling — adapt the tool names to your fleet.

One honest caveat: osquery’s schema isn’t identical across platforms or versions. disk_encryption returns BitLocker state on Windows, FileVault on macOS, and LUKS on Linux, but column names like encrypted should be confirmed against osquery.io/schema for your version before you trust a negative result. Same for the EDR query — process names differ per vendor (csagent is CrowdStrike, MsMpEng is Defender); add whatever your fleet actually runs or the query silently reports nothing missing.

osquery fleet scan

osquery runs on Windows, macOS, and Linux, and its tables join to system_info through the host uuid. Run these and they surface every device failing the checklist:

-- Devices with unencrypted disks
SELECT
  si.hostname,
  de.name AS disk,
  de.encrypted
FROM disk_encryption de
JOIN system_info si ON si.uuid = de.uuid
WHERE de.encrypted = 0;

-- macOS devices with the application firewall off (use windows_firewall on Windows)
SELECT
  si.hostname,
  alf.global_state
FROM alf
JOIN system_info si ON si.uuid = alf.uuid
WHERE alf.global_state = 0;

-- Hosts with no EDR/AV agent process running (CrowdStrike csagent, SentinelOne, Defender)
SELECT DISTINCT si.hostname
FROM system_info si
WHERE si.hostname NOT IN (
  SELECT DISTINCT si2.hostname
  FROM processes p
  JOIN system_info si2 ON si2.uuid = p.uuid
  WHERE p.name LIKE '%csagent%'
     OR p.name LIKE '%SentinelAgent%'
     OR p.name LIKE '%MsMpEng%'
);

-- Removable USB devices currently attached
SELECT
  si.hostname,
  u.vendor,
  u.product,
  u.serial_number
FROM usb_devices u
JOIN system_info si ON si.uuid = u.uuid
WHERE u.removable = 1;

Windows compliance via Intune

Get compliance and encryption state for every enrolled device out of Microsoft Graph:

# Connect with read access to managed devices
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

# Compliance + encryption overview across enrolled devices
Get-MgDeviceManagementManagedDevice -All |
  Select-Object DeviceName, OperatingSystem, OsVersion,
                ComplianceState, EncryptionState |
  Format-Table -AutoSize

# Filter to non-compliant devices only
Get-MgDeviceManagementManagedDevice -All -Filter "complianceState ne 'compliant'" |
  Select-Object DeviceName, UserPrincipalName, ComplianceState

macOS encryption audit via Jamf Pro

Jamf Pro’s v1 API can report FileVault status fleet-wide:

#!/bin/bash
set -euo pipefail

# Get an API token (basic auth → bearer token)
JAMF_URL="https://yourorg.jamfcloud.com"
API_TOKEN=$(curl -s -u "api-user:api-pass" \
  -X POST "$JAMF_URL/api/v1/auth/token" | jq -r '.token')

# FileVault status across managed Macs
curl -s -H "Authorization: Bearer $API_TOKEN" \
  "$JAMF_URL/api/v1/computers-inventory?section=FILE_VAULT&page-size=100" |
  jq -r '.results[] | [
    .computer.name,
    (.fileVault.diskEncryptionStatus // "unknown")
  ] | @tsv'

Further Reading

• CIS Benchmarks: the device-hardening baselines this checklist is loosely modeled on.
• NIST SP 800-124 — Guidelines for Managing the Security of Mobile Devices: the reference for mobile endpoint controls.
• Microsoft Intune security baselines: ready-made Windows baseline policies.
• Apple Platform Security: FileVault, SIP, and Gatekeeper internals for the macOS section.
• osquery schema docs: look up the exact table and column names for your osquery version before running the fleet queries.