MFA under NIS 2 Article 21(2)(j)
NIS 2 makes multi-factor authentication a duty of its own. Article 21(2)(j) is where the obligation lives, CIR (EU) 2024/2690 §11.7 says where and how strong, and §30(2)(10) BSIG carries it into German law.
The short version
MFA is not optional and it is not just nice-to-have. Article 21(2)(j) puts it on the list of ten cybersecurity measures every essential and important entity has to put in place. The same wording also covers secure voice, video and text communication, and where it matters, secure emergency communications inside your organisation.
CIR (EU) 2024/2690 §11.7 fills in the detail. Users must authenticate with multiple factors or with continuous authentication when the classification of the asset they are accessing calls for it. The strength of the authentication has to match that classification. Crown jewels need stronger authentication than a coffee-menu portal.
CIR §11.3.2 then puts a hard floor under privileged accounts. Strong identification, authentication and authorisation procedures (multi-factor authentication is the example the CIR names) must be in place for privileged and system administration accounts by default. Germany copies the duty over through §30(2)(10) BSIG with almost the same wording.
Article 21(2)(j) NIS 2 Directive (2022/2555)
the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
Point (j) on the list of ten cybersecurity measures. It does two things at once: it names MFA (or continuous authentication) as the access-control standard, and it pulls secure internal voice, video, text and emergency comms into the same duty.
CIR (EU) 2024/2690, Annex §11.7 and §11.3
The relevant entities shall ensure that users are authenticated using multiple authentication factors or continuous authentication mechanisms for accessing the network and information systems of the relevant entities, where appropriate, in accordance with the classification of the asset to be accessed.
§11 is the CIR's access-control chapter and covers Article 21(2)(i) and (j) together. §11.7 is the MFA-specific sub-section. §11.3.2(a) goes further for privileged and administration accounts: strong identification, authentication (MFA named as the example) and authorisation procedures are required. Because the CIR is a regulation, it is directly binding EU law for the sectors named in its Annex.
§30(2)(10) BSIG (Germany)
the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
Germany copies the EU text almost word for word. Practical operationalisation in Germany points at IT-Grundschutz baustein ORP.4 (Identity and access management), which is the BSI's reference catalogue for getting authentication right in operations.
MFA appropriate to asset classification
Users authenticate with multiple factors or with continuous authentication for access to your network and information systems, calibrated to the classification of the asset they are reaching. The implicit precondition: you have classified your assets. Without a classification you cannot meet the rule.
Privileged accounts: MFA by default
For privileged accounts and for system administration accounts, strong identification, authentication and authorisation are mandatory. The CIR names multi-factor authentication as the worked example. This is the one place where MFA stops being conditional on classification and becomes the default state.
Authentication strength matches classification
The strength of the authentication has to be appropriate to the classification of the asset being accessed. That is the second test. MFA is not a single thing. SMS, app-based TOTP, push approval, FIDO2 hardware keys and certificate-based auth sit on very different rungs. The higher the classification, the higher the rung you need.
Secure communications, not only MFA (Article 21(2)(j))
Point (j) is wider than authentication. It names secure voice, video and text communication, and emergency communication systems inside the entity, where appropriate. An MFA roll-out alone does not close the obligation. Internal video conferencing, messaging and any out-of-band emergency channel are inside the same duty.
Asset classification drives depth (Article 21(1))
Article 21(1) requires measures to be appropriate and proportionate. The CIR turns that into a concrete test for MFA: the classification of the asset sets the strength. A small Stadtwerk does not need FIDO2 hardware keys for every internal portal. A control-system jump host is a different conversation. The classification is the lever, not the company size alone.
BSI / §30(2)(10) BSIG
Germany copies the EU wording almost verbatim into §30(2)(10) BSIG. The BSI's implementation reference is IT-Grundschutz baustein ORP.4 (Identity and access management), which gives concrete requirements for credential issuance, MFA, privileged account separation and emergency access. If you implement ORP.4 properly, you are inside the §30(2)(10) duty.
ENISA Technical Implementation Guidance
ENISA's TIG for the CIR walks through §11 in plain operational language and maps it onto ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 and CEN/TS 18026:2024. If you already run ISO 27001 (controls A.5.16, A.5.17, A.8.5) you are most of the way there. The TIG also lists the evidence auditors expect: MFA policy, account classification, enrolment records, exception register.
National transposition laws
Every member state has its own NIS 2 transposition (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The MFA duty itself is identical because it sits in the directive and the CIR. What differs across countries: the reference catalogue (Grundschutz in Germany, BIO in the Netherlands, no formal catalogue elsewhere), the reporting channel and the supervisory authority.
We have MFA on the VPN, so we are done.
VPN MFA is one access path. CIR §11.7 is about access to assets in line with their classification, not about one perimeter device. If a privileged user can reach a domain controller, a backup console, a cloud admin console or a SaaS tenant without MFA, the duty is not met. The classification of the asset behind the door is the test, not the door you came through.
SMS-based MFA is fine for everyone.
CIR §11.7.2 says the strength of authentication must match the classification. SMS and voice OTP are the weakest factor: SIM swap, SS7 interception and phishing all defeat them. For ordinary internal access the auditor may accept it. For crown jewels (admin consoles, control systems, identity providers) you need phishing-resistant authentication (FIDO2 / WebAuthn / smartcard). The strength must scale with the classification.
Service and system accounts don't need MFA.
CIR §11.3.2(a) explicitly covers privileged accounts and system administration accounts. Service accounts are out of scope of human MFA only if they are properly classified and use a different strong control (managed identities, short-lived credentials, signed certificates, vault-issued secrets with rotation). 'Service account, can't do MFA, exempt' is not a defence. Either it is human-driven (then MFA), or it is machine-driven (then a documented machine-credential model).
Most German Mittelstand teams start in the same place: MFA on every administrator account first (cloud admin consoles, domain admin, hypervisor, backup, network gear, SaaS tenants), then MFA on email, then MFA on the identity provider for all human users. That covers the §11.3.2 floor and the high-classification rows in one move. The rest is rolled out to all human users on classified assets within the first year.
What auditors actually open: the asset-classification list, the MFA enrolment report from your identity provider, and the exception register. If those three line up, the duty is met. The deepest single hole we see is not technical, it is documentary: the asset classification is missing, so there is no rule for which assets warrant which authentication strength. Fix the classification first, then the MFA roll-out reads itself off the list.
The platform's ACC (access control) module carries the §11 duty end-to-end. You record assets with their classification, list which user groups need access, and document the authentication strength for each row. The same table answers both the §11.7.1 (MFA where appropriate) and §11.7.2 (strength matches classification) tests, and surfaces the §11.3.2 privileged-account rows separately.
Sign-off on the access-control inventory is by name. Exceptions (the legacy system that cannot do MFA yet, the integration that has to use a service account) live in the same record with a documented compensating control and a review date. The audit trail and the platform's evidence export give the auditor the artefacts the ENISA TIG names: policy, classification, enrolment record, exception register, all in one place.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §11.3 and §11.7 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(10) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI IT-Grundschutz, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (as of May 2026)