NIS2, ustawa o KSC i RODO7 nie podają długości hasła ani częstotliwości jego zmiany. Dyrektywa NIS24 i nowelizacja ustawy o KSC5 wymagają od podmiotów kluczowych i ważnych polityki kontroli dostępu i podstawowych zasad cyberhigieny, a uwierzytelniania wieloskładnikowego tylko "w stosownych przypadkach". Konkretne wartości, czyli co najmniej 14 znaków, brak wymuszanej zmiany i odrzucanie haseł znanych z wycieków, pochodzą z zaleceń CERT Polska1, nie z prawa. Dostawcy usług cyfrowych wymienieni w art. 8b ust. 1 ustawy mają natomiast według rozporządzenia 2024/26906 wymagać zmiany danych uwierzytelniających w określonych z góry odstępach, a to stoi w napięciu z zaleceniem CERT Polska.
Polityka haseł rozstrzyga kilka spraw: jak długie ma być hasło, czy wymagać cyfr i znaków specjalnych, czy i kiedy je zmieniać, dla których kont włączyć drugi składnik logowania i co robić po wycieku. NIS2, ustawa o KSC i RODO mówią o tych sprawach ogólnie albo wcale. Konkretne wartości pochodzą z rekomendacji CERT Polska, które nie są przepisem i są skierowane do administratorów systemów. Polityka, która pomyli te dwa poziomy, albo narzuci pracownikom regułę bez podstawy, albo przeoczy wymóg, który wynika z rozporządzenia.
Czego wymaga prawo, a co jest tylko zaleceniem
Dyrektywa NIS2 wylicza w art. 21 ust. 2, co mają obejmować środki zarządzania ryzykiem. Hasła z nazwy tam nie ma, są za to podstawowe praktyki cyberhigieny i szkolenia (lit. g), polityka kontroli dostępu (lit. i) oraz, "w stosownych przypadkach", uwierzytelnianie wieloskładnikowe lub ciągłe (lit. j)4. Środki mają być proporcjonalne do ryzyka, wielkości podmiotu oraz prawdopodobieństwa i dotkliwości incydentów (art. 21 ust. 1). Zmiana haseł pojawia się w całej dyrektywie tylko raz, w motywie 49, wśród przykładów praktyk cyberhigieny, a motyw nie podaje ani częstotliwości, ani przypadków, w których hasło trzeba zmienić. Nie jest też przepisem.
Ustawa o krajowym systemie cyberbezpieczeństwa (KSC) w brzmieniu z nowelizacji z 23 stycznia 2026 roku idzie tym samym tropem. Art. 8 ust. 1 pkt 2 nakłada na podmiot kluczowy i ważny obowiązek wdrożenia środków proporcjonalnych do oszacowanego ryzyka, w szczególności polityk szacowania ryzyka i bezpieczeństwa systemu informacyjnego (lit. a), edukacji personelu (lit. i), podstawowych zasad cyberhigieny (lit. j), polityk kontroli dostępu (lit. n) oraz bezpiecznych środków komunikacji elektronicznej, uwzględniających uwierzytelnianie wieloskładnikowe w stosownych przypadkach (lit. l)5. Podmioty, które spełniały przesłanki w dniu wejścia nowelizacji w życie, 3 kwietnia 2026 roku, mają na te obowiązki 12 miesięcy, czyli czas do 3 kwietnia 2027 roku (art. 33 ust. 1 nowelizacji), a odpowiada za nie kierownik podmiotu (art. 8c ust. 1). Ani dyrektywa, ani nowelizacja ustawy nie podają minimalnej długości hasła, wymaganego składu ani częstotliwości zmiany. Art. 8a pozwala Radzie Ministrów określić rozporządzeniem szczegółowe wymagania dla systemu zarządzania bezpieczeństwem informacji.
Konkretniejszy wymóg dotyczący danych uwierzytelniających ma grupa, którą art. 8b ust. 1 ustawy wylicza z nazwy: dostawcy usług DNS, rejestry domen najwyższego poziomu, dostawcy usług chmurowych i centrów przetwarzania danych, sieci dostarczania treści, usług zarządzanych i zarządzanych usług bezpieczeństwa, internetowych platform handlowych, wyszukiwarek i platform społecznościowych. Dalej nazywamy ich dostawcami usług cyfrowych. Stosują oni środki z rozporządzenia wykonawczego Komisji (UE) 2024/26906, a pozostałe podmioty kluczowe i ważne środki z aktów wykonawczych Komisji wydanych dla ich rodzaju działalności (art. 8b ust. 2). Pkt 11.6.2 załącznika do rozporządzenia nakazuje dostawcom usług cyfrowych wymagać zmiany danych uwierzytelniających "na początku, w określonych z góry odstępach czasu oraz w przypadku podejrzenia, że dane uwierzytelniające zostały naruszone" (lit. c). Do tego mają resetować dane i blokować użytkowników po określonej z góry liczbie nieudanych prób logowania (lit. d) oraz stosować osobne dane do kont uprzywilejowanych i administracyjnych (lit. f). Rozporządzenie mówi o danych uwierzytelniających, nie o hasłach, i nie podaje długości odstępu, więc dostawca ustala go sam.
Wymóg zmiany w określonych z góry odstępach stoi w napięciu z rekomendacją CERT Polska, według której system nie powinien wymuszać okresowej zmiany haseł1. Rekomendacja nie jest przepisem, więc dostawca objęty rozporządzeniem stosuje rozporządzenie. W pozostałych firmach okresowa zmiana nie wynika ani z dyrektywy, ani z ustawy. Podział na wymóg i zalecenie, według stanu na 7 października 2026 roku, wygląda tak:
| Element polityki | Co mówią przepisy | Co zaleca CERT Polska | Status |
|---|---|---|---|
| Minimalna długość hasła | Brak liczby w dyrektywie, w nowelizacji ustawy i w rozporządzeniu 2024/2690 | Co najmniej 14 znaków (od czerwca 2025 roku, wcześniej 12) i przyjmowanie haseł co najmniej do 64 znaków | Zalecenie |
| Skład hasła: cyfry, znaki specjalne, wielkie litery | Brak wymogu | Nie wymagać dodatkowych kryteriów złożoności | Zalecenie |
| Okresowa zmiana hasła lub danych uwierzytelniających | Dyrektywa i ustawa: brak wymogu. Dostawcy usług cyfrowych: zmiana danych uwierzytelniających w określonych z góry odstępach (pkt 11.6.2 lit. c) | Nie wymuszać okresowej zmiany haseł, wymusić ją po potwierdzonym lub podejrzewanym przejęciu hasła | Dostawcy usług cyfrowych: wymóg zmiany danych uwierzytelniających; CERT: nie wymuszać zmiany haseł |
| Odrzucanie haseł z wycieków | Brak wymogu | System nie pozwala ustawić hasła z listy słabych i często używanych | Zalecenie |
| Drugi składnik logowania | W stosownych przypadkach: NIS2 art. 21 ust. 2 lit. j, ustawa art. 8 ust. 1 pkt 2 lit. l (przy środkach komunikacji elektronicznej), rozporządzenie pkt 11.7.1 (zgodnie z klasyfikacją składnika aktywów) | Zaleca się wsparcie uwierzytelniania dwuskładnikowego | Wymóg warunkowy |
| Polityka kontroli dostępu | NIS2 art. 21 ust. 2 lit. i, ustawa art. 8 ust. 1 pkt 2 lit. n | Rekomendacje dotyczą systemów, nie polityki firmy | Wymóg, bez treści szczegółowych |
| Szkolenia i cyberhigiena | NIS2 art. 21 ust. 2 lit. g, ustawa art. 8 ust. 1 pkt 2 lit. i i j | Poradnik dla użytkowników i organizacji | Wymóg, bez treści szczegółowych |
| Środki odpowiednie do ryzyka w firmie spoza ustawy o KSC | RODO art. 32 ust. 1 i 2, bez wymogów dla hasła | Konkretne wartości dla systemów uwierzytelniania | Wymóg, bez treści szczegółowych |
Firma, która nie jest podmiotem kluczowym ani ważnym, nie ma obowiązków z rozdziału 3 ustawy o KSC, ale jako administrator danych osobowych, choćby danych własnych pracowników, podlega art. 32 RODO. Przepis każe wdrożyć środki techniczne i organizacyjne zapewniające bezpieczeństwo odpowiednie do ryzyka, a przy ocenie ryzyka uwzględnić w szczególności nieuprawniony dostęp do danych (ust. 1 i 2)7. Art. 32 RODO nie wymienia haseł. Ich długość, skład i zmianę administrator dobiera więc sam do oszacowanego ryzyka, a zalecenia CERT Polska mogą mu posłużyć jako punkt odniesienia. Podmioty kluczowe i ważne stosują art. 32 RODO obok ustawy o KSC, jeśli przetwarzają dane osobowe.
Rekomendacje CERT Polska dla systemów uwierzytelniania
CERT Polska opublikował rekomendacje techniczne 10 stycznia 2022 roku, a w czerwcu 2025 roku podniósł w nich minimalną długość hasła z 12 do 14 znaków1. Dokument jest skierowany do administratorów, twórców i projektantów systemów, które uwierzytelniają hasłem, więc opisuje to, co system ma egzekwować. CERT Polska opiera go na własnych badaniach oraz między innymi na wytycznych NIST (SP 800-63B), brytyjskiego NCSC i amerykańskiego FBI1.
System powinien ustalać minimalną długość hasła na co najmniej 14 znaków, przyjmować hasła co najmniej do 64 znaków i nie wymagać dodatkowych kryteriów złożoności, takich jak znaki specjalne, cyfry czy wielkie litery. Nie powinien wymuszać okresowej zmiany, a zmianę ma wymusić wtedy, gdy potwierdzono albo podejrzewa się, że hasło zostało przejęte lub upublicznione1. Pozostałe zasady dotyczą działania systemu: ma odrzucać hasła z listy słabych i często używanych oraz hasła z przewidywalnymi członami, na przykład nazwą firmy albo usługi, nie blokować wklejania w polu hasła, podawać dokładny powód odrzucenia nowego hasła i przechowywać hasła w postaci skrótu obliczonego algorytmem Argon2, bcrypt, PBKDF2 lub scrypt. Zaleca się też wsparcie uwierzytelniania dwuskładnikowego i wskaźnik siły nowego hasła1.
CERT Polska uzasadnia to dwiema obserwacjami. Według przytaczanych przez niego badań długość jest dla bezpieczeństwa hasła znacznie ważniejsza niż złożoność, a wymuszona zmiana daje hasła, które są najczęściej wariacją poprzednich i powstają w przewidywalny sposób2. Przewidywalny dodatek niewiele zmienia, jak pokazują przykłady z poradnika: zaq1@wsxCERT jest tak samo słabe jak zaq1@wsx, jeśli używa go pracownik CERT Polska, a hasła pozornie silne, takie jak Galwaniczny123$, złamano w teście wewnętrznym w czasie krótszym niż 5 minut przy zabezpieczeniu przestarzałym algorytmem SHA12.
CERT zauważa przy tym, że wiele organizacji nadal stosuje cykliczną zmianę hasła i wymóg znaków specjalnych, a to jego zdaniem szkodzi bezpieczeństwu polskich instytucji i użytkowników2. Okresowej zmiany haseł w systemach przetwarzających dane osobowe wymagało dawne rozporządzenie MSWiA z 29 kwietnia 2004 roku, które uchylono 6 lutego 2019 roku1.
Lista znanych haseł jako filtr przy ustawianiu hasła
CERT Polska publikuje polski zbiór około miliona haseł z wycieków, ułożonych od najczęściej używanych, i zaznacza, że administratorzy mogą go wykorzystać przy wdrażaniu polityki haseł1. Filtr działa w chwili ustawiania hasła: system porównuje nowe hasło z listą i odrzuca je, jeśli się na niej znajduje. Próbkę tego zbioru i odnośnik do pełnego pliku zawiera strona z polskim zbiorem około miliona haseł z wycieków, a hasła używanego w firmie nie wpisuje się przy tym do żadnej wyszukiwarki haseł.
Filtr sprawdza to, czego reguły składu sprawdzić nie mogą, czyli czy hasło już krąży po wyciekach. W analizie miliona haseł z listy CERT Polska widać to na liczbach. Klasyczną regułę złożoności, czyli co najmniej 8 znaków oraz wielką literę, małą literę, cyfrę i znak specjalny, spełnia tylko 893 z 1 001 240 wpisów listy (0,1%), więc reguła odrzuca prawie całą listę, a mimo to te 893 hasła z wycieków bez filtra zostałyby przyjęte. Co najmniej 14 znaków ma 71 001 wpisów (7,1%), więc sama minimalna długość również nie zastępuje filtra. Długość mimo to ma znaczenie, bo pozostałe 92,9% wpisów jest od 14 znaków krótszych. CERT Polska stawia filtr obok minimalnej długości1.
Uwierzytelnianie wieloskładnikowe i klucze dostępu
Dyrektywa i ustawa wiążą uwierzytelnianie wieloskładnikowe z formułą "w stosownych przypadkach": dyrektywa w art. 21 ust. 2 lit. j, ustawa w art. 8 ust. 1 pkt 2 lit. l, gdzie mówi o bezpiecznych środkach komunikacji elektronicznej uwzględniających ten mechanizm45. Rozporządzenie 2024/2690 wymaga od dostawców usług cyfrowych, by uwierzytelniali użytkowników wieloma czynnikami lub mechanizmami ciągłego uwierzytelniania w stosownych przypadkach, zgodnie z klasyfikacją składnika aktywów (pkt 11.7.1), a siła uwierzytelnienia ma odpowiadać tej klasyfikacji (pkt 11.6.2 lit. a)6. Żaden z tych przepisów nie nakazuje drugiego składnika bezwarunkowo, więc polityka haseł powinna wskazać, przy jakich kontach i systemach jest wymagany, i oprzeć ten wybór na oszacowanym ryzyku.
CERT Polska zaleca wsparcie uwierzytelniania dwuskładnikowego po stronie systemów1 i opisuje je jako weryfikację dwóch z trzech grup czynników: czegoś, co się zna, czegoś, co się posiada, i czegoś, czym się jest. Atakujący, który zdobył login i hasło, nie zaloguje się wtedy bez drugiego składnika2. Do kont administracyjnych rozporządzenie dokłada wymóg osobnych danych uwierzytelniających, który dostawcy usług cyfrowych muszą spełnić niezależnie od drugiego składnika6.
Drugi składnik nie chroni jednak w każdej postaci jednakowo. NIST w wytycznych SP 800-63B stwierdza, że składnik wymagający ręcznego przepisania, jak kod jednorazowy albo kod z SMS, nie jest odporny na phishing, bo fałszywa strona może przekazać go prawdziwej usłudze, więc phishing z pośrednikiem pokonuje taki składnik razem z hasłem3. Odporność daje uwierzytelnianie kryptograficzne związane z nazwą usługi3. Zapewniają je klucze dostępu (passkeys) i klucze sprzętowe standardu FIDO2: urządzenie podpisuje wyzwanie serwera dla konkretnej domeny, więc podpis wytworzony dla fałszywej strony nie zadziała w prawdziwej usłudze. Klucz dostępu zastępuje przy tym hasło, więc nie ma czego wyłudzić, a klucz sprzętowy użyty jako drugi składnik nie pozwala zalogować się samym wyłudzonym hasłem.
Hasła w pracy: karta dla pracowników
Rekomendacje techniczne CERT Polska opisują, co ma egzekwować system, więc pracownik nie dowie się z nich, co samemu zrobić z hasłem do konta firmowego. Tę lukę wypełnia karta Hasła w pracy w formacie PDF na jednej stronie A4. Zaczyna od tego, że najlepsze hasło generuje menedżer haseł: długie, losowe i inne dla każdego konta. Hasło z pełnego zdania zostaje dla haseł, które pracownik musi wpisać z pamięci, takich jak główne hasło do menedżera albo hasło do logowania w komputerze lub telefonie. CERT Polska podaje jako przykłady haseł, które trzeba zapamiętać, hasło do bazy menedżera haseł i do konta w systemie operacyjnym2. Dalej karta mówi, że każde konto ma mieć osobne hasło, do czego służy drugi składnik logowania i co zrobić, gdy ktoś mógł poznać hasło. Pod zasadami stoją trzy pola na kontakty: do działu IT, do menedżera haseł używanego w firmie i do osoby odpowiedzialnej za bezpieczeństwo, a licencja CC BY-ND 4.0 pozwala firmie drukować kartę i rozsyłać ją bez zmian.
Prawo wymaga szkoleń i cyberhigieny ogólnie: NIS2 wymienia szkolenia i podstawowe praktyki cyberhigieny (art. 21 ust. 2 lit. g), a ustawa o KSC edukację personelu i podstawowe zasady cyberhigieny (art. 8 ust. 1 pkt 2 lit. i i j)45. Dostawcy usług cyfrowych mają wprost doradzać pracownikom, jak postępować z informacjami uwierzytelniającymi (pkt 11.6.2 lit. b rozporządzenia 2024/2690)6. Karta nie zastępuje szkolenia. Jest materiałem do edukacji, więc obok niej potrzebne są szkolenia z cyberbezpieczeństwa dla pracowników.
Kilka zasad z karty zakłada procedurę po stronie firmy: menedżer haseł, jeśli firma go udostępnia, zasady zmiany hasła i przede wszystkim zgłoszenie od razu, gdy ktoś mógł poznać hasło. CERT Polska zaleca wymuszać zmianę hasła po potwierdzonym lub podejrzewanym przejęciu1, a polityka powinna wskazać, komu pracownik to zgłasza i w jakim czasie. Jeśli wyciek obejmuje dane, a nie tylko hasło, kolejne kroki opisuje przewodnik: co robić po wycieku danych.
Kto w Polsce pomoże wdrożyć politykę haseł
Wdrożenie polityki haseł to kilka osobnych zamówień. Pierwsze to przegląd uwierzytelniania i uprawnień: dostawcy usług cyfrowych mają go w rozporządzeniu wprost, jako przegląd procedur i technologii uwierzytelniania w zaplanowanych odstępach czasu (pkt 11.6.4)6, a pozostałym firmom pokazuje, czy polityka działa w praktyce. Taki przegląd mieści się w zakresie firm wykonujących testy penetracyjne i audyty. Zapisanie zasad w dokumentach zgodności to praca firm, które opisuje artykuł kto w Polsce wdroży NIS2 i ustawę o KSC.
Przeniesienie polityki na ustawienia katalogu użytkowników i systemów, w tym Active Directory, oraz wdrożenie drugiego składnika logowania to praca wdrożeniowa administratora albo wykonawcy, która zależy od środowiska firmy. W katalogu takie projekty prowadzą firmy zajmujące się bezpieczeństwem infrastruktury, kont i kontrolą dostępu.
Źródła
- CERT Polska, "Rekomendacje techniczne CERT Polska dla systemów uwierzytelniania", 10.01.2022 - zasady dla systemu uwierzytelniającego, minimalna długość hasła podniesiona w czerwcu 2025 roku z 12 do 14 znaków (odczyt 13.10.2026)
- CERT Polska, "Kompleksowo o hasłach", 10.01.2022 - poradnik dla użytkowników i organizacji z uzasadnieniem rekomendacji i testem łamania haseł (odczyt 13.10.2026)
- NIST, "NIST Special Publication 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management", rewizja 4 - odporność na phishing, ręcznie przepisywane kody i wiązanie podpisu z nazwą weryfikatora (odczyt 07.10.2026)
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 ust. 1 i ust. 2 lit. g, i, j oraz motyw 49 (odczyt 07.10.2026)
- Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252), art. 8 ust. 1 pkt 2 lit. a, i, j, l i n, art. 8a, art. 8b ust. 1 i 2 oraz art. 8c ust. 1 ustawy o KSC w brzmieniu nadanym tą ustawą, art. 33 ust. 1 i art. 49 (odczyt 13.10.2026)
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 z dnia 17 października 2024 r., załącznik pkt 11.6.2 lit. a-d i f, pkt 11.6.4 oraz pkt 11.7.1 (odczyt 07.10.2026)
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 32 ust. 1 i 2 (odczyt 07.10.2026)