MFA podle článku 21(2)(j) NIS 2
NIS 2 činí z vícefaktorové autentizace samostatnou povinnost. Povinnost žije v článku 21(2)(j), CIR (EU) 2024/2690 §11.7 určuje kde a jak silně a §30(2)(10) BSIG ji přenáší do německého práva.
Krátká verze
MFA není volitelná a není jen příjemný doplněk. Článek 21(2)(j) ji řadí mezi deset opatření kybernetické bezpečnosti, která musí zavést každý zásadní a důležitý subjekt. Stejná formulace pokrývá i zabezpečenou hlasovou, video a textovou komunikaci a tam, kde na tom záleží, i zabezpečenou nouzovou komunikaci uvnitř vaší organizace.
CIR (EU) 2024/2690 §11.7 doplňuje detail. Uživatelé se musí autentizovat více faktory nebo průběžnou autentizací, pokud to vyžaduje klasifikace aktiva, k němuž přistupují. Síla autentizace musí odpovídat této klasifikaci. Korunní klenoty potřebují silnější autentizaci než portál s nabídkou kávy.
CIR §11.3.2 pak stanoví pevnou spodní hranici pro privilegované účty. U privilegovaných účtů a účtů pro správu systému musí být ve výchozím nastavení zavedeny silné postupy identifikace, autentizace a autorizace (CIR jako příklad uvádí vícefaktorovou autentizaci). Německo tuto povinnost přebírá přes §30(2)(10) BSIG téměř se stejným zněním.
Článek 21(2)(j) směrnice NIS 2 (2022/2555)
používání řešení vícefaktorové autentizace nebo průběžné autentizace, zabezpečené hlasové, video a textové komunikace a zabezpečených systémů nouzové komunikace uvnitř subjektu, je-li to vhodné.
Bod (j) v seznamu deseti opatření kybernetické bezpečnosti. Dělá dvě věci najednou: jmenuje MFA (nebo průběžnou autentizaci) jako standard řízení přístupu a vtahuje zabezpečenou interní hlasovou, video, textovou a nouzovou komunikaci do téže povinnosti.
CIR (EU) 2024/2690, příloha §11.7 a §11.3
Relevantní subjekty zajistí, aby uživatelé byli pro přístup k sítím a informačním systémům relevantních subjektů autentizováni pomocí více autentizačních faktorů nebo mechanismů průběžné autentizace, je-li to vhodné, v souladu s klasifikací aktiva, k němuž má být přistupováno.
§11 je kapitola CIR o řízení přístupu a pokrývá články 21(2)(i) a (j) společně. §11.7 je pododdíl specifický pro MFA. §11.3.2(a) jde u privilegovaných a administrátorských účtů dále: vyžaduje silné postupy identifikace, autentizace (jako příklad je uvedena MFA) a autorizace. Protože CIR je nařízení, je pro sektory uvedené v jeho příloze přímo závazným právem EU.
§30(2)(10) BSIG (Německo)
používání řešení vícefaktorové autentizace nebo průběžné autentizace, zabezpečené hlasové, video a textové komunikace a zabezpečených systémů nouzové komunikace uvnitř subjektu, je-li to vhodné.
Německo kopíruje text EU téměř slovo od slova. Praktická operacionalizace v Německu míří na baustein ORP.4 z IT-Grundschutz (správa identit a přístupů), což je referenční katalog BSI pro správné nastavení autentizace v provozu.
MFA přiměřená klasifikaci aktiva
Uživatelé se autentizují více faktory nebo průběžnou autentizací pro přístup k vašim sítím a informačním systémům, kalibrovaně podle klasifikace aktiva, k němuž se dostávají. Implicitní podmínka: máte klasifikovaná aktiva. Bez klasifikace pravidlo splnit nemůžete.
Privilegované účty: MFA ve výchozím nastavení
U privilegovaných účtů a účtů pro správu systému jsou povinné silná identifikace, autentizace a autorizace. CIR uvádí vícefaktorovou autentizaci jako vypracovaný příklad. Toto je jediné místo, kde MFA přestává být podmíněna klasifikací a stává se výchozím stavem.
Síla autentizace odpovídá klasifikaci
Síla autentizace musí odpovídat klasifikaci aktiva, k němuž se přistupuje. To je druhý test. MFA není jediná věc. SMS, aplikační TOTP, schválení push, hardwarové klíče FIDO2 a autentizace na bázi certifikátů stojí na velmi odlišných příčkách. Čím vyšší klasifikace, tím vyšší příčku potřebujete.
Zabezpečená komunikace, nejen MFA (článek 21(2)(j))
Bod (j) je širší než autentizace. Jmenuje zabezpečenou hlasovou, video a textovou komunikaci a systémy nouzové komunikace uvnitř subjektu, je-li to vhodné. Samotné zavedení MFA povinnost neuzavírá. Interní videokonference, posílání zpráv a jakýkoli záložní nouzový kanál mimo hlavní cestu spadají do téže povinnosti.
Hloubku určuje klasifikace aktiva (článek 21(1))
Článek 21(1) vyžaduje, aby opatření byla vhodná a přiměřená. CIR z toho dělá konkrétní test pro MFA: klasifikace aktiva určuje sílu. Malé Stadtwerk nepotřebuje hardwarové klíče FIDO2 pro každý interní portál. Skokový hostitel řídicího systému je jiná diskuse. Pákou je klasifikace, nikoli jen velikost společnosti.
BSI / §30(2)(10) BSIG
Německo kopíruje znění EU téměř doslovně do §30(2)(10) BSIG. Implementační referencí BSI je baustein ORP.4 z IT-Grundschutz (správa identit a přístupů), který dává konkrétní požadavky na vydávání přihlašovacích údajů, MFA, oddělení privilegovaných účtů a nouzový přístup. Pokud ORP.4 zavedete správně, jste uvnitř povinnosti podle §30(2)(10).
Technické implementační pokyny ENISA
TIG od ENISA k CIR prochází §11 v prostém provozním jazyce a mapuje jej na ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 a CEN/TS 18026:2024. Pokud již provozujete ISO 27001 (kontroly A.5.16, A.5.17, A.8.5), máte většinu hotovou. TIG také uvádí důkazy, které auditoři očekávají: politika MFA, klasifikace účtů, záznamy o zapojení, registr výjimek.
Národní transpoziční zákony
Každý členský stát má vlastní transpozici NIS 2 (Nizozemsko: Cyberbeveiligingswet, Rakousko: NISG, Belgie: NIS2-Wet). Samotná povinnost MFA je shodná, protože sídlí ve směrnici a v CIR. Co se mezi zeměmi liší: referenční katalog (Grundschutz v Německu, BIO v Nizozemsku, jinde žádný formální katalog), ohlašovací kanál a dozorový orgán.
Máme MFA na VPN, takže máme hotovo.
MFA na VPN je jedna přístupová cesta. CIR §11.7 je o přístupu k aktivům v souladu s jejich klasifikací, nikoli o jednom perimetrovém zařízení. Pokud se privilegovaný uživatel může bez MFA dostat na řadič domény, konzoli zálohování, cloudovou administrátorskou konzoli nebo SaaS prostředí, povinnost není splněna. Testem je klasifikace aktiva za dveřmi, nikoli dveře, kterými jste přišli.
MFA přes SMS stačí pro každého.
CIR §11.7.2 říká, že síla autentizace musí odpovídat klasifikaci. SMS a hlasové OTP jsou nejslabší faktor: výměna SIM, odposlech SS7 i phishing je porazí. Pro běžný interní přístup to auditor může přijmout. Pro korunní klenoty (administrátorské konzole, řídicí systémy, poskytovatelé identity) potřebujete autentizaci odolnou proti phishingu (FIDO2 / WebAuthn / čipová karta). Síla musí růst s klasifikací.
Servisní a systémové účty MFA nepotřebují.
CIR §11.3.2(a) výslovně pokrývá privilegované účty a účty pro správu systému. Servisní účty jsou mimo působnost lidské MFA jen tehdy, jsou-li řádně klasifikovány a používají jinou silnou kontrolu (spravované identity, krátkodobé přihlašovací údaje, podepsané certifikáty, tajemství vydávaná trezorem s rotací). „Servisní účet, nelze MFA, výjimka“ není obhajoba. Buď je řízen člověkem (pak MFA), nebo je řízen strojem (pak zdokumentovaný model strojových přihlašovacích údajů).
Většina německých týmů Mittelstandu začíná na stejném místě: nejprve MFA na každém administrátorském účtu (cloudové administrátorské konzole, doménový administrátor, hypervizor, zálohování, síťové prvky, SaaS prostředí), pak MFA na e-mail, pak MFA na poskytovateli identity pro všechny lidské uživatele. To pokrývá spodní hranici §11.3.2 i řádky s vysokou klasifikací jedním tahem. Zbytek se během prvního roku zavádí ke všem lidským uživatelům na klasifikovaných aktivech.
Co auditoři skutečně otevírají: seznam klasifikace aktiv, zprávu o zapojení do MFA od vašeho poskytovatele identity a registr výjimek. Pokud se tyto tři srovnají, povinnost je splněna. Nejhlubší jednotlivá díra, kterou vidíme, není technická, ale dokumentační: chybí klasifikace aktiv, takže neexistuje pravidlo, která aktiva si zaslouží jakou sílu autentizace. Nejprve opravte klasifikaci, pak se zavádění MFA samo přečte ze seznamu.
Modul ACC (řízení přístupu) na platformě nese povinnost §11 od začátku do konce. Zaznamenáte aktiva s jejich klasifikací, uvedete, které skupiny uživatelů potřebují přístup, a zdokumentujete sílu autentizace pro každý řádek. Stejná tabulka zodpovídá test §11.7.1 (MFA, je-li to vhodné) i §11.7.2 (síla odpovídá klasifikaci) a samostatně zobrazuje řádky privilegovaných účtů podle §11.3.2.
Schválení inventáře řízení přístupu je jmenovité. Výjimky (starší systém, který zatím MFA nezvládá, integrace, která musí používat servisní účet) žijí ve stejném záznamu se zdokumentovaným kompenzačním opatřením a datem revize. Auditní stopa a export důkazů z platformy dají auditorovi artefakty, které jmenuje TIG od ENISA: politika, klasifikace, záznam o zapojení, registr výjimek, vše na jednom místě.
- Směrnice (EU) 2022/2555 (NIS 2), článek 21(2)(j) (eur-lex.europa.eu/eli/dir/2022/2555/oj)
- Prováděcí nařízení Komise (EU) 2024/2690 (CIR), příloha §11.3 a §11.7 (eur-lex.europa.eu/eli/reg_impl/2024/2690/oj)
- Zákon o BSI (BSIG), §30(2)(10) ve znění zákona o zavedení NIS2 a posílení kybernetické bezpečnosti
- BSI IT-Grundschutz, Baustein ORP.4 „Identitäts- und Berechtigungsmanagement“
- Technické implementační pokyny ENISA k CIR (EU) 2024/2690 (stav květen 2026)