Microsoft Entra ID and NIS2 Article 21(2)(i): What PIM, Conditional Access, and Identity Governance Cover (and What They Don’t)
This article maps Microsoft Entra ID (formerly Azure AD) capabilities to NIS2 Article 21(2)(i) and Commission Implementing Regulation (EU) 2024/2690 Annex Section 11. It provides general compliance information only and does not constitute legal or regulatory advice — see the disclaimer before Sources.
Where Article 21(2)(i) Meets Your Identity Provider
NIS2 Article 21(2)(i) requires “human resources security, access control policies and asset management” as part of the risk-management measures every essential and important entity must implement.[1] If your organisation runs Microsoft 365 or Azure, Entra ID is very likely your access control plane by default — whether IT chose it deliberately or inherited it along with the rest of the Microsoft stack.
This isn’t a paperwork exercise layered on top of security. ENISA’s 2025 Threat Landscape report, analysing roughly 4,900 incidents between July 2024 and June 2025, found phishing responsible for 60% of initial intrusions — most of which end in a stolen or reused credential rather than an exploited server.[9] Access control policy is mechanistically where NIS2 compliance and breach prevention overlap: get identity right and you close the door attackers use most. That is also why the type of MFA matters, not just its presence. A one-time code sent by text message can still be phished or relayed in real time by an attacker sitting between the user and the login page, while a phishing-resistant method such as a FIDO2 security key or certificate-based authentication resists that relay, because the cryptographic proof is bound to the specific site the user is actually on.
| Reader role | What this article gives you |
|---|---|
| CISO / IT lead | Which Entra feature maps to which CIR 11 sub-point, and the exact license SKU each one requires |
| Compliance officer | The documentation gap Entra’s admin console does not close on its own — what still needs a written policy and a review record |
One scope note before the detail: Article 21(2)(i) applies regardless of your Entra tenant’s license tier. A Free-tier tenant is still in scope — the tier only determines which technical controls are actually available to satisfy it, which is the licensing thread running through every section below.
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
CIR 2024/2690 Section 11, Sub-Point by Sub-Point
Article 21(2)(i) splits across three CIR Annex sections — Section 10 (human resources security), Section 11 (access control), and Section 12 (asset management).[3] Section 11 is where Entra ID’s technical controls actually live, and it breaks into seven sub-points, each with its own Entra equivalent and its own license floor.[2][4]
| CIR 11 sub-point | What it requires | Entra ID equivalent | License floor |
|---|---|---|---|
| 11.1 Access control policy | A documented, reviewed logical and physical access control policy | Conditional Access policy set (the enforcement layer, not the document itself) | P1 |
| 11.2 Access rights management | Need-to-know, least privilege, separation of duties, periodic documented review | Access Reviews + Entitlement Management access packages | P2 core; auto-assignment needs Governance |
| 11.3–11.4 Privileged & admin accounts | Separate, monitored privileged accounts on segregated administration systems | Privileged Identity Management (PIM) eligible assignments | P2 or Governance |
| 11.5 Unique identification | Full identity lifecycle management; deactivate unneeded identities without delay | Lifecycle Workflows + HR-driven provisioning | Governance for full automation |
| 11.6 Authentication strength | Authentication matched to asset classification, reviewed regularly | Authentication strength policies inside Conditional Access | P1 baseline; risk-based needs P2 |
| 11.7 MFA / continuous authentication | MFA or continuous authentication for critical systems and remote access | Conditional Access-enforced MFA | P1 baseline; risk-based needs P2 |
PIM and Conditional Access: Coverage and the License Floor Under Each
PIM is the sharpest tool in the stack for the 11.3/11.4 privileged-account controls — but it does nothing until it’s licensed and configured. A permanent Global Administrator account sitting outside PIM’s governance defeats the control regardless of how well the rest of the tenant is set up, a gap our own Azure coverage flags as the single most common misconfiguration in this area.[5]
Mechanically, PIM converts standing privilege into eligible assignments: an administrator requests time-bound activation, optionally gated by approval and an MFA re-prompt, and every activation is logged.[6] That log is the literal access-review evidence 11.3 describes — not a proxy for it.
The licensing reality is where most tenants quietly fall short. PIM requires Entra ID P2 or the separate Entra ID Governance add-on — not P1, and not the Free tier.[7] And when that license lapses, the control doesn’t fail safe: eligible role assignments are removed, but active time-bound assignments silently become permanent, unmanaged ones.[7] A tenant can lose its privileged-access control and end up in a worse position than before PIM was ever configured, without anyone noticing until the next audit.
Conditional Access splits the same way. Core policies — blocking legacy authentication, requiring MFA, checking device compliance — run on P1.[8] Risk-based Conditional Access, which scores sign-in and user risk in real time, needs Microsoft Entra ID Protection, a P2 feature.[8] A P1-only tenant can technically satisfy 11.7’s MFA requirement while falling short of the risk-based access control maturity regulators increasingly expect. And like PIM, Conditional Access doesn’t fail closed: when its licenses expire, existing policies keep running rather than switching off, so a lapsed license stays invisible until someone checks the billing page.[8]
Identity Governance: Where “Periodic Review” Actually Happens
Access Reviews are the direct implementation of 11.2’s demand to review access rights “at planned intervals” and document the result.[2][4] The core capability ships at P2; AI-assisted review recommendations, reviews scoped to inactive users, and catalog-wide reviews are Governance-add-on features layered on top.[7]
Entitlement Management handles the separation-of-duties half of 11.2 through access packages with multi-stage approval chains. But automatic, attribute-driven assignment — the part that actually removes a leaver’s access without a ticket — needs the Governance license, not just P2.[6][7]
Lifecycle Workflows is the identity-lifecycle piece of 11.5: deactivating identities without delay rather than on the next scheduled review. It’s a Governance-only feature.[6][7] Without it, P1/P2 tenants fall back to manual joiner-mover-leaver processing, exactly the queued-for-the-next-maintenance-window pattern CIR 11.2 treats as insufficient.[4]
Building the Audit Trail: What to Export and How Often
Configuring the controls above is only half the job. CIR Section 11 is an evidence requirement as much as a technical one. An auditor does not take a verbal claim about Conditional Access on faith; they want the policy export, the review record, and a date stamp. The checklist below is a practical starting point, not an exhaustive one, and assumes a mid-sized tenant with a handful of privileged roles.
| Evidence artifact | Where it lives | Effort | Cadence |
|---|---|---|---|
| Conditional Access policy set | Graph API or admin center export (JSON) | Low | Quarterly, or after any policy change |
| PIM activation history and eligible-assignment list | PIM audit history, per role | Medium | Monthly for privileged roles, matching the 11.3 review cadence |
| Access Reviews completion records | Access Reviews history, generated once a recurring review is configured | Low | Automatic, on the review’s own schedule |
| Sign-in and audit logs | Entra diagnostic settings piped to a SIEM or Log Analytics workspace | Medium | Continuous, retained per your incident-response policy’s window |
| License SKU snapshot | Microsoft 365 admin center, Billing, Licenses | Low | Before every audit cycle — the single check that catches a P1-only gap before an auditor does |
One retention detail catches tenants out here: Entra ID’s own audit and sign-in logs are kept for just 7 days on the Free tier and 30 days on P1 or P2, not automatically archived and not retroactive if you upgrade after the fact.[10] A 30-day native window does not cover a typical annual audit cycle, which is the practical reason the SIEM export row above is not optional. Without it, an auditor asking for evidence from three months ago gets nothing, regardless of how well the underlying controls were configured at the time.
None of this replaces the policy document 11.1 requires. It is the evidence that the policy is actually being followed, which auditors treat as a separate and equally checkable claim.
What Entra ID Doesn’t Give You
Entra ID is a control-enforcement layer, not a documentation system. CIR 11.1 wants a written, dated, reviewed access control policy; the admin center produces configuration exports and sign-in logs, not a governance document with version history and management sign-off. Those are related but not the same artifact.
Nothing in the Entra admin center references “CIR 2024/2690” or “Article 21(2)(i)” by name — mapping a specific toggle to a specific sub-point is manual work every tenant currently redoes from scratch, usually during audit prep rather than before it.
The most consequential gap is the silent one: a tenant can be textually “MFA-enforced” under 11.7 while structurally unable to produce the privileged-account review evidence 11.3 wants, simply because PIM was never licensed. Before telling an auditor “we use Entra ID for access control,” check the license SKU against the sub-point table above — the claim needs a P2 or Governance floor to hold across all seven sub-points, not just any Entra tenant.
Frequently Asked Questions
Does Microsoft Entra ID alone make us NIS2 compliant for Article 21(2)(i)?
No single tool satisfies a legal requirement by itself. Entra ID can support the technical controls Section 11 describes, but the written policy, review records, and management sign-off CIR 2024/2690 expects sit outside any admin console.[1][2]
Is Entra ID P1 enough, or do we need P2?
P1 covers baseline Conditional Access — MFA enforcement, legacy-authentication blocking, device compliance checks. It does not include PIM, core Access Reviews, or Entitlement Management; those need P2 at minimum.[7][8]
What’s the difference between Entra ID P2 and the Entra ID Governance add-on?
P2 unlocks PIM, core access reviews, and entitlement management. Governance adds Lifecycle Workflows, AI-assisted review recommendations, auto-assignment policies, and catalog-scoped reviews on top of P2.[7]
Does this apply if we don’t use Microsoft 365 or Azure?
Yes — Article 21(2)(i) is platform-neutral. Any identity provider must produce the same category of evidence: a documented policy, access-rights review records, privileged-account controls, and MFA enforcement.[1][2] The CIR Section 11 sub-point table above applies regardless of vendor; only the specific feature names change.
How long should we keep Entra ID sign-in and audit log evidence?
Longer than Entra’s own default. Free-tier logs last 7 days and P1/P2 logs last 30 days before they age out, which is well short of most audit cycles.[10] Route logs to a SIEM, Log Analytics workspace, or storage account, and set the retention window to match your incident-response and audit-evidence policy rather than Microsoft’s default.
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
- NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
- Commission Implementing Regulation (EU) 2024/2690, Annex Section 11 (Access Control) — OpenKRITIS implementing-acts mapping
- NIS2 Article 21 Decoded: All 10 Security Measures, CIR 2024/2690 Sub-Requirements
- NIS2 Access Control and Human Resources Security: A Complete Guide to Article 21(2)(i)
- Azure NIS2 Compliance: Mapping Defender for Cloud, Policy, PIM, and Key Vault to Article 21(2)
- Microsoft Entra ID Governance overview — Microsoft Learn
- Microsoft Entra ID Governance licensing fundamentals — Microsoft Learn
- Microsoft Entra Conditional Access: Zero Trust Policy Engine — Microsoft Learn
- ENISA Cybersecurity Threat Landscape Report 2025: Key takeaways for SMEs — European DIGITAL SME Alliance
- Microsoft Entra data retention — Microsoft Learn
Get the NIS2 Article 21 Compliance Checklist
90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.
