E-Invoice Finder
Menu
Kraje Oprogramowanie Terminy Przewodniki Checker Sprawdź obowiązek
ENFRDEPLNL
Polska · architektura i nadzór nad certyfikatami

Limity, nazewnictwo i własność certyfikatów KSeF dla wielu podmiotów

Zaprojektuj certyfikaty KSeF dla spółek i procesów ERP: bieżące limity, właściciel, nazwy, konteksty, klucze i testy odbiorowe.

Praktyczne podsumowanie:
  • • Zakres certyfikatu projektuj według właściciela, procesu i skutków odwołania.
  • • Największym zagrożeniem jest wspólny klucz bez kontroli kopii i selektywnego wyłączenia.
  • • Zacznij od uzgodnienia aktywnych pozycji z rejestrem systemów i opiekunów.
Sprawdź raport gotowościŹródła oficjalne
Ostatnia aktualizacja: 5 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

Tożsamość właściciela a kontekst podmiotu

Fakt oficjalny: certyfikat KSeF zawiera tożsamość uwierzytelnionego właściciela, nie zawiera uprawnień KSeF i nie jest przypisany do kontekstu konkretnej firmy. KSeF sprawdza uprawnienia po stronie serwera przy działaniu w wybranym kontekście. Dlatego ten sam certyfikat może technicznie zostać użyty w różnych spółkach, o ile jego właściciel ma w każdej z nich odpowiednie uprawnienie. Nie oznacza to jednak, że certyfikat przyznaje dostęp ani że raz poprawne logowanie potwierdza dostęp do całej grupy. Rekomendowanym mechanizmem nadzoru jest matryca właściciel–podmiot–proces–uprawnienie, za którą odpowiada właściciel kontroli dostępu. Dla każdej relacji należy wskazać podstawę uprawnienia, środowisko, system korzystający z klucza oraz wynik testu. Krytyczne ryzyko to błędne utożsamienie posiadania pliku certyfikatu z autoryzacją, prowadzące do wadliwej konfiguracji ERP albo zbyt szerokiej dystrybucji sekretu. Kryterium odbioru: każda planowana spółka ma osobny, udokumentowany test pozytywny i negatywny, a architekt potrafi wykazać, że odmowa wynika z kontroli serwerowej, nie z zawartości certyfikatu.

Przewodnik

Bieżący limit, zdolność do wydania i zapas operacyjny

Fakt oficjalny: przed złożeniem wniosku przewodnik techniczny zaleca wywołanie GET /certificates/limits. Odpowiedź podaje maksymalną liczbę certyfikatów, które właściciel może posiadać, bieżącą liczbę aktywnych certyfikatów oraz informację, czy można złożyć kolejny wniosek. To ten punkt API jest źródłem prawdy; nie należy wpisywać stałego limitu do dokumentacji, kodu ani kalkulatora, ponieważ wartości mogą się zmienić. Za odczyt przed wdrożeniem i każdą rotacją powinien odpowiadać administrator certyfikatów, a wynik wraz ze znacznikiem czasu powinien trafić do zgłoszenia zmiany. Zalecanym, a nie ustawowym, mechanizmem jest utrzymywanie zapasu na awaryjne zastąpienie klucza oraz planowaną rotację bez wyłączania starego certyfikatu przed testem nowego. Ryzykiem jest wykorzystanie całej dostępnej pojemności przez certyfikaty testowe, porzucone lub dublujące ten sam proces. Kryterium odbioru: przed każdą falą zespół ma aktualną odpowiedź endpointu, policzone zapotrzebowanie, jawny zapas operacyjny i plan usunięcia zbędnych pozycji bez zakładania konkretnej wartości limitu.

Przewodnik

Certyfikat firmowy i osobisty: dwa modele odpowiedzialności

Fakt oficjalny: certyfikat firmowy wydany osobie prawnej nie jest związany z jednym pracownikiem. Firma odpowiada za ewidencję jego pobrania, przekazania, użycia i odwołania, a podmiot prawny może wnioskować o wiele takich certyfikatów w granicach aktualnego limitu. Certyfikat osobisty należy do wskazanej osoby; wyłącznie ta osoba może o niego wnioskować, pobrać go i używać. Oba modele dają w KSeF odmienne przypisanie czynności, więc wyboru nie wolno sprowadzać do technicznej wygody. Dla automatycznego procesu ERP certyfikat firmowy może ograniczyć zależność od zatrudnienia jednej osoby, ale wymaga mocnej kontroli organizacyjnej. Dla działania faktycznie wykonywanego przez konkretną osobę certyfikat osobisty zapewnia jednoznaczniejszą atrybucję i nie powinien być współdzielony. Zalecane kontrole to jeden odpowiedzialny opiekun dla każdego certyfikatu firmowego, zatwierdzona lista systemów lub osób mających dostęp oraz rejestr eksportów sekretu. Kryterium odbioru: dla każdego zastosowania właściciel biznesowy uzasadnia model, a audyt potrafi ustalić kto, kiedy, gdzie i w jakim celu posłużył się poświadczeniem.

Przewodnik

Praktyczna konwencja nazw i inwentaryzacja

Fakt oficjalny: przy rejestracji wymagane jest certificateName, a wybrana nazwa trafia później do metadanych. Można ją odczytać przez POST /certificates/query razem ze statusem, datą wygaśnięcia, typem i numerem seryjnym. Ministerstwo nie narzuca przedsiębiorstwom konwencji nazewniczej, dlatego każdy schemat opisany tutaj jest rekomendowaną kontrolą ładu, a nie wymogiem prawnym. Użyteczna nazwa może mieć postać PROD-ERP-SAP-WYSYLKA-GRUPA-A-01: pokazuje środowisko, obciążenie, funkcję, zakres i kolejną generację, ale nie umieszcza danych wrażliwych ani samego sekretu. Gdy jeden certyfikat obsługuje kilka spółek, nazwa powinna odsyłać do identyfikatora zakresu w inwentarzu zamiast tworzyć nieczytelną listę NIP. Za unikalność nazw odpowiada opiekun rejestru, a rekord powinien obejmować właściciela, typ, odcisk lub numer seryjny, magazyn klucza, podmioty, proces, środowisko, status i terminy. Kryterium odbioru: sto procent aktywnych pozycji z zapytania KSeF daje się uzgodnić z rejestrem i ma właściciela oraz jednoznaczny cel.

Przewodnik

Kiedy współdzielić zakres, a kiedy rozdzielić certyfikaty

Techniczna możliwość użycia jednego poświadczenia w wielu kontekstach nie oznacza, że zawsze jest to najlepszy projekt. Decyzję warto oprzeć na właścicielu certyfikatu, zgodności cyklu życia, liczbie spółek i systemów, wymaganej atrybucji, sposobie przechowywania klucza, skutkach kompromitacji oraz możliwości niezależnego odwołania. Jeden certyfikat dla spójnego, centralnego procesu może uprościć rotację i zmniejszyć zużycie dostępnej pojemności, jeżeli ten sam właściciel ma uprawnienia w każdym kontekście. Rozdzielenie na podmiot, środowisko albo krytyczne obciążenie zwiększa liczbę pozycji, lecz zmniejsza promień rażenia: wyciek lub awaria jednego klucza nie zatrzymuje wszystkich spółek, a odwołanie może być bardziej selektywne. Bezwzględnie należy oddzielić sekrety produkcyjne od testowych. Architekt bezpieczeństwa rekomenduje wariant, właściciel procesu akceptuje ryzyko, a administrator weryfikuje bieżący limit. Kryteria decyzji powinny być zapisane przed rejestracją; brak uzasadnienia, niekontrolowane kopiowanie jednego klucza i wspólny magazyn bez izolacji są sygnałami do przeprojektowania.

Przewodnik

Rejestracja, CSR i ochrona klucza prywatnego

Fakt oficjalny: dane rejestracyjne zwrócone przez GET /certificates/enrollments/data trzeba skopiować dokładnie do żądania PKCS#10 CSR. Wniosek może być wystawiony tylko na własne dane wnioskodawcy. Uwierzytelnienie tokenem systemowym nie pozwala pobrać danych rejestracyjnych; potrzebne jest uwierzytelnienie podpisane, XAdES. POST /certificates/enrollments przyjmuje certificateName, type, CSR oraz opcjonalne validFrom, działa asynchronicznie i zwraca referenceNumber, który należy zachować do śledzenia operacji. Typ 1 Authentication służy do uwierzytelniania, natomiast Typ 2 Offline służy do podpisywania kodów weryfikacyjnych wystawcy w trybie offline; typów nie można połączyć w jednym certyfikacie, a Typ 2 nie uwierzytelnia. Klucz prywatny powstaje podczas generowania CSR. Pobranie wydanego certyfikatu nie odtworzy utraconego klucza, dlatego operator musi od razu zapisać go w zatwierdzonym magazynie, ograniczyć eksport i sprawdzić kopię awaryjną. Kryterium odbioru: zachowane są hash CSR, referenceNumber, nazwa, typ i dowód kontroli klucza, a test potwierdza funkcję właściwą dla wybranego typu.

Przewodnik

Uprawnienia po stronie serwera i testy negatywne kontekstu

Fakt oficjalny: KSeF ocenia uprawnienia właściciela certyfikatu po stronie serwera w kontekście wybranego podmiotu. Endpointy zarządzania certyfikatami dotyczą uwierzytelnionego właściciela i pokazują ten sam zbiór jego certyfikatów niezależnie od kontekstu logowania. Lista widoczna po zmianie spółki nie dowodzi więc, że certyfikat należy do tej spółki ani że działa w niej automatycznie. Plan odbioru powinien obejmować macierz kontekstów: dozwoloną operację w każdej zamierzonej spółce, odmowę w podmiocie bez uprawnienia oraz próbę czynności przekraczającej rolę właściciela. Zespół QA ma zapisać identyfikator scenariusza, kontekst, operację, oczekiwany kod lub status, faktyczny wynik i korelację logów, bez utrwalania sekretu. Mierzalne kryterium: wszystkie dozwolone komórki macierzy kończą się sukcesem, wszystkie zabronione są odrzucone, a nieoczekiwany dostęp blokuje wdrożenie. Test należy ponowić po zmianie uprawnień, rotacji certyfikatu i dodaniu kolejnej spółki; samo powodzenie uwierzytelnienia nigdy nie zastępuje testu autoryzacji.

Przewodnik

Dowody wdrożenia, rotacji i odwołania — przykład operacyjny

Fakt oficjalny: certyfikat KSeF jest ważny nie dłużej niż dwa lata, lecz organizacja powinna planować wymianę na podstawie konkretnej daty ważności z metadanych, a nie wyłącznie tego maksimum. Przykład rekomendowanego procesu: centralny ERP obsługuje Spółkę Alfa i Spółkę Beta certyfikatem firmowym PROD-ERP-WYSYLKA-ZAKRES-AB-01. Przed rotacją administrator zapisuje wynik /certificates/limits, generuje nowy klucz i CSR w magazynie HSM, składa wniosek i wiąże referenceNumber ze zgłoszeniem. Po wydaniu aktualizuje inwentarz, testuje uwierzytelnienie oraz dozwolone i zabronione operacje osobno w obu kontekstach, następnie przełącza ruch, monitoruje błędy i dopiero po zatwierdzonym okresie nakładania odwołuje starą pozycję. Pakiet dowodowy obejmuje zgodę właściciela procesu, odpowiedź limitów, metadane obu certyfikatów, protokoły testów, log wdrożenia, potwierdzenie odwołania i uzgodnienie wyniku /certificates/query. Kryterium odbioru: brak utraty przetwarzania, pełne pokrycie obu spółek, odrzucenie kontekstu kontrolnego oraz brak starego klucza w aktywnych konfiguracjach po zamknięciu zmiany.

Przewodnik

Kryteria odbioru dostawcy, częste błędy i następne działania

Dostawca ERP lub integrator powinien udowodnić, a nie tylko zadeklarować, obsługę oddzielnych Typów 1 i 2, asynchronicznej rejestracji, bezpiecznego generowania CSR, magazynu kluczy, zmiany certyfikatu bez przestoju, wyboru kontekstu podmiotu i czytelnych błędów autoryzacji. Wymagaj demonstracji na realistycznej macierzy wielu spółek oraz eksportowalnego inwentarza z nazwą, typem, statusem, numerem seryjnym i datą wygaśnięcia. Kryteria mierzalne to: zero sekretów w logach, pełne uzgodnienie aktywnych certyfikatów z /certificates/query, stuprocentowe odrzucenie scenariuszy niedozwolonych, skuteczny powrót do poprzedniej konfiguracji i udokumentowane odwołanie testowego poświadczenia. Częste błędy to stały limit wpisany w kodzie, traktowanie certyfikatu jak nadania uprawnień, mylenie osobistego z firmowym, łączenie typów, pobieranie danych rejestracyjnych tokenem oraz założenie, że ponowne pobranie certyfikatu odzyska klucz. Następne działania: wyznacz opiekuna, pobierz żywe limity, uzgodnij inwentarz, zatwierdź model separacji i przeprowadź test awaryjnej rotacji. To informacje praktyczne, nie porada prawna ani podatkowa.

Lista kontrolna

Wyznacz odpowiedzialnego opiekuna każdego certyfikatu oraz właściciela biznesowego obsługiwanego procesu.

Zbuduj matrycę właściciel–podmiot–obciążenie–uprawnienie dla wszystkich środowisk i spółek.

Przed rejestracją i rotacją odczytaj GET /certificates/limits oraz zachowaj odpowiedź w zgłoszeniu.

Ustal zapas operacyjny na wymianę awaryjną bez wpisywania stałego limitu do polityki lub kodu.

Wybierz model firmowy albo osobisty na podstawie atrybucji, cyklu życia i odpowiedzialności za klucz.

Nadaj celową, unikalną nazwę opisującą środowisko, proces, zakres i generację certyfikatu.

Generuj CSR i klucz prywatny w zatwierdzonym magazynie oraz dokładnie kopiuj dane rejestracyjne.

Oddziel Typ 1 od Typu 2, a sekrety produkcyjne od testowych, bez niekontrolowanego współdzielenia.

Przetestuj sukces i odmowę dla każdej zamierzonej operacji oraz każdego kontekstu podmiotu.

Uzgadniaj inwentarz z /certificates/query i przechowuj dowody wdrożeń, rotacji oraz odwołań.

Najczęstsze pytania

Ile certyfikatów KSeF może mieć firma lub osoba?

Nie należy przyjmować stałej liczby. Aktualną maksymalną liczbę, liczbę aktywnych certyfikatów i możliwość złożenia kolejnego wniosku zwraca GET /certificates/limits dla uwierzytelnionego właściciela. Odczytaj endpoint bezpośrednio przed planowaniem wydania lub rotacji, zachowaj wynik i pozostaw uzasadniony zapas operacyjny.

Czy jeden certyfikat może działać dla wielu spółek i NIP?

Tak, technicznie może być używany w różnych kontekstach podmiotów, jeżeli jego właściciel ma tam właściwe uprawnienia. Certyfikat nie jest jednak przypisany do tych spółek i sam nie daje dostępu. Każdy kontekst trzeba przetestować osobno, a potencjalne uproszczenie zestawić z większym promieniem rażenia przy wycieku lub odwołaniu.

Czy dla każdego podmiotu ERP potrzebny jest osobny certyfikat?

Nie jest to automatyczny wymóg oficjalny. Rozdzielenie bywa rozsądne, gdy spółki mają innych właścicieli procesu, odmienne cykle wdrożeń, różne magazyny kluczy, wysokie wymagania atrybucji lub potrzebę selektywnego odwołania. Wspólny certyfikat może pasować do centralnego procesu, jeśli uprawnienia, ryzyko i bieżąca pojemność zostały udokumentowane.

Jak nazwać certyfikat KSeF?

KSeF wymaga pola certificateName, ale oficjalne materiały nie nakazują firmowej konwencji. Praktyczna nazwa może wskazywać środowisko, system, funkcję, zakres i generację, na przykład PROD-ERP-WYSYLKA-GRUPA-A-01. Nie umieszczaj w niej sekretów; pełny zakres spółek prowadź w inwentarzu powiązanym z numerem seryjnym.

Kto jest właścicielem certyfikatu firmowego, a kto osobistego?

Certyfikat firmowy jest wydany osobie prawnej i nie jest przypisany do jednego pracownika; firma odpowiada za jego pobranie, dystrybucję, użycie i odwołanie. Certyfikat osobisty należy do konkretnej osoby i tylko ona może o niego wnioskować, pobrać go i używać. Modele dają również inną atrybucję czynności w KSeF.

Czy certyfikat KSeF zawiera uprawnienia do wystawiania faktur?

Nie. Certyfikat potwierdza tożsamość właściciela, a KSeF sprawdza jego uprawnienia po stronie serwera dla bieżącego kontekstu i operacji. Dlatego samo posiadanie certyfikatu, widoczność jego metadanych albo udane uwierzytelnienie nie potwierdzają prawa do działania w danej spółce.

Czy Typ 1 i Typ 2 można połączyć w jednym certyfikacie?

Nie. Typ 1 Authentication służy do uwierzytelniania w KSeF, a Typ 2 Offline do podpisywania kodów weryfikacyjnych wystawcy w trybie offline i nie może służyć do uwierzytelnienia. Jeżeli proces potrzebuje obu funkcji, trzeba zaprojektować osobne certyfikaty, klucze, nazwy i kontrole użycia.

Co zrobić, gdy zgubiono klucz prywatny albo zbliża się wygaśnięcie?

Pobranie wydanego certyfikatu nie odtworzy klucza prywatnego utworzonego wraz z CSR. Utracony lub podejrzany klucz wymaga procedury odwołania i wydania nowego poświadczenia. Przy planowej rotacji sprawdź datę ważności oraz żywy limit, zachowaj czas na równoległy test nowego klucza i usuń stary z konfiguracji po kontrolowanym przełączeniu.

Kluczowe przepisy, formaty i pojęcia

Komisja EuropejskaEN 16931Dyrektywa 2014/55/UEustrukturyzowana faktura elektronicznaLimity, nazewnictwo i własność certyfikatów KSeF dla wielu podmiotówPolska

Czytaj dalej

Źródła oficjalne

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