Many intrusions start on an ordinary company device. Someone opened an attachment on their laptop, a contractor signed in from a machine nobody in IT had seen before, or a server that was meant to be retired kept running an old operating system with a known flaw. Whatever else is in place, the first code an attacker runs usually runs on an endpoint.
An endpoint, for the purposes of this article, is any laptop, desktop or server that a person or a service logs into and runs software on. Phones and tablets count too, although most assessments treat them as a separate scope. When we run an endpoint security assessment, the question is simple to state and tedious to answer: how are these machines configured today, how far does that configuration drift from a sensible baseline, and would your detection tooling notice if one of them were used against you?
Why endpoints carry so much of the risk
Three of the most common ways into an organisation all pass through an endpoint. Phishing delivers a link or a file that executes on a user's machine. A stolen or lost laptop puts whatever is on its disk in someone else's hands, along with any saved browser sessions. And once an attacker has a foothold on one device, lateral movement (using that device's credentials, network position and trust relationships to reach other machines) is how a single compromised laptop becomes a much larger problem. We cover that internal side in more detail in perimeter versus internal network security.
Remote and hybrid working has shifted more weight onto the device itself. A laptop on a home broadband connection sits outside the office network controls, so its own settings, encryption and agent software are doing most of the protective work. If those settings are inconsistent across the fleet, the weakest machine sets the level for everyone.
CIS Benchmarks: the usual yardstick
A configuration review needs something to measure against, otherwise it turns into a list of personal preferences. The most widely used reference is the set of CIS Benchmarks published by the Center for Internet Security, a non-profit organisation. Each benchmark is a consensus-based set of secure configuration recommendations for a specific product: Windows 11, Windows Server 2022, macOS, various Linux distributions, the major browsers, Microsoft Office and many others. Each recommendation comes with a rationale, an audit procedure and a remediation procedure.
Level 1 and Level 2 profiles
Most CIS Benchmarks group their recommendations into profiles. Level 1 is the practical baseline: settings that reduce attack surface meaningfully while rarely affecting how the system works for its users or the applications that run on it. Level 2 adds stricter settings on top of Level 1 and is meant for environments where security needs to take precedence, accepting that some of those settings may reduce functionality or break things people rely on. The levels are cumulative, so a Level 2 configuration includes everything in Level 1.
The pragmatic approach is to treat Level 1 as the target for the whole estate and apply Level 2 selectively, to machines that justify the additional testing and support cost: domain controllers, administrators' workstations, servers holding sensitive data. Applying Level 2 across a fleet without testing it first tends to produce broken printing, failed line-of-business applications and a helpdesk queue, followed by a quiet rollback that leaves you with less than you started with. A recommendation that conflicts with a genuine business need is better handled as a documented exception.
CIS Controls and vendor baselines
The CIS also publishes the CIS Critical Security Controls, currently at version 8.1 (released in June 2024). These are a different thing from the Benchmarks. The Controls are a prioritised set of security practices for a whole programme, covering asset inventory, data protection, access control, vulnerability management and so on. The Benchmarks are the detailed, product-by-product configuration guidance you would use to meet some of those practices on a particular system.
For Windows, Microsoft publishes its own security baselines, distributed through the Security Compliance Toolkit and available as templates in Intune. Either is a defensible reference, provided you pick one, record deviations and measure every machine against it.
What an endpoint security assessment checks
The detail varies by operating system and by what tooling is already in place, but the core areas are consistent.
Patch and version currency. Whether operating systems are on supported versions, how far behind the latest security updates each device is, and whether third-party software (browsers, PDF readers, runtimes, remote access tools) is patched on the same cadence as the OS.
Local administrator rights. How many users hold local admin on their own machines, and why. Day-to-day admin rights let malware that runs in the user's session install drivers, disable protections and dump credentials. Removing them is one of the most effective endpoint changes available, and it usually needs a workable process for the occasional legitimate software install.
Local administrator password management. Whether the built-in local administrator account has the same password on every machine. If it does, one compromised device hands over the rest. Windows LAPS, built into supported versions of Windows and Windows Server since the April 2023 updates, rotates that password per device and stores it in Active Directory or Microsoft Entra ID. The older, separately installed Microsoft LAPS product is deprecated on newer Windows releases.
Disk encryption. Whether BitLocker on Windows or FileVault on macOS is enabled on every laptop, and where the recovery keys are escrowed.
Application control. Whether there is any restriction on what software can run. On Windows this means Windows Defender Application Control (renamed App Control for Business from Windows 11 24H2) or AppLocker. Full allow-listing is a significant project, so many organisations start with blocking execution from user-writable locations such as Downloads and temporary folders.
Removable media. Whether USB storage is allowed, blocked, read-only or restricted to approved devices, and whether autorun is disabled.
Browser and Office macro settings. Whether macros from internet-sourced documents are blocked, which browser extensions are permitted, and whether browser security settings are centrally managed or left to each user.
Screen lock and sign-in. Inactivity timeouts, lock on lid close, and how users authenticate to the device itself.
Host firewall. Whether the built-in firewall is enabled on every network profile, and whether inbound rules have accumulated exceptions nobody can explain.
MDM enrolment and policy drift. Whether every device is enrolled in your management platform (Microsoft Intune, Jamf or similar), and whether the policies the console shows as assigned are actually applied on the device. Drift between the two is common, especially after migrations between tools.
EDR and antivirus coverage. Whether every endpoint is running the agent, whether it is reporting in, whether tamper protection is on so that a local administrator or malware cannot simply switch it off, and whether alerts go to someone who reads them.
Logging. Whether the machine records enough to support an investigation: process creation with command lines, PowerShell script block logging, sign-in events, and retention long enough to cover the time it usually takes to notice a problem. If you have never checked this from the investigator's side, incident response readiness covers what responders typically need.
Testing your EDR
Endpoint detection and response tools are often bought, deployed with default settings and then assumed to work. Testing them has two parts.
The first is coverage. We compare the list of devices the EDR console knows about against other sources of truth, such as the MDM inventory, Active Directory or Entra ID computer objects, DHCP leases and network scans. The differences are the interesting part: servers built before the agent was rolled out, machines whose agent stopped reporting months ago, Linux hosts nobody considered, and build images that never included the agent at all.
The second is detection. With agreed scope and timing, we run safe simulations of real attacker techniques on a small number of nominated test machines and record what the EDR does with each one: whether it detects it, raises an alert someone would see, blocks it, or stays silent. Techniques are chosen from MITRE ATT&CK, the public knowledge base of adversary behaviour, so each result maps to a named technique. The open-source Atomic Red Team project, maintained by Red Canary, provides a library of small tests mapped to ATT&CK techniques that suits this kind of exercise well, alongside custom tests where your environment needs them.
Typical areas include credential access (attempts to read credential material from memory), persistence (scheduled tasks, run keys, new services), defence evasion (attempts to disable logging or the agent itself), discovery commands and suspicious script execution. The output is a table of techniques against outcomes, which shows where to tune rules and where a detection simply does not exist.
This kind of testing needs written authorisation and clear rules of engagement before anything runs. That means the named test machines, the techniques in scope, the testing window, who in your team knows it is happening, how to stop it, and what happens if a test triggers a real response from your security operations team or managed service provider. We use simulations designed to be reversible and avoid anything destructive on production systems. The exercise also shows whether a detection reached a person and what they did with it.
Sampling or the full estate
Configuration can be checked in two ways. A deep manual review of a sample (say, a few machines from each build or department, plus every server in a critical role) shows exactly how devices are set up and why. Automated collection across the full estate, through your MDM, your EDR console or a lightweight script, shows how consistent that setup is. Most assessments combine the two: sample deeply to understand the build, then check a smaller set of high-value settings (encryption, patch level, agent health, local admin membership) across every device.
How findings are prioritised
Not every deviation from a benchmark carries the same weight. We rank findings by how directly they would help an attacker and how many machines they affect. Missing EDR coverage, shared local admin passwords, unencrypted laptops and users with standing admin rights generally sit at the top. Each finding is also marked by effort, separating changes you can push through existing device policies this week from those that need testing and change control, such as application control or Level 2 settings on servers.
What a useful report contains
A report your team can act on usually includes:
- The baseline used (for example, CIS Benchmark Level 1 for Windows 11 and macOS, with stated exceptions) and the versions assessed.
- Coverage figures for encryption, patching, EDR and MDM enrolment, with the list of non-compliant devices.
- Findings ranked by risk, each with evidence, affected devices and specific remediation steps for your tooling.
- The EDR test results mapped to ATT&CK techniques, showing detected, alerted, blocked or missed.
- A recommended baseline you can deploy through Intune, Jamf or Group Policy.
- A short management summary that can also serve as audit evidence.
How it supports ISO 27001
For organisations working towards or maintaining ISO 27001, an endpoint assessment produces evidence for several of the technological controls in Annex A of ISO/IEC 27001:2022. Control 8.1 covers user endpoint devices, 8.7 covers protection against malware, 8.8 covers management of technical vulnerabilities, and 8.9 covers configuration management. Auditors will want to see that you have a defined baseline, that you know how far devices deviate from it, and that you act on what you find. A dated assessment and a tracked remediation plan answer all three. Our ISO 27001 consulting work often uses the endpoint findings directly in the control implementation.
A practical endpoint security checklist
If you want to check your own position before commissioning anything, these questions cover most of the ground:
- Do you have a current, complete list of company laptops, desktops and servers, and does it match what your MDM and EDR consoles report?
- Is every laptop encrypted, with recovery keys stored centrally?
- Are all operating systems on supported versions, with security updates applied within a defined number of days?
- Do ordinary users work without local administrator rights?
- Is the local administrator password unique per device and rotated?
- Is there a written hardening baseline (CIS or Microsoft) and a record of exceptions?
- Is tamper protection enabled on your EDR, and does someone review its alerts every working day?
- Have you ever tested whether your EDR detects common attacker techniques?
- Would your endpoint logs still hold the relevant events two weeks after an incident began?
If several of these get a "not sure", that is a reasonable signal that an assessment would be worth the time.
Related work
An endpoint assessment looks at devices one at a time, and pairs naturally with broader testing such as VAPT. A network security assessment looks at what those devices can reach once one of them is compromised, and the two are often scoped together. If an endpoint has already been compromised, the priority shifts to investigation and containment, which is the job of digital forensics and incident response.
Working with Safe Tech AI
Safe Tech AI's endpoint security assessment covers the hardening review against CIS Benchmarks or Microsoft security baselines, patch, encryption and admin-rights posture, and an EDR coverage and detection review mapped to MITRE ATT&CK, delivered as a prioritised gap analysis and a baseline you can apply through your existing device management. If you are unsure where to start, the free 30-minute assessment is a call with a practitioner who will tell you which areas to examine first. The service page sets out scope and deliverables.