Lesson 5.2: Endpoint Security

00 Introduction

Lesson 5.1 examined the operating system — the foundation layer on which everything else runs. This lesson examines the endpoints themselves — the laptops, desktops, servers, and mobile devices through which users work and through which the enterprise's data is created, accessed, and moved.

Endpoints are the modern battleground. Most enterprise attacks begin at or target an endpoint — through phishing, through drive-by downloads, through exploitation of endpoint software, or through compromised credentials. Most adversary activity occurs on endpoints — process execution, file modification, credential access, lateral movement. Endpoints are where users work, where data is most accessible, and where the enterprise's security controls are most directly challenged by the diversity, distribution, and dynamism of the endpoint estate.

The endpoint estate has changed substantially over the past two decades. Where enterprises once managed a relatively homogeneous population of corporate-owned desktops on the corporate network, they now manage a diverse population of laptops, desktops, servers, mobile devices, virtual devices, and — increasingly — devices the enterprise does not own. Endpoints connect from anywhere; they run workloads in cloud environments; they access cloud services directly. The endpoint estate has become distributed, heterogeneous, and frequently outside the enterprise's direct control.

This lesson examines endpoint security in detail. It establishes why endpoint security matters. It examines the modern endpoint estate — its diversity, distribution, and the specific challenges it presents. It examines the principal endpoint security capabilities — endpoint hardening, endpoint detection and response (EDR), device management, application control, endpoint patching, device compliance and posture, and the specific challenges of BYOD and unmanaged devices. It closes with the pitfalls that recur across endpoint security programmes.

The material here builds on the OS security foundation from Lesson 5.1 and prepares for the platform-specific considerations in the rest of Unit 5 — application security, database security, cloud security, container security, mobile and IoT security, and critical infrastructure security. It also connects directly to the detection material from Unit 4 — EDR was introduced in Lesson 4.6 as one of the principal detection technologies; this lesson examines it in the context of the endpoint estate it protects.

How to read this lesson

Sections 1–2 establish the framing and the endpoint estate. Sections 3–8 examine the principal endpoint security capabilities. Section 9 addresses BYOD and unmanaged devices. Section 10 addresses pitfalls. If you are short on time, read Sections 2, 4, and 5 carefully — the endpoint estate, EDR, and device management are the most consequential material for enterprise practice and for the assessment.

01 Learning objectives

By the end of this lesson you should be able to:

Lesson objectives

Explain why endpoint security matters and how it relates to OS security and enterprise detection.
Describe the modern endpoint estate — its diversity, distribution, and the challenges it presents.
Apply the principles of endpoint hardening.
Explain endpoint detection and response (EDR) — its capabilities, its uses, and its limitations.
Describe device management — MDM, UEM, and configuration management for the endpoint estate.
Explain application control — allowlisting, blocklisting, and their role in endpoint security.
Analyse endpoint patching and the specific challenges of patching the endpoint estate.
Evaluate device compliance and posture — its role in access decisions and its limitations.
Describe the specific challenges of BYOD and unmanaged devices.
Identify common enterprise pitfalls in endpoint security programmes.

These objectives contribute to Unit 5 outcome U5.1 (secure infrastructure), and to Module 2 outcome M2.8. See the Unit 5 learning outcomes page for the full mapping.

02 Why endpoint security matters

Endpoints are where the enterprise's work happens — where users access data, run applications, communicate, and conduct business. They are also where most enterprise attacks begin and where most adversary activity occurs. Understanding why endpoint security matters clarifies the priorities that inform the rest of this lesson.

Most attacks begin at endpoints

Phishing delivers malware to endpoints; drive-by downloads compromise endpoints; credential theft captures endpoint credentials; exploitation targets endpoint software.
The initial foothold in most enterprise breaches is an endpoint — a workstation, a laptop, or a server.
Endpoint security determines whether the initial attack succeeds and how far it can spread.

Endpoints hold enterprise data

Endpoints hold enterprise data — locally, in caches, in browser sessions, in email clients, in application storage.
Data on endpoints is frequently more accessible than data in centralised systems — because the endpoint is where the user works.
Compromise of an endpoint provides access to whatever data the endpoint holds.

Endpoints are where adversary activity is visible

Most adversary activity occurs on endpoints — process execution, file modification, credential access, lateral movement, persistence.
Endpoint detection provides visibility into this activity — the visibility that network and cloud detection cannot provide.
EDR (Lesson 4.6) has become the dominant form of detection in modern enterprises because the endpoint is where the activity is.

Endpoints are distributed and diverse

Endpoints connect from anywhere — corporate offices, homes, hotels, customer sites. The enterprise's perimeter no longer contains them.
Endpoints run diverse operating systems, applications, and configurations. Managing security across this diversity is substantially more difficult than managing a homogeneous estate.
Endpoints are frequently outside the enterprise's direct control — personal devices, contractor devices, unmanaged systems.

Endpoints are the primary control point for identity

Authentication occurs on endpoints — credentials are entered, tokens are stored, sessions are established.
Compromise of an endpoint frequently means compromise of the credentials and sessions it holds.
Endpoint security is an essential component of identity security — protecting the point at which identity is established and used.

The evolution of endpoint security

Endpoint security has evolved substantially over the past three decades:

Antivirus era (1990s–2000s). Signature-based antivirus provided the primary endpoint protection — detecting known malware by matching signatures.
Endpoint protection platform era (2000s–2010s). Antivirus was supplemented by additional capabilities — host firewalls, intrusion prevention, application control, device encryption — integrated into endpoint protection platforms.
EDR era (2010s). Endpoint Detection and Response platforms introduced continuous monitoring, behavioural detection, and response capability — a substantial evolution beyond signature-based detection.
Integrated endpoint management era (2020s). Endpoint security integrated with device management, identity, and broader security platforms — through XDR, through UEM, and through cloud-native endpoint management.

The trajectory is clear: endpoint security has moved from signature-based detection toward behavioural monitoring and response, and from standalone endpoint tools toward integrated platforms that connect endpoint security with identity, cloud, and enterprise detection.

The most useful framing

The most useful framing for endpoint security is that endpoints are where the enterprise's actual security posture is most frequently tested. Advanced controls — Zero Trust, identity-aware proxies, network segmentation — are frequently designed to protect against threats that begin at endpoints. If the endpoint is compromised, those controls may be bypassed. Endpoint security is the point at which the enterprise's defensive architecture either holds or fails.

03 The modern endpoint estate

The endpoint estate has changed substantially over the past two decades. Understanding its characteristics — diversity, distribution, and dynamic change — is prerequisite to designing effective endpoint security.

Categories of endpoint

Categories of endpoint in the modern enterprise
Category	Characteristics
Managed workstations and laptops	Corporate-owned endpoints with enterprise management agents. Typically managed through device management platforms; subject to enterprise configuration and security policy.
Managed servers	Corporate-owned servers — physical or virtual — running enterprise workloads. Frequently managed through server-specific management platforms; require the same hardening and monitoring as workstations.
Mobile devices	Smartphones and tablets — corporate-owned or personal — running iOS, Android, or equivalent. Managed through MDM; subject to enterprise policy for corporate applications and data. Examined in detail in Lesson 5.7.
Virtual desktops	Virtual desktop infrastructure (VDI) — desktops running in the cloud or data centre and accessed remotely. Changing the endpoint security model — the endpoint is a thin client; the desktop is a managed instance in the data centre.
Cloud instances	Virtual machines running in cloud environments. Frequently ephemeral; require cloud-native management and security approaches.
IoT and operational technology endpoints	Internet of Things devices and operational technology — sensors, controllers, medical devices, industrial equipment. Frequently cannot support standard endpoint security controls. Examined in Lessons 5.7 and 5.8.
Personal devices (BYOD)	Employee-owned devices used for work. The enterprise has limited control — through MDM, through containerisation, or through policy alone. Examined in Section 9.
Contractor and partner devices	Devices owned by contractors, partners, or suppliers that access enterprise resources. Frequently less well-managed than enterprise devices.
Unmanaged devices	Devices that access enterprise resources without enterprise management — personal devices accessing cloud services, shadow IT, and others. Frequently invisible to the enterprise's endpoint security programme.

Characteristics of the modern endpoint estate

Diversity

Multiple operating systems — Windows, macOS, Linux, iOS, Android, and others.
Multiple versions of each — some current, some legacy.
Multiple hardware platforms — laptops, desktops, servers, mobile devices, virtual devices, embedded devices.
Diversity multiplies the management burden — each platform requires its own tools, its own baselines, and its own expertise.

Distribution

Endpoints connect from anywhere — corporate offices, homes, hotels, customer sites, public networks.
Endpoints are not contained by the enterprise's perimeter — they operate outside the network, on untrusted networks, in untrusted environments.
Distribution means that endpoint security cannot rely on network controls — endpoint controls must be effective regardless of where the endpoint is.

Dynamic change

Endpoints are created, modified, and retired continuously — new devices enrolled, existing devices updated, old devices decommissioned.
Cloud instances are ephemeral — created and destroyed in minutes or hours.
Dynamic change requires automated management — manual processes cannot keep pace.

Partial enterprise control

The enterprise fully controls managed corporate devices — it can enforce configuration, install agents, and manage security.
The enterprise has partial control of BYOD devices — through MDM, through containerisation, or through policy alone.
The enterprise has no direct control of unmanaged devices — but they may still access enterprise resources.
Partial control requires different approaches — the enterprise must adapt its controls to what it can actually enforce.

Shared responsibility with cloud and SaaS

Cloud services and SaaS applications shift some security responsibility to the provider — but the endpoint accessing them remains the enterprise's responsibility.
The endpoint is where the user authenticates, where the session is established, where the data is accessed — regardless of where the service runs.
Endpoint security remains essential even as the enterprise's workloads move to cloud services.

The management challenge

The characteristics of the modern endpoint estate produce a management challenge:

Scale. Enterprises operate thousands, tens of thousands, or hundreds of thousands of endpoints — including many that are not in the enterprise's inventory.
Diversity. Multiple platforms, versions, and configurations — each requiring its own approach.
Distribution. Endpoints connect from anywhere — requiring controls that work regardless of network location.
Change. Endpoints change continuously — requiring automated management that manual processes cannot match.
Partial control. Some endpoints are fully managed; some partially; some not at all — requiring differentiated approaches.
Visibility. Some endpoints are visible to the enterprise's management and security tools; some are not — producing gaps where adversaries operate.

Effective endpoint security requires automation, integration, and differentiated approaches — tailored to what the enterprise can actually control. The rest of this lesson examines the specific capabilities through which endpoint security is achieved.

The most useful question

A useful question for endpoint security assessments is: what proportion of the endpoints accessing enterprise resources are covered by the enterprise's endpoint security programme — and what proportion are not? The gap between what the enterprise believes it manages and what actually accesses enterprise resources is where endpoint security risk accumulates. Many enterprises underestimate this gap substantially.

04 Endpoint hardening

Endpoint hardening applies the OS hardening principles from Lesson 5.1 to the endpoint estate. The principles are the same — reduce the attack surface, apply secure configuration, reduce privilege — but the implementation adapts to the distributed, diverse endpoint estate.

Endpoint hardening dimensions

Attack surface reduction

Remove unnecessary software. Endpoints frequently accumulate applications — some legitimate, some not. Uninstall what is not needed.
Disable unnecessary services and features. Bluetooth, USB access, local admin accounts — disabled unless required.
Restrict endpoint capabilities. Limit what the endpoint can do — where feasible — to the minimum required for the user's function.
Disable legacy features. Disable legacy protocols, weak algorithms, and outdated capabilities that are frequently exploited.

Secure configuration

Enforce configuration baselines. Apply role-appropriate baselines — using MDM, group policy, configuration management, or platform-specific mechanisms.
Enable platform security features. Disk encryption (BitLocker, FileVault), secure boot, endpoint firewalls, exploitation mitigations.
Configure password and authentication policy. Enforce strong authentication — including MFA where the platform supports it.
Restrict administrative rights. Users should generally not have local administrative rights; administrative work should require elevation.

Privilege management on endpoints

Remove standing administrative rights. Most users should be standard users. Where elevation is required, it should be controlled and audited.
Manage local accounts. Local administrator accounts should be controlled — with unique passwords, or managed through endpoint privilege management tools.
Manage service accounts on endpoints. Services running on endpoints should use dedicated accounts with minimum privilege.
Monitor privileged activity. Administrative actions on endpoints should be logged and monitored.

Endpoint encryption

Full-disk encryption. Encrypt the endpoint's disk — BitLocker, FileVault, or equivalent — protecting data if the device is lost or stolen.
Key management. Encryption keys should be managed — through TPM, through enterprise key management, or through escrow for recovery.
Removable media encryption. Where removable media is permitted, it should be encrypted — with controls on what can be written to it.
Encrypted communication. Endpoint communication should use encrypted protocols — TLS, VPN, or equivalent — for data in transit.

Endpoint hardening implementation

Implementing endpoint hardening across a distributed, diverse estate requires specific considerations:

Role-based baselines. Different endpoints serve different functions — standard user, developer, executive, mobile, server. Each requires a baseline appropriate to its role. A single baseline for all endpoints either over-restricts or under-restricts.
Automated deployment. Baselines should be deployed automatically — through MDM, through group policy, through configuration management, or through cloud-native mechanisms. Manual configuration does not scale.
Continuous compliance monitoring. Endpoints drift from their baseline. Compliance should be monitored continuously, with drift detected and remediated automatically where feasible.
User experience. Endpoint hardening affects user experience — restricted capabilities, required authentication, enforced encryption. Hardening that degrades user experience excessively drives circumvention; hardening should balance security with usability.
Exception management. Some endpoints require deviations from baseline — for specific application requirements, for executive flexibility, for legitimate business need. Exceptions should be documented, time-bounded, and reviewed.
Integration with endpoint management. Endpoint hardening is closely coupled with endpoint management — the same platforms (MDM, UEM) typically handle both. Hardening and management should be coordinated.

The most useful framing

The most useful framing for endpoint hardening is that the endpoint is the enterprise's most exposed surface. Unlike servers, which are frequently behind layers of network controls, endpoints operate in diverse, untrusted environments — requiring security controls that protect the endpoint regardless of where it is. Hardening the endpoint itself is the foundation of that protection.

05 Endpoint detection and response (EDR)

EDR — Endpoint Detection and Response — is the dominant form of endpoint security in modern enterprises. It combines continuous monitoring of endpoint activity with detection, investigation, and response capabilities — providing visibility into what happens on the endpoint and the ability to act on what is found.

What EDR provides

Continuous monitoring

EDR monitors endpoint activity continuously — process execution, file activity, network connections, registry changes, user activity, and more.
Monitoring is not event-driven — it captures activity continuously, providing the record of what happened on the endpoint.
Continuous monitoring provides the foundation for both detection and investigation.

Behavioural detection

EDR detects malicious behaviour — not just known malware signatures — including living-off-the-land techniques, novel attacks, and post-compromise activity.
Detection is based on the sequence of actions — process trees, command-line arguments, parent-child relationships — rather than on file signatures.
Behavioural detection is what distinguishes EDR from traditional antivirus — and what makes it effective against modern adversaries.

Investigation capability

EDR provides the tools to investigate detections — examining the sequence of activity, the affected systems, and the scope of a potential compromise.
Investigation can be retrospective — examining historical activity to determine what happened and when.
Investigation capability is essential for response — understanding the incident is prerequisite to responding to it.

Response capability

EDR can respond to incidents — isolating endpoints, terminating processes, removing malicious files, and enabling remediation.
Response can be automated — through playbooks — or manual — through analyst action.
Response capability distinguishes EDR from detection-only tools — EDR is not just about seeing; it is about acting.

Threat hunting support

EDR data supports proactive threat hunting — searching for evidence of activity that did not generate alerts.
Hunting can search across the endpoint fleet — for specific indicators, for specific behaviours, for specific patterns.
Hunting capability is what allows the SOC to search for adversaries that evaded detection — the adversaries that matter most.

EDR capabilities in practice

EDR capabilities and their uses
Capability	Uses
Process tree analysis	Detecting malicious process relationships — a document that spawns PowerShell, an office application that launches a command shell, a web browser that executes a script.
Command-line monitoring	Detecting malicious command execution — encoded PowerShell, suspicious command-line arguments, unusual invocation patterns.
File activity monitoring	Detecting malicious file creation and modification — ransomware encryption, malware installation, persistence mechanisms.
Network connection monitoring	Detecting malicious network connections — command and control, data exfiltration, unusual destinations.
Registry monitoring	Detecting persistence mechanisms — registry keys used for persistence, security configuration changes.
User activity monitoring	Detecting credential theft, privilege escalation, and other user-level activity.
Endpoint isolation	Isolating an endpoint from the network — stopping an active incident from spreading — while maintaining management connectivity for investigation.
Process termination	Terminating malicious processes — stopping an active incident in progress.

EDR deployment considerations

Coverage. EDR requires an agent on every endpoint. Coverage should span the endpoint estate — managed endpoints, servers, mobile devices where EDR is available, and cloud instances. Unmanaged endpoints are not covered.
Agent management. Managing EDR agents at scale — deployment, updates, configuration, troubleshooting — is a substantial operational effort. Agent sprawl — multiple agents from multiple vendors — complicates management and consumes resources.
Performance impact. EDR agents consume resources — CPU, memory, disk, network. Performance impact must be managed — particularly on constrained endpoints.
Detection content. EDR's value depends on its detection content — the rules, analytics, and models that determine what it detects. Default content addresses common threats; enterprise- specific content addresses the enterprise's specific threats.
Tuning. EDR produces alerts; without tuning, the alert volume exceeds analyst capacity. Tuning is essential — reducing false positives while preserving detection coverage.
Integration. EDR should integrate with the broader detection architecture — SIEM, XDR, SOAR — so that endpoint detections are correlated with other layers and handled through coordinated response.
Adversary evasion. Sophisticated adversaries attempt to evade EDR — through agents tampering, through kernel-level exploitation, through living-off-the-land techniques, through signed binaries used for malicious purposes. EDR effectiveness depends on vendor capability and continuous improvement.

EDR limitations

Despite its importance, EDR has significant limitations:

Endpoint coverage. EDR cannot protect endpoints that do not have an agent — unmanaged endpoints, legacy systems, IoT and operational technology, and other endpoints where agents cannot be deployed.
Blind spots. EDR sees endpoint activity but not what happens off-endpoint — cloud activity, network traffic, identity activity. Correlating with other layers is required for complete visibility.
Adversary adaptation. Sophisticated adversaries adapt to EDR — developing new evasion techniques, exploiting gaps in detection content, targeting EDR agents themselves.
Investigation skills. EDR provides data; analysing it requires skilled analysts. Without skilled investigation, EDR data is collected but not used effectively.
Alert volume. EDR generates substantial alert volume. Without tuning and automation, the volume exceeds analyst capacity.

The most useful framing

The most useful framing for EDR is that it provides the visibility into endpoint activity that no other detection layer provides. Network detection sees traffic; cloud detection sees cloud API activity; identity detection sees authentication. EDR sees what happens on the endpoint — the activity where most adversaries operate. EDR has become dominant in modern enterprises because this visibility is essential to detecting the threats that matter.

06 Device management

Device management is the discipline of managing the endpoint estate — enrolment, configuration, application management, security policy, and lifecycle management. It provides the foundation on which endpoint security controls are deployed and maintained.

Device management platforms

Device management platforms
Platform type	Characteristics
MDM (Mobile Device Management)	Manages mobile devices — iOS, Android — through device enrolment, configuration profiles, and security policy. The original device management model.
UEM (Unified Endpoint Management)	Extends MDM to manage all endpoint types — mobile devices, desktops, laptops, and servers. Combines mobile and traditional endpoint management.
Modern device management	Cloud-native device management — Microsoft Intune, VMware Workspace ONE, Jamf — managing endpoints through cloud services rather than on-premises infrastructure.
Configuration management	Traditional configuration management tools — SCCM, Ansible, Puppet — managing servers and, in some cases, endpoints.
Endpoint agents	Agents that provide management and security capabilities — from EDR vendors, from management platforms, from configuration management tools.

Device management capabilities

Enrolment. Bringing endpoints under management — through automated enrolment (autopilot, zero-touch), through user-driven enrolment (for BYOD), or through other mechanisms.
Configuration. Applying configuration profiles — security settings, network configuration, application settings, and other configuration — to enrolled devices.
Application management. Deploying applications, managing application updates, and controlling which applications can run on managed devices.
Security policy enforcement. Enforcing security policies — password requirements, encryption, jailbreak/root detection, and other controls.
Compliance monitoring. Monitoring endpoints for compliance with enterprise policy — and taking action when endpoints are non-compliant.
Remote actions. Locking, wiping, and remotely managing endpoints — including remote wipe for lost or stolen devices.
Lifecycle management. Managing endpoints through their lifecycle — from enrolment through retirement — including decommissioning and data removal.
Reporting. Reporting on the endpoint estate — what endpoints are enrolled, what their status is, and how they comply with enterprise policy.

Device management integration

Device management is increasingly integrated with other enterprise security capabilities:

Integration with identity. Device management integrates with identity platforms — so that device state informs access decisions. Conditional access — permitting access only from compliant devices — is a common integration pattern.
Integration with EDR. Device management and EDR are increasingly integrated — with combined platforms providing both management and security capabilities.
Integration with access control. Zero Trust access (Module 1, Lesson 2.7) depends on device posture — the state of the device as reported by device management — informing access decisions.
Integration with cloud services. Cloud services increasingly accept device compliance information — through integration with device management platforms — to inform their own access decisions.
Integration with security operations. Device management information feeds into the SOC — providing context for investigation and response.

Device management challenges

Coverage. Not all endpoints are enrolled in device management — unmanaged devices, BYOD without management, and shadow devices fall outside coverage.
User resistance. Device management restricts what users can do on their devices — producing resistance, particularly for BYOD.
Platform diversity. Different platforms require different management approaches — MDM for mobile, UEM for all types, platform-specific tools for some.
Integration complexity. Device management platforms must integrate with many systems — identity, security, applications, cloud services — producing integration complexity.
Performance impact. Management agents consume resources; enforcement of policy affects user experience. Balance must be managed.
Shadow devices. Devices that access enterprise resources without being enrolled — personal devices using cloud services, contractor devices, and others — are outside the enterprise's management.

The most useful framing

The most useful framing for device management is that it provides the foundation on which endpoint security controls are deployed. Hardening baselines, EDR agents, security policies, and compliance monitoring all depend on device management to reach the endpoint estate. Without device management, endpoint security is applied inconsistently — producing gaps that adversaries exploit.

07 Application control

Application control is the discipline of determining which applications can run on endpoints — permitting approved applications and blocking unapproved ones. It is one of the strongest endpoint security controls, and one of the most operationally demanding.

Application control models

Application control models
Model	Characteristics
Blocklisting	Permits all applications except those on a blocklist of known-malicious or prohibited applications. Simple to deploy but ineffective against novel threats — the adversary just needs an application not on the list.
Allowlisting	Permits only applications on an allowlist of approved applications; blocks everything else. Substantially more secure — unknown applications cannot run — but operationally demanding — the allowlist must be comprehensive.
Publishing (AppLocker, WDAC)	Application control through publisher signing — permitting applications signed by trusted publishers, in addition to explicit allowlists. Balances security with manageability.
Containerisation	Isolating applications — running them in containers or sandboxes where their impact is limited. Provides protection without requiring comprehensive allowlisting.
Privilege-based control	Permitting all applications to run but restricting what they can do — through least privilege, through application sandboxing. Allows flexibility while limiting consequence.

Application control in practice

Implementing application control involves trade-offs between security and usability:

Allowlisting is more secure but more demanding. Allowlisting prevents all unapproved applications from running — blocking not only known malware but also novel threats and unauthorised software. But it requires a comprehensive allowlist, a process for adding applications, and tolerance for the friction it introduces.
Blocklisting is less secure but simpler. Blocklisting permits most applications — producing less friction — but is defeated by any application not on the list. It is a reasonable starting point but not a sufficient long-term strategy.
Publisher-based allowlisting balances security and manageability. Permitting applications signed by trusted publishers — in addition to explicit allowlists — provides substantial security without requiring every application to be individually approved.
Role-based application control. Different user roles require different applications — a developer needs development tools; a receptionist does not. Role-based application control applies different allowlists to different roles.
Phased deployment. Application control should be deployed in phases — starting with monitoring (what applications run, what would be blocked), then moving to enforcement as the allowlist matures.

Application control challenges

Allowlist maintenance. The allowlist must be maintained as applications change — updates, new versions, new requirements. Maintenance is a substantial operational effort.
User friction. Application control restricts what users can install and run — producing friction and requiring exception processes.
Legitimate software circumvention. Applications frequently have legitimate use cases not anticipated when the allowlist was created. Exception processes are necessary but can undermine the control if not managed.
Living-off-the-land. Application control permits legitimate applications — but legitimate applications can be used maliciously. Living-off-the-land techniques use permitted applications (PowerShell, WMI, etc.) — application control alone does not prevent them.
Coverage. Application control requires an agent or platform support on the endpoint. Endpoints without the control leave gaps.
Cloud and SaaS applications. Application control on the endpoint does not control cloud and SaaS applications — which run in the browser or through cloud services. Different controls are required for these.

The most useful framing

The most useful framing for application control is that it is a prevention control — it prevents unapproved applications from running, including the malware that adversaries would otherwise deploy. Its value is highest where the endpoint's required applications are well-defined — in fixed-function contexts like kiosks, servers, and operational technology — and lower in dynamic environments where users require flexibility. Application control should be deployed where it fits, not uniformly across all endpoints.

08 Endpoint patching and vulnerability management

Endpoint patching applies the patch management principles from Lesson 5.1 to the endpoint estate. The principles are the same — discovery, assessment, prioritisation, testing, deployment, verification — but the implementation adapts to the specific challenges of the endpoint estate.

Endpoint patching considerations

Operating system patches. Endpoint operating systems — Windows, macOS, Linux — require continuous patching. Patches address vulnerabilities, deliver features, and fix bugs. Patching should be automated and verified.
Application patches. Endpoint applications — productivity software, browsers, utilities, and industry-specific applications — also require patching. Application patching is frequently neglected relative to OS patching.
Browser and plugin patches. Browsers and their plugins are frequently targeted by attackers. They should be patched promptly, and unused plugins should be removed.
Firmware patches. Endpoint firmware — BIOS/UEFI, device firmware — also requires patching for security vulnerabilities. Firmware patching is frequently neglected.
Third-party applications. Applications from third parties — Adobe, Java, and others — are frequently targeted and frequently unpatched. Third-party patching tools automate the process.
Endpoint patching tools. Specialised endpoint patching tools — Patch My PC, Ivanti, ManageEngine, and others — automate endpoint patching across OS, application, and third-party patches.

Endpoint patching challenges

Scale and distribution

Endpoints are distributed — connecting from anywhere, on untrusted networks. Patch deployment must work regardless of network location.
Endpoints are frequently offline or on unreliable networks — affecting patch delivery.
Cloud-based patching tools address these challenges — patching endpoints wherever they are.

User disruption

Endpoint patching frequently requires reboots — disrupting user work.
Users defer reboots, produce patch pending states, and accumulate unpatched systems.
Deployment policies must balance security with user experience — through deployment windows, forced reboots, and user communication.

Application compatibility

Patches can break applications — introducing compatibility issues.
Testing patches against the endpoint's applications is essential — but at scale, testing is challenging.
Balance between security (patching quickly) and stability (testing thoroughly) depends on the vulnerability and the endpoint.

Coverage gaps

Unmanaged endpoints — personal devices, contractor devices, shadow devices — are not patched by the enterprise's processes.
Legacy endpoints — running unsupported operating systems — cannot be patched.
Coverage gaps are where endpoint vulnerabilities accumulate.

Third-party patching

Third-party applications — Adobe, Java, browsers, and others — require patching in addition to OS patching.
Third-party patching is frequently neglected — producing a substantial source of endpoint vulnerabilities.
Third-party patching tools automate the process — but require deployment and management.

Verification

Verifying that endpoints are actually patched — that deployment succeeded, that reboots completed, that patches were not reverted — is essential.
Verification at scale requires automated tools that report patch status across the endpoint estate.
Unverified patching produces the appearance of compliance without the substance.

Endpoint vulnerability management

Endpoint patching is one component of endpoint vulnerability management — the broader discipline of identifying and remediating vulnerabilities on endpoints. Endpoint vulnerability management includes:

Vulnerability scanning. Scanning endpoints for vulnerabilities — missing patches, misconfigurations, vulnerable applications.
Configuration assessment. Assessing endpoint configuration against baselines — identifying deviations.
Patch management. Applying patches to address identified vulnerabilities.
Remediation tracking. Tracking vulnerabilities through remediation — from identification through verification.
Exception management. Documenting and managing exceptions — endpoints that cannot be remediated, with compensating controls.

Endpoint vulnerability management integrates with the broader vulnerability management discipline examined in Lesson 3.3 — applying the same principles of prioritisation, remediation, and verification to the endpoint estate.

The most useful framing

The most useful framing for endpoint patching is that endpoints are where most enterprise vulnerabilities accumulate. Operating systems, applications, browsers, plugins, and firmware — each requires patching, each is frequently neglected, each is a potential source of compromise. Endpoint patching is a substantial operational effort, but it addresses a substantial portion of the enterprise's actual exposure.

09 Device compliance and posture

Device compliance is the state of an endpoint with respect to enterprise policy — whether it is enrolled, configured correctly, patched, protected, and otherwise conforming to the enterprise's requirements. Device posture is the information about that state — the signals that inform access decisions.

What device compliance includes

Enrolment and management

Is the device enrolled in the enterprise's device management platform?
Is the device subject to enterprise policy — configuration, applications, security settings?
Is the device under the enterprise's control — or is it a personal device outside the enterprise's management?

Configuration

Does the device conform to the enterprise's configuration baseline?
Are the required security settings enabled — disk encryption, secure boot, endpoint firewall, MFA?
Are administrative rights restricted per enterprise policy?

Patch status

Is the device current with operating system patches?
Are the required applications patched?
Are critical vulnerabilities remediated?

Security controls

Is the EDR agent installed, running, and up to date?
Are the required security controls enabled and functioning?
Have security controls been tampered with or disabled?

Integrity

Has the device been jailbroken or rooted?
Has the boot process been modified — through bootkits or other tampering?
Is the device in a trustworthy state?

Threat signals

Are there active threats on the device — malware, malicious processes, suspicious activity?
Have there been recent detections — alerts, incidents?
Are there indicators of compromise?

How device posture is used

Device posture informs access decisions in several contexts:

Zero Trust access. Zero Trust architectures (Module 1, Lesson 2.7) use device posture as one of the signals informing access decisions. Access from a compliant device may be permitted; access from a non-compliant device may be restricted or denied.
Conditional access. Identity platforms use device compliance as a condition for access — permitting access only from devices that meet enterprise requirements.
Cloud service access. Cloud services — Microsoft 365, Google Workspace, and others — accept device compliance information and use it to inform access decisions.
VPN and remote access. VPN and remote access platforms check device posture before granting access — permitting connections only from compliant devices.
Application access. Applications with compliance requirements — healthcare, financial — may check device posture before permitting access to sensitive data.

Device compliance challenges

Coverage. Device compliance requires that the device be enrolled and managed. Unmanaged devices are not covered — but they may still access enterprise resources through cloud services or other means.
Accuracy. Device compliance depends on the accuracy of the information reported by the device. Devices can be misreported — through agent tampering, through compromises that affect reporting.
Latency. Device compliance information may be stale — the device's state may have changed since the last report. Real-time posture assessment is challenging.
Exceptions. Some legitimate access requires exceptions — an executive on a personal device, a contractor with an unusual configuration. Exception management is essential but can undermine the control if not governed.
User friction. Device compliance requirements produce friction — devices that do not meet policy are denied access. Users may resist or circumvent requirements they find inconvenient.
Platform variation. Different platforms report different information — the same posture signals may not be available across all platforms. Consistency is challenging.

The most useful framing

The most useful framing for device compliance is that it provides the endpoint signal that Zero Trust access requires. Zero Trust cannot be implemented without knowing the state of the device — whether it is managed, patched, protected, and trustworthy. Device compliance is what makes this information available — and what makes Zero Trust access practical.

10 BYOD and unmanaged devices

BYOD — Bring Your Own Device — is the practice of allowing employees to use personal devices for work. It is one of the most challenging areas of endpoint security — because the enterprise does not own the device, does not control the device, and frequently cannot enforce the controls that would protect enterprise data.

Why BYOD matters

It is common. Most enterprises have some form of BYOD — whether sanctioned or not. Users expect to use their personal devices for work, and prohibiting it entirely is frequently impractical.
It expands the endpoint estate. BYOD devices add to the endpoint estate — devices the enterprise does not own, does not control, and may not know about.
It blurs the line between personal and enterprise. Personal devices hold both personal and enterprise data — producing privacy and management challenges.
It produces gaps. BYOD devices are frequently outside the enterprise's endpoint security programme — not covered by EDR, not enrolled in device management, not subject to enterprise patching.

BYOD approaches

BYOD approaches
Approach	Characteristics
Prohibition	BYOD is prohibited — only corporate devices may access enterprise resources. Simple to administer but frequently circumvented — users access resources anyway through personal devices or browsers.
Full device management	The personal device is enrolled in MDM — the enterprise manages the device, enforces policy, and can wipe the device. Provides strong control but raises privacy concerns — the enterprise has access to personal data.
Containerisation (work profile)	The enterprise manages a container on the personal device — a work profile with enterprise applications and data — while leaving the personal portion of the device under the user's control. Balances enterprise security with user privacy.
Application-level controls	Enterprise applications enforce their own controls — through mobile application management (MAM), through application-level policy — without managing the device. Provides limited protection.
Access from any device	Access is permitted from any device — with security enforced at the application, identity, and data layers rather than on the device. This is the Zero Trust approach — assuming that the device cannot be trusted and enforcing controls elsewhere.

Unmanaged devices beyond BYOD

Unmanaged devices extend beyond BYOD — they include:

Contractor and partner devices. Devices owned by contractors, partners, or suppliers that access enterprise resources — frequently outside the enterprise's management.
Shadow devices. Devices that access enterprise resources without the enterprise's knowledge — personal devices using cloud services, unapproved hardware, and others.
Personal devices accessing cloud services. Users who access enterprise cloud services — email, file storage, collaboration — from personal devices outside the enterprise's management.
IoT and OT devices. Devices that connect to enterprise networks or services but cannot support standard endpoint security controls. Examined in Lessons 5.7 and 5.8.
Kiosks and shared devices. Devices used by multiple users — kiosks, shared workstations — frequently not managed like standard endpoints.

Managing BYOD and unmanaged devices

Managing BYOD and unmanaged devices requires differentiated approaches:

Zero Trust access. The Zero Trust approach — permitting access from any device but enforcing controls at the identity, application, and data layers — is increasingly the preferred approach for unmanaged devices. The enterprise assumes the device cannot be trusted and protects the resources regardless.
Containerisation. Where the enterprise needs to protect enterprise data on personal devices, containerisation — a managed work profile — provides a balance between enterprise security and user privacy.
Application-level controls. Mobile application management (MAM) — managing enterprise applications on unmanaged devices — provides protection for enterprise data within applications without managing the device.
Data-level controls. Data-loss prevention, encryption of enterprise data, and restrictions on where enterprise data can be stored protect the data regardless of the device.
Policy and awareness. Where technical controls are limited, policy and awareness — acceptable use, security expectations, reporting requirements — provide some protection. Alone, they are insufficient; combined with technical controls, they help.
Visibility. The enterprise should know what unmanaged devices access its resources — through cloud access security brokers, through identity logs, through monitoring. Unknown unmanaged devices are the most significant risk.

The most consequential BYOD risk

The most consequential BYOD risk is the enterprise's lack of visibility into personal devices that access enterprise resources. Many enterprises have users accessing cloud services — email, file storage, collaboration — from personal devices outside the enterprise's management. The enterprise frequently does not know which devices are accessing its resources, what state they are in, or what data they hold. Closing this visibility gap — through Zero Trust access, through cloud access controls, through monitoring — is the first step in managing BYOD risk.

11 Common pitfalls

Enterprise endpoint security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Coverage gaps

Endpoint security controls applied to some endpoints but not others — unmanaged devices, legacy systems, cloud instances, and shadow devices are outside the programme.

Mitigation: Assess coverage across the endpoint estate. Expand coverage where feasible; apply compensating controls where not.

Pitfall 2 — EDR without tuning

Deploying EDR without the effort to tune it to the environment. Default detection content produces excessive false positives; analysts ignore alerts; the value is not realised.

Mitigation: Invest in detection engineering. Tune detections to the enterprise's environment. Review and improve continuously.

Pitfall 3 — Agent sprawl

Multiple agents from multiple vendors on each endpoint — EDR, device management, vulnerability scanning, configuration management — consuming resources and complicating management.

Mitigation: Consolidate agents where feasible. Use platforms that provide multiple capabilities in a single agent.

Pitfall 4 — Excessive user privilege

Users provisioned with administrative rights on their endpoints — producing endpoints where the user can disable controls, install unapproved software, and undermine security.

Mitigation: Remove administrative rights where feasible; use just-in-time elevation where administrative access is required.

Pitfall 5 — Endpoint patching neglected

Endpoint operating systems patched but applications, browsers, plugins, and third-party software neglected — producing substantial vulnerability from applications.

Mitigation: Implement comprehensive endpoint patching — OS, applications, browsers, plugins, and third-party software. Use endpoint patching tools to automate.

Pitfall 6 — Device management coverage gaps

Device management enrolled on some endpoints but not others — leaving unmanaged endpoints outside the enterprise's configuration and security controls.

Mitigation: Expand device management enrolment. Where full management is not feasible, use containerisation or other approaches.

Pitfall 7 — Application control with poor maintenance

Application control deployed but allowlists not maintained — producing user friction, exception proliferation, and eventual abandonment.

Mitigation: Maintain allowlists actively. Establish exception processes. Balance security with user experience.

Pitfall 8 — BYOD without controls

BYOD permitted without adequate controls — personal devices accessing enterprise resources outside the enterprise's management and security programme.

Mitigation: Adopt a BYOD strategy — prohibition, containerisation, application-level controls, or Zero Trust access — and implement it consistently.

Pitfall 9 — No device compliance integration

Device management deployed but not integrated with access decisions — compliance is monitored but does not inform what devices can access.

Mitigation: Integrate device compliance with identity, access control, and cloud services. Use compliance as a signal for access decisions.

Pitfall 10 — Under-investment in endpoint security

Endpoint security treated as a solved problem — antivirus deployed, EDR deployed, device management deployed — without the ongoing investment in tuning, coverage, and improvement that effective endpoint security requires.

Mitigation: Recognise endpoint security as an ongoing programme. Invest in detection engineering, coverage expansion, and continuous improvement.

Endpoint security pitfalls and mitigations
Pitfall	Primary mitigation
Coverage gaps	Assess coverage; expand or compensate.
EDR without tuning	Invest in detection engineering; tune continuously.
Agent sprawl	Consolidate agents; use integrated platforms.
Excessive user privilege	Remove administrative rights; use just-in-time elevation.
Endpoint patching neglected	Implement comprehensive patching; use endpoint patching tools.
Device management coverage gaps	Expand enrolment; use containerisation where needed.
Application control with poor maintenance	Maintain allowlists; establish exception processes.
BYOD without controls	Adopt a BYOD strategy and implement it consistently.
No device compliance integration	Integrate compliance with access decisions.
Under-investment in endpoint security	Treat endpoint security as an ongoing programme.

The most consequential pitfall

The most consequential pitfall in endpoint security is coverage gaps — the endpoints that are not covered by the enterprise's security programme. Whether they are unmanaged personal devices, legacy systems, contractor devices, or shadow devices, the endpoints outside the programme are where adversaries operate — because the enterprise's controls do not apply. Closing coverage gaps — through expanded management, through Zero Trust access, through visibility into what accesses enterprise resources — is one of the highest-value activities in endpoint security.

12 Key concepts

The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

Endpoint: A device through which users access enterprise resources — laptops, desktops, servers, mobile devices, virtual devices, and others. The modern battleground on which most enterprise attacks begin and most adversary activity occurs.
Endpoint estate: The full population of endpoints in the enterprise — diverse, distributed, and dynamic. Includes managed corporate devices, BYOD devices, contractor devices, IoT and OT endpoints, and unmanaged devices.
Endpoint hardening: Reducing the attack surface of endpoints to the minimum required — removing unnecessary software, disabling unnecessary services, applying secure configuration, reducing privilege, and enabling endpoint encryption.
EDR (Endpoint Detection and Response): Continuous monitoring of endpoint behaviour with detection, investigation, and response capabilities. The dominant form of endpoint security in modern enterprises.
Behavioural detection: Detection based on what activity does — the sequence of actions, process relationships, command lines — rather than on file signatures. Enables detection of living-off-the-land techniques and novel attacks.
Process tree analysis: EDR capability to examine process relationships — parent-child relationships — to detect malicious process patterns.
Endpoint isolation: EDR response capability to isolate an endpoint from the network while maintaining management connectivity — stopping an active incident from spreading.
Threat hunting: Proactive searching for evidence of undetected adversaries — using EDR data, threat intelligence, and hypotheses to guide the search. Examined in Lesson 4.6.
Device management: The discipline of managing the endpoint estate — enrolment, configuration, application management, security policy, and lifecycle management. Provides the foundation on which endpoint security controls are deployed.
MDM (Mobile Device Management): Device management platform for mobile devices — iOS, Android — through enrolment, configuration profiles, and security policy.
UEM (Unified Endpoint Management): Device management platform extending MDM to all endpoint types — mobile devices, desktops, laptops, and servers.
Application control: The discipline of determining which applications can run on endpoints — permitting approved applications and blocking unapproved ones.
Allowlisting: Application control model that permits only applications on an allowlist; blocks everything else. More secure but more operationally demanding than blocklisting.
Blocklisting: Application control model that permits all applications except those on a blocklist of known-malicious or prohibited applications. Simpler but defeated by any application not on the list.
Endpoint patching: Applying patches to endpoint operating systems, applications, browsers, plugins, and firmware. Substantially more complex than server patching due to the distribution and diversity of the endpoint estate.
Device compliance: The state of an endpoint with respect to enterprise policy — whether it is enrolled, configured correctly, patched, protected, and otherwise conforming to the enterprise's requirements.
Device posture: Information about a device's compliance state — the signals that inform access decisions in Zero Trust architectures, conditional access, and other contexts.
Conditional access: The practice of permitting access only from devices that meet enterprise requirements — using device compliance as a condition for access.
BYOD (Bring Your Own Device): The practice of allowing employees to use personal devices for work. One of the most challenging areas of endpoint security — because the enterprise does not own or control the device.
Containerisation: Isolating enterprise data and applications on personal devices — through a managed work profile — providing enterprise security while leaving the personal portion of the device under the user's control.
MAM (Mobile Application Management): Managing enterprise applications on unmanaged devices — providing protection for enterprise data within applications without managing the whole device.
Unmanaged device: A device that accesses enterprise resources without enterprise management — personal devices, contractor devices, shadow devices. Frequently outside the enterprise's endpoint security programme.

13 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

Activity 1 — Endpoint security assessment

For an enterprise context you know well, assess its endpoint security posture:

what categories of endpoint exist — managed, BYOD, contractor, IoT, cloud, and others?
which endpoints are covered by EDR, device management, and other endpoint security controls? Which are not?
what is the state of endpoint hardening — baselines defined, deployed, monitored?
what is the state of endpoint patching — OS, applications, browsers, plugins?
is device compliance integrated with access decisions?
what is the enterprise's visibility into unmanaged devices accessing its resources?

Write up your assessment (400–500 words). Identify the most significant coverage gap and describe how it would be closed or compensated.

Activity 2 — Endpoint security programme design

For an enterprise context of your choice, outline an endpoint security programme (500–600 words) covering:

the scope — which endpoints are covered, and which are out of scope;
the hardening approach — baselines, deployment, compliance monitoring;
the EDR approach — deployment, tuning, integration with SOC;
the device management approach — enrolment, configuration, policy enforcement;
the application control approach — model, deployment, maintenance;
the patching approach — OS, applications, third-party, firmware;
the BYOD approach — what controls are applied to personal devices;
the metrics that would demonstrate the programme is working;
the principal challenges and how they would be addressed.

Support your design with reference to the lesson material and to published guidance (NIST, CIS, or equivalent).

Activity 3 — Preparing for Forum 5 and Assignment 2

Forum 5 includes discussion of cloud security governance and critical infrastructure protection. Assignment 2 includes a defence-in-depth strategy for a financial institution and a secure cloud-migration architecture — both of which depend on the endpoint security reasoning developed in this lesson.

Review the Forum 5 prompts and the Assignment 2 brief, and note where the material from this lesson — particularly the endpoint estate, EDR, device management, and BYOD — will strengthen your analysis.

14 Self-check

Answer the questions below before moving to Lesson 5.3. If you cannot answer a question confidently, revisit the corresponding section.

15 Summary

This lesson has examined endpoint security — the discipline of protecting the devices through which users work and through which most enterprise attacks begin. The essential points are:

Endpoint security matters because endpoints are where most attacks begin, where enterprise data is held, and where most adversary activity is visible. Endpoints are distributed, diverse, and frequently outside the enterprise's direct control.
The modern endpoint estate is diverse, distributed, and dynamic. Managed corporate devices, BYOD devices, contractor devices, IoT and OT endpoints, cloud instances, and unmanaged devices — each requiring different approaches.
Endpoint hardening reduces the attack surface. Attack surface reduction, secure configuration, privilege management, and endpoint encryption — applied through role-based baselines, automated deployment, and continuous compliance monitoring.
EDR provides the visibility and response capability that modern endpoint security requires. Continuous monitoring, behavioural detection, investigation, response, and hunting support — the dominant form of endpoint security in modern enterprises.
Device management provides the foundation on which endpoint security controls are deployed. MDM, UEM, and modern device management — enrolment, configuration, application management, security policy, and lifecycle management.
Application control determines which applications can run. Allowlisting, blocklisting, publisher-based control, and containerisation — each with trade-offs between security and usability.
Endpoint patching addresses the vulnerabilities that accumulate on endpoints. OS, applications, browsers, plugins, and firmware — all require patching, and all are frequently neglected.
Device compliance and posture inform access decisions. The endpoint signal that Zero Trust access requires — enrolment, configuration, patch status, security controls, integrity, and threat signals.
BYOD and unmanaged devices present the greatest challenge. The enterprise does not own or control the device but remains responsible for the data it holds and accesses. Zero Trust access, containerisation, application-level controls, and data-level controls are the approaches.
Common pitfalls recur. Coverage gaps; EDR without tuning; agent sprawl; excessive user privilege; endpoint patching neglected; device management coverage gaps; application control with poor maintenance; BYOD without controls; no device compliance integration; under-investment in endpoint security.

These ideas prepare for Lesson 5.3, which examines application security — the controls that protect the software running on endpoints, servers, and cloud platforms, and that address the application-layer attacks that endpoints and servers are exposed to.

Before moving on

Make sure you can describe the modern endpoint estate, explain EDR and its capabilities, describe device management, explain device compliance and its role in Zero Trust access, and identify the BYOD challenges. If you cannot yet do all five, revisit Sections 2, 4, 5, 8, and 9.

Next lesson

Lesson 5.3 — Application Security examines the controls that protect applications — the software running on endpoints, servers, and cloud platforms — and the application-layer attacks that endpoints and servers are exposed to.

COMP 6660 · Enterprise Cybersecurity Endpoint Security

00 Introduction

How to read this lesson

01 Learning objectives

Lesson objectives

02 Why endpoint security matters

Most attacks begin at endpoints

Endpoints hold enterprise data

Endpoints are where adversary activity is visible

Endpoints are distributed and diverse

Endpoints are the primary control point for identity

The evolution of endpoint security

The most useful framing

03 The modern endpoint estate

Categories of endpoint

Characteristics of the modern endpoint estate

Diversity

Distribution

Dynamic change

Partial enterprise control

Shared responsibility with cloud and SaaS

The management challenge

The most useful question

04 Endpoint hardening

Endpoint hardening dimensions

Attack surface reduction

Secure configuration

Privilege management on endpoints

Endpoint encryption

Endpoint hardening implementation

The most useful framing

05 Endpoint detection and response (EDR)

What EDR provides

Continuous monitoring

Behavioural detection

Investigation capability

Response capability

Threat hunting support

EDR capabilities in practice

EDR deployment considerations

EDR limitations

The most useful framing

06 Device management

Device management platforms

Device management capabilities

Device management integration

Device management challenges

The most useful framing

07 Application control

Application control models

Application control in practice

Application control challenges

The most useful framing

08 Endpoint patching and vulnerability management

Endpoint patching considerations

Endpoint patching challenges

Scale and distribution

User disruption

Application compatibility

Coverage gaps

Third-party patching

Verification

Endpoint vulnerability management

The most useful framing

09 Device compliance and posture

What device compliance includes

Enrolment and management

Configuration

Patch status

Security controls

Integrity

Threat signals

How device posture is used

Device compliance challenges

The most useful framing

10 BYOD and unmanaged devices

Why BYOD matters

BYOD approaches

Unmanaged devices beyond BYOD

Managing BYOD and unmanaged devices