Art. 21(2)(i)+(j) NIS 2 + CIR §11

NIS 2 access control under Article 21(2)(i)+(j)

Article 21(2)(i) names access control policies. Article 21(2)(j) names multi-factor authentication. CIR §11 covers them together in seven sub-sections. This page walks the broader policy, privileged-account and identity duties. The dedicated MFA page covers §11.7.

Simon OrzelSimon Orzel·

The short version

Access control sits at points (i) and (j) of Article 21(2). Point (i) names 'human resources security, access control policies and asset management'. Point (j) names 'the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications'. Both apply to every essential and important entity across the EU.

CIR (EU) 2024/2690 §11 covers both letters together, under the heading 'Access control (Article 21(2) points (i) and (j) of Directive (EU) 2022/2555)'. It splits the duty into seven sub-sections: the policy itself, rights management, privileged accounts, system-administration systems, identification, authentication, and multi-factor authentication. This page walks §11.1 through §11.6. For §11.7 specifically, see the dedicated MFA page.

Germany puts the policy duty into §30(2)(9) BSIG and the MFA duty into §30(2)(10) BSIG. The German baseline for implementation is IT-Grundschutz ORP.4 'Identitäts- und Berechtigungsmanagement'.

The legal source
Three layers, but the directive level splits into two letters. Article 21(2)(i) for access control policies (with personnel security and asset management). Article 21(2)(j) for MFA and secure communications. CIR §11 then covers both letters together. BSIG splits them again at the national level.

info.accessControl.legalAnchor.directiveI.label

info.accessControl.legalAnchor.directiveI.quote

info.accessControl.legalAnchor.directiveI.context

info.accessControl.legalAnchor.directiveJ.label

info.accessControl.legalAnchor.directiveJ.quote

info.accessControl.legalAnchor.directiveJ.context

CIR (EU) 2024/2690, Annex §11

Access control (Article 21(2), points (i) and (j) of Directive (EU) 2022/2555).

CIR §11 has seven sub-sections: §11.1 access control policy, §11.2 management of access rights, §11.3 privileged accounts and system-administration accounts, §11.4 system-administration systems, §11.5 identification, §11.6 authentication, §11.7 multi-factor authentication. This regulation binds DNS providers, cloud, data centres, managed service providers and the other sectors named in the Annex directly.

§30(2)(9) and (10) BSIG (Germany)

Konzepte für die Zugriffskontrolle und für das Management von Anlagen. […] Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung.

Germany splits the EU's point (i)+(j) into two BSIG numbers. §30(2)(9) carries access control and asset management. §30(2)(10) carries MFA and secure communications. The substance is the same EU rule.

The three things CIR §11 actually requires (excluding §11.7 MFA)
CIR §11 splits access control into seven sub-sections. Sub-sections §11.1 to §11.6 cover the policy, the rights register, privileged accounts and the identity layer. §11.7 (MFA) has its own page. Here are the three blocks the other six sub-sections fall into.
§11.1 + §11.2

Policy and rights management

Write down how access works (logical and physical) for staff, visitors, providers and service providers. Grant, modify and revoke rights based on business need: need-to-know, need-to-use, separation of duties. Every right is assigned to a named person. Revocation runs on employment change, not on a weekly cycle. Third-party access (visitors, providers) is tracked.

§11.3 + §11.4

Privileged and admin accounts

Admin accounts get strong identification, authentication and authorisation. Dedicated administration accounts only, used solely for installation, configuration, management and maintenance. Admin rights are tailored individually and restricted. System-administration systems sit on their own logical network, separated from application networks, accessed via authentication and encryption.

§11.5 + §11.6

Identity and authentication

Identity lifecycle: unique IDs, each ID linked to one person, monitoring and logging across the lifecycle. Authentication procedures match the access control policy: password strength scaled to asset classification, change procedures, lockout on failed attempts, session timeouts, separate credentials for privileged accounts.

Two rules that shape everything else
Two principles run through every CIR §11 sub-section. Both decide how an auditor reads what you actually built.

Need-to-know, need-to-use, separation of duties

CIR §11.2 names all three. Need-to-know: only people who need the data get the data. Need-to-use: rights match the task, not the title. Separation of duties: no single person should be able to grant, use and audit the same right. If your AD groups are 'IT' and 'everyone else', you have not implemented any of the three.

Privileged is not just regular with more rights

CIR §11.3 and §11.4 elevate the bar specifically for admin accounts. Strong identification. MFA named in §11.3 itself, not just §11.7. Dedicated accounts used only for admin work. System-administration systems on their own network. The point: a compromised admin account compromises everything, so admin accounts get their own regime.

How national regulators actually run this
The EU sets the rule. Each country transposes it. The substance is the same. The local mechanics differ a little.
Germany

BSI / IT-Grundschutz ORP.4

The German baseline is IT-Grundschutz module ORP.4 'Identitäts- und Berechtigungsmanagement'. ORP.4 covers identity lifecycle, role-based rights, privileged account separation, password rules, and review cadence. Under §44(2) BSIG, implementing Grundschutz is explicitly recognised as fulfilling the NIS 2 obligations in Germany.

EU-wide

ENISA Technical Implementation Guidance

ENISA's Technical Implementation Guidance for CIR (EU) 2024/2690 walks each §11 sub-section in operational language and maps it onto ISO/IEC 27001:2022 (A.5.15 to A.5.18, A.8.2 to A.8.5) and NIST CSF 2.0 (PR.AA). An existing ISO 27001 access control implementation covers most of §11 already.

Other member states

National transposition laws

Every member state transposes Article 21(2)(i) and (j) into its own law (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The duties are identical because the directive sets one EU-wide standard. What differs: which baseline standard the national regulator points at.

Three traps we see all the time
Three assumptions that turn up in almost every Mittelstand access control review. All three create gaps an auditor will find.

  • We have AD groups, so we have access control.

    A start, not the finish. CIR §11.2 wants a documented access-rights policy, rights assigned to named persons, a revocation procedure tied to employment change, and an audit log of grants and revocations. AD groups give you the mechanism. They do not give you the policy, the named-person register, or the joiners-movers-leavers procedure that an auditor will ask for.

  • Our admins use their normal account for admin work, with sudo or 'run as administrator'.

    Not under CIR §11.3.2. The text requires 'dedicated administration accounts' used only for installation, configuration, management and maintenance. An admin's regular account is for email, calendar and Excel. A separate admin account, with its own MFA, is for the privileged work. Mixing the two means a phishing email can compromise the admin role.

  • We sync access rights every Monday morning.

    Close, but not what §11.2 asks for. The revocation duty fires on employment change, not on a calendar cycle. Someone who left on Tuesday should not have access on Wednesday. For role changes inside the company, especially privileged ones, the change should be immediate. A weekly cadence is fine for the audit review, not for the revocation itself.

How real Mittelstand operators actually do this

Typical 50-250 person Mittelstand setup: Active Directory or Entra ID for identities, AD groups for application access, an HR system that issues onboarding tickets to IT. The mechanism is mostly there. The §11 gaps live in three places.

What we see practitioners catch first: a written access-rights policy (most have a draft, few have a current signed version), dedicated administration accounts (most admins still use sudo on their daily account), and the joiners-movers-leavers procedure being IT-only rather than HR-driven (so a contractor's account lingers because HR never told IT they left). Fixing those three closes most of the §11 gap.

How we handle this on the platform

Our ACC module covers §11.1 (you upload or draft the access control policy and the management body signs it off), §11.2 (a rights register linked to named users), §11.3 (privileged-account inventory with separate authentication evidence), and §11.5 plus §11.6 (identity-source log linked to your IdP). The §11.4 system-administration system separation is documented as an architecture decision with evidence.

For the §11.7 MFA piece specifically, see the dedicated MFA page and its evidence flow. The audit trail that the platform keeps automatically (sign-offs, task status, change log) covers what an auditor wants to see for review cadence and for the management decision.

Sources
  • Directive (EU) 2022/2555 (NIS 2), Article 21(2)(i) and (j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
  • Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §11 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
  • BSI Act (BSIG), §30(2)(9) and §30(2)(10) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
  • IT-Grundschutz Compendium, module ORP.4 'Identitäts- und Berechtigungsmanagement' — bsi.bund.de/grundschutz
  • ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (as of May 2026)
Run access control without the spreadsheet pile
Policy, rights register, privileged accounts and identity log on one platform. Free, open source, no lock-in.
Open the free platform