E-Invoice Finder
Menu
Kraje Oprogramowanie Terminy Przewodniki Checker Sprawdź obowiązek
ENFRDEPLNL
Polska · incydent bezpieczeństwa KSeF

Kompromitacja certyfikatu KSeF — unieważnienie i wymiana

Odizoluj wyciek klucza prywatnego KSeF, unieważnij właściwy certyfikat, sprawdź możliwe nadużycia i bezpiecznie wymień dane ERP.

Praktyczne podsumowanie:
  • Zakres: ustal jeden numer seryjny i wszystkie miejsca, w których odpowiadający mu klucz był dostępny.
  • Ryzyko: pozornie zdrowa integracja może nadal zawierać kopię przejętego sekretu lub błędny kontekst spółki.
  • Działanie: prowadź odrębne testy dla sesji API oraz podpisywania dokumentów wystawianych poza KSeF.
Sprawdź raport gotowościŹródła oficjalne
Ostatnia aktualizacja: 31 lipca 2026Źródła oficjalneJasne podsumowanieInformacja praktyczna, nie porada prawna
Priorytet dla źródeł oficjalnych
Widoczne daty weryfikacji
Darmowy checker bez rejestracji

Co warto wiedzieć

Przewodnik

Klasyfikacja incydentu i ocena pilności

Uruchom procedurę po utracie urządzenia, ujawnieniu pliku klucza, dostępie nieuprawnionej osoby do magazynu sekretów, publikacji poświadczeń w repozytorium albo niewyjaśnionym użyciu certyfikatu. Nie czekaj na dowód wystawienia fałszywej faktury: podejrzenie dostępu do klucza prywatnego wystarcza, by potraktować zdarzenie jako incydent. Jednocześnie nie ogłaszaj, że doszło do nadużycia, dopóki analiza tego nie potwierdzi. Zalecana, wewnętrzna oś działania — nie termin ustawowy KSeF — to: natychmiast otworzyć incydent i ograniczyć dostęp; w pierwszej fazie ustalić numer seryjny, typ, właściciela i wdrożenia; następnie unieważnić przez czystą, autoryzowaną ścieżkę; później przeanalizować logi, wymienić klucz i certyfikat, wdrożyć je etapami oraz monitorować. Kierownik incydentu koordynuje decyzje, właściciel certyfikatu zatwierdza unieważnienie, bezpieczeństwo zabezpiecza dowody, a zespół ERP utrzymuje ciągłość. Priorytet rośnie, gdy klucz był eksportowalny, znajdował się na wielu hostach, obsługiwał produkcję lub nie wiadomo, kto mógł go skopiować.

Przewodnik

Identyfikacja certyfikatu, typu, właściciela i wdrożeń

Najpierw zbuduj kartę incydentu: numer seryjny certyfikatu, jego odcisk, status, daty ważności, właściciel, typ oraz środowisko. Oficjalne API pozwala wyszukiwać metadane przez POST /certificates/query; statusy obejmują Active, Blocked, Revoked i Expired. Nie opieraj decyzji wyłącznie na nazwie pliku PFX ani opisie w panelu ERP, bo podobne etykiety łatwo pomylić. Rozróżnij Type 1 Authentication od Type 2 Offline. Pierwszy służy do uwierzytelnienia, drugi do weryfikacji wystawcy faktur przygotowanych w trybach offline24, niedostępności systemu lub awaryjnym i nie uwierzytelnia sesji API. Certyfikat potwierdza tożsamość; nie przenosi uprawnień KSeF ani kontekstu firmy. Dlatego osobno ustal, w jakim kontekście integracja otwierała sesje i jakie uprawnienia miał właściciel. Właściciel zasobu tworzy inwentaryzację wdrożeń: ERP, middleware, agent podpisujący, sejf sekretów, CI/CD, kopie zapasowe, laptopy administratorów i dostawcy utrzymaniowi. Dla każdego miejsca zanotuj osobę odpowiedzialną, wersję sekretu, ostatnie użycie i możliwość zdalnego odcięcia. Ta mapa zapobiega pozostawieniu aktywnej kopii po wymianie.

Przewodnik

Ograniczenie skutków i czysta ścieżka unieważnienia

Odizoluj zagrożone hosty i poświadczenia bez niszczenia danych potrzebnych do analizy. Zablokuj zadania używające klucza, cofnij dostęp do sejfu, zabezpiecz pipeline wdrożeniowy i odłącz przejęte konto administracyjne. Jeżeli zatrzymanie integracji wpływa na fakturowanie, aktywuj zatwierdzony plan ciągłości, zamiast kopiować podejrzany klucz na nową maszynę. Klucz prywatny powinien być przechowywany zgodnie z polityką bezpieczeństwa organizacji. Oficjalna dokumentacja CIRFMF wskazuje, że certyfikat może unieważnić wyłącznie jego właściciel, używając POST /certificates/{certificateSerialNumber}/revoke. Żądanie zawiera numer seryjny i może zawierać przyczynę. Wykonaj je ze znanego, czystego stanowiska oraz autoryzowanego kontekstu, po niezależnym potwierdzeniu numeru przez drugą osobę. Nie loguj klucza ani pełnych poświadczeń w zgłoszeniu serwisowym. To zalecenia operacyjne, nie dodatkowe reguły prawne KSeF. Jeśli właściciel jest niedostępny lub ścieżka techniczna nie działa, eskaluj do osoby odpowiedzialnej za usługę i oficjalnego wsparcia, dokumentując próby. Nie obchodź kontroli przez użycie poświadczeń niewiadomego pochodzenia.

Przewodnik

Mechanika unieważnienia i granice jego skutków

Zgodnie z oficjalną procedurą poprawne żądanie unieważnienia automatycznie blokuje certyfikat w KSeF, niezależnie od publikacji listy CRL. Nie zakładaj więc, że opóźnienie CRL pozostawia skutecznie unieważniony certyfikat użyteczny w KSeF. Po unieważnieniu nie można go ponownie użyć; potrzebny jest nowy certyfikat. Ministerstwo podaje również, że certyfikat może być ważny nie dłużej niż dwa lata. Unieważnienie dotyczy konkretnego certyfikatu. Nie usuwa uprawnień jego właściciela w KSeF, nie unieważnia jego pozostałych certyfikatów i nie zmienia samoistnie kontekstu firmy. Nie dowodzi też, czy klucz został wykorzystany przed blokadą, oraz nie usuwa skopiowanych plików, konfiguracji, tokenów czy haseł z hostów. Jeśli dostęp osoby powinien zostać ograniczony, wykonaj odrębny przegląd i zmianę uprawnień. Po wywołaniu endpointu zachowaj odpowiedź, czas i identyfikator operacji, a następnie potwierdź status niezależnym zapytaniem o metadane. Rozbieżność, błąd lub brak potwierdzenia wymaga eskalacji — nie uznawaj samego wysłania żądania za zakończenie kontroli.

Przewodnik

Dochodzenie, dowody i ocena możliwego nadużycia

Utwórz chronioną chronologię: kto wykrył zdarzenie, kiedy klucz mógł zostać ujawniony, kiedy ograniczono dostęp i kiedy potwierdzono unieważnienie. Zachowaj logi KSeF i integracji, dzienniki sejfu sekretów, systemu operacyjnego, EDR, CI/CD oraz administratorów. Utrwal źródła i sumy kontrolne zgodnie z firmową procedurą dowodową; nie wykonuj chaotycznego „sprzątania”, które nadpisze ślady. Szukaj użycia danego numeru seryjnego, nietypowych godzin i adresów, nowych sesji, zmian wolumenu oraz faktur niepasujących do ERP, zamówień i sekwencji biznesowej. Porównaj aktywność z oknem możliwej ekspozycji i uwzględnij opóźnienia logowania. Brak alertu nie jest dowodem braku wykorzystania, a pojedyncza anomalia nie przesądza o oszustwie. Bezpieczeństwo prowadzi analizę techniczną, finanse i podatki weryfikują aktywność fakturową, właściciele procesów potwierdzają transakcje, a prawnik lub inspektor ochrony danych ocenia obowiązki właściwe dla konkretnego zdarzenia. Ten podział jest rekomendowaną praktyką reagowania; dokumentacja KSeF nie ustanawia jednego ustawowego czasu zakończenia dochodzenia.

Przewodnik

Czysta wymiana i wdrożenie etapami

Wygeneruj nową parę kluczy w zaufanym środowisku; nie używaj ponownie starego klucza prywatnego. Uzyskaj nowy certyfikat odpowiedniego typu, sprawdź właściciela, numer seryjny, okres ważności oraz przeznaczenie. Następnie zmień zależne sekrety, jeżeli mogły zostać ujawnione razem z kluczem: hasło kontenera, dane sejfu, hasła usługowe, klucze wdrożeniowe i dostęp dostawcy. Wdrażaj według wcześniej sporządzonej inwentaryzacji. Najpierw środowisko testowe, potem pojedynczy kontrolowany węzeł produkcyjny, a dopiero po poprawnej obserwacji reszta klastra. Przetestuj otwarcie sesji wyłącznie certyfikatem Type 1 oraz osobno podpis i weryfikację dokumentu certyfikatem Type 2; pozytywny wynik jednego testu nie potwierdza drugiego. Zapisz numery seryjne i oczekiwane miejsca użycia w CMDB lub rejestrze sekretów. Kryteria przejścia to poprawna tożsamość, właściwy kontekst podmiotu, brak odwołań do starego sekretu, udana ścieżka awaryjna i widoczność telemetryczna. Kryterium wycofania stanowią błędy uwierzytelnienia, podpisu, kontekstu albo niezgodność numeru seryjnego. Wycofanie oznacza zatrzymanie wdrożenia i analizę, nie przywrócenie przejętego klucza.

Przewodnik

Ciągłość działania dla uwierzytelnienia i trybów offline

Plan ciągłości powinien osobno obejmować dostęp API i wystawianie poza KSeF. Utrata Type 1 może zatrzymać nowe sesje danej integracji, ale nie uzasadnia użycia Type 2 do logowania. Utrata Type 2 wpływa na wiarygodną weryfikację wystawcy dokumentów z trybów offline24, niedostępności systemu lub awaryjnego, lecz nie jest awarią mechanizmu uwierzytelnienia API. Przed incydentem określ dopuszczalny czas przerwy, kolejność usług, osoby mogące uzyskać nowy certyfikat i bezpieczny kanał jego dystrybucji. Ministerstwo wskazuje, że przedsiębiorstwa rozprowadzające certyfikaty podmiotu muszą zapewnić rozliczalność pobrania, przekazania, używania i unieważnienia. Rejestr wydania powinien więc łączyć numer seryjny z odbiorcą, systemem i potwierdzeniem zwrotu lub zniszczenia kopii. Tokeny pozostają użyteczne obok certyfikatów od 1 lutego 2026 r., lecz zgodnie z aktualnymi informacjami certyfikaty mają być docelową pozostałą metodą od 1 stycznia 2027 r. Nie przełączaj awaryjnie na istniejący token bez oceny, czy nie został ujawniony tym samym kanałem, ograniczenia jego zakresu i zaplanowania późniejszego usunięcia.

Przewodnik

Scenariusze i częste błędy

Scenariusz 1: administrator umieścił kontener PFX Type 1 w publicznym repozytorium. Zespół usuwa dostęp do repozytorium, zabezpiecza historię, identyfikuje numer seryjny i wszystkie wdrożenia, a właściciel unieważnia certyfikat z czystego stanowiska. Nowy klucz powstaje w sejfie, po czym integracja jest uruchamiana etapami. Samo usunięcie commitu nie kończy incydentu, bo istnieją forki, cache i klony. Scenariusz 2: skradziono laptop zawierający Type 2 Offline. Należy unieważnić właśnie ten numer, przeanalizować dokumenty wystawione w możliwym oknie ekspozycji i wydać nową parę do podpisywania offline. Nie ma powodu twierdzić, że skradziony certyfikat otwierał sesje API, chyba że na urządzeniu były również inne poświadczenia. Scenariusz 3: dostawca ERP zgłasza „wymianę certyfikatu”, ale nie podaje numeru seryjnego. Wstrzymaj zmianę do czasu identyfikacji właściciela, typu, środowiska i listy kopii. Częste błędy to unieważnienie sąsiedniego certyfikatu, mylenie blokady z odebraniem uprawnień, ponowne użycie klucza, brak dowodów, masowe wdrożenie bez pilota i pozostawienie starego sekretu w kopii zapasowej.

Przewodnik

Kryteria wyboru zabezpieczeń i dalsze działania

Oceń oprogramowanie według możliwości przechowywania klucza poza konfiguracją aplikacji, ograniczania eksportu, wskazywania numeru seryjnego, rotacji bez ręcznego kopiowania, rozdzielenia Type 1 i Type 2, rejestrowania użycia oraz szybkiego odcięcia węzła. Istotne są też kontrola dostępu dostawcy, integracja z HSM lub sejfem, alerty anomalii, jednoznaczny kontekst podmiotu, wersjonowana konfiguracja bez sekretów i udokumentowany tryb odtworzenia. Przy decyzji „unieważnić teraz czy najpierw diagnozować” pierwszeństwo ma ograniczenie ryzyka, gdy istnieje wiarygodna możliwość skopiowania klucza; analizę prowadź równolegle na zachowanych dowodach. Gdy problem dotyczy wyłącznie błędnej konfiguracji bez ekspozycji, właściciel bezpieczeństwa powinien udokumentować podstawę innej decyzji. Nie ma oficjalnego progu KSeF, który zastępowałby ocenę ryzyka organizacji. Po przywróceniu usługi monitoruj użycie nowego numeru, próby starego certyfikatu, wolumen faktur i błędy kontekstu. Zamknij incydent dopiero po sprawdzeniu całej inwentaryzacji, usunięciu zależnych kopii i przypisaniu działań naprawczych. Przegląd po incydencie powinien poprawić zarządzanie sekretami, rozliczalność dystrybucji, testy awaryjne i szkolenie właścicieli.

Lista kontrolna

Nadaj incydentowi właściciela, poziom pilności i chronioną chronologię zdarzeń.

Potwierdź numer seryjny, odcisk, typ, status, właściciela i datę ważności certyfikatu.

Zmapuj wszystkie hosty, sejfy, pipeline’y, kopie zapasowe i osoby mające dostęp do klucza.

Odizoluj zagrożone systemy oraz zatrzymaj użycie klucza, zachowując materiał dowodowy.

Unieważnij właściwy numer przez czystą, autoryzowaną ścieżkę właściciela certyfikatu.

Potwierdź status niezależnym zapytaniem i zachowaj odpowiedź operacji unieważnienia.

Przeszukaj logi, sesje i faktury z całego możliwego okna ekspozycji.

Wygeneruj nowy klucz i certyfikat oraz obróć wszystkie potencjalnie współdzielone sekrety.

Wdróż zmianę według inwentaryzacji, z pilotem i osobnymi testami uwierzytelnienia oraz offline.

Monitoruj nowe i stare identyfikatory, a po incydencie usuń przyczyny i luki w rozliczalności.

Najczęstsze pytania

Kto może unieważnić certyfikat KSeF?

Według dokumentacji CIRFMF może to zrobić wyłącznie właściciel certyfikatu. Technicznie służy do tego POST /certificates/{certificateSerialNumber}/revoke z numerem seryjnym i opcjonalną przyczyną. Organizacja powinna wcześniej zapewnić właścicielowi bezpieczną ścieżkę oraz zastępstwo operacyjne na wypadek jego niedostępności.

Kiedy unieważnienie zaczyna działać w KSeF?

Oficjalna procedura podaje, że prawidłowe żądanie automatycznie blokuje certyfikat w KSeF niezależnie od publikacji CRL. Zespół powinien jednak zachować wynik operacji i potwierdzić status przez zapytanie o metadane; błąd lub brak potwierdzenia wymaga eskalacji.

Czy unieważnienie usuwa uprawnienia właściciela?

Nie. Certyfikat jest mechanizmem identyfikacji i uwierzytelnienia, a nie nośnikiem uprawnień ani kontekstu spółki. Jeśli incydent wymaga ograniczenia dostępu osoby lub podmiotu, wykonaj osobną zmianę uprawnień i sprawdź pozostałe certyfikaty oraz poświadczenia.

Jak sprawdzić, czy klucz został nadużyty?

Zestaw logi KSeF, ERP, sejfu, systemów i CI/CD z oknem możliwej ekspozycji. Szukaj nietypowych sesji, źródeł, godzin oraz faktur nieobecnych w procesie biznesowym. Brak anomalii zmniejsza niepewność, ale sam nie dowodzi, że klucz nigdy nie został użyty.

Czy można ponownie użyć klucza po unieważnieniu?

Nie należy tego robić. Unieważnionego certyfikatu nie można ponownie użyć, a po podejrzeniu kompromitacji stary klucz również nie jest godny zaufania. Wygeneruj nową parę w czystym środowisku i wydaj nowy certyfikat właściwego typu.

Jak wymienić certyfikat bez niekontrolowanego przestoju?

Przygotuj inwentaryzację wdrożeń, nowy klucz oraz plan pilota i wycofania. Po ograniczeniu zagrożenia uruchom pojedynczy węzeł, sprawdź tożsamość, kontekst i telemetrię, a następnie rozszerz wdrożenie. Plan ciągłości nie może polegać na przywróceniu przejętego sekretu.

Czy certyfikat Offline może uwierzytelnić sesję API?

Nie. Type 2 Offline służy do weryfikacji wystawcy dokumentów z trybów offline24, niedostępności systemu lub awaryjnego. Do uwierzytelnienia przeznaczony jest Type 1 Authentication, dlatego oba zastosowania trzeba testować i odtwarzać oddzielnie.

Czy w awarii można po prostu przełączyć ERP na token?

Nie bez oceny ryzyka. Token mógł zostać ujawniony razem z innymi sekretami, a jego zakres i miejsca użycia wymagają sprawdzenia oraz ograniczenia. Ponadto według aktualnych informacji certyfikaty mają pozostać docelową metodą od 1 stycznia 2027 r., więc takie obejście nie zastępuje bezpiecznej wymiany.

Kluczowe przepisy, formaty i pojęcia

Komisja EuropejskaEN 16931Dyrektywa 2014/55/UEustrukturyzowana faktura elektronicznaKompromitacja i awaryjne unieważnienie certyfikatu KSeFPolska

Czytaj dalej

Źródła oficjalne

Priorytetowo traktujemy oficjalne źródła rządowe i UE, gdy są dostępne, oraz pokazujemy daty weryfikacji.