Azure NIS2 Compliance: Mapping Defender for Cloud, Policy, PIM, and Key Vault to Article 21(2)

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.

Does This Apply to You? Azure Customers vs. Microsoft as a Cloud Provider

Two separate NIS2 obligations sit on top of the same Azure subscription, and conflating them is the single most common scoping mistake in this area. Commission Implementing Regulation (EU) 2024/2690 (“CIR 2024/2690”) directly and mandatorily binds seven categories of digital-infrastructure entity without any national transposition step — and “cloud computing service providers” is one of them [2]. That means Microsoft, as the operator of Azure, carries its own CIR obligations for the infrastructure it runs. Your organisation, as a customer building on top of that infrastructure, is a separate legal actor under Article 21 of the NIS2 Directive (EU) 2022/2555 [1] — unless your own organisation independently qualifies as one of those seven digital-infrastructure categories, in which case CIR 2024/2690 applies to your systems directly, not “by analogy.”

Germany’s BSI — the national NIS2 competent authority responsible for most German essential and important entities — states this distinction plainly in its own NIS2 FAQ: “Auch wenn die IT komplett ausgelagert ist, bleiben Sie als besonders wichtige oder wichtige Einrichtung selbst verantwortlich” — even if IT is fully outsourced, the entity remains personally responsible [8]. A contract with Microsoft does not transfer your Article 21(2) obligation; it only changes who executes the underlying control. You still need the risk assessment, the policy documents, and the evidence trail with your organisation’s name on them.

Who	Governed by	What that means in practice
Microsoft (as Azure operator)	CIR 2024/2690, directly	Microsoft’s own security-of-service obligations for the Azure platform itself
Your organisation, if NIS2-scoped	Article 21(2), NIS2 Directive	Your own risk management measures for systems you run on Azure — CIR applies “by analogy” as good practice, not as a binding requirement, unless you are separately a digital-infrastructure entity
Your organisation, if also a CSP/MSP/DNS/trust-service provider	CIR 2024/2690, directly	Your own systems (which may run on Azure) face the same CIR Annex sections Microsoft does

The Azure-to-Article 21(2) Control Map

The table below is the core of this article: which Azure service maps to which Article 21(2) measure, and which CIR 2024/2690 Annex section defines the underlying control in enough detail to write an evidence document against. Every mapping is checked against the CIR’s own section numbering [3][4], not a vendor’s marketing claim.

Azure service	Article 21(2) measure	CIR 2024/2690 section	What it actually gives you
Azure Policy	(a) risk analysis & information system security policies	Sections 1–2 (security policy, risk management)	Enforced configuration guardrails — not the risk register itself
Microsoft Defender for Cloud	(b) incident handling (detection layer)	Section 3.2, monitoring and logging	Continuous posture scoring against a built-in “EU 2022 2555 (NIS2) 2022” standard [5]
Microsoft Sentinel	(b) incident handling (response layer)	Sections 3.2–3.6, monitoring through post-incident review	SIEM correlation and case management once Defender raises a signal
Microsoft Entra Privileged Identity Management (PIM)	(i) human resources security, access control, asset management	Section 11, access control	Just-in-time elevation and access review for privileged/admin accounts
Azure Key Vault	(h) cryptography and encryption policy	Section 9, cryptography and encryption	HSM-backed key and secret management for the encryption-at-rest/in-transit controls you already have to document
Entra Conditional Access / MFA	(j) multi-factor or continuous authentication	Section 11.7, the MFA sub-point within access control	Enforced MFA for admin and remote access, not the policy document describing when exceptions are permitted

Defender for Cloud: Continuous Monitoring for Article 21(2)(b)

For compliance officers: Defender for Cloud is a dashboard, not a filing. It scores your Azure resources against Microsoft’s own regulatory-compliance mapping for “EU 2022 2555 (NIS2) 2022” and shows each control as compliant, non-compliant, or greyed out [5]. Greyed-out controls are the ones Microsoft’s own documentation admits it cannot automatically assess — those still need a manually collected evidence artefact, and Microsoft does not tell you which document to produce.

For CISOs and IT security managers: enable Defender for Cloud’s standard tier (the free tier does not run the regulatory compliance assessments), assign the NIS2 initiative at the management-group level so newly created subscriptions inherit it automatically, and route every non-compliant finding into a ticketing queue with an owner and a due date — an unassigned red control is functionally the same as no control.

Azure Policy: Enforcing Article 21(2)(a) Risk Controls at Scale

Azure Policy’s built-in NIS2-relevant definitions cover encryption-at-rest enforcement, diagnostic-logging requirements, and resource tagging for asset inventory [7]. Group related definitions into an Initiative so a single assignment covers, for example, every Section 1–2 policy control at once rather than one resource at a time. The mechanism-level point auditors miss: Azure Policy’s default effect for most built-ins is Audit, which reports non-compliance without blocking it. Article 21(2)(a) asks for risk analysis and security policies that are actually enforced — so the built-in-to-audit-only gap is exactly where a policy on paper diverges from a policy in production. Switch load-bearing definitions to Deny or DeployIfNotExists once you have validated they will not break existing workloads.

Privileged Identity Management: Article 21(2)(i) Access Control

CIR Section 11 requires additional controls specifically for privileged accounts — system administrators, database administrators, anything with root-equivalent access — on top of standard access control [4]. PIM implements this as just-in-time role activation: an administrator requests elevation for a fixed window instead of holding standing privileged access, and every activation is logged for the access-review evidence Section 11 expects. The gap most Azure tenants leave open is Global Administrator: PIM only protects roles it is explicitly configured to govern, and a break-glass account left as a permanent Global Administrator outside PIM defeats the entire control.

Azure Key Vault: Article 21(2)(h) Cryptography and Key Management

CIR Section 9 asks organisations to define which data classifications require encryption at rest and in transit, and which algorithms and key lengths are approved [4]. Key Vault (or its HSM-backed tier, Managed HSM) is the mechanism that enforces the answer — it is not the answer itself. The document Article 21(2)(h) actually requires is a cryptography policy stating your organisation’s approved algorithms, minimum key lengths, and key-rotation interval; Key Vault then becomes the audit evidence that the policy is implemented, via its access logs and key-rotation history, rather than the policy’s substitute.

Microsoft Sentinel: Closing the Loop on Incident Handling

CIR Section 3 runs from monitoring and logging (3.2) through incident response and post-incident review (3.5–3.6) [3]. Defender for Cloud generates the detection signal; Sentinel is where that signal becomes a documented case with a timeline — which matters directly for Article 23’s notification clock. An essential or important entity has 24 hours from awareness of a significant incident for an early warning, 72 hours for a fuller notification, and one month for a final report. Sentinel’s incident timestamps are the first evidence a competent authority will ask for when it checks whether that clock was honoured, so configuring Sentinel’s incident creation to fire from the moment of detection — not from the moment an analyst gets around to triaging — is what keeps the 24-hour window realistic.

What Azure’s Compliance Dashboard Can’t Do For You

This is the gap competitor guides gloss over: Defender for Cloud’s own documentation states plainly that when a control “can’t be automatically assessed,” the dashboard shows it greyed out and simply cannot decide compliance either way [5]. In practice, that greyed-out set consistently includes the documents no API call can generate — a written risk assessment methodology, a supplier security policy with your actual vendor list attached, a board-approved business continuity plan, a training record showing staff actually completed cyber-hygiene training. Azure gives you the technical control; NIS2 Article 21(2) asks for the technical control plus the policy, procedure, and evidence trail proving it was deliberately designed, not accidentally correct.

Azure gives you (automatable)	Article 21(2) still requires (document)
Defender for Cloud compliance score	Written risk assessment methodology and treatment plan (a)
Key Vault encryption enforcement	Cryptography policy naming approved algorithms and key lengths (h)
PIM activation logs	Access control policy defining who may request which role, and why (i)
Sentinel incident timeline	Incident notification forms mapped to the 24h/72h/1-month Article 23 clock (b)

Common Azure Configuration Mistakes and What They Cost

Four patterns recur across Azure tenants attempting NIS2 alignment: leaving Defender for Cloud on its free tier, where the regulatory-compliance assessments simply do not run; assigning Azure Policy definitions with the default Audit effect and treating a passing dashboard as proof of enforcement; excluding break-glass or service accounts from PIM governance; and setting log retention below the 12-month window most competent authorities expect to see during an audit request. None of these are exotic misconfigurations — they are default settings left unchanged.

The financial exposure for getting Article 21 wrong is set by Article 34 of the Directive [1]: essential entities face fines of up to €10,000,000 or 2% of total worldwide annual turnover, whichever is higher; important entities face up to €7,000,000 or 1.4%, whichever is higher. A misconfigured Azure environment is not itself what triggers a fine — an undocumented risk management process, discovered during a supervisory review or after an incident, is.

Azure NIS2 Compliance Checklist

• CISO / IT lead: Defender for Cloud standard tier enabled tenant-wide; NIS2 initiative assigned at management-group level; Sentinel connected as the SIEM for every Defender alert; PIM governing every privileged role including break-glass accounts; Key Vault or Managed HSM holding every production encryption key.
• Compliance officer: a written cryptography policy naming approved algorithms; an access control policy defining privileged-role eligibility; incident notification procedures mapped to the 24h/72h/1-month Article 23 timeline; an evidence log for every Defender for Cloud control marked “greyed out.”
• Board / C-suite: confirmation that Azure’s shared-responsibility model has been explicitly reviewed against Article 21(2), not assumed; budget allocated for the manual evidence documents Azure cannot generate.

FAQ

Does using Microsoft Azure make my organisation NIS2 compliant?
No. Azure provides the technical infrastructure and several built-in controls, but Article 21(2) compliance requires your organisation’s own risk assessment, policies, and evidence trail on top of that infrastructure — Microsoft’s own regulatory compliance dashboard explicitly cannot assess every control automatically [5].

Is Microsoft Azure itself subject to NIS2?
Yes, separately. As a cloud computing service provider, Microsoft is directly bound by CIR 2024/2690 for the Azure platform itself [2]. That is a distinct obligation from your organisation’s Article 21(2) duties as an Azure customer.

Which Azure feature covers NIS2’s MFA requirement?
Microsoft Entra Conditional Access enforcing multi-factor or continuous authentication maps to Article 21(2)(j) and CIR Section 11.7, the MFA sub-point inside the access-control section — distinct from PIM, which governs privileged-access elevation under the broader Article 21(2)(i) and Section 11 [1][4].

Do I need CIR 2024/2690 compliance if I only use Azure and I’m not a cloud provider myself?
Not directly. CIR 2024/2690 binds Microsoft as the cloud provider, not your organisation as the customer, unless your own organisation independently falls into one of the CIR’s seven bound categories [2]. Most Azure customers apply the CIR Annex “by analogy” as good-practice detail for their own Article 21(2) measures, not as a binding requirement.

Sources

• “Article 21,” NIS2 Directive (EU) 2022/2555 — nis-2-directive.com (EUR-Lex CELEX:32022L2555)
• “CIR 2024/2690 — NIS2 Technical Measures” — nisd2.eu
• “CIR 2024-2690 Annex 1: Technical and methodological requirements” — advisera.com
• “NIS2 Implementing Regulation (CIR 2024/2690): Complete Guide to Technical Requirements” — NIS2-Templates.com
• “Regulatory compliance in Defender for Cloud” — Microsoft Learn
• “NIS2 Compliance & Cybersecurity Solutions” — Microsoft Security Trust Center
• “Leverage Microsoft Azure tools to navigate NIS2 compliance” — Microsoft Azure Blog
• “FAQ zu NIS-2” — Bundesamt für Sicherheit in der Informationstechnik (BSI)
• “How Azure network security can help you meet NIS2 compliance” — Microsoft Community Hub (techcommunity.microsoft.com)

Related reading: for a vendor-neutral shared-responsibility framework across IaaS/PaaS/SaaS deployment models, see NIS2 Cloud Security: 5 Article 21 Controls Mapped to CIR 2024/2690. For the full CIR 2024/2690 Annex breakdown, see the Implementing Regulation guide. For all ten Article 21(2) measures in one place, see Article 21 Decoded. To check whether your organisation is in scope at all, see the NIS2 scope test.