MFA conform NIS 2, articolul 21 alin. (2) lit. (j)
NIS 2 face din autentificarea cu mai mulți factori o obligație de sine stătătoare. Articolul 21 alin. (2) lit. (j) este locul în care se află obligația, CIR (UE) 2024/2690 §11.7 spune unde și cât de puternică, iar §30 alin. (2) pct. 10 BSIG o duce în dreptul german.
Pe scurt
MFA nu este opțională și nu este doar un plus de avut. Articolul 21 alin. (2) lit. (j) o pune pe lista celor zece măsuri de securitate cibernetică pe care fiecare entitate esențială și importantă trebuie să le implementeze. Aceeași formulare acoperă și comunicarea vocală, video și text securizată, și, unde contează, comunicațiile de urgență securizate din interiorul organizației tale.
CIR (UE) 2024/2690 §11.7 completează detaliile. Utilizatorii trebuie să se autentifice cu mai mulți factori sau cu autentificare continuă atunci când clasificarea activului pe care îl accesează o impune. Puterea autentificării trebuie să corespundă acelei clasificări. Bijuteriile coroanei au nevoie de o autentificare mai puternică decât un portal cu meniul cafenelei.
CIR §11.3.2 stabilește apoi un prag minim ferm pentru conturile privilegiate. Procedurile puternice de identificare, autentificare și autorizare (autentificarea cu mai mulți factori este exemplul pe care CIR îl numește) trebuie să fie implementate în mod implicit pentru conturile privilegiate și de administrare a sistemelor. Germania copiază obligația prin §30 alin. (2) pct. 10 BSIG cu o formulare aproape identică.
Articolul 21 alin. (2) lit. (j) Directiva NIS 2 (2022/2555)
utilizarea de soluții de autentificare cu mai mulți factori sau de autentificare continuă, de comunicații vocale, video și text securizate și de sisteme de comunicații de urgență securizate în cadrul entității, după caz.
Punctul (j) de pe lista celor zece măsuri de securitate cibernetică. Face două lucruri deodată: numește MFA (sau autentificarea continuă) drept standard de control al accesului și aduce comunicațiile interne securizate vocale, video, text și de urgență în aceeași obligație.
CIR (UE) 2024/2690, Anexa §11.7 și §11.3
Entitățile relevante se asigură că utilizatorii sunt autentificați folosind mai mulți factori de autentificare sau mecanisme de autentificare continuă pentru accesarea rețelelor și sistemelor informatice ale entităților relevante, după caz, în conformitate cu clasificarea activului care urmează să fie accesat.
§11 este capitolul CIR privind controlul accesului și acoperă împreună articolul 21 alin. (2) lit. (i) și (j). §11.7 este subsecțiunea specifică MFA. §11.3.2 lit. (a) merge mai departe pentru conturile privilegiate și de administrare: sunt necesare proceduri puternice de identificare, autentificare (MFA numită drept exemplu) și autorizare. Întrucât CIR este un regulament, este drept al UE direct obligatoriu pentru sectoarele numite în Anexa sa.
§30 alin. (2) pct. 10 BSIG (Germania)
utilizarea de soluții de autentificare cu mai mulți factori sau de autentificare continuă, de comunicații vocale, video și text securizate și de sisteme de comunicații de urgență securizate în cadrul entității, după caz.
Germania copiază textul UE aproape cuvânt cu cuvânt. Operaționalizarea practică în Germania trimite la blocul IT-Grundschutz ORP.4 (gestionarea identității și a accesului), care este catalogul de referință al BSI pentru o autentificare corectă în operațiuni.
MFA adecvată clasificării activului
Utilizatorii se autentifică cu mai mulți factori sau cu autentificare continuă pentru accesul la rețelele și sistemele tale informatice, calibrat la clasificarea activului pe care îl accesează. Precondiția implicită: ți-ai clasificat activele. Fără o clasificare nu poți îndeplini regula.
Conturi privilegiate: MFA în mod implicit
Pentru conturile privilegiate și pentru conturile de administrare a sistemelor, identificarea, autentificarea și autorizarea puternice sunt obligatorii. CIR numește autentificarea cu mai mulți factori drept exemplul de referință. Acesta este singurul loc unde MFA nu mai este condiționată de clasificare și devine starea implicită.
Puterea autentificării corespunde clasificării
Puterea autentificării trebuie să fie adecvată clasificării activului accesat. Acesta este al doilea test. MFA nu este un lucru unic. SMS, TOTP bazat pe aplicație, aprobare prin push, chei hardware FIDO2 și autentificare bazată pe certificate se află pe trepte foarte diferite. Cu cât clasificarea este mai înaltă, cu atât treapta de care ai nevoie este mai înaltă.
Comunicații securizate, nu doar MFA (articolul 21 alin. (2) lit. (j))
Punctul (j) este mai larg decât autentificarea. Numește comunicarea vocală, video și text securizată și sistemele de comunicații de urgență din interiorul entității, după caz. O simplă implementare a MFA nu închide obligația. Videoconferințele interne, mesageria și orice canal de urgență în afara benzii intră în aceeași obligație.
Clasificarea activelor determină profunzimea (articolul 21 alin. (1))
Articolul 21 alin. (1) cere ca măsurile să fie adecvate și proporționale. CIR transformă asta într-un test concret pentru MFA: clasificarea activului stabilește puterea. Un mic Stadtwerk nu are nevoie de chei hardware FIDO2 pentru fiecare portal intern. Un jump host al unui sistem de control este o discuție diferită. Pârghia este clasificarea, nu doar mărimea companiei.
BSI / §30 alin. (2) pct. 10 BSIG
Germania copiază formularea UE aproape textual în §30 alin. (2) pct. 10 BSIG. Referința de implementare a BSI este blocul IT-Grundschutz ORP.4 (gestionarea identității și a accesului), care oferă cerințe concrete pentru emiterea de credențiale, MFA, separarea conturilor privilegiate și accesul de urgență. Dacă implementezi ORP.4 corect, ești în interiorul obligației din §30 alin. (2) pct. 10.
ENISA, ghidul tehnic de implementare
TIG-ul ENISA pentru CIR parcurge §11 într-un limbaj operațional clar și îl pune în corespondență cu ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 și CEN/TS 18026:2024. Dacă rulezi deja ISO 27001 (controalele A.5.16, A.5.17, A.8.5), ești aproape de obiectiv. TIG-ul listează și dovezile pe care le așteaptă auditorii: politica MFA, clasificarea conturilor, înregistrările de înrolare, registrul de excepții.
Legi naționale de transpunere
Fiecare stat membru are propria transpunere NIS 2 (Țările de Jos: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obligația MFA în sine este identică, deoarece se află în directivă și în CIR. Ce diferă între țări: catalogul de referință (Grundschutz în Germania, BIO în Țările de Jos, niciun catalog formal în altă parte), canalul de raportare și autoritatea de supraveghere.
Avem MFA pe VPN, deci am terminat.
MFA pe VPN este o singură cale de acces. CIR §11.7 se referă la accesul la active în concordanță cu clasificarea lor, nu la un singur dispozitiv de perimetru. Dacă un utilizator privilegiat poate ajunge la un controler de domeniu, la o consolă de backup, la o consolă de administrare cloud sau la un tenant SaaS fără MFA, obligația nu este îndeplinită. Testul este clasificarea activului din spatele ușii, nu ușa prin care ai intrat.
MFA prin SMS e suficientă pentru toată lumea.
CIR §11.7.2 spune că puterea autentificării trebuie să corespundă clasificării. SMS-ul și OTP-ul vocal sunt cel mai slab factor: schimbul de SIM, interceptarea SS7 și phishingul le înfrâng pe toate. Pentru accesul intern obișnuit, auditorul îl poate accepta. Pentru bijuteriile coroanei (console de administrare, sisteme de control, furnizori de identitate) ai nevoie de autentificare rezistentă la phishing (FIDO2 / WebAuthn / smartcard). Puterea trebuie să scaleze cu clasificarea.
Conturile de serviciu și de sistem nu au nevoie de MFA.
CIR §11.3.2 lit. (a) acoperă explicit conturile privilegiate și conturile de administrare a sistemelor. Conturile de serviciu sunt în afara domeniului MFA uman doar dacă sunt clasificate corespunzător și folosesc un alt control puternic (identități gestionate, credențiale cu durată scurtă, certificate semnate, secrete emise dintr-un vault cu rotație). „Cont de serviciu, nu poate face MFA, scutit” nu este o apărare. Ori este condus de oameni (atunci MFA), ori este condus de mașini (atunci un model documentat de credențiale de mașină).
Cele mai multe echipe germane din Mittelstand încep în același loc: mai întâi MFA pe fiecare cont de administrator (console de administrare cloud, administrator de domeniu, hypervisor, backup, echipamente de rețea, tenanți SaaS), apoi MFA pe e-mail, apoi MFA pe furnizorul de identitate pentru toți utilizatorii umani. Asta acoperă pragul minim din §11.3.2 și rândurile cu clasificare înaltă într-o singură mișcare. Restul este implementat pentru toți utilizatorii umani pe activele clasificate în primul an.
Ce deschid efectiv auditorii: lista de clasificare a activelor, raportul de înrolare MFA din furnizorul tău de identitate și registrul de excepții. Dacă acele trei se aliniază, obligația este îndeplinită. Cea mai adâncă gaură pe care o vedem nu este tehnică, ci documentară: lipsește clasificarea activelor, deci nu există o regulă pentru ce active justifică ce putere de autentificare. Repară mai întâi clasificarea, apoi implementarea MFA se citește singură de pe listă.
Modulul ACC (controlul accesului) al platformei duce obligația din §11 de la un capăt la altul. Înregistrezi activele cu clasificarea lor, listezi ce grupuri de utilizatori au nevoie de acces și documentezi puterea autentificării pentru fiecare rând. Același tabel răspunde atât testului §11.7.1 (MFA după caz), cât și testului §11.7.2 (puterea corespunde clasificării) și evidențiază separat rândurile cu conturi privilegiate din §11.3.2.
Aprobarea inventarului de control al accesului se face pe nume. Excepțiile (sistemul vechi care încă nu poate face MFA, integrarea care trebuie să folosească un cont de serviciu) trăiesc în aceeași evidență, cu un control compensatoriu documentat și o dată de revizuire. Traseul de audit și exportul de dovezi al platformei îi oferă auditorului artefactele pe care le numește TIG-ul ENISA: politica, clasificarea, înregistrarea de înrolare, registrul de excepții, toate într-un singur loc.
- Directiva (UE) 2022/2555 (NIS 2), articolul 21 alin. (2) lit. (j), eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamentul de punere în aplicare (UE) 2024/2690 al Comisiei (CIR), Anexa §11.3 și §11.7, eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legea BSI (BSIG), §30 alin. (2) pct. 10, astfel cum a fost modificată prin Legea de implementare a NIS2 și de întărire a securității cibernetice
- BSI IT-Grundschutz, blocul ORP.4 „Identitäts- und Berechtigungsmanagement”
- ENISA, ghidul tehnic de implementare pentru CIR (UE) 2024/2690 (la zi în mai 2026)