Does Your Antivirus Satisfy NIS2 Article 21(2)(e)? Why EDR and XDR Are Becoming the Endpoint Security Baseline

Article 21(2)(e) of the NIS2 Directive requires essential and important entities to secure the acquisition, development, and maintenance of their network and information systems — including how they handle vulnerabilities. It never mentions the words “antivirus,” “EDR,” or “XDR.” That silence is deliberate: the Directive is technology-neutral by design. But it creates a real problem for compliance officers walking into an audit with a decade-old signature-based antivirus deployment and nothing else — because the technical rules that sit underneath Article 21(2)(e) increasingly point in one direction, and it is not the direction most legacy AV contracts were written for.

This guide covers what Article 21(2)(e) and its implementing technical rules actually require for endpoint security, why legacy antivirus struggles against the attack techniques regulators are now naming explicitly, where XDR and managed EDR fit for teams that cannot staff a 24/7 SOC, and the one category of endpoint — industrial control systems — where none of this applies the way vendors claim it does.

Does This Apply to Your Organisation?

In plain terms: if you are an essential or important entity under NIS2, Article 21(2)(e) applies to you directly, in every sector. A narrower set of technical rules — Commission Implementing Regulation (EU) 2024/2690 — only formally binds a specific list of digital-infrastructure providers, but its Annex is the closest thing to an official answer on what “good” endpoint security looks like, and auditors elsewhere use it as a benchmark even where it does not legally apply.

Entity type	Art. 21(2)(e) applies?	CIR 2024/2690 Annex 6.9 formally binding?
DNS providers, TLD registries, cloud, data centre, CDN providers	Yes	Yes
Managed service providers & managed security service providers	Yes	Yes
Online marketplaces, search engines, social networking platforms	Yes	Yes
Trust service providers	Yes	Yes
Manufacturing, energy, health, transport, water, and every other Annex I/II sector not listed above	Yes	No — not legally bound, but treated as sector benchmark[2]

What Article 21(2)(e) Actually Requires

The Directive text is short. Article 21(2)(e) requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”^[1]. Read on its own, that sentence says nothing about endpoints specifically — it is a lifecycle requirement covering how systems get built, changed, and patched.

Commission Implementing Regulation (EU) 2024/2690 turns that lifecycle requirement into ten numbered technical controls for the specific entity types it binds, and point 6.9 is the one that lands squarely on endpoints: entities must implement controls to detect or prevent the use of malicious or unauthorised software, and — where appropriate — deploy detection and response mechanisms, alongside measures like minimising attack surface and controlling which applications can execute on an endpoint^[2]. Point 6.10, immediately after it, covers the “vulnerability handling and disclosure” half of the same Article 21(2)(e) sentence.

The phrase that matters is “where appropriate.” Neither the Directive nor the Implementing Regulation names EDR or XDR as mandatory products. What they require is a control that can detect and respond to malicious or unauthorised software on an endpoint, proportionate to your risk profile. In practice, that requirement has become very hard to satisfy with signature-matching alone — not because a regulator said so, but because of how modern attacks actually behave, which is the next section.

CIR 2024/2690 Annex point	Topic	NIS2 Article 21(2)(e) link
6.6	Security patch management	Maintenance of systems
6.9	Protection against malicious and unauthorised software	Endpoint detection and response controls
6.10	Vulnerability handling and disclosure	Explicit Art. 21(2)(e) wording

Why Legacy Antivirus Fails the Audit — Not the Law

Traditional antivirus works by comparing files against a database of known-bad hashes and code patterns. It is fast, cheap, and still catches the bulk of commodity malware. Its blind spot is anything that does not look like a file at all: attackers logging in with stolen but valid credentials, then using tools already installed on the machine — PowerShell, WMI, PsExec — to move around the network. Security agencies call this “living off the land,” and a joint CISA/FBI/Five Eyes advisory singled it out precisely because it evades signature-based defences: nothing novel or malicious gets written to disk, so there is nothing for a hash-matching engine to flag^[3].

EDR closes that gap by watching behaviour instead of files — process trees, parent-child relationships, network connections, registry and file-system changes — and flagging patterns that deviate from an endpoint’s normal baseline^[7]. That is also why an auditor reviewing your Article 21(2)(e) evidence file will ask a different question than “do you have antivirus?” They will ask whether you can detect and respond to an attacker who is already past the front door, because that is the scenario point 6.9 is actually written for.

XDR: The Efficiency Play, Not a Separate Requirement

XDR is not a new legal category — it is an operational upgrade to the same 6.9 control. Where EDR correlates telemetry from endpoints only, XDR pulls in signals from email, identity, network, and cloud workloads and correlates them into a single incident instead of a dozen disconnected alerts. For a compliance officer building the evidence file, the practical value is fewer false positives per analyst and a shorter path from “something looks odd” to “here is the incident timeline,” which matters directly for your Article 23 notification clock once an incident is confirmed^[1]. It does not change what Article 21(2)(e) requires; it changes how efficiently a small security team can meet it, which matters most for entities without a dedicated detection engineering function.

Managed EDR: The MSSP Route When You Cannot Staff a SOC

For an SME owner, this is the section that matters most. EDR technology alone does not satisfy point 6.9 — someone has to watch the alerts and act on them, and doing that around the clock in-house is expensive. Industry cost data consistently puts a staffed, 24/7 in-house SOC in six-to-seven-figure annual territory once analysts, tooling, and shift coverage are counted^[8]; that is out of reach for most entities newly in scope under NIS2’s broadened Annex I/II thresholds.

Managed EDR — sold under names like MDR, SOCaaS, or bundled into an MSSP contract — is the practical substitute: the vendor supplies the EDR/XDR platform and the 24/7 analyst team that triages and responds to what it flags. From an audit-evidence standpoint, a signed MSSP contract with defined detection and response SLAs is a stronger Article 21(2)(e) artefact than an unmonitored EDR licence sitting on a shelf, because point 6.9 is about detection and response, not detection alone. If you are already routing incident notification through a managed provider, extending that relationship to cover endpoint monitoring closes an obvious gap in the same contract.

OT Endpoints: Where PLCs and RTUs Break the EDR Model

Everything above assumes an endpoint that can run an agent. Programmable logic controllers, remote terminal units, and legacy human-machine interfaces frequently cannot: they run proprietary firmware, have no spare CPU or memory headroom, and vendor warranties often explicitly prohibit installing third-party software on the device. Manufacturing entities carry the most exposure here — Dragos’s 2026 OT Cybersecurity Year in Review recorded 119 ransomware groups affecting 3,300 industrial organisations in 2025, a 49% increase on 2024, with manufacturing accounting for more than two-thirds of all OT ransomware victims^[6].

The compensating control is not “install EDR anyway” — it is network-based visibility that never touches the device: passive monitoring of industrial protocol traffic, protocol-aware anomaly detection, and segmentation that keeps a compromised endpoint from reaching the rest of the OT network^[5]. This lines up with a joint US government guide published in April 2026, which frames Zero Trust for OT around zoning, conduits, and identity controls precisely because agent-based tooling cannot be assumed to exist on the shop floor^[4]. Where an engineering workstation or HMI can run an agent, treat it as an IT endpoint for 6.9 purposes; where it cannot, your evidence file should point to the network-monitoring control instead, with a documented justification — the manufacturing sector guide covers this scoping decision in more depth. Do not accept a vendor’s claim that a lightweight agent is “safe for legacy PLCs” without a written compatibility statement from the equipment manufacturer.

Coverage Percentage as an Audit Metric

For the compliance officer building the audit trail: “we have EDR” is not evidence; a coverage percentage is. Detection coverage — the share of in-scope endpoints running an active, current EDR agent, divided by the total inventory of in-scope endpoints — is the practitioner metric auditors most often ask for^[8], but be clear internally that no NIS2 article or CIR annex sets an official coverage threshold. There is no regulatory number to hit; there is a documentation expectation to meet.

Three things make that number defensible on paper: an asset inventory that is reconciled at least quarterly (so “100% coverage” is not measured against a stale list), an explicit list of exclusions with the compensating control noted against each one — OT devices routed to network monitoring, for instance — and a trend line, not a single snapshot, since auditors read a coverage percentage that has been falling for six months very differently from one that has been rising. Mapping detection rules against a recognised framework such as MITRE ATT&CK, rather than just counting installed agents, is emerging as the more rigorous version of this exercise, though it remains a voluntary best practice rather than a directive requirement.

Closing the Gap: A Practical Path

Most entities sit somewhere between “antivirus only” and “fully monitored XDR,” and the jump between the two is not a single project.

Current state	Target state (Art. 21(2)(e))	Effort
Signature-based antivirus, no central console	Managed EDR with 24/7 triage	High
Unmanaged EDR licence, alerts unreviewed	Contracted MDR/MSSP with response SLA	Medium
EDR on IT endpoints only, OT unmonitored	Passive network monitoring added for OT/ICS	Medium
EDR deployed, no coverage tracking	Quarterly coverage % reconciled against asset inventory	Low

Role	Responsibility
CISO / IT Security Manager	Selects EDR/XDR platform, defines detection use cases, owns OT network-monitoring architecture
Compliance Officer	Maintains coverage percentage evidence, exclusion register, and MSSP contract SLAs for audit
IT / Operations	Keeps asset inventory current; flags new endpoints and decommissions for coverage tracking
Board / Management	Approves MDR/MSSP budget as a proportionate Art. 21(2)(e) control, not a discretionary IT purchase

Patch management and vulnerability disclosure sit right next to this control in both the Directive text and the CIR Annex — see the vulnerability and patch management guide and the Article 25 vulnerability disclosure guide for the other half of what Article 21(2)(e) expects.

Frequently Asked Questions

Does NIS2 legally require EDR by name?
No. Article 21(2)(e) requires proportionate security measures for systems maintenance and vulnerability handling; CIR 2024/2690 point 6.9 requires malware detection and response “where appropriate,” without naming a product category. EDR and XDR are the current practical way most organisations satisfy that requirement, not a named legal mandate.

Is my organisation bound by CIR 2024/2690 if I am not a cloud, DNS, or MSSP provider?
No, not formally. The Implementing Regulation’s technical Annex only binds the specific digital-infrastructure entity types listed in its Article 1. Everyone else is bound by Article 21(2)(e) directly, and most auditors use the CIR Annex as an interpretive benchmark rather than a checklist you are legally required to follow line-for-line.

Can XDR replace EDR entirely?
XDR is built on top of EDR telemetry, not a replacement for it — you still need endpoint agents collecting the underlying data. XDR is the correlation and response layer across endpoints, network, identity, and email; without EDR at the endpoint, there is no endpoint signal to correlate.

What if a device genuinely cannot run any agent?
Document why (firmware limitations, vendor warranty restriction, no vendor compatibility statement), then apply a compensating control — typically passive network monitoring and segmentation — and record that decision as your Article 21(2)(e) risk treatment for that asset class. An undocumented gap is an audit finding; a documented, justified exception is a risk-based decision.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS 2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
2. Commission Implementing Regulation (EU) 2024/2690, Article 1 and Annex Section 6 — EUR-Lex
3. CISA, FBI, and international partners, “Identifying and Mitigating Living Off the Land Techniques” — cisa.gov
4. CISA and US government partners, “Adapting Zero Trust Principles to Operational Technology” (April 2026) — cisa.gov
5. Nozomi Networks, “Zero Trust in OT” — nozominetworks.com
6. Dragos, 2026 OT Cybersecurity Year in Review — dragos.com
7. Red Canary, “EDR vs. antivirus: What’s the difference?” — redcanary.com
8. Industry practitioner sources on detection coverage and MDR/SOC cost benchmarking — PureDome, Corsica Technologies