Przejdź do treści głównej
NIS2Certify
Powrót do przeglądu

Wymogi MFA w NIS2: dlaczego „mamy MFA" już nie przechodzi audytu

Autor: NIS2Certify
nis2mfaodporne-na-phishingartykul-21enisa
Wymogi MFA w NIS2: dlaczego „mamy MFA" już nie przechodzi audytu

Wymogi MFA w NIS2: dlaczego „mamy MFA" już nie przechodzi audytu

Klient mówi, że uwierzytelnianie mają ogarnięte. Każdy ma Microsoft Authenticator, zatwierdzanie push jest wymuszone, gotowe. Wtedy audytor otwiera wytyczne techniczne ENISA i zadaje jedno pytanie: czy MFA na waszych kontach uprzywilejowanych jest odporne na phishing? I nagle odpowiedź brzmi nie.

To luka, której większość organizacji nie przewiduje. NIS2 wprost wymienia uwierzytelnianie wieloskładnikowe, ale konsensus nadzorców już dawno wyszedł poza podstawowe MFA. Jeśli doradzasz europejskim podmiotom w zakresie zgodności z NIS2, rozmowa o MFA sprzed osiemnastu miesięcy jest już nieaktualna.

Artykuł 21(2)(j) wymienia MFA — ale nie definiuje „wystarczająco dobre"

Artykuł 21(2)(j) NIS2 wymaga „stosowania rozwiązań uwierzytelniania wieloskładnikowego lub uwierzytelniania ciągłego, zabezpieczonej komunikacji głosowej, wideo i tekstowej oraz zabezpieczonych systemów łączności alarmowej w obrębie podmiotu, w stosownych przypadkach."

Dwa sformułowania w tym zdaniu wprowadzają w błąd. Pierwsze to „w stosownych przypadkach." To nie jest dobrowolność. Oznacza, że podmiot musi podjąć udokumentowaną, opartą na ryzyku decyzję o tym, gdzie MFA ma zastosowanie. Audytor, który znajdzie konta uprzywilejowane bez MFA i bez oceny ryzyka wyjaśniającej to pominięcie, potraktuje to jako ustalenie, a nie kwestię uznaniową.

Drugi problem to to, czego dyrektywa nie mówi. Artykuł 21 wymienia MFA, ale nigdy nie definiuje, które czynniki się kwalifikują. Ten szczegół znajduje się w rozporządzeniu wykonawczym Komisji (UE) 2024/2690 z dnia 17 października 2024 r., które ustala wymogi techniczne i metodyczne dla środków zarządzania ryzykiem. Dyrektywa mówi, że potrzebujesz MFA. Rozporządzenie wykonawcze, i oparte na nim wytyczne, mówi jakiego rodzaju.

ENISA już ustawiła poprzeczkę na odporność na phishing

W czerwcu 2025 r. ENISA opublikowała wersję 1.0 swoich Technical Implementation Guidance do rozporządzenia wykonawczego 2024/2690. To dokument, na którym opierają się nadzorcy, oceniając, czy wasze środki faktycznie spełniają normę.

Wytyczne są jednoznaczne: wybierz metodę uwierzytelniania, której poziom pewności odpowiada klasyfikacji chronionych danych i systemów, i stosuj opcje odporne na phishing „wszędzie tam, gdzie to możliwe." Wymieniają klucze bezpieczeństwa FIDO2 i passkeys, oparte na standardach FIDO i W3C WebAuthn, jako najsilniejszą dostępną metodę — przed hasłami, kodami SMS i hasłami jednorazowymi z aplikacji.

Uzasadnienie jest techniczne, a nie modowe. Powiadomienia push, kody OTP i SMS opierają się na współdzielonym sekrecie lub zatwierdzeniu, które można wyłudzić od użytkownika. Atakujący pokonują je codziennie za pomocą zmęczenia MFA, proxy adversary-in-the-middle i podmiany kart SIM. Passkeys i klucze FIDO2 są z założenia powiązane z domeną: poświadczenie po prostu nie zostanie wydane wobec sfałszowanej domeny. Nie ma kodu do wyłudzenia ani monitu do zmęczenia.

Dla podmiotu kluczowego ma to znaczenie zarówno finansowe, jak i techniczne. Brak zgodności naraża podmioty kluczowe na kary do 10 milionów euro lub 2% rocznego światowego obrotu. „Mieliśmy MFA" to słaba obrona, gdy własna agencja nadzorcy udokumentowała, że wdrożone MFA było tym słabym rodzajem.

Artykuł 21 — 10 Środków Cyberbezpieczeństwa NIS2
Artykuł 21
10 Środków Cyberbezpieczeństwa
Zarządzanie & Strategia
1Analiza ryzyka & polityki bezpieczeństwa informacji
6Ocena skuteczności środków bezpieczeństwa
Incydenty & Ciągłość
2Obsługa incydentów & zgłaszanie
3Ciągłość działania & odtwarzanie po awarii
Łańcuch Dostaw & Systemy
4Bezpieczeństwo łańcucha dostaw
5Bezpieczeństwo w rozwoju systemów sieciowych i informatycznych
Kontrole Techniczne
8Kryptografia & szyfrowanie
10Uwierzytelnianie wieloskładnikowe & bezpieczna komunikacja
Ludzie & Zasoby
7Cyberhigiena & szkolenia
9Bezpieczeństwo HR & kontrola dostępu

Nie każde konto potrzebuje tego samego czynnika

Praktyczny błąd w drugą stronę to traktowanie odpornego na phishing MFA jako wdrożenia wszystko-albo-nic i utknięcie, bo klucze sprzętowe dla 4000 pracowników wyglądają drogo. Wytyczne są stopniowane według ryzyka i tak samo powinno być twoje doradztwo.

Dostęp uprzywilejowany i o dużym wpływie to obszar, gdzie odporne na phishing MFA jest faktycznie nienegocjowalne: administratorzy domeny, administratorzy dzierżawy chmurowej, dostęp do konsol hypervisora i kopii zapasowych oraz każde konto zdolne wyłączyć środki bezpieczeństwa. Jeśli jedno z nich zostanie skompromitowane, incydent kończy się, zanim się zaczął. Wdróż tu najpierw klucze FIDO2 lub passkeys platformowe.

Dostęp zdalny i tożsamości skierowane na zewnątrz są następne — VPN, bramy RDP i każdy system osiągalny z internetu. To frontowe drzwi, do których faktycznie pukają atakujący, więc poziom pewności powinien być wysoki.

Standardowe konta pracownicze mogą przechodzić na odporne na phishing MFA według zaplanowanego harmonogramu, ale kierunek musi być jasny w dokumentacji. Audytor chce zobaczyć, że wiesz, gdzie nadal jest słabe MFA, i masz datowany plan jego wycofania, a nie że rozwiązałeś wszystko z dnia na dzień.

To stopniowanie pozwala też zachować rozsądek w rozmowach budżetowych. Konsultant, który wchodzi i żąda 200 000 euro na klucze sprzętowe, traci salę. Konsultant, który mówi „trzydzieści kluczy FIDO2 dla waszych piętnastu uprzywilejowanych administratorów w tym kwartale, passkeys dla reszty w następnym", dostaje podpis.

Jak uczynić to audytowalnym, a nie tylko wdrożonym

Wdrożenie to połowa pracy. Połowa, która przetrwa audyt, to dokumentacja dowodząca, że wdrożenie było świadomą, opartą na ryzyku decyzją w rozumieniu artykułu 21.

Trzy artefakty dźwigają większość ciężaru. Po pierwsze, klasyfikacja dostępu, która przypisuje typy kont do wymaganych poziomów pewności — to dokument operacjonalizujący „w stosownych przypadkach." Po drugie, dowód egzekwowania, czyli polityki dostępu warunkowego lub równoważne, które faktycznie blokują niezgodne logowania, zamiast jedynie zalecać MFA. Polityka w trybie „report-only" nie jest środkiem. Po trzecie, rejestr wyjątków: każde konto, które nie może jeszcze używać odpornego na phishing MFA, dlaczego, środek kompensujący i data naprawy.

Zrób te trzy dobrze, a sekcja MFA w audycie stanie się krótka. Pomiń je, a nawet technicznie solidne wdrożenie wygląda na szczęście, a nie na ład organizacyjny.

Czy NIS2 Dotyczy Twojej Organizacji?
1
Czy Twoja organizacja działa w sektorze kluczowym lub ważnym (energia, transport, ochrona zdrowia, infrastruktura cyfrowa itp.)?
Tak ↓Nie →
2
Czy Twoja organizacja zatrudnia co najmniej 50 pracowników lub osiąga roczny obrót przekraczający 10 milionów euro?
Tak ↓Nie →
3
Czy Twoja organizacja jest dostawcą infrastruktury krytycznej lub kwalifikowanym dostawcą usług zaufania?
Tak ↓Nie →
✗
NIS2 nie dotyczy bezpośrednio Twojej organizacji.
✓
NIS2 dotyczy Twojej organizacji jako podmiotu kluczowego lub ważnego.
!
NIS2 może dotyczyć Twojej organizacji — skonsultuj się z prawnikiem w celu potwierdzenia statusu.
Dotyczy
Możliwe zastosowanie
Nie dotyczy

Co to oznacza dla MSP zarządzających wieloma dzierżawami

Jeśli prowadzisz tożsamość dla kilku klientów, przejście na odporność na phishing to program operacyjny, a nie poprawka klient po kliencie. Klienci, którzy będą mieli trudności, to ci wciąż na przestarzałym MFA na całej linii, a zwykle są to twoje mniejsze zlecenia, gdzie opór budżetowy jest największy.

Standaryzuj teraz. Wybierz odporną na phishing metodę, którą możesz wdrażać i wspierać na skalę — passkeys platformowe plus zapasowy klucz sprzętowy dla administratorów to obronny standard — i uczyń ją linią bazową dla każdej dzierżawy. Zbuduj klasyfikację dostępu raz jako szablon i dostosowuj ją do klienta, zamiast wymyślać ją na nowo przy każdym zleceniu. I włącz rejestr wyjątków do swojego normalnego rytmu raportowania, aby daty naprawy nie przemknęły cicho obok terminu audytu.

Koszt zrobienia tego źle nie jest rozłożony równo. Gdy naruszenie spada na zarządzanego klienta, a przyczyną źródłową jest podatne na phishing MFA na koncie administratora, przepisy NIS2 dotyczące łańcucha dostaw kierują rozmowę ku twojej umowie, a nie tylko ich.

Eskalacja sankcji NIS2 — Poza karą finansową
!
Zdarzenie wyzwalające
Wykryto niezgodność lub wystąpił incydent
Organ nadzorczy identyfikuje lukę w zgodności lub organizacja nie spełnia wymagań NIS2
Organy mogą nałożyć
▼
Sankcje niefinansowe
1
Nakazy zgodności z wiążącymi terminami
2
Obowiązkowe audyty bezpieczeństwa na Twój koszt
3
Publiczne ujawnienie naruszeń
4
Wiążące instrukcje dotyczące konkretnych środków bezpieczeństwa
Eskaluje do
▼
Konsekwencje operacyjne i osobiste
1
Zawieszenie certyfikatów lub licencji operacyjnych
2
Tymczasowy zakaz pełnienia funkcji zarządczych dla osób
3
Publiczne wskazanie odpowiedzialnych osób fizycznych
Zdarzenie wyzwalające
Niefinansowe
Operacyjne / osobiste

Ruch do wykonania w tym kwartale

Przestań traktować MFA jak już odhaczone pole. Pytanie, które ma znaczenie pod NIS2, nie brzmi już „czy mamy MFA", lecz „czy nasze MFA jest odporne na phishing tam, gdzie to się liczy, i czy możemy udowodnić, że decyzja była świadoma."

Zacznij od kont uprzywilejowanych, udokumentuj poziomy ryzyka, egzekwuj w trybie blokowania i prowadź uczciwy rejestr wyjątków. To różnica między czystym a kosztownym ustaleniem dotyczącym uwierzytelniania.

Jeśli nie masz pewności, gdzie naprawdę stoi MFA twoich klientów wobec wytycznych ENISA, ustrukturyzowana ocena gotowości ujawni luki, zanim zrobi to audytor. Wykonaj bezpłatny quick scan NIS2, aby zobaczyć, gdzie dziś są uwierzytelnianie i reszta środków artykułu 21.

Aby zobaczyć szerszy obraz tego, czego wymaga artykuł 21, zobacz nasze omówienie dziesięciu środków artykułu 21. Aby przetestować swoją ogólną postawę, przejdź przez nasz przewodnik krok po kroku po analizie luk.