NIS2 is not a future obligation. The directive entered into force across EU member states in October 2024, enforcement actions began in early 2025, and supervisory authorities are conducting their first wave of examinations now. If your organisation falls within NIS2 scope — and the directive's coverage is significantly broader than its predecessor — the question is not whether you need to be compliant but whether you can demonstrate compliance when asked. This checklist covers the identity security controls that NIS2 Article 21 mandates, organised by what you need to have in place, what you need to be able to prove, and where the gaps most commonly appear.
Who NIS2 Applies To: Scope Clarification
NIS2 applies to medium and large entities in 18 sectors designated as essential or important. Essential entities — those in energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space — face the strictest supervision and the highest penalties. Important entities — those in postal services, waste management, chemicals, food, manufacturing, digital providers, and research — face lighter-touch supervision but identical substantive obligations under Article 21.
Size thresholds apply in most sectors: medium entities (50+ employees, €10M+ turnover) and large entities (250+ employees, €50M+ turnover) are within scope. Some sectors — DNS providers, TLD registries, cloud computing providers, data centre services, content delivery networks, and certain public administration entities — are in scope regardless of size. If you are uncertain about your scope status, that uncertainty is itself a compliance risk; supervisory authorities expect in-scope entities to have made a self-assessment determination and documented it.
One critical point on supply chain exposure: if you provide ICT services to an in-scope NIS2 entity, your contractual obligations to that entity will increasingly mirror NIS2's requirements, even if you are not directly in scope yourself. The security of the supply chain is a mandatory assessment area for in-scope entities, and they will pass that requirement down through their vendor relationships.
Article 21: The Identity Controls NIS2 Mandates
NIS2 Article 21 requires organisations to implement "appropriate and proportionate technical, operational and organisational measures" across ten specific areas. Of these, the following directly implicate identity security controls and are the areas where supervisory authorities are focusing examination attention.
Access control policies (Article 21(2)(i)): NIS2 requires documented access control policies covering who has access to what, on what basis, and subject to what review. This means a written IAM policy that specifies your access provisioning and deprovisioning processes, your role-based access control model, and your procedures for emergency and privileged access. The policy must be approved by management (Article 20) and must be demonstrably implemented — a policy that exists on paper but is not followed will not satisfy examination requirements.
Multi-factor authentication (Article 21(2)(j)): NIS2 explicitly requires the use of multi-factor authentication or continuous authentication solutions wherever relevant. "Wherever relevant" has been interpreted by member state authorities as meaning all remote access, all privileged access, and all access to systems processing personal data or critical operational data. Push-based MFA that is susceptible to fatigue attacks satisfies the technical requirement but creates risk; phishing-resistant MFA (FIDO2/passkeys) is the standard ENISA recommends for high-assurance use cases.
Privileged access management: While not enumerated separately in Article 21, PAM controls are a mandatory component of the ICT risk management framework that Article 21 requires. Supervisory examinations consistently probe whether organisations can demonstrate control over privileged access — who holds privileged accounts, what they are used for, whether sessions are recorded, and how privilege is granted and removed. Informal privileged access management — shared administrator passwords, unrecorded privileged sessions, permanent privilege grants without review — will fail examination.
NIS2 supervisory examinations are not document reviews — they are evidence assessments. Examiners will ask to see your access certification records, your PAM session logs, your MFA enforcement reports, and your incident response evidence. The organisations that pass are the ones that have operational controls producing evidence as a by-product of normal operations — not the ones that generate documentation in response to an audit notice.
The NIS2 Identity Security Checklist
1. Complete identity inventory. You must be able to enumerate all identities — human and non-human — with access to systems in scope. This includes service accounts, API keys, OAuth grants, and third-party vendor accounts, not just your employee user population. If you cannot produce this inventory within 24 hours, it does not exist operationally.
2. Documented access control policy. A written policy approved by your management body (Article 20 requirement) covering: how access is granted (request, justification, approval), how access is reviewed (access certification frequency and scope), how access is removed (offboarding and role-change triggers), and how emergency access is handled and logged. The policy must be current — last reviewed within 12 months — and must reflect actual practice.
3. MFA enforced on all remote and privileged access. No exceptions. Remote access (VPN, remote desktop, cloud console) and privileged access (administrator accounts, PAM-controlled sessions) must require MFA at every authentication event. Document which systems are covered and which are not, with a remediation timeline for gaps. Unprotected remote access is a high-severity finding in examination.
4. Privileged access management programme. All privileged accounts must be managed through a PAM solution (Delinea, CyberArk, BeyondTrust) that provides: session recording for all privileged sessions, just-in-time access provisioning where feasible, credential vaulting (no shared plaintext passwords), and an audit log of all privileged access events. Ad-hoc privileged access that bypasses your PAM solution is a control failure.
5. Access certification programme. Periodic review — at minimum annually, quarterly for privileged access — of all access grants, with documented decisions on whether each grant is still appropriate. Access that survives certification has been reviewed and confirmed; access that is revoked in certification is evidence the control is working. Certification records must be retained for examination.
6. Third-party identity controls. An inventory of all vendor and contractor accounts, with an owner of record for each. Third-party access must be provisioned on a just-in-time basis where possible, with automatic expiry tied to the contract period. Third-party privileged sessions must be recorded. Your contracts with ICT service providers must include security obligations consistent with NIS2 Article 21 — an addendum template your legal team has reviewed and approved.
7. Identity incident detection. An ITDR (Identity Threat Detection and Response) capability that monitors for identity-based attack patterns: impossible travel, credential stuffing, anomalous privilege use, lateral movement. This can be delivered through your SIEM with identity log ingestion, through your IdP's risk detection (Microsoft Entra ID Protection, Okta ThreatInsight), or through a specialist ITDR platform. Log coverage must include your IdP, PAM solution, and Active Directory at minimum.
8. Incident response procedure covering identity events. A documented procedure for identity-related incidents — credential compromise, privilege abuse, account takeover — with defined roles, escalation paths, containment steps, and the evidence-gathering workflow required to support NIS2 Article 23 reporting within the 24/72-hour timeline. The procedure must have been tested (tabletop exercise or simulation) within the past 12 months.
9. Non-human identity governance. Service accounts and API keys must have documented owners, defined scopes, and rotation schedules. Discovery tooling must run continuously or periodically to surface ungoverned NHIs. Orphaned credentials — those with no active owner or consuming application — must be revoked. Evidence of this programme (discovery outputs, revocation records, rotation logs) is increasingly requested in examinations as a proxy for overall identity security maturity.
10. Management body approval and training. Your board or management body must have formally approved your cybersecurity risk management framework, including the identity security controls above. That approval must be documented with a date. Management body members must have completed cybersecurity training appropriate to their oversight role within the past 12 months, with records retained. This is the control most commonly missing in first-wave examinations.
NIS2 and DORA: The Dual Compliance Path
Financial sector organisations in scope for both NIS2 and DORA face overlapping identity security requirements that, approached correctly, can be satisfied through a single programme. DORA Article 9 requires identity and access management controls as part of the ICT risk framework — its specific requirements for MFA, privileged access, and audit logging substantially overlap with NIS2 Article 21. A unified identity governance programme that satisfies DORA's specificity satisfies NIS2's equivalent requirements.
The key difference is reporting: DORA's Article 19 imposes specific incident reporting timelines that NIS2's Article 23 mirrors but does not identically match. Build your incident response capability against the more demanding of the two — DORA's financial sector specificity — and your NIS2 reporting obligations are covered as a subset. Do not build two separate incident response workflows; build one that satisfies both.
Examination Preparation: What to Have Ready
When a NIS2 supervisory examination is announced — typically with 30-60 days notice — organisations that have operational controls in place spend that time organising evidence. Organisations without operational controls spend it generating documentation that examiners will quickly identify as created for the audit rather than produced by normal operations. The difference is visible and consequential.
The evidence package for identity security should include: your current identity inventory (date-stamped, showing all identity types), your most recent access certification report (showing decisions made, not just a list of access grants), your PAM session log exports for the past 90 days, your MFA enforcement report (percentage of authentication events covered by MFA, by system and user population), your identity incident log for the past 12 months (including near-misses), and the board minutes recording approval of your cybersecurity framework. If any of these cannot be produced quickly from operational systems, that is the gap that needs to close before the examination window.