IAM solutions for essential and important entities across energy, transport, health, water, digital infrastructure, ICT service management, public administration and manufacturing - delivered by specialists across EMEA. Intragen's Identity and Access Management solutions help you meet the access control, identity and authentication measures NIS2 requires, and evidence them to your regulator, your auditor and your customers.
compliance
NIS2 Identity Access Management
Looking for DORA?
Financial entities in scope of DORA are subject to its sector-specific digital resilience requirements. Explore our DORA IAM guidance.
What does NIS2 mean for Identity and Access Management?
Of the ten mandatory cybersecurity risk-management measures NIS2 sets out in Article 21, two are directly about identity. The first covers the security of human resources, access control policies and asset management. The second covers multi-factor or continuous authentication. Two further measures touch identity indirectly, through supply chain security and basic cyber hygiene.
Grouping human resources security, access control and asset management into a single measure is deliberate, and it is the part some organisations tend to underestimate. Access decisions are only as reliable as the joiner-mover-leaver processes that feed them and the asset inventory they are made against. An access review conducted against an incomplete asset inventory does not produce a defensible result, however well the review itself is run.
The technical detail sits in the accompanying implementing regulation, which specifies requirements in depth for eleven categories of digital entity including cloud and data centre providers, managed service providers and managed security service providers. Organisations in other NIS2 sectors are not directly bound by it, but it remains the clearest published statement of what supervisors consider adequate, and it is widely read that way.
Who does NIS2 apply to?
NIS2 covers organisations classed as essential or important entities across eighteen sectors, including financial services, retail, healthcare, energy, digital infrastructure, ICT service management, public administration, manufacturing and research.
A directive, not a regulation
Unlike an EU regulation, which applies directly and uniformly across the bloc, NIS2 is a directive - each Member State must transpose it into national law, so the specific requirements differ from country to country. For organisations operating in several countries, requirements may be applied and supervised differently in each jurisdiction.
Mapping those jurisdictional differences comes before any technical control work. Scoping the compliance landscape is the practical first step.
Reach through the supply chain
NIS2's supply chain security measure requires entities to address the security practices of their direct suppliers and service providers. The implementing regulation sets out what supplier contracts should specify: cybersecurity requirements, background verification of supplier employees, incident notification, audit rights, and requirements flowing down to subcontractors.
If you supply an essential or important entity
In practice, many suppliers first encounter NIS2 when a client questionnaire arrives asking them to demonstrate their own controls. It is a different entry point to the same compliance journey, and Intragen's experience is that it often prompts the wider identity programme.
What NIS2 requires from your identity and access controls
Six requirements account for most of the work organisations need to do.
Access control policies covering people and systems
The access control policy must address access by persons - staff, visitors, suppliers and service providers - and access by network and information systems. Access should only be granted to users who have been adequately authenticated, and the policy reviewed at planned intervals and after significant incidents or changes.
Access rights assigned, documented and reviewed
Access rights should be assigned and revoked according to need-to-know, least privilege and separation of duties. Rights must be updated whenever employment changes or ends, and every change authorised by the appropriate person. A register of access rights granted must be maintained, access rights management must be logged, and reviews conducted at planned intervals with the results, including any necessary changes, documented.
The register is the requirement most often missing. Entitlements distributed across source systems with no consolidated, queryable record do not satisfy it, however complete each individual system is.
Dedicated administrative accounts and separated administration systems
Accounts should be set up for system administration operations exclusively, with privileges individualised and restricted as far as possible, and administration accounts used only to connect to administration systems. Administration systems themselves should be used for administration only, kept logically separate from other application software, and protected through authentication and encryption.
Unique identities and full lifecycle management, for systems as well as users
Unique identities are required for network and information systems and their users, user identities must be linked to a single person, and the full identity lifecycle must be managed. Shared identities are permitted only where necessary, with an explicit approval process and documentation. Identities no longer needed must be deactivated without delay - the orphaned service account requirement in all but name.
Authentication proportionate to the asset
Authentication strength should be appropriate to the classification of the asset being accessed, with controlled allocation of authentication credentials, credential changes at defined points, session termination after inactivity, and separate credentials for privileged and administrative accounts.
Management body approval and oversight
Management bodies must approve the cybersecurity risk-management measures taken to comply with Article 21 and oversee their implementation, and members of management bodies are required to undergo training.
What this means for identity teams
Access risk has to be reported in a form the board can understand and approve - and that approval needs to be evidenced. Intragen's view is that this turns identity reporting from an internal IT metric into a governance artefact, and organisations that have never produced one usually find this the hardest part of the programme to retrofit.
Does NIS2 require multi-factor authentication?
This is the question Intragen is asked most often about NIS2 and identity, and it is frequently answered too simply.
NIS2 requires multi-factor authentication or continuous authentication solutions, where appropriate. That phrasing carries three implications.
It is an alternative, not a hierarchy
Because the requirement is framed as an alternative, continuous or risk-based authentication counts as an accepted approach in its own right, not a fallback option.
"Where appropriate" is doing work
The qualifier brings in the proportionality principle that runs throughout Article 21.
Scoped to asset classification
For digital entities covered by the implementing regulation, the requirement is explicitly scoped to the classification of the asset being accessed.
A defensible position
Not multi-factor authentication applied universally, but an asset classification with an authentication strength decision mapped against it, and a documented rationale wherever a control has been judged not appropriate. Organisations that rolled out MFA broadly without that reasoning often have the right controls but no way to justify their scope. That is a straightforward problem to fix, but not one that fixes itself.
Where MFA is applied, method quality matters
ENISA's technical implementation guidance is clear that phishing-resistant methods should be used wherever possible, and ranks methods by strength.
- SMS one-time passcodes. Ranked as less secure because of the risk of SIM swapping.
- Authenticator applications and push notifications. Stronger, and widely deployed.
- Hardware tokens, passkeys and FIDO2 security keys. The phishing-resistant end of the range.
The evidence you will be asked to produce
NIS2 gives competent authorities the power to request evidence that cybersecurity policies have been implemented, including the results of security audits and the underlying evidence behind them. For the management of access rights, ENISA's technical implementation guidance expects the following.
- Defined user roles and the access rights corresponding to each
- A central register of all granted access rights, recording usernames, roles, access levels and dates of change
- Approved access request forms supporting every entry in that register
- Evidence of periodic access reviews, and records of their outcomes
- System logs covering the creation, modification and deletion of access rights
- Audit trails with timestamps, user identifiers and the actions performed
- Records of access-related incidents and the corrective action taken
- Evidence of the systems enforcing those controls, which ENISA identifies as identity and access management solutions
The same guidance sets a review cadence that the regulation itself leaves open, directing organisations to review access rights at least annually, in addition to reviews following termination or change of employment, with privileged access authorisations reviewed separately.
Our key message
Most NIS2 remediation is about provability, not new controls
Taken together this is an artefact standard rather than a control standard. A control that operates correctly but produces no dated, approved and retained record will not satisfy it. From our experience, the Intragen team know that this is where the majority of NIS2 remediation effort goes. Organisations rarely need to build access governance from nothing - they need existing controls orchestrated so that every grant, approval, review and revocation leaves a record an auditor will accept, and they need that to keep happening without manual effort.
NIS2 requirements mapped to identity and access controls
Each obligation, the article it comes from, the control that satisfies it, and the Intragen capability that delivers it.
Scroll the table sideways →
| NIS2 requirement | Reference | IAM control | Intragen solution |
|---|---|---|---|
| Access control policies | Art. 21(2)(i) | Access governance | IGA |
| Human resources security | Art. 21(2)(i) | Identity lifecycle management | IGA |
| Asset management underpinning access decisions | Art. 21(2)(i) | Asset-aware entitlement design | IGA and Advisory |
| Multi-factor or continuous authentication, where appropriate | Art. 21(2)(j) | Adaptive and risk-based authentication | Access Management |
| Supply chain security across direct suppliers and service providers | Art. 21(2)(d) | Third-party access governance | IGA and PAM |
| Management body approval and oversight of measures | Art. 20(1) | Identity risk reporting | Advisory and Managed |
| Access on need-to-know, least privilege and separation of duties | Impl. Reg. 2024/2690 | Entitlement and role governance | IGA |
| Access modified on termination or change of employment | Impl. Reg. 2024/2690 | Automated deprovisioning | IGA |
| A maintained register of access rights granted | Impl. Reg. 2024/2690 | Entitlement repository and audit trail | IGA |
| Documented periodic review of access rights | Impl. Reg. 2024/2690 | Access certification | IGA |
| Accounts used exclusively for system administration | Impl. Reg. 2024/2690 | Administrative account separation | PAM |
| Administration systems separated, access authenticated and encrypted | Impl. Reg. 2024/2690 | Privileged access workstations | PAM |
| Unique identities and full lifecycle, for systems as well as users | Impl. Reg. 2024/2690 | Identity lifecycle including non-human | IGA and NHI |
| Identities deactivated without delay when no longer needed | Impl. Reg. 2024/2690 | Orphan account remediation | IGA and NHI |
| Separate credentials for privileged and administrative accounts | Impl. Reg. 2024/2690 | Credential separation and vaulting | PAM |
| Time-boxed, authorised service provider connections | Impl. Reg. 2024/2690 | Third-party privileged access | PAM |
| Supplier cybersecurity requirements, audit rights and staff vetting | Impl. Reg. 2024/2690 | Third-party governance | Advisory and IGA |
References are to Directive (EU) 2022/2555 (NIS2) and Commission Implementing Regulation (EU) 2024/2690, with review cadence and evidence expectations from ENISA's technical implementation guidance.
Common gaps Intragen sees in NIS2 identity controls
Across NIS2 engagements, the same findings recur.
Most common finding
No single register of access rights
Entitlements are distributed across source systems with no consolidated, queryable record, where the requirement is explicitly to maintain one.
Administration performed from ordinary user accounts
The requirement is accounts established for system administration exclusively, with administration systems kept logically separate from other software.
Service accounts without ownership
There is no named owner, no recorded purpose, no review date and no defined privilege level, which also removes any practical means of identifying identities that should be deactivated.
Permanent supplier access
Standing accounts remain in place for integrators and support partners, where the expectation is connections authorised on request and limited to the duration of the work.
Multi-factor authentication applied by convenience
It is deployed where it was straightforward rather than where asset classification indicates it is needed, with no documented rationale for the exceptions.
Reviews performed without documented outcomes
The requirement is to document the results of the review including the changes it produced, and a completed campaign with no retained output does not satisfy it.
Measures never formally approved
Management bodies are required to approve the measures and oversee implementation, and in many organisations no record of that approval exists.
How Intragen supports your NIS2 journey
Intragen works across the full lifecycle of a NIS2 identity programme, from scoping what applies to you through to running the controls once they are live.
Identity Governance and Administration
Delivers control for the identity lifecycle, access request and approval workflows, the access rights register and audit trail, certification campaigns with documented outcomes, and role and separation-of-duties governance.
Explore →Privileged Access Management
Provides dedicated administrative accounts, separated administration systems, credential vaulting, just-in-time elevation, session monitoring, and authorised, time-boxed access for service providers.
Explore →Access Management
Allows implementation of multi-factor and continuous authentication scoped to asset classification, phishing-resistant methods, single sign-on, session controls, and adaptive access for remote and third-party users.
Explore →Non-Human Identities
Delivers discovery and inventory of service identities with owner, purpose, review date and privilege level recorded, lifecycle management and oversight, credential rotation, and deactivation of identities that are no longer required.
Explore →Advisory and consulting
Scopes the requirements against the national legislation that applies to you, maps your current controls, identifies where the gaps carry the most risk, and produces a prioritised roadmap you can take to your management body.
Explore →Implementation and integration
Delivers that roadmap across leading IAM platforms, onboards the applications that matter, and instruments the processes so that grants, approvals, reviews and revocations produce evidence automatically rather than as a manual exercise.
Explore →Managed Services
Sustains the programme, running the review cycles, maintaining the evidence set, and keeping controls aligned as national implementations and guidance develop. Intragen's experience shows that a Managed Service model can accelerate time-to-value and reduce operational burden.
Explore →Why choose Intragen for NIS2
Identity is the only thing we do
Having delivered enterprise IAM solutions since 2006, Intragen is one of Europe's established Identity and Access Management specialists. We have a total focus on IAM across our business, and our people are experienced IAM practitioners working across EMEA.
For NIS2, that focus is useful in a particular way. What catches organisations out is rarely the headline obligations. It is the operational detail underneath them: the access rights register, the administrative accounts used exclusively for administration, the supplier connection that must be authorised and time-limited, the service account with a named owner, and the review whose outcome was documented. Intragen's view is that these are identity engineering problems, and resolving them across a live estate is the work our consultants do.
- Certified to the standards we design for. ISO 27001 certified and Cyber Essentials certified, so the access governance we build for clients is governance we are audited against ourselves.
- Recognised platform expertise. Okta Apex Partner and Okta EMEA Partner of the Year 2025, One Identity Platinum Premier Plus Partner and a double Partner Award winner.
- Established across five European markets. So we can advise on how requirements are being applied in practice where your entities operate, not only on what the Directive says.
- Backed by group scale. Part of the Nomios Group, one of Europe's largest cyber security and secure networking specialists.
Identity specialists at European scale
Intragen has worked exclusively on Identity and Access Management since 2006, across offices in London, Helsinki, Neuss, Athens and Zoeterwoude.
- Implementations delivered
- 400+ IAM implementations
- People
- 250 Identity and Access Management specialists
- Certifications
- ISO 27001 certified, alongside Cyber Essentials
- Okta
- Apex Partner and EMEA Partner of the Year 2025
Questions we hear most about NIS2 and identity
Article 21(2)(i) makes human resources security, access control policies and asset management one of ten mandatory cybersecurity risk-management measures, and Article 21(2)(j) covers multi-factor or continuous authentication. For the eleven categories of digital entity covered by the implementing regulation, the detail includes an access control policy covering logical and physical access, access rights assigned on need-to-know and least privilege principles with a maintained register and documented periodic review, accounts used exclusively for system administration, separated administration systems, unique identities with full lifecycle management, and defined authentication requirements.
Not unconditionally. NIS2 requires multi-factor authentication or continuous authentication solutions, where appropriate. The requirement is expressed as an alternative, so continuous or risk-based authentication is an accepted approach, and it is qualified by appropriateness. The implementing regulation scopes it to the classification of the asset being accessed. A defensible position requires an asset classification, an authentication strength decision mapped against it, and a documented rationale wherever a control has been judged not appropriate.
The implementing regulation requires review at planned intervals without specifying one, and requires the results of the review, including any necessary changes, to be documented. ENISA's technical implementation guidance is more specific, directing organisations to review access rights at least annually, in addition to reviews following termination or change of employment, with privileged access authorisations reviewed separately. Identities that are no longer needed must be deactivated without delay.
The implementing regulation requires a policy covering privileged and system administration accounts, including strong identification and authentication such as multi-factor authentication, accounts established for system administration operations exclusively, privileges individualised and restricted as far as possible, administration accounts used only to connect to administration systems, separate credentials for privileged accounts, and a separate documented review of privileged access rights. Administration systems must be used for administration only, kept logically separate from other application software, and protected through authentication and encryption.
The implementing regulation requires unique identities for network and information systems as well as their users, applies full lifecycle management to system identities, requires oversight of them, requires the access control policy to address access by systems, and requires identities that are no longer needed to be deactivated without delay. ENISA's guidance goes further, stating that the identity inventory should include all service identities with the owning department, review date, purpose and privilege level recorded, and that identities assigned to systems should be subject to segregated approval and independent ongoing oversight.
Competent authorities can request evidence that cybersecurity policies have been implemented, including audit results and the underlying evidence. For access rights, ENISA's guidance expects defined user roles and corresponding access rights, a central register of granted access rights recording user names, roles, access levels and dates of change, approved access request forms supporting each entry, evidence of periodic reviews and their outcomes, system logs covering creation, modification and deletion of access rights, audit trails with timestamps and user identifiers, records of access-related incidents, and evidence of the identity and access management systems enforcing those controls.
Essential and important entities across eighteen sectors, including energy, transport, health, water, digital infrastructure, ICT service management, public administration, space, manufacturing, food, chemicals, waste, postal services, digital providers and research. It applies through national transposing legislation, so the detail varies between Member States. Suppliers to those entities are also reached indirectly, through the supply chain security measure and the contractual requirements it drives.
For most organisations, no. NIS2 disapplies its own provisions, including those on supervision and enforcement, where a sector-specific Union act imposes at least equivalent requirements, and DORA is designated as that act for financial entities. The carve-out operates provision by provision rather than as a blanket exemption, and entities in the financial sector that are not covered by DORA remain within NIS2, so groups spanning both should have the mapping done deliberately. See our DORA IAM page for the financial services equivalent.
Assess your identity controls against NIS2
A Maturity Assessment gives you an independent view of your current identity and access controls, a gap analysis against the NIS2 requirements that apply to you, and a prioritised roadmap for improvement. It is available as a four-week Light engagement or an eight-week Core engagement, and it is not a commitment to buy.
Request an assessment
Prefer to talk it through first? Speak to an IAM specialist
This page provides general information and does not constitute legal or compliance advice. NIS2 applies through national transposing legislation, which varies between Member States. Organisations should assess their obligations against the applicable national legislation and their competent authority.