NIS2 to dyrektywa, która w wielu organizacjach została odebrana przede wszystkim jako wymóg proceduralny: polityki, rejestry, klasyfikacje, audyty. Tymczasem jej realne oddziaływanie jest o wiele głębsze – dopiero na poziomie kryptografii zaczyna się prawdziwa zgodność. To właśnie tutaj dyrektywa oczekuje dowodu na to, że organizacja rozumie współczesne zagrożenia i potrafi utrzymać bezpieczeństwo techniczne na poziomie „state of the art”.

Dlaczego?
Bo TLS, certyfikaty, klucze i protokoły szyfrujące są bezpośrednią linią kontaktu między organizacją a jej użytkownikami, partnerami, klientami i systemami wewnętrznymi. Jeżeli ta warstwa jest słaba, żadna dokumentacja nie ochroni organizacji przed incydentem, a tym bardziej – przed odpowiedzialnością regulacyjną. NIS2 nie mówi wprost „używaj TLS 1.3”, ale efekt końcowy jest jasny: firmy muszą udowodnić, że ich kryptografia odpowiada aktualnemu poziomowi zagrożeń.

SSL/TLS jako element zgodności, nie konfiguracja serwera.

W wielu firmach SSL/TLS jest czymś, co „ktoś kiedyś skonfigurował”. Certyfikat został wgrany, komunikacja działa, kłódka jest – koniec tematu. NIS2 odwraca tę logikę: SSL/TLS przestaje być techniczną ciekawostką i staje się miarą dojrzałości operacyjnej. To oznacza konieczność bieżącego monitorowania, utrzymania i weryfikacji, czy stosowane konfiguracje:

• nie wykorzystują przestarzałych algorytmów,
• są w pełni zgodne z aktualnymi rekomendacjami branżowymi,
• zapewniają odpowiednią odporność na współczesne zagrożenia,
• są rozwijalne — bo NIS2 patrzy również w przyszłość.

Co ważne – zgodność nie jest zero-jedynkowa. Audytor nie szuka listy protokołów, ale dowodu, że firma ma proces i kontrolę nad kryptografią.

Minimalny profil SSL/TLS pod NIS2.

Organizacje często pytają: „jaki profil SSL/TLS jest zgodny z NIS2?”. Nie ma jednego oficjalnego wzorca, ale istnieje coś, co można nazwać średnią rynkową, wynikającą ze standardów CA/B Forum, BSI, ENISA, OWASP i praktyki sektora finansowego.

Minimalny zestaw, który można realnie obronić podczas audytu:

• TLS 1.3 jako główny protokół, a TLS 1.2 tylko dla kompatybilności.
• Wyłączenie TLS 1.0-1.1, bo nie są odporne na współczesne ataki.
• Algorytmy AEAD (AES-GCM, ChaCha20-Poly1305), bo zapewniają integralność i poufność.
• RSA od 3072 w górę lub ECDSA P-256/P-384, bo krótsze klucze są praktycznie nie do obrony.
• Brak SHA-1 w jakiejkolwiek części łańcucha – również w pośrednich certyfikatach.
• Obowiązkowy SAN, bo CN jest ignorowany przez przeglądarki od lat.

Zauważ, że każda z tych pozycji ma konkretne uzasadnienie. Audytor NIS2 nie pyta „co włączone?”, tylko:

•  „dlaczego?”
• „jak to monitorujecie?”
• „czy potraficie to zmienić, jeśli jutro pojawi się nowa rekomendacja ENISA?”

Inwentaryzacja TLS/PKI – fundament, bez którego cała zgodność się rozsypie.

NIS2 wymaga, aby organizacje miały pełną świadomość tego, co działa w ich środowisku. W kontekście SSL/TLS oznacza to wykrycie nie tylko stron publicznych, ale całej komunikacji szyfrowanej, w tym:

• API wewnętrznych i zewnętrznych,
• mikroserwisów,
• integracji z partnerami,
• rozwiązań B2B,
• paneli administracyjnych,
• tuneli i brokerów komunikacyjnych,
• usług legacy, o których „nikt nie pamięta”.

Pełna mapa PKI/TLS pozwala:

• wykryć ryzykowne konfiguracje,
• kontrolować terminy certyfikatów,
• ocenić, które systemy wymagają pilnych zmian,
• przygotować realistyczny plan migracji.

To jest krok, którego nie da się ominąć – bez niego każda organizacja „idzie na oślep”.

Zarządzanie certyfikatami: w NIS2 proces jest ważniejszy niż narzędzie.

Firmy często skupiają się na tym, czy mają system ACME, czy monitorują certyfikaty, czy jest panel do odnowień.
To jest ważne, ale NIS2 idzie głębiej – wymaga dowodu, że organizacja panuje nad cyklem życia kluczy i certyfikatów.

Dlatego dojrzały proces powinien obejmować:

• rejestr wszystkich certyfikatów,
• monitoring wygasania, błędów łańcucha i konfiguracji,
• politykę użycia (kiedy wildcard, kiedy EV, kiedy cert wewnętrzny),
• automatyzację tam, gdzie błędy ludzkie są największym ryzykiem,
• regularne przeglądy konfiguracji TLS.

To nie jest już „ładna praktyka” – to warunek zgodności.

Klucze prywatne – sekcja, którą audytorzy NIS2 będą traktować wyjątkowo surowo.

Żaden element PKI nie jest tak krytyczny jak klucz prywatny. NIS2 traktuje jego ochronę jako absolutny fundament, bo jego kompromitacja oznacza:

• przejęcie tożsamości domeny,
• możliwość MITM w czasie rzeczywistym,
• utratę zaufania partnerów i regulatora,
• obowiązek raportowania incydentu,
• konsekwencje finansowe i operacyjne.

Dlatego organizacje muszą wykazać:

• gdzie generowane są klucze,
• jak są przechowywane,
• jakie mają uprawnienia,
• jak wygląda ich rotacja,
• kto ma uprawnienia dostępu,
• jakie mechanizmy wykrywają nieautoryzowane użycie.

Tu nie ma miejsca na półśrodki – audytorzy od razu sprawdzają tę sekcję.

Crypto agility i PQC – NIS2 patrzy na przyszłość bardziej niż jakakolwiek wcześniejsza regulacja.

Tu zaczyna się najciekawsza część. NIS2 nie wymaga jeszcze certyfikatów post-kwantowych, ale wymaga, aby organizacje planowały bezpieczeństwo w perspektywie lat – nie miesięcy.

To oznacza konieczność rozważenia:

• odporności na „harvest now, decrypt later”,
• planów migracji do ECDHE + ML-KEM (hybrydowy SSL/TLS),
• harmonogramów wdrażania PQTLS w systemach o wysokiej wrażliwości,
• zgodności z roadmapami CA, CDN i dostawców chmury,
• gotowości infrastruktury (OpenSSL 3.x, biblioteki TLS wspierające PQC).

Crypto agility – zdolność do szybkiej wymiany algorytmów – staje się jednym z kluczowych wymogów zgodności.

Realny plan działania pod NIS2.

Najlepiej działają organizacje, które przyjmują pięcioetapowy model:

1. Odkrycie (Discovery): Pełna mapa TLS/PKI, wszystkie endpointy, wszystkie certyfikaty, cała komunikacja.
2. Ocena (Assessment): Analiza ryzyk, długości kluczy, protokołów, łańcuchów, konfiguracji.
3. Standaryzacja (Baseline): Utworzenie jednolitego profilu TLS obowiązującego w całej firmie.
4. Automatyzacja (Automation): ACME, API CA, rotacja kluczy, monitoring konfiguracji i wygasania.
5. Modernizacja (PQC Ready): Roadmapa do ECDHE + ML-KEM, przygotowanie na PQTLS i hybrydowe certyfikaty.

To jest dokładnie to, czego oczekuje NIS2 – niezależnie od wielkości firmy.

Najczęstsze błędy organizacji.

To nie są błędy teoretyczne – to realne przykłady, które doprowadziły do negatywnych ocen zgodności:

• skupienie na dokumentacji, zamiast na konfiguracji serwerów,
• ignorowanie API i usług wewnętrznych działających na TLS 1.0/1.1,
• brak automatyzacji certyfikatów i powtarzające się incydenty wygasania,
• klucze prywatne przechowywane w katalogach serwerowych,
• brak strategii kryptograficznej na kolejne 5 lat,
• całkowita ślepota na PQC i zagrożenia HNDL.

Każdy z tych punktów podważa zgodność.

Można mieć wzorowe procedury, analizy ryzyka i polityki bezpieczeństwa – ale jeśli TLS, certyfikaty i klucze są zaniedbane, audyt NIS2 to obnaży. To kryptografia staje się dowodem na to, czy organizacja naprawdę dba o bezpieczeństwo, czy tylko je deklaruje. NIS2 nie przesadza – wymaga po prostu, aby kryptografia była traktowana poważnie. A to oznacza:

• dojrzałe SSL/TLS,
• bezpieczne klucze,
• automatyzację,
• monitoring,
• crypto agility,
• przygotowanie na PQC.