EDR and XDR: endpoint protection, detection and response
The endpoint is where an attacker’s actions become visible: processes and scripts run here, credentials are used, persistence is established and movement through the infrastructure begins. That is why endpoint security has long gone beyond scanning files for malware.
Prevention first
A solid preventive layer before detection is tuned.
The whole chain is visible
An analyst should see how the attack developed, not a single alert.
The platform can be operated
We test not only detection, but whether the platform can be run day to day.
Endpoint Protection, EDR and XDR solutions
Hafaza Tech designs and implements endpoint security based on CrowdStrike Falcon, Palo Alto Networks Cortex XDR, Fidelis Endpoint and Kaspersky — from the prevention baseline and architecture through to the pilot, detection validation, response workflow and SOC integration.
A single Falcon platform and one sensor, on top of which different capabilities are enabled. The base architecture is Falcon Prevent and Falcon Insight XDR: preventive protection, continuous endpoint telemetry, investigation and response.
As the security program matures, the architecture can be extended — identity protection, exposure management, threat hunting, device control, firewall management, mobile, next-gen SIEM. This is not a single licence: the set of modules and subscriptions is defined per project.
A logical choice where you need to start with strong endpoint protection and grow the platform step by step.
Cortex XDR combines preventive endpoint protection, behavioural detection, investigation and response, and is part of the wider Cortex architecture for security operations.
A separate direction is Cortex Agentic Endpoint Security: discovery and governance of AI agents and other emerging software on endpoints.
Particularly suitable where endpoint security is already part of a wider Palo Alto architecture.
Fidelis Endpoint
Takes a slightly different position: its strengths are deep telemetry, retrospective investigation, forensic visibility and remote response.
Works with activity on Windows, Linux and macOS and lets you use historical and forensic data during analysis. Endpoint telemetry can be complemented by Fidelis Network and Fidelis Deception.
Relevant where depth of investigation and forensics matter, not only the speed of blocking.
The Kaspersky Next line develops EDR and XDR on top of endpoint protection and offers different capability tiers depending on SOC maturity and deployment requirements.
On-premise and isolated deployment models matter in environments with such requirements.
Treating it as a classic antivirus is no longer accurate: the current line-up is considerably broader.
There is no universally best platform. One organization needs strong prevention and simple operation, another depth of investigation, a third local deployment, a fourth a single ecosystem with the rest of its security tools. So the platform is chosen for the infrastructure — and for the people who will work with it every day.
Antivirus, EPP, EDR and XDR
This is not a succession of generations: modern platforms combine these capabilities in one console.
Antivirus
Detects and blocks malware. Modern engines use not only signatures but machine learning, behavioural and cloud-based analysis.
EPP — endpoint protection platform
Combines preventive controls: malware and ransomware protection, exploit protection, behavioural prevention and other endpoint controls.
EDR — detection and response
Adds continuous endpoint telemetry, behavioural detection, investigation, threat hunting and response actions.
XDR — extended detection
Links endpoint activity to other domains: identity, cloud, network, email, mobile devices, third-party sources. It is not “EDR with more features” but an architecture for detection and investigation across several domains.
So the right model is not “antivirus or EDR”, but prevention, detection, investigation and response in one architecture.
The preventive layer
EDR does not make prevention unnecessary
A good architecture first tries to stop malicious activity, and only then detects and investigates what could not be prevented or what looks like legitimate action. The more attacks are stopped automatically, the fewer events reach the analyst.
What a modern preventive layer works against
Malware
Ransomware
Exploit techniques
Malicious scripts
Fileless techniques
Suspicious process behaviour
Abuse of trusted tools
A separate goal of the project is a reliable prevention baseline that does not break business applications and production workloads.
Behavioural detection and attack context
An attacker does not have to bring an obvious malicious file onto the endpoint.
Attacks use legitimate tools and operating system mechanisms: PowerShell, scripts, WMI, command shells, remote administration tools, signed system utilities. PowerShell being launched does not in itself mean an attack — what matters is the sequence of actions.
Instead of an isolated “suspicious PowerShell” alert, the analyst should see the whole scenario: user → application → script → PowerShell → credential access → remote connection. That context shows not only what was detected, but how the attack developed and how far it could have gone.
Investigation, threat hunting and response
EDR/XDR should not be limited to automatically generated alerts. An analyst needs to be able to explore the data — both from an alert and retrospectively.
What the analyst must be able to reach
From alert to investigation and back
Process execution, command lines, users, files and hashes, network activity, persistence artefacts, historical telemetry and similar activity on other hosts. This makes it possible not only to triage an alert, but to look for related traces in advance: after a compromised account, for example, other endpoints can be checked before new alerts appear.
Possible response actions
Host isolation
Process termination
File quarantine
Indicator or hash blocking
Remote investigation
Scripted actions
Forensic collection
The set of available actions depends on the product, the operating system, the licence, the state of the endpoint and connectivity. Containment and full incident response are different things: isolating a host does not close the incident — the scope, the accounts, persistence and related systems still have to be checked.
An attack rarely stays on the endpoint alone
A modern attack usually passes through several security domains. If the team sees only endpoint telemetry, part of the chain stays outside the investigation.
CrowdStrike Falcon Insight XDR, for example, combines endpoint data with identity, cloud and mobile signals and can add third-party sources. Other platforms differ in their domains and correlation mechanics — that has to be verified, not assumed.
Identity compromise and endpoint compromise are usually different stages of the same attack. Stolen credentials, token abuse, credential dumping and lateral movement tie them together so closely that investigating them separately becomes ineffective. The practical question is no longer only “what did the process do”, but
Operating system coverage
You cannot choose protection by how it behaves on a Windows workstation alone
Enterprise scope usually includes Windows workstations, Windows Server, Linux, macOS, VDI, remote devices and cloud-hosted server workloads. Declared support for an operating system does not mean the same depth of protection: the phrase “the EDR supports Linux” on its own says almost nothing.
What we check for each platform
Telemetry depth
Supported prevention techniques
Available response actions
Supported distributions and kernels
Sensor dependencies
Offline behaviour
Performance impact
So coverage is assessed by real capabilities on the customer’s own systems, not by the existence of an installer package.
Endpoints, servers and containers are not the same thing
A cloud server workload can usually be protected by an ordinary agent. With containers that does not carry over automatically.
Host coverage
A classic agent on a workstation, server or virtual machine: processes, files, network, accounts, persistence.
Container and runtime coverage
Kubernetes activity, the container runtime, image lifecycle, workload identity and container-specific behaviour cannot be reduced to a host EDR.
Some platforms combine endpoint and cloud workload security in one ecosystem, but container scenarios may require separate capabilities. So we keep the two kinds of coverage apart and verify them independently.
Offline operation and remote response
For distributed environments it matters what happens when an endpoint temporarily loses connectivity with the management platform.
Local prevention and remote response are different things. The agent may keep enforcing part of the preventive controls locally, while centralised investigation and remote commands require connectivity. So offline behaviour should be a separate pilot scenario, not an assumption based on the datasheet.
Resilience of the solution
The security agent is itself a target
An adversary may try to stop the sensor, disable protection, change policy, make use of exclusions or break telemetry collection. So the architecture has to provide tamper protection, sensor health monitoring, policy integrity and visibility of systems where protection is disabled.
What is controlled separately
Protection of the agent from being stopped or altered
Sensor state and health
Policy integrity
Visibility of systems with protection disabled
Exclusions governance
Exclusions deserve particular attention. They are sometimes necessary for compatibility with applications and workloads, but an over-broad exclusion turns a strong EDR into a blind spot. An exclusion is
Adjacent capabilities around endpoint security
Modern platforms use one ecosystem for several related controls. That reduces the number of agents and consoles, but should not automatically be treated as part of EDR or of one base licence.
Additional controls
Device control, host firewall, encryption management, vulnerability visibility and other functions — depending on the product.
For a project it matters which of them the customer actually needs, rather than enabling the maximum number of modules.
Exposure context
Vulnerabilities, misconfigurations, asset criticality and identity exposure help prioritise alerts: the same activity on an ordinary workstation and on an internet-facing privileged server carries different risk.
This adds context to EDR but replaces neither detection nor vulnerability management.
Artificial intelligence
Machine learning has long been used for malware classification and behavioural detection. A newer direction is assisting the analyst: summarising activity, drafting hunting queries, explaining detections, collecting context and speeding up triage.
At the same time AI does not make up for missing telemetry and does not fix weak detection logic.
A separate new theme is AI agents, developer extensions, MCP-based tools and other autonomous software running on the endpoint with the user’s rights. Such components reach local data, credentials, browser sessions and external services, so the market is beginning to add separate discovery and governance for them. We treat this as an emerging direction, not as a mandatory requirement for every EDR today.
How Hafaza Tech implements endpoint security
We do not treat EDR as a project to “install a new agent on the computers”. The stages are ordered so that protection first becomes reliable, and then manageable in day-to-day operation.
01
Assessment
02
Scope
03
Architecture
04
Prevention baseline
05
Pilot
06
Deployment
07
Detection validation
08
SOC integration
09
Continuous tuning
We map the real landscape: workstations, servers, operating systems, privileged and engineering devices, remote users, virtual desktops, cloud workloads and isolated systems. At the same time we review the existing security tools, exclusions, unsupported and unmanaged devices.
We build a map: device or workload → OS → criticality → user and role → existing controls → required capabilities. It prevents the same policy being applied to an ordinary workstation, an administrator’s privileged machine and a production Linux server.
Before deployment we define the management model, cloud and on-premise constraints, data residency requirements, sensor installation, update paths, network requirements, policy hierarchy, integrations and offline scenarios. Coexistence with already installed agents is checked separately.
We configure the preventive layer: malware and exploit protection, behavioural protection, ransomware controls, exclusions and the remaining policies. The goal is a reliable baseline that does not disrupt applications.
The pilot tests the full cycle, not the fact that an agent installed: malicious scripts, suspicious PowerShell, ransomware-like behaviour, credential access, persistence, remote execution, host isolation and remote investigation. In parallel we assess performance, false positives, application compatibility, agent stability, administrative usability, offline behaviour and correct uninstall and rollback.
For critical scenarios we verify the chain technique → telemetry → detection → context → response on the customer’s own infrastructure, not against a MITRE ATT&CK map from the datasheet. Servers, Linux and specialised workloads get particular attention.
After rollout you have to watch sensor health, stale hosts, exclusions, false positives, policy exceptions, unsupported devices and changes in the estate. Endpoint protection degrades quickly if the configuration does not evolve with the infrastructure.
CrowdStrike, Cortex XDR, Fidelis or Kaspersky?
A feature matrix is only the start of the evaluation. We define a few critical scenarios and test them in a pilot rather than comparing hundreds of datasheet rows.
Prevention
The quality of the preventive layer and its impact on applications and performance.
Telemetry and detection
Depth of data, behavioural detection, the quality of context for the analyst.
Investigation
The triage workflow, threat hunting, historical data, day-to-day usability.
System coverage
Windows, Linux, macOS, servers, virtual desktops, offline behaviour.
Resilience
Agent protection, health monitoring, exclusions governance, deployment constraints.
Operations
Integrations, licensing, operational complexity — whether the team can work with the system every day.
The last question is critical: a strong platform that cannot realistically be operated in production is not a good endpoint security solution.
What good endpoint security means
It cannot be judged by the number of detections or a neat technique coverage map.
And all of it has to work on the customer’s real operating systems, applications and workloads — not only in the datasheet.
Any other questions? We will definitely answer!
Didn't find the answer to your questions? Send your question below and our support team will answer it soon. We are here to help you with cybersecurity!
Ask a question!
Get a consultation!
If you want to learn more about our cybersecurity services or are not sure which solutions are right for you, leave a request and our specialists will contact you for a free consultation.
Related solutions
Complementary solutions for comprehensive infrastructure protection and a higher overall level of information security.
SIEM
Feeding endpoint telemetry into a single monitoring and investigation process.
PAM
Control of privileged access to the systems the protection runs on.
Vulnerability & Patch Management
Remediation of vulnerabilities on the same endpoints and servers.