E-Invoice Finder
Menu
Kraje Oprogramowanie Terminy Przewodniki Checker Sprawdź obowiązek
ENFRDEPLNL
Polska · eksploatacja certyfikatów KSeF

Inwentaryzacja i rotacja certyfikatów KSeF

Prowadź ewidencję certyfikatów KSeF, monitoruj ważność i bezpiecznie rotuj poświadczenia ERP z testem, rollbackiem i kontrolowanym unieważnieniem.

Praktyczne podsumowanie:
  • Zakres: oddzielne sterowanie poświadczeniami dla logowania i faktur offline.
  • Ryzyko: nieznana zależność systemowa może ujawnić się dopiero przy przełączeniu.
  • Działanie: zatwierdź właścicieli i kryteria odbioru przed wygenerowaniem CSR.
Sprawdź raport gotowościŹródła oficjalne
Ostatnia aktualizacja: 2 sierpnia 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

Cykl życia certyfikatu i ryzyko przerwy

Certyfikat KSeF jest poświadczeniem tożsamości używanym przez człowieka albo system, a nie zbiorem uprawnień ani opisem spółki. Uprawnienia są weryfikowane po stronie KSeF, dlatego ważny certyfikat nie gwarantuje, że konto techniczne może wykonać daną operację. Operacyjny cykl życia obejmuje zaplanowanie zastosowania, utworzenie klucza i wniosku, wydanie, bezpieczne wdrożenie, test, monitoring, rotację oraz unieważnienie. Przerwa może powstać nie tylko po wygaśnięciu: częste przyczyny to certyfikat wgrany do niewłaściwego środowiska, brak dostępu aplikacji do klucza, pozostawienie starego numeru seryjnego w konfiguracji albo niezgodne uprawnienia. Właściciel usługi powinien więc mierzyć gotowość całej ścieżki ERP–integracja–KSeF, a nie samą obecność pliku. Przykładowy minimalny dowód działania to zakończona próba uwierzytelnienia certyfikatem Typu 1, poprawny wynik kontrolowanej operacji zgodnej z uprawnieniami oraz zapis czasu, środowiska, wersji konfiguracji i osoby zatwierdzającej. To praktyka ciągłości działania, nie dodatkowy wymóg ustawowy KSeF. Osobny tryb postępowania trzeba zachować dla podejrzenia kompromitacji: wtedy priorytetem jest ograniczenie ryzyka i unieważnienie, a nie spokojna rotacja z długim okresem współistnienia.

Przewodnik

Zbuduj ewidencję i przypisz jej właściciela

Ewidencja powinna mieć jednego właściciela biznesowego oraz opiekuna technicznego, ale korzystać z rozdzielenia obowiązków przy wydaniu i wdrożeniu. Dla każdego certyfikatu zapisz unikalną, czytelną nazwę, numer seryjny, Typ 1 albo Typ 2, status, datę początku i końca ważności, właściciela, system oraz środowisko, miejsce użycia, odpowiedzialny zespół, datę ostatniego testu i odwołanie do zgłoszenia zmiany. Dodaj zależności: instancję ERP, konektor, usługę integracyjną, procedurę awaryjną i kontakt eskalacyjny. Nie zapisuj w ewidencji klucza prywatnego, hasła, sekretu, pełnej zawartości magazynu ani danych pozwalających je odtworzyć. Sam klucz powinien pozostać w kontrolowanym sejfie sekretów, HSM lub innym rozwiązaniu dobranym do ryzyka i możliwości aplikacji, z ograniczonym dostępem oraz śladem użycia. Raz w ustalonym przez firmę cyklu właściciel porównuje rejestr z metadanymi zwróconymi przez KSeF i konfiguracją produkcyjną. Rozbieżność, na przykład aktywny certyfikat bez przypisanej usługi albo wpisany certyfikat, którego nie ma już w systemie, staje się zadaniem z terminem i właścicielem. Dowodem kontroli może być zatwierdzony eksport samych metadanych, protokół uzgodnienia i lista wyjątków — bez kopiowania materiału kluczowego do arkuszy, logów czy systemu zgłoszeń.

Przewodnik

Oficjalne typy, ważność i model statusów

Ministerstwo Finansów rozróżnia dwa certyfikaty wydawane oddzielnie. Typ 1 Uwierzytelnianie służy do uwierzytelniania w KSeF. Typ 2 Offline służy wyłącznie do potwierdzenia tożsamości wystawcy i integralności faktury w trybach offline24, niedostępności systemu oraz awaryjnym; nie można nim uwierzytelnić sesji API. Organizacja potrzebująca obu zastosowań składa zatem dwa odrębne wnioski i prowadzi dwa odrębne wpisy. Według informacji Ministerstwa certyfikat jest ważny nie dłużej niż dwa lata od utworzenia albo od wskazanej przez podatnika daty początku ważności. Nie należy z tego wywodzić automatycznego odnowienia — rotacja polega na wystąpieniu o nowy certyfikat i jego wdrożeniu. Oficjalne zapytanie POST /certificates/query zwraca metadane certyfikatów aktywnych i historycznych; pozwala filtrować między innymi po statusach Active, Blocked, Revoked i Expired, dacie wygaśnięcia, nazwie, typie oraz numerze seryjnym. To dobre źródło do uzgadniania ewidencji, lecz nie zastępuje sprawdzenia, gdzie dany klucz faktycznie działa. Certyfikat może zostać unieważniony przez właściciela przez POST /certificates/{certificateSerialNumber}/revoke i po unieważnieniu nie nadaje się do ponownego użycia. Nazwy statusów i zachowanie API warto potwierdzać w aktualnej dokumentacji CIRFMF przed zmianą produkcyjną.

Przewodnik

Monitoring wygaśnięcia i eskalacja

Monitoring powinien pobierać metadane z autorytatywnego źródła, łączyć je z ewidencją oraz kierować alert do osoby, która może podjąć działanie. Zespół sam ustala progi, na przykład wcześniejszy sygnał dla właściciela usługi, późniejszą eskalację do kierownika i alert krytyczny przed końcem ważności; nie są to urzędowe okna ani terminy KSeF. Progi należy dobrać do czasu potrzebnego na akceptację, wystawienie, testy, okno wdrożeniowe i ewentualne wycofanie zmiany. Kontrola powinna wykrywać również status Blocked lub Revoked, brak certyfikatu spodziewanego w KSeF, niezgodność typu, przesuniętą datę validFrom i certyfikat osierocony. Każdy alert musi zawierać numer seryjny, nazwę, typ, system, datę ważności, właściciela i instrukcję eskalacji, ale nigdy klucz prywatny. Przetestuj sam mechanizm: zasymuluj zbliżający się termin w danych testowych, potwierdź dostarczenie powiadomienia, utworzenie zadania, zastępstwo na czas urlopu i zamknięcie dopiero po okazaniu dowodu. Przydatne mierniki to liczba certyfikatów bez właściciela, bez potwierdzonego wdrożenia, z nieuzgodnionym statusem oraz czas od alertu do zaakceptowanego planu rotacji. Co najmniej jedna osoba spoza zespołu integracji powinna okresowo potwierdzić, że alerty nie kończą w nieobserwowanej skrzynce.

Przewodnik

Zaplanuj wydanie nowego certyfikatu i okres współistnienia

Oficjalny przepływ API zaczyna się od GET /certificates/limits oraz GET /certificates/enrollments/data. Następnie w kontrolowanym środowisku tworzy się klucz prywatny i żądanie PKCS#10 CSR, po czym wysyła POST /certificates/enrollments z nazwą, typem, CSR i opcjonalnym validFrom. Status wniosku sprawdza się przez GET /certificates/enrollments/{referenceNumber}, a wydany certyfikat pobiera przez POST /certificates/retrieve. Od lutego 2026 r. wnioskowanie i pobieranie są dostępne przez API KSeF 2.0 oraz Aplikację Podatnika. Przed rozpoczęciem wpisz do planu właściciela, zatwierdzającego, operatora technicznego, typ, jednoznaczną nazwę, środowisko, datę validFrom, systemy docelowe i kryteria odbioru. Klucz prywatny generuj i przekazuj zgodnie z firmową polityką; Ministerstwo wskazuje na potrzebę bezpiecznego przechowywania oraz odpowiedzialności organizacyjnej za pobieranie, przekazywanie, używanie i unieważnianie certyfikatów firmowych. Firma może zaplanować własny okres współistnienia starego i nowego certyfikatu, aby wykonać test i wrócić do poprzedniej konfiguracji, ale KSeF nie narzuca konkretnej długości takiego okresu. „Odnowienie” nie jest osobnym oficjalnym endpointem: to nowe wydanie, bezpieczne dostarczenie i kontrolowana zmiana. Dowody obejmują zatwierdzony CSR workflow, numer referencyjny, metadane certyfikatu i potwierdzenie umieszczenia klucza w docelowym magazynie, bez ujawniania jego treści.

Przewodnik

Wdrożenie i test rotacji Typu 1 Uwierzytelnianie

Dla Typu 1 przygotuj zmianę tak, aby nowy certyfikat można było aktywować w jednej instancji integracji albo w kontrolowanym oknie, bez nadpisywania jedynej działającej konfiguracji. Administrator umieszcza klucz i certyfikat w magazynie, nadaje usłudze minimalny dostęp, aktualizuje odwołanie konfiguracyjne i zapisuje wersję wdrożenia. Operator wykonuje próbę uwierzytelnienia do właściwego środowiska KSeF, a właściciel procesu potwierdza co najmniej jedną bezpieczną operację odpowiadającą rzeczywistym uprawnieniom. Błąd autoryzacji po udanym uwierzytelnieniu może wskazywać na brak uprawnień po stronie KSeF, bo certyfikat sam ich nie przenosi; nie należy „naprawiać” tego kopiowaniem kluczy ani nadawaniem nadmiernych praw. Test negatywny powinien potwierdzić, że usługa bez dostępu do sekretu nie może go odczytać, a logi nie pokazują klucza, hasła ani pełnych danych wrażliwych. Kryteria odbioru mogą obejmować stabilne zestawienie sesji, oczekiwany wynik operacji, poprawny numer seryjny w telemetrii, brak wzrostu błędów i zatwierdzenie przez finanse oraz IT. Rollback polega na bezpiecznym przywróceniu odwołania do nadal ważnego starego certyfikatu i poprzedniej wersji konfiguracji; przećwicz go przed unieważnieniem starego poświadczenia.

Przewodnik

Wdrożenie i test rotacji Typu 2 Offline

Typ 2 wymaga osobnej ścieżki testowej, ponieważ nie służy do logowania do API. Nowy certyfikat i odpowiadający mu klucz należy wdrożyć wyłącznie do komponentu wystawiającego faktury w trybie offline24, podczas niedostępności KSeF lub w trybie awaryjnym. Przygotuj kontrolowany przypadek testowy zgodny z aktualną specyfikacją: system powinien użyć nowego poświadczenia do potwierdzenia tożsamości wystawcy i integralności dokumentu, zachować wymagane powiązanie z fakturą oraz umożliwić późniejszą obsługę dokumentu właściwą dla danego trybu. Weryfikator powinien potwierdzić numer seryjny certyfikatu, integralność wyniku, zgodność danych wystawcy i brak próby użycia Typu 2 do uwierzytelnienia sesji. Wykonaj także próbę negatywną na zmodyfikowanym artefakcie oraz kontrolę przejścia z trybu offline do standardowej pracy. Właścicielem testu powinny być wspólnie finanse i IT, a dowodem: identyfikator scenariusza, wynik walidacji, znaczniki czasu, wersja oprogramowania i podpisy zatwierdzających. Nie przenoś klucza do narzędzia testowego tylko dla wygody; jeśli środowisko nie obsługuje bezpiecznego wdrożenia, jest to luka do usunięcia przed produkcją. Zakres testu i formaty zawsze porównaj z aktualną dokumentacją urzędową.

Przewodnik

Przełączenie, unieważnienie, rollback i dowody

Po pozytywnych testach przełącz pozostałe instancje według zatwierdzonej kolejności, obserwuj uwierzytelnienia lub operacje offline oraz porównuj numer seryjny używany przez aplikację z ewidencją. Ustal z góry kryteria zatrzymania, na przykład powtarzalny błąd sesji, niezgodność integralności albo wzrost kolejki dokumentów, oraz osobę podejmującą decyzję o rollbacku. Stary certyfikat unieważnij dopiero po potwierdzeniu, że wszystkie zależności korzystają z nowego i rollback nie jest już potrzebny; wybór momentu jest kontrolą operacyjną firmy, nie urzędowo narzuconym okresem. Po POST /certificates/{certificateSerialNumber}/revoke sprawdź status, zamknij dostęp do starego sekretu i zaktualizuj ewidencję. Zachowaj w pakiecie zmiany akceptacje, numery seryjne, wyniki testów, metryki obserwacji, decyzję o przełączeniu, wynik unieważnienia i listę systemów — nigdy prywatne klucze. Typowe błędy to traktowanie certyfikatu jak uprawnienia, pomylenie Typu 1 z Typem 2, zakładanie automatycznego odnowienia, usunięcie starego certyfikatu przed testem, wspólna nazwa dla wielu wdrożeń, alert bez właściciela i sekret w tickecie lub logu. Przy podejrzeniu ujawnienia klucza nie czekaj na zwykłe okno rotacji: uruchom procedurę incydentową, ogranicz dostęp, oceń zasięg i unieważnij zgodnie z zatwierdzonym planem.

Przewodnik

Kryteria wyboru oprogramowania i następne działania

Oprogramowanie do zarządzania certyfikatami KSeF oceniaj na demonstracji własnych scenariuszy, nie na samej deklaracji „obsługujemy KSeF”. Wymagaj rozdzielenia Typu 1 i Typu 2, obsługi pełnego oficjalnego przepływu wydania, zapytań o status i unieważnienia, bezpiecznej integracji z wybranym magazynem kluczy, kontroli dostępu, śladu audytowego oraz alertów kierowanych do właściciela. Sprawdź, czy produkt mapuje numer seryjny, typ, ważność i wdrożenie bez kopiowania sekretów; umożliwia test wstępny, stopniowe przełączenie i rollback; pokazuje błędy uwierzytelnienia oddzielnie od braku uprawnień; oraz eksportuje dowody bez danych kluczowych. Poproś dostawcę o pokazanie rotacji w dwóch instancjach ERP, scenariusza wygaśnięcia, statusu Revoked, testu offline i odzyskania po nieudanym wdrożeniu. Kryteria decyzji powinny obejmować również SLA, odpowiedzialność za aktualizacje API, role administracyjne, retencję logów, przenośność konfiguracji, koszty HSM lub sejfu oraz sposób zakończenia umowy. Najpierw zinwentaryzuj obecne certyfikaty i zależności, potem usuń wpisy bez właścicieli, ustal wewnętrzne progi monitoringu i przeprowadź próbną rotację przed najbliższym terminem produkcyjnym. Tokeny i certyfikaty współistnieją od 1 lutego 2026 r., natomiast oficjalna strona wskazuje, że od 1 stycznia 2027 r. pozostaną wyłącznie certyfikaty, co warto uwzględnić w planie integracji.

Lista kontrolna

Wyznacz właściciela biznesowego i opiekuna technicznego dla każdego certyfikatu oraz zastępstwo na czas nieobecności.

Zapisz w ewidencji nazwę, numer seryjny, typ, status, okres ważności, system, środowisko i ostatni potwierdzony test.

Uzgodnij rejestr wewnętrzny z wynikami POST /certificates/query i wyjaśnij każdy brak lub osierocony wpis.

Usuń klucze prywatne, hasła i sekrety z arkuszy, ticketów oraz logów; pozostaw je w kontrolowanym magazynie.

Ustal własne progi alertów i eskalacji na podstawie czasu wydania, akceptacji, testów, wdrożenia i rollbacku.

Zamów osobno Typ 1 i Typ 2, jeśli potrzebujesz obu zastosowań, używając jednoznacznych nazw i właściwego validFrom.

Przetestuj nowy Typ 1 przez uwierzytelnienie i dozwoloną operację, oddzielając błąd poświadczenia od braku uprawnień.

Przetestuj nowy Typ 2 na kontrolowanej fakturze offline, weryfikując tożsamość wystawcy, integralność i numer seryjny.

Przećwicz rollback, obserwuj wdrożenie po przełączeniu i unieważnij stary certyfikat dopiero po potwierdzeniu wszystkich zależności.

Zachowaj akceptacje, metadane, wyniki testów, obserwacje i dowód unieważnienia bez utrwalania materiału kluczowego.

Najczęstsze pytania

Ile jest ważny certyfikat KSeF?

Według Ministerstwa Finansów certyfikat KSeF jest ważny nie dłużej niż dwa lata od utworzenia albo od daty początku ważności wybranej przez podatnika. W praktyce trzeba odczytać dokładne validFrom i datę wygaśnięcia dla konkretnego numeru seryjnego, zamiast liczyć termin wyłącznie z pamięci lub daty wdrożenia. Wewnętrzne alerty warto ustawić z zapasem odpowiadającym realnemu czasowi przygotowania i testów, ale nie przedstawiać tego zapasu jako urzędowego terminu.

Czy certyfikat KSeF odnawia się automatycznie?

Nie należy zakładać automatycznego odnowienia ani szukać oficjalnego endpointu „renewal”. Kontynuacja pracy wymaga wystąpienia o nowy certyfikat, bezpiecznego wdrożenia powiązanego klucza, wykonania właściwych testów i kontrolowanego przełączenia. Stary i nowy certyfikat są odrębnymi poświadczeniami z własnymi numerami seryjnymi, okresami ważności i wpisami w ewidencji.

Jak zmienić certyfikat KSeF bez przerwy w ERP?

Zacznij przed wygaśnięciem od wydania nowego certyfikatu i zachowaj działającą konfigurację starego jako opcję rollbacku. Wdróż nowy sekret do kontrolowanej instancji, sprawdź uwierzytelnienie Typem 1 oraz operację zgodną z uprawnieniami, potem stopniowo przełącz pozostałe instancje i obserwuj błędy. Długość okresu współistnienia ustala firma według ryzyka; nie jest to narzucone przez KSeF okno.

Kiedy unieważnić stary certyfikat po rotacji?

W zwykłej rotacji zaplanowanej przed wygaśnięciem unieważnij stare poświadczenie dopiero po uzyskaniu dowodu, że wszystkie aplikacje i procedury korzystają z nowego, monitoring jest stabilny, a powrót nie będzie już potrzebny. Po unieważnieniu certyfikatu nie można użyć ponownie, dlatego decyzja powinna mieć właściciela i akceptację. Przy podejrzeniu kompromitacji obowiązuje inna logika: ograniczenie ryzyka i szybka reakcja incydentowa mają pierwszeństwo przed wygodnym okresem współistnienia.

Czym różni się certyfikat Typu 1 od Typu 2?

Typ 1 Uwierzytelnianie służy do uwierzytelniania w KSeF. Typ 2 Offline potwierdza tożsamość wystawcy i integralność faktury w trybach offline24, niedostępności systemu oraz awaryjnym, lecz nie może uwierzytelnić sesji API. Certyfikaty są wydawane osobno, dlatego należy osobno je zamówić, zinwentaryzować, wdrożyć i przetestować zgodnie z ich przeznaczeniem.

Co powinien zawierać rejestr certyfikatów KSeF?

Rejestr powinien łączyć unikalną nazwę i numer seryjny z typem, statusem, datami ważności, właścicielem, systemem, środowiskiem, miejscem wdrożenia, datą testu, zależnościami i dokumentacją zmiany. Dobrze dodać kontakt eskalacyjny oraz informację o planowanej rotacji i unieważnieniu. Nie wolno umieszczać w nim klucza prywatnego, haseł ani danych umożliwiających odtworzenie sekretu.

Czy certyfikat KSeF zawiera uprawnienia firmy?

Nie. Certyfikat jest poświadczeniem tożsamości i nie przenosi uprawnień ani kontekstu firmy; zakres dozwolonych działań KSeF sprawdza po stronie serwera. Dlatego pomyślne uwierzytelnienie nie oznacza automatycznie prawa do wysłania faktury lub wykonania każdej operacji. W diagnostyce trzeba oddzielić ważność i dostępność certyfikatu od konfiguracji uprawnień danego podmiotu.

Jak sprawdzić status i uzyskać nowy certyfikat przez API?

Metadane aktywne i historyczne można wyszukiwać przez POST /certificates/query, między innymi po statusie, terminie, nazwie, typie i numerze seryjnym. Proces wydania obejmuje sprawdzenie limitów i danych do wniosku, utworzenie PKCS#10 CSR wraz z prywatnym kluczem, POST /certificates/enrollments, odpytywanie statusu po numerze referencyjnym i POST /certificates/retrieve. Szczegóły żądań, autoryzacji i aktualne ograniczenia należy zawsze potwierdzić w oficjalnej dokumentacji CIRFMF przed automatyzacją.

Kluczowe przepisy, formaty i pojęcia

Komisja EuropejskaEN 16931Dyrektywa 2014/55/UEustrukturyzowana faktura elektronicznaInwentaryzacja, ważność i rotacja certyfikatów 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.