Microsoft Defender and NIS2 Article 21(2): What Each Product Covers — and What It Doesn’t

Ask a Microsoft account rep whether Microsoft 365 E5 makes an organization NIS2 compliant, and the pitch is confident: the security stack “aligns with NIS2.” Ask which specific Defender product satisfies which of the ten measures in Article 21(2), and the answer turns vague fast. That’s not an accident — Microsoft’s own NIS2 guidance stays at the level of “Zero Trust principles” and Sentinel/XDR name-drops. It never states which product satisfies which clause.

Working through Article 21(2) letter by letter against the actual Microsoft Defender product documentation turns up a pattern most SOC teams will recognize: the detection tooling is genuinely strong, but it covers roughly four of the ten measures. The other six are policy documents and processes that no software license writes for you. This article maps exactly which Defender product covers which Article 21(2) letter — quoting the product documentation directly — and names the measures a Defender deployment doesn’t touch at all.

Does Article 21(2) Apply to You?

Article 21(2) binds two categories of organization under NIS2: Essential entities and Important entities, determined by sector and size under the Directive’s scope rules. If an organization falls into either bucket, Article 21(1) requires “appropriate and proportionate technical, operational and organisational measures” sized to actual risk exposure, cost, and the state of the art — not a one-size-fits-all checklist.

The measures aren’t optional once scope is confirmed. Non-compliance with Article 21 carries fines of up to EUR 10 million or 2% of global annual turnover for Essential entities, and up to EUR 7 million or 1.4% of turnover for Important entities — whichever figure is higher in each case. Enforcement is no longer theoretical: compliance trackers report early fines already issued in Belgium, Italy, Hungary, Lithuania, and — as recently as February 2026 — a EUR 120,000 fine against a French DNS provider for late incident notification, though these figures are self-reported aggregates rather than an official EU register.

The Ten Article 21(2) Measures — Where Microsoft Defender Actually Lands

Article 21(2) lists ten minimum categories, from risk-analysis policy through multi-factor authentication. The full breakdown of all ten, with CIR 2024/2690 sub-requirements, is covered separately — the table below focuses on one question competitors and Microsoft itself both dodge: which of the four Defender products actually reaches which letter, and where the reach stops.

Defender Product	Article 21(2) Letter(s)	What It Actually Covers	Where Coverage Stops
Defender for Endpoint	(b) Incident handling; (e) vulnerability handling (partial)	EDR, automatic attack disruption, ransomware prevention, attack surface reduction	Doesn’t write the incident-response policy or file the regulatory notification
Defender for Identity	(i) Access control (partial); (j) MFA/authentication (detection, not enforcement)	Detects credential compromise, lateral movement, domain dominance; identity posture scoring	Doesn’t enforce MFA itself — that’s Microsoft Entra ID’s job, not Defender’s
Defender for Cloud Apps	(d) Supply chain security (SaaS/OAuth layer only)	Discovers shadow SaaS, scores app risk, governs OAuth app permissions	Doesn’t cover direct-supplier contracts, hardware supply chain, or on-prem vendor risk
Defender Vulnerability Management	(e) Security in systems acquisition, development, maintenance	Continuous asset discovery, CIS/STIG baseline assessment, risk-based patch prioritization	Doesn’t cover secure-development-lifecycle policy or acquisition due diligence

Defender for Endpoint: Incident Handling and the 72-Hour Clock

Article 21(2)(b) requires “incident handling” as a standing capability, not a one-time plan. Microsoft Defender for Endpoint is the piece of the stack that actually does this work: it correlates endpoint signals into the unified Defender portal, applies automatic attack disruption to contain active threats, and layers next-generation protection and attack surface reduction rules on top of a traditional antivirus baseline. This is genuinely strong ground for (b).

The mechanism worth understanding is how detection speed connects to a separate legal clock. Once an organization becomes aware of a significant incident, Article 23 starts a 24-hour early-warning deadline, a 72-hour notification deadline, and a one-month final-report deadline. Defender for Endpoint doesn’t file any of those reports — but its correlated-incident view is usually what determines the exact moment an organization can be said to have “become aware,” which is the trigger the clock runs from. Faster, better-correlated detection doesn’t shrink the legal deadline; it just gives the compliance team more of the 24 hours to actually use.

Defender for Identity: Access Control and Authentication, With a Catch

Article 21(2)(i) covers human resources security, access control policies, and asset management; (j) covers multi-factor or continuous authentication. Microsoft Defender for Identity monitors on-premises Active Directory, Microsoft Entra ID, and third-party identity providers, mapping detections to specific attack stages: reconnaissance, credential compromise, lateral movement, and full domain-controller compromise. It also runs proactive identity posture assessments that surface risky configurations before an attacker finds them.

The catch: Defender for Identity is a detection and investigation layer, not the authentication mechanism itself. It tells a security team when MFA is being bypassed or credentials are being abused — it doesn’t enforce the MFA policy that satisfies Article 21(2)(j)’s authentication requirement, and it doesn’t write the access-control policy document an auditor will ask to see under (i). That enforcement and documentation sit with Microsoft Entra ID and with internal policy, respectively — a distinction most vendor comparisons blur.

Defender for Cloud Apps: Supply Chain Security, Narrowly Defined

Article 21(2)(d) requires supply chain security measures that account for “the vulnerabilities specific to each direct supplier or service provider.” Microsoft Defender for Cloud Apps addresses one real slice of that: it discovers shadow SaaS usage across the organization, scores discovered apps against more than 90 risk indicators, and governs OAuth apps that have been granted standing permissions into company data — the app-to-app relationships that traditional vendor-risk questionnaires never capture.

What it doesn’t reach is the rest of (d): the contractual security clauses with a hardware vendor, an on-premises software supplier, or a manufacturing subcontractor never touch Defender for Cloud Apps at all, because there’s no cloud app to discover. Treat Defender for Cloud Apps as covering the SaaS/OAuth corner of supply chain risk — real, underrated, and specific — not the whole of (d).

Defender Vulnerability Management: Systems Acquisition and Maintenance

Article 21(2)(e) covers “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” Microsoft Defender Vulnerability Management is built for the maintenance half of that: continuous, largely agentless asset discovery across software, certificates, hardware, firmware, and browser extensions, security baseline assessment against CIS and STIG benchmarks, and risk-based prioritization that weighs Microsoft’s own threat intelligence and breach-likelihood modeling rather than raw CVSS scores alone.

That’s a genuinely strong answer to “how do we find and prioritize what to patch” — one of the more detailed patch-management sub-requirements under CIR 2024/2690. It is not an answer to the acquisition and development half of (e): nothing in Defender Vulnerability Management reviews a vendor contract before signature or enforces secure-coding standards on an in-house development team. Those need a documented secure development lifecycle, which is process, not a scan.

The Measures Defender Never Touches

This is the part of the mapping that vendor content routinely skips, because naming a gap doesn’t sell a license. Five of the ten Article 21(2) measures have no meaningful Defender-product coverage at all:

Letter	Measure	What Actually Closes It
(a)	Risk analysis and information system security policy	A documented risk methodology and register — a policy artifact, not a product
(c)	Business continuity, backup management, disaster recovery, crisis management	A continuity strategy, crisis management plan, and tested recovery procedure
(f)	Assessing the effectiveness of cybersecurity risk-management measures	A measurement methodology and a recurring assessment report — Defender dashboards show telemetry, not a documented effectiveness review
(g)	Basic cyber hygiene practices and cybersecurity training	A training plan and a hygiene policy your staff actually complete
(h)	Cryptography and encryption policy and procedures	A cryptographic controls policy defining algorithms, key management, and encryption scope

None of this means the Defender family is a weak purchase — its four products are genuinely strong at what they do. It means “we run Microsoft Defender” answers roughly four of ten letters, and an auditor working through Article 21(2) will still ask about the other five by name.

What an Auditor Still Wants to See

Regardless of which security stack sits underneath, a NIS2 audit trail is built from documents, not dashboards. At minimum, expect a competent authority or auditor to ask for: a risk assessment methodology and current risk register; an incident handling policy naming who declares a “significant incident” and starts the Article 23 clock; a business continuity and crisis management plan that’s been tested, not just written; a supply chain security policy covering suppliers a CASB will never see; and a cryptography policy stating which encryption standards apply where. A Defender deployment can supply the technical evidence behind several of these documents — screenshots of posture scores, remediation logs, detection timelines — but it cannot replace the document itself.

Frequently Asked Questions

Does Microsoft 365 E5 make an organization NIS2 compliant on its own?
No. E5 licensing bundles Defender for Endpoint, Identity, and Cloud Apps, which — per the mapping above — reach into roughly four of the ten Article 21(2) measures. The remaining measures require policy documentation and processes that exist independently of any license tier.

Which Defender product matters most for NIS2 incident-notification deadlines?
Defender for Endpoint and Defender XDR’s correlated incident view are what typically establish the moment an organization “became aware” of a significant incident — the trigger for Article 23’s 24-hour and 72-hour deadlines. Neither product files the notification; that remains a manual, policy-driven step.

Is Defender for Cloud Apps required for NIS2 supply chain compliance?
It’s useful, not sufficient. It’s the right tool for SaaS shadow IT and OAuth app risk specifically. Article 21(2)(d) also covers direct suppliers with no cloud footprint at all — hardware vendors, on-premises software, manufacturing subcontractors — which a CASB was never built to see.

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.

Key Takeaways

Microsoft Defender’s four products are a real, verifiable answer to about four of Article 21(2)’s ten measures — strongest on incident handling, identity threat detection, SaaS-layer supply chain visibility, and vulnerability prioritization. They are not an answer to risk-analysis policy, business continuity planning, effectiveness assessment, cyber hygiene training, or cryptography procedure — measures that stay on the organization’s desk regardless of license tier. Treat the mapping above as a gap list, not a compliance certificate: close the technical four with configuration, and close the other six with the documents an auditor will actually ask to read.

Sources

1. NIS 2 Directive, Article 21 — Cybersecurity risk-management measures (nis-2-directive.com)
2. NIS 2 Directive, Article 23 — Reporting obligations (nis-2-directive.com)
3. NIS 2 Directive, Article 34 — Administrative fines (nis-2-directive.com)
4. Microsoft Defender for Endpoint — Microsoft Learn
5. Microsoft Defender for Identity Overview — Microsoft Learn
6. Overview — Microsoft Defender for Cloud Apps — Microsoft Learn
7. Microsoft Defender Vulnerability Management — Microsoft Learn
8. Navigating NIS2 requirements with Microsoft Security solutions — Microsoft Security Blog
9. NIS2 Enforcement Tracker 2026 — Legiscope (directional/self-reported data, not an official EU register)