Endpoint Detection and Response for Crypto and Web3 Firms

The debate about smart contract security has dominated the Web3 security conversation for years, and rightly so. Smart contract vulnerabilities have caused billions in losses. But the conversation has created a blind spot. Developers write smart contracts on physical devices. Signers authorise transactions from physical devices. Credentials, seed phrases, and API keys are accessed, copied, and pasted on physical devices. The endpoint, the laptop or workstation used by every employee, is where the human layer of your security posture meets the technical layer. And in the vast majority of serious crypto compromises, the endpoint was either the primary target or an enabling vector.

Endpoint detection and response (EDR) is the operational control that addresses this reality. It is not antivirus in a new package. It is a continuous monitoring and response capability that watches what devices are actually doing, detects behavioural anomalies that indicate compromise, and gives security teams the ability to investigate and respond in real time. For crypto firms, it is not optional infrastructure. It is a core operational requirement.

Why Endpoint Security Matters in Crypto

Every meaningful action in a crypto organisation ultimately passes through a device. A trader executes a transaction from a workstation. A developer pushes code from a laptop. A signer approves a multi-signature withdrawal from a dedicated machine. The keys, credentials, and authorisation actions that control billions of pounds in digital assets exist, even briefly, on physical hardware. Attackers understand this. Endpoint compromise is not a secondary concern in crypto security; it is increasingly the primary attack surface.

Endpoints as the Primary Social Engineering Target

Social engineering attacks, whether phishing, spear-phishing, or pretexting, require delivery to a device. A malicious email attachment executes on the target's laptop. A fake browser extension installs in their Chrome profile. A compromised npm package runs during a developer's build process. The social engineering is the initial vector; the endpoint is where the payload lands and where the damage begins. Organisations that invest heavily in network perimeter controls but neglect endpoint monitoring are defending the wrong boundary.

Crypto firms are disproportionately targeted because of asset value and because the sector's culture of open collaboration, developer tool sharing, and remote work creates a rich environment for social engineering. Teams are often distributed across multiple countries. Employees may use personal devices for work tasks. Contractors and freelancers access systems from unmanaged hardware. Each of these patterns expands the endpoint attack surface.

Developer Machine Compromises and Supply Chain Risk

Developer workstations in crypto firms carry a specific and elevated risk profile. A developer's machine typically has access to private repositories, staging environments, package signing keys, and internal tools. If an attacker compromises a developer's machine, they may be able to introduce malicious code into a project, clone private repositories, or pivot to other internal systems. The 2021 SolarWinds compromise, though not crypto-specific, demonstrated precisely how a developer environment breach could cascade into a supply chain attack affecting thousands of downstream organisations.

In the Web3 context, a compromised developer machine could enable: malicious changes to smart contract code before deployment; theft of private keys stored in local environment variables or configuration files; credential theft enabling lateral movement to cloud infrastructure or CI/CD pipelines; and modification of deployment scripts to redirect funds to attacker-controlled addresses. EDR monitoring on developer machines is accordingly among the highest-value investments a crypto firm can make.

The Bybit Hack: Endpoint Compromise in Practice

The Bybit hack of February 2025, attributed to the Lazarus Group, is the most instructive recent example of endpoint-targeted attack against a major crypto firm. Lazarus did not attack the blockchain. They did not exploit a smart contract vulnerability. They targeted the Safe{Wallet} signing interface used by Bybit personnel, through a compromise of the developer machines used by Safe's development team. The result was that legitimate-looking transactions, visually indistinguishable from normal operations, were presented to Bybit signers for approval. The attack bypassed the cryptographic safeguards of the multi-signature architecture by compromising the devices and software interfaces through which signers interacted with the wallet. Approximately 1.5 billion dollars in digital assets were lost.

This attack makes the operational case for EDR with absolute clarity. The question is not whether your smart contract is secure. The question is whether you would detect a compromise of the devices used to interact with it.

"Lazarus Group did not attack the blockchain. They attacked the laptops. Endpoint detection and response is the control that catches this class of threat before transactions are signed."

Remote Work and BYOD Risks in Web3 Teams

Web3 organisations are among the most remote-native in the technology sector. Teams frequently operate across multiple continents, with employees working from home offices, shared workspaces, and travel environments. Bring-your-own-device (BYOD) policies are common, particularly for contractors and early-stage teams. Remote and BYOD environments significantly complicate endpoint security. Devices that are not organisation-managed cannot have EDR agents deployed without user cooperation. Devices that are used for personal activities alongside work carry additional exposure from personal browsing, personal email, and non-work software. Every unmonitored device that has access to organisational systems is a gap in endpoint visibility.

What Is Endpoint Detection and Response?

Endpoint detection and response (EDR) is a category of security tooling that monitors devices continuously, collects telemetry about process activity, file system changes, network connections, registry modifications, and user behaviour, and applies behavioural analytics to detect threats. It differs fundamentally from traditional antivirus in both approach and capability.

EDR vs Traditional Antivirus

Traditional antivirus operates primarily through signature matching. It maintains a database of known malware signatures and scans files for matches. This approach is effective against known, static malware but fails against novel threats, fileless attacks, and living-off-the-land (LotL) techniques where attackers use legitimate system utilities such as PowerShell, WMI, or Python to execute malicious actions. A sophisticated attacker can trivially evade signature-based detection by modifying their payloads or using legitimate tools entirely.

EDR takes a behavioural approach. Rather than asking "does this file match a known bad signature?", EDR asks "is this process behaving in a way that suggests malicious intent?" A process that spawns a child process, makes unusual API calls, reads the clipboard repeatedly, or establishes an outbound connection to an unusual IP address will trigger behavioural detection even if the process itself has never been seen before. This is the capability that catches novel malware, zero-day exploits, and advanced persistent threat (APT) tradecraft.

Continuous Monitoring and Telemetry Collection

EDR agents run continuously on monitored devices and stream telemetry to a central platform. This telemetry includes process creation events, network connection logs, file read and write operations, registry changes on Windows systems, user logon and logoff events, and device configuration changes. The volume of data collected is significant. Modern EDR platforms apply machine learning and rule-based detection to this stream, surfacing alerts only where behaviour deviates meaningfully from a baseline. The underlying data is retained for retrospective investigation, enabling security analysts to reconstruct exactly what happened on a device in the period leading up to and following a security event.

Threat Hunting Capability

Beyond automated alerting, EDR provides threat hunting capability: the ability for security analysts to proactively query device telemetry to look for indicators of compromise (IoCs) or tactics, techniques, and procedures (TTPs) associated with known threat actors. Rather than waiting for an alert to fire, a threat hunter can search across the entire device fleet for specific behaviours, for example asking whether any device has executed a particular command, connected to a specific IP range, or accessed a sensitive file path in the past 30 days. This proactive capability is particularly valuable for detecting sophisticated attackers who operate quietly over extended periods before executing their objective.

XDR: The Evolution Beyond Endpoint

Extended detection and response (XDR) is the evolution of EDR that correlates telemetry across multiple security domains: endpoints, network, cloud, identity, and email. Where EDR sees only what is happening on a device, XDR can correlate an endpoint event with a concurrent network anomaly, a suspicious cloud API call, and an identity authentication event to build a richer picture of an attack. For crypto firms with cloud infrastructure, distributed teams, and complex authentication environments, XDR provides detection capability that single-domain EDR cannot match. Many leading EDR platforms now offer XDR capabilities as part of their product suite.

Crypto-Specific Endpoint Threats

Generic malware and ransomware affect all industries. The crypto sector additionally faces a category of threats specifically designed to target the ways in which crypto organisations operate. Understanding these threat types is essential for configuring EDR detections and building crypto-relevant response playbooks.

Clipboard Hijackers

Clipboard hijacking is one of the most operationally dangerous threats for crypto firms. Clipboard hijackers are malware components that monitor the system clipboard for content that matches cryptocurrency wallet address formats. When a user copies a wallet address to paste into a transaction, the hijacker silently replaces the copied address with an attacker-controlled address. Because wallet addresses are long, unintelligible strings that users typically do not verify character by character, the substitution goes unnoticed until the transaction is sent and the funds arrive at the wrong destination. Given that blockchain transactions are irreversible, a single clipboard hijack on a device processing a significant transaction can result in catastrophic loss. EDR detection rules should monitor for processes that register unusual clipboard access hooks or read clipboard contents at abnormal frequency.

Keyloggers Targeting Seed Phrase Entry

Hardware wallets require users to enter or verify seed phrases on occasions such as device recovery or wallet initialisation. If a keylogger is active on the device at the moment seed phrase words are entered into any interface, those words are captured. Even if the hardware wallet's secure element protects keys at rest, the act of entering seed phrases on a compromised device exposes them. Keyloggers in the crypto context are often targeted rather than opportunistic: threat actors compromise a device and then wait for the moment when sensitive material is entered. EDR monitoring for unexpected keyboard hook APIs and process injection into browser or wallet application processes is the detection layer for this threat.

Cryptostealers

Cryptostealers are a broad category of information-stealing malware specifically designed to identify and exfiltrate crypto-relevant data from compromised devices. This includes: browser-stored credentials and session cookies for exchange accounts; wallet files and private key stores from software wallets; configuration files containing API keys for exchange integrations; SSH keys that may provide access to infrastructure; and environment variable files (.env) that are commonly used in developer workflows to store credentials. Cryptostealers have become increasingly common and are regularly distributed via malicious browser extensions, fake software downloads, cracked applications, and trojanised tools distributed on developer forums and Discord servers.

Browser Extension Malware

Browser extensions present a specific and underappreciated endpoint risk in the crypto context. Malicious extensions can access page content from every website visited, read and modify clipboard contents, capture authentication tokens and session cookies, and inject malicious JavaScript into web pages including exchange interfaces and Web3 DApp frontends. The 2023 Ledger Connect Kit compromise, in which a supply chain attack injected malicious code into a widely-used Web3 wallet connection library, demonstrated how the browser extension and JavaScript dependency surface can serve as an attack vector against users across multiple platforms simultaneously. EDR monitoring should include policies for detecting unexpected browser extension installations and for flagging extensions with unusual permission scopes.

Malicious npm Packages on Developer Machines

The JavaScript and Node.js ecosystem, fundamental to most Web3 development, has a persistent supply chain compromise problem. Threat actors publish malicious packages to npm using names that closely resemble legitimate, widely-used packages (typosquatting), or they compromise the accounts of legitimate package maintainers to insert malicious code into established packages. When a developer installs or updates a compromised package, the malicious code executes with the full privileges of the developer's account. This can result in environment variable exfiltration, credential theft, or the establishment of remote access. EDR monitoring for unexpected outbound connections during package installation workflows, and for processes spawning from npm install or yarn commands, is an important detection layer for developer machines.

Fake Job Offer PDFs and Spear-Phishing Payloads

Lazarus Group has extensively used fake job offers and recruiter outreach as a social engineering vector against crypto professionals. The pattern is consistent: a target receives a message via LinkedIn or Telegram purportedly from a recruiter at a well-known firm, is sent a PDF or document containing a job description, and the document carries a malicious payload that executes on opening. In some documented cases, the payload was a staged attack that first established persistence and then waited for a subsequent stage to be delivered. Security awareness training addresses the human layer, but EDR provides the technical backstop: process spawn chains from PDF readers or document applications should be treated as high-priority alerts requiring immediate investigation.

EDR Deployment Considerations for Crypto Firms

Deploying EDR is not simply a matter of purchasing a licence and installing agents. A successful EDR programme requires planning for agent deployment methodology, operating system coverage, device scope decisions, and the management model for the EDR console itself.

Agent-Based vs Agentless Deployment

Most enterprise EDR platforms use an agent-based deployment model: a lightweight software agent is installed on each monitored device and runs continuously in the background. The agent is the source of telemetry and the mechanism through which response actions are executed. Agentless approaches, used by some cloud-native platforms, collect telemetry through hypervisor or cloud API integration rather than a local agent, but these are typically limited to virtual machine environments and provide less endpoint visibility than agent-based solutions. For crypto firms managing physical devices (laptops, workstations, signing devices), an agent-based deployment is the appropriate choice.

Operating System Coverage

Crypto and Web3 teams typically operate a mixed operating system environment. Windows remains common in corporate functions, while developers frequently use macOS and Linux. All three platforms must be covered. EDR platforms vary in their quality of macOS and Linux support: some vendors offer near-parity across platforms, while others have significantly weaker capability on non-Windows systems. When evaluating EDR platforms, security teams should explicitly test macOS and Linux agent functionality, particularly for the detection use cases most relevant to crypto developer workflows.

Linux coverage is particularly important for firms running self-hosted nodes, validators, or infrastructure servers. These systems are frequently targeted by threat actors looking to compromise node operations, steal validator keys, or pivot to internal networks. An EDR or workload protection agent on Linux servers significantly improves detection capability for server-side compromises.

Contractor Device Policy

Web3 firms make extensive use of contractors, freelancers, and external developers. These individuals may never agree to having an EDR agent installed on their personal devices, and in many jurisdictions there are employment law and privacy considerations that complicate mandatory agent deployment on personal hardware. The appropriate policy depends on the nature of the contractor's access. Contractors with access only to low-risk systems and no access to key material or source code may be managed through network segmentation and access controls alone. Contractors with privileged access should be required to use organisation-provided or organisation-managed devices with EDR deployed, or access systems through a virtual desktop infrastructure (VDI) environment where endpoint telemetry is collected at the server rather than the contractor's personal device.

Performance Impact on Developer Workstations

Developer workstations are resource-intensive environments. Compilation tasks, virtual machine execution, and containerised development workflows place significant demands on CPU and memory. Some EDR agents have historically had a reputation for performance impact, particularly during file scanning intensive operations. When selecting an EDR platform for a development-heavy organisation, performance should be evaluated explicitly. Most modern EDR platforms have substantially reduced their performance footprint compared to early generations of the technology, but the impact should be measured in the organisation's specific development environment before committing to a platform at scale. Developer buy-in is more easily maintained when the security tooling does not tangibly slow their workflow.

Cloud-Managed vs On-Premises Console

Most commercial EDR platforms now operate on a cloud-managed model: the EDR console, alert management, and threat intelligence are hosted by the vendor, and the organisation connects to the cloud platform to manage policy and respond to alerts. Cloud-managed EDR reduces infrastructure overhead and ensures that threat intelligence feeds and detection rules are updated continuously. On-premises EDR console deployment is available from some vendors but is typically chosen only by organisations with strict data sovereignty requirements or regulatory obligations that prevent telemetry from leaving specific jurisdictions. For most crypto firms, cloud-managed EDR is the appropriate default choice.

Configuring EDR for Crypto-Relevant Detections

An EDR platform deployed with default configuration provides meaningful baseline protection. However, the full value of EDR for a crypto firm requires custom detection rules and policies tailored to the specific threats and workflows of the organisation. This is the configuration layer that separates a capable EDR deployment from a genuinely crypto-aware one.

Custom Detection Rules for Crypto-Relevant Events

Out-of-the-box EDR detections focus on generic threat behaviours. Crypto-specific custom rules should target:

• Clipboard monitoring events. Flag processes that register persistent clipboard change listeners or read clipboard content at intervals inconsistent with user-driven paste operations. This catches clipboard hijackers before they have the opportunity to substitute wallet addresses.
• Unexpected process spawning from browser or PDF applications. A browser or PDF reader spawning a command shell, PowerShell instance, or network utility should be treated as a critical alert. This is the characteristic behaviour of malicious document payloads and browser-based exploitation.
• Outbound connections to known command-and-control infrastructure. Integrate threat intelligence feeds (discussed below) and alert on any outbound connection to known C2 IP ranges or domains, particularly from developer machines and signing devices.
• Credential access patterns. Alert on access to common credential storage locations: browser password databases, system keychain files, .env files in code directories, SSH private key files, and hardware wallet interface processes. Legitimate access to these locations is predictable and infrequent; unexpected access warrants investigation.
• Abnormal npm or pip package installation behaviour. Alert on package manager processes that make outbound connections to non-standard registries, execute shell commands post-install, or spawn child processes with network access. This catches malicious package execution during dependency installation workflows.
• Access to hardware wallet interfaces. Monitor for unexpected processes attempting to communicate with hardware wallet USB interfaces. Legitimate wallet software is predictable; unexpected process access to these interfaces may indicate trojanised wallet software.

Threat Intelligence Integration

EDR platforms support the ingestion of external threat intelligence feeds, which provide indicators of compromise: IP addresses, domains, file hashes, and URLs associated with known malicious infrastructure. For crypto firms, this should include feeds specifically covering the crypto threat landscape: Lazarus Group infrastructure, cryptocurrency exchange-targeting malware families, and the command-and-control infrastructure used by prominent cryptostealers. Cyber threat intelligence integration transforms generic EDR capability into a detection layer that is calibrated specifically to the threats most likely to target your organisation. Leading EDR platforms support STIX/TAXII feed ingestion as well as proprietary threat intelligence APIs.

Exclusion and Tuning Policy

EDR configurations require careful exclusion management. Overly broad exclusions, created to suppress noisy alerts from legitimate developer tools, create detection gaps that attackers can exploit. Exclusions should be as narrow as possible: scoped to specific file paths, specific processes, and specific behaviours rather than broad directory exclusions. Every exclusion should be documented with a business justification and reviewed on a regular cadence. Exclusion management is an underappreciated component of EDR operations; poorly maintained exclusion lists are a common finding in security assessments of organisations that believe their EDR is configured adequately.

Alert Triage and Response for Crypto Firms

An EDR platform generates alerts continuously. The operational challenge is not deploying the technology but managing the alert stream effectively. Alert fatigue, where security teams are overwhelmed by alert volume and begin missing or dismissing critical alerts, is one of the most common failure modes in EDR programmes. Effective alert triage requires a defined classification framework, clear escalation paths, and response playbooks calibrated to crypto-relevant scenarios.

Managing Alert Fatigue

Alert fatigue develops when an EDR deployment generates a high volume of false positives or low-severity notifications that require regular dismissal. Security analysts, particularly in small crypto firms without a dedicated security operations team, quickly learn to treat the EDR console as background noise. The remedy is not to reduce alert sensitivity but to tune it: identify the specific alert types that consistently generate false positives for your environment, understand why they are firing, and adjust detection rules or exclusions to eliminate the noise while preserving detection capability for genuine threats. This tuning work is iterative and should be ongoing rather than a one-time post-deployment activity.

Severity Classification for Crypto-Relevant Events

Severity classification should reflect the potential business impact for a crypto firm, not generic IT severity labels. An alert indicating a process accessing a seed phrase storage location on a developer machine should be treated as critical regardless of how the EDR platform's default severity classification rates it. Define a severity escalation matrix that maps EDR alert types to business risk levels in the context of your organisation's specific asset profile, key management arrangements, and team structure. Events that could indicate imminent key compromise or active transaction manipulation should be escalated immediately to senior security personnel and, depending on the severity, to the CISO and executive team.

Incident Response Playbooks for Compromised Developer Machines

Incident response for a compromised developer machine in a crypto firm requires more than the standard IR steps. In addition to standard containment, eradication, and recovery procedures, the response must address: immediate review of any code changes pushed from the compromised machine since the estimated time of compromise; audit of any credentials or API keys that may have been accessible on the device; assessment of whether any transactions were initiated or signed from the device during the compromise window; and notification procedures for downstream systems and users that may have been affected by supply chain exposure. These steps should be documented in a playbook specific to developer machine compromise scenarios, reviewed and tested regularly.

Isolation Procedures That Preserve Forensic Evidence

When EDR identifies a compromised device, the immediate response instinct is to wipe and rebuild. This is operationally efficient but destroys forensic evidence. Before any remediation action, the device should be isolated from the network (which EDR platforms can execute remotely without requiring physical access) and a forensic image or memory capture should be taken if the severity and available resources permit. EDR telemetry itself constitutes forensic evidence and will be available for retrospective analysis regardless of what happens to the device, but physical evidence may be required for law enforcement referrals or regulatory notifications. Define isolation and evidence preservation procedures before an incident occurs, not during one.

Privileged Device Security and PAW

Not all devices carry equal risk. Devices used by signers, key managers, and treasury personnel represent the highest-risk tier in a crypto firm's endpoint estate. These devices require additional security controls beyond standard EDR deployment.

Privileged Access Workstations for Signers and Key Managers

A privileged access workstation (PAW) is a dedicated, hardened device used exclusively for high-privilege activities. For a crypto firm, the signer's PAW is used only for reviewing and approving transactions; it does not browse the internet, receive email, run developer tools, or perform any other function. This single-purpose design dramatically reduces the attack surface. The device runs a minimal, hardened operating system configuration with all unnecessary services disabled, removable media blocked, and network access restricted to the specific endpoints required for signing operations. Privileged access management for crypto firms should incorporate the PAW model for any role that has the ability to initiate or authorise transactions above a defined value threshold.

Network Segmentation for High-Risk Devices

Privileged devices should sit in a separate network segment with strict firewall rules governing permitted communications. Outbound access should be whitelisted to the specific services required for the device's function; all other outbound traffic should be blocked. Inbound access from other internal network segments should similarly be restricted. This network segmentation ensures that a compromise of a lower-privilege device within the organisation cannot directly reach the privileged device network, reducing the blast radius of lateral movement attacks.

Removable Media and Screen Recording Controls

Privileged devices should have USB storage and removable media access disabled at the policy level to prevent data exfiltration and the introduction of malicious media. Screen recording, screen sharing, and remote desktop access should be disabled or strictly controlled on privileged devices. An attacker who has compromised another device within the organisation should not be able to use screen capture or remote access tools to observe what is happening on a signing workstation. These controls should be enforced through both MDM policy and EDR configuration, not merely through user guidance.

EDR Integration with the Security Operations Centre

EDR operating in isolation is valuable. EDR integrated into a broader security operations programme is transformatively more capable. The integration of EDR with SIEM, network monitoring, and threat hunting workflows is the difference between reactive incident response and proactive security operations.

Feeding EDR Alerts into SIEM

EDR platforms should forward alerts and telemetry to the organisation's security information and event management (SIEM) platform. This integration enables correlation between endpoint events and events from other sources: network logs, cloud infrastructure logs, identity provider authentication events, and application logs. A security operations centre that receives correlated alerts from both EDR and network monitoring can detect attack sequences that would be invisible to either system independently. A suspicious outbound connection detected by EDR, correlated with an unusual authentication event from the identity provider and an anomalous API call in the cloud logs, paints a far richer picture of a potential intrusion than any single data source could.

Correlation with Network Logs

EDR telemetry identifies what a process was doing on a device. Network logs show what traffic actually left the network boundary. These two data sources are complementary. A process that EDR identifies as suspicious may or may not have succeeded in exfiltrating data; network logs provide the answer. Conversely, network logs may show unusual outbound traffic that EDR telemetry can contextualise by identifying which process initiated the connection. This bidirectional correlation is a core capability of a mature security operations function and should be a design requirement when integrating EDR with network monitoring infrastructure.

Threat Hunting Workflows

Threat hunting is the proactive search for evidence of compromise in an environment where no alert has yet fired. EDR provides the telemetry that makes threat hunting possible. Regular threat hunting exercises should be conducted by security teams, using hypotheses derived from current threat intelligence: for example, "has any device in our fleet executed a process consistent with a Lazarus Group staging implant in the past 30 days?" These hunts validate the coverage of existing detection rules, identify gaps in monitoring, and occasionally uncover compromises that automated detection missed. For crypto firms with access to cyber threat intelligence covering the crypto threat landscape, threat hunting hypotheses should be derived from the most current TTPs observed in the sector.

Regular Endpoint Security Reviews

EDR programme effectiveness should be reviewed at regular intervals, at minimum quarterly. Reviews should cover: alert volume trends and false positive rates; coverage gaps (devices that should have agents but do not); detection rule performance; threat hunting outputs; and whether any incidents occurred that should have generated EDR alerts but did not. This review cadence ensures that the EDR programme adapts to changes in the threat landscape, the organisation's technology environment, and the lessons learned from past incidents.

Regulatory and Compliance Requirements

Endpoint security is increasingly addressed explicitly in the regulatory frameworks that govern crypto and financial services firms. Understanding the relevant requirements helps justify EDR investment internally and ensures that deployments are configured in a manner consistent with compliance obligations.

DORA ICT Risk Management Requirements

The Digital Operational Resilience Act (DORA), which applies to financial entities in the EU including many crypto asset service providers, establishes detailed requirements for ICT risk management. DORA Article 9 requires financial entities to implement protection and prevention measures for ICT systems, including endpoint security controls. Article 10 requires continuous monitoring of ICT systems to detect anomalous activity. These provisions, read together, create a regulatory expectation of continuous endpoint monitoring capability equivalent to what EDR provides. Firms subject to DORA that have not deployed EDR should treat this as a compliance gap as well as an operational risk.

ISO 27001 Annex A Controls

ISO 27001 Annex A.8.7 addresses protection against malware and requires organisations to implement detection, prevention, and recovery controls to protect against malware, combined with user awareness measures. Annex A.8.22 addresses filtering of web services and the associated monitoring of web activity from endpoints. A well-deployed EDR programme directly addresses both of these controls. For organisations pursuing ISO 27001 certification, EDR deployment and evidence of its operational management (alert review logs, tuning records, incident response outputs) constitutes important certification evidence.

MiCA Operational Resilience Requirements

The Markets in Crypto-Assets Regulation (MiCA) requires crypto asset service providers to implement operational resilience measures proportionate to the risks they face. Article 96 of MiCA requires CASPs to maintain ICT systems and security measures that ensure the integrity, authenticity, and confidentiality of data, and to report major security incidents to competent authorities. An effective EDR programme supports both the prevention objective (by detecting and stopping attacks before they succeed) and the incident detection objective (by providing timely alerting when security events occur). For CASPs building out their MiCA compliance programme, endpoint security should be a documented component of the ICT security control framework.

Frequently Asked Questions