NIS2 Identity Security Requirements

NIS2 Identity Security Requirements: Start With What the Text Actually Says

If you are trying to understand nis2 identity security requirements, the first mistake to avoid is treating NIS2 as if it were a Microsoft configuration guide. It is not. Directive (EU) 2022/2555 sets risk-management obligations and governance expectations at EU level. It does not tell teams to deploy Microsoft Entra Privileged Identity Management, to enforce a specific Conditional Access template, or to set a particular password length in Active Directory.

That distinction matters because identity teams are still expected to prove something concrete. Even though NIS2 does not name Microsoft products, AD and Entra teams still need to show that privileged access is controlled, that authentication is strong enough for the risk, that access control is enforced in production, and that monitoring can prove policy violations or drift.

This article keeps four layers separate on purpose:

Layer	What it gives you	What it does not give you
NIS2 Directive text	The legal baseline at EU level	Product-specific Microsoft settings
Recitals and official context	Interpretation and policy intent	A substitute for the operative articles
Implementing Regulation (EU) 2024/2690	More technical requirements for specific covered entity types	A universal rulebook for every NIS2 entity
AD / Entra controls	Reasonable technical implementations and evidence patterns	Proof that one exact Microsoft control is legally mandated

That framing is the difference between a defensible identity review and a compliance article that overclaims.

What Does NIS2 Actually Require for Identity Security?

At the highest level, Article 21(1) of NIS2 requires Member States to ensure that essential and important entities take appropriate and proportionate technical, operational, and organisational measures to manage risks to the security of network and information systems. That is a risk-based obligation, not a checkbox list.

Identity shows up more directly in Article 21(2). For this topic, two points matter most:

Article 21(2)(i) includes policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
Article 21(2)(j) includes the use of multi-factor authentication or continuous authentication solutions, secured communications, and secured emergency communication systems within the entity, where appropriate.

NIS2 also gives important context in recital 89, which lists basic cyber hygiene practices such as zero-trust principles, software updates, network segmentation, identity and access management, and user awareness. That recital is not a hidden Microsoft baseline. It is a strong signal that identity governance, authentication, and access discipline are part of what regulators expect entities to treat as foundational security work.

The safe interpretation for identity teams is this: NIS2 does not prescribe one vendor pattern, but it clearly expects defensible identity controls that are risk-based, reviewed, and able to reduce incident impact.

Where Identity and Access Management Fits in NIS2

For AD and Entra teams, the practical question is not “which Microsoft feature does NIS2 require?” The practical question is “which identity security objectives would we struggle to prove under review?”

A useful technical reading looks like this:

NIS2 objective	What security teams should be able to prove	Example AD / Entra evidence
Access is controlled	Privileged and sensitive access is limited and reviewed	Privileged group exports, Entra role assignment exports, access review records
Authentication is appropriate to risk	Sensitive access is not protected only by a password	Conditional Access policy state, Security Defaults state, admin MFA evidence
Privilege is proportionate	Standing administrative access is minimized and exceptions are owned	Permanent vs eligible role assignments, stale admin review, break-glass governance
Monitoring works	Identity changes and role changes are reviewable after the fact	Entra audit logs, AD audit policy, evidence for group and object-change visibility
Third-party and app access are governed	Guests, external access, and app permissions do not drift silently	Guest restrictions, cross-tenant settings, app consent settings, service principal permission review

This is also where AD and Azure Compliance: NIS2, ISO 27001, CIS Controls remains useful. That article maps several frameworks broadly. The article you are reading now narrows the question to one harder problem: what an identity team can actually prove under a NIS2-style review.

Why Scope Matters: NIS2, Sector Rules, and National Transposition

Scope is where many compliance articles go wrong.

First, NIS2 is a directive, not a directly self-executing product standard. Member States transpose it into national law, and supervisory expectations are shaped by that national implementation. A team working in France, Germany, Italy, or another Member State should expect the same EU baseline but not necessarily the same supervisory packaging, reference materials, or implementation workflow.

Second, not every technical detail that people associate with NIS2 comes from the directive text itself. Commission Implementing Regulation (EU) 2024/2690 lays down technical and methodological requirements for certain categories of covered entities under Article 21(5), such as DNS service providers, cloud computing service providers, data centre service providers, managed service providers, managed security service providers, and trust service providers. That regulation is highly relevant, but it is not a generic shortcut you can apply unchanged to every NIS2-assujetted organization.

Third, some entities also sit inside sector-specific or national rule sets. A serious NIS2 identity review therefore needs three checks before it starts:

Is the entity in scope for NIS2, and in which category?
Is the entity also covered by more specific Union or national texts?
Which technical expectations are coming from the directive itself, which from implementing acts, and which from national guidance?

That matters because otherwise teams start making claims such as “NIS2 requires PIM” or “NIS2 requires 12-character passwords.” Those statements are not technically defensible from the EU text alone.

AD and Entra Controls That Commonly Support NIS2 Identity Objectives

NIS2 does not name Active Directory or Microsoft Entra. But if your estate uses them, they are obvious places where evidence will be gathered.

Privileged access

A mature identity review should be able to show which users and groups hold effective administrative access on-premises and in Entra, how that access was granted, and whether it is still justified.

That usually means reviewing:

direct and nested membership in privileged AD groups
principals with DCSync-equivalent rights
delegated rights on sensitive AD objects, especially where GenericAll, WriteDACL, or WriteOwner create escalation paths
permanent versus eligible Entra role assignments
accounts that retain privilege despite dormancy or ownership drift

That is exactly why Privileged Access Drift Active Directory and Azure Privileged Access: Too Many Global Admins are relevant internal references for this topic. They do not prove NIS2 compliance by themselves. They show the kinds of identity conditions a team would struggle to defend under NIS2 scrutiny.

Authentication strength

NIS2 clearly gives MFA or continuous authentication a place in the control set, but “where appropriate” still matters. A defensible identity program should therefore be able to explain:

which privileged accounts are always behind MFA
which high-risk applications and admin workflows are subject to stronger access controls
whether legacy authentication paths remain open
whether the tenant relies only on password-plus-exception patterns

Microsoft’s own documentation is useful here because it explains what Conditional Access actually is: a policy engine that combines signals and enforces access decisions. That makes it evidence of a control path, not proof that NIS2 specifically mandated Conditional Access as a product.

In the same way, Azure Identity Security: Why MFA Alone Is Not Enough helps frame the technical limitation correctly: MFA is important, but poor role governance, open guest access, or malicious app consent can still leave major identity exposure.

Access control, guest access, and app permissions

Identity scope under NIS2 is wider than employee logon. Access control also touches external users, application access, and delegated authority.

A technical team should be able to show:

how guest access is restricted
who is allowed to invite guests
whether cross-tenant collaboration is tightly governed or left broadly open
how application permissions and consent are controlled
whether over-privileged enterprise apps are periodically reviewed

Those are not abstract concerns. Microsoft documents that application permissions can grant app-only access and that user or admin consent governs how applications obtain access to protected resources. Microsoft also documents how user consent settings can be restricted to reduce malicious or overly broad consent. That is why Azure App Registrations: Over-Privileged Tenant Apps and OAuth Consent Phishing: How Malicious Apps Bypass Password Theft belong in a serious NIS2 identity reading, even though NIS2 itself never uses those product names.

Evidence Security Teams Should Be Able to Produce

A weak identity compliance program usually has a policy deck but not an evidence package. Under a NIS2-oriented review, AD and Entra teams should be able to produce current, reviewable evidence for the controls they claim to enforce.

A practical evidence package usually includes:

Control theme	Evidence example
Privileged access	Current AD privileged group exports, Entra role assignment exports, eligible vs permanent privilege evidence
Access review discipline	Role review records, group membership review outputs, guest access review evidence
MFA and access protection	Conditional Access state, Security Defaults state where relevant, role-targeted MFA coverage
Guest and external access	Guest restriction settings, invitation policy, cross-tenant collaboration settings
Application governance	App permission inventory, consent settings, review records for high-risk service principals
Monitoring	Entra audit logs, AD audit policy outputs, proof that relevant identity changes are recorded and retained
Exceptions	A documented exception register with owner, rationale, and review date

That is also where How to Audit Microsoft Entra ID Security, How to Audit Active Directory Security, and Active Directory Monitoring: Security Event IDs That Matter help turn framework language into operational review steps.

Common Gaps Between Written Policy and Enforced Identity Controls

The highest-risk NIS2 identity failures usually do not come from missing policy language. They come from the gap between what the policy says and what the directory and tenant actually enforce.

Common examples include:

a written least-privilege policy with too many permanent admins in Entra or too many standing privileged groups in AD
an MFA policy that still leaves sensitive admin flows or legacy authentication paths outside effective coverage
a third-party access policy that exists on paper while guest invitation settings or cross-tenant access remain too open
a quarterly access review process with no current evidence that guest, group, or role reviews were actually completed
an application governance policy that exists, but no one can show current service principal permissions, app-only grants, or consent settings
an audit-and-monitoring policy that names controls, but no one can prove current AD auditing or current Entra audit coverage

This is why a NIS2 identity article should not end with governance slogans. A technical team needs to be able to show enforced state, not only written intent.

France and ANSSI Context

Because this article is UE-first, France belongs in context rather than in the normative core.

ANSSI’s official NIS2 page states that it will communicate throughout national transposition, that future essential and important entities are encouraged to begin a NIS2-consistent security approach now, and that since 17 March 2026 ANSSI has made the Référentiel Cyber France (ReCyF) available as a working document. ANSSI also states that ReCyF is, by default, non-mandatory at this stage and corresponds to the cybersecurity framework mentioned in Article 14 of the French Résilience bill.

The safe reading is straightforward:

ReCyF is not the NIS2 directive itself
ReCyF is not a substitute for reading the applicable legal texts
France-based entities may still find it useful as a practical supervisory reference point
teams should treat French implementation status and supervisory expectations as national context layered on top of the EU directive

That makes ANSSI Active Directory Guide: Applying the Security Recommendations in Practice a helpful adjacent read, but not a substitute for NIS2 analysis.

Validation After Remediation

A NIS2-ready identity program has to prove that gaps were closed, not only that they were identified.

After remediation, teams should be able to show:

updated privileged access inventories for both AD and Entra
current evidence that strong authentication controls apply where the organization says they should
updated guest, cross-tenant, and application-governance settings after changes
current audit evidence showing that identity changes are still visible
a refreshed exception list that distinguishes residual risk from drift or neglect

That validation step is what separates a one-time framework exercise from a review that will still survive the next audit cycle.

How EtcSec Helps Measure NIS2 Identity Gaps

EtcSec should be positioned narrowly here.

The point is not that EtcSec “proves NIS2 compliance.” The point is that it helps measure technical identity gaps that often matter when a team is trying to prove that access, authentication, privilege governance, and monitoring are actually enforced.

Examples include:

EXCESSIVE_PRIVILEGED_ACCOUNTS
PRIVILEGED_ACCOUNT_STALE
DANGEROUS_GROUP_NESTING
DCSYNC_CAPABLE
ACL_GENERICALL
CA_NO_MFA_REQUIREMENT
PA_PIM_NOT_ENABLED
GUEST_INVITATION_UNRESTRICTED
B2B_CROSS_TENANT_OPEN
AZ_SECURITY_DEFAULTS_DISABLED

Those findings do not create a legal presumption. They help a security team answer a harder question: if we say our identity controls are risk-based and enforced, what current evidence supports that claim?

NIS2 Identity Security Requirements: What AD and Entra Teams Need to Prove