Bezpieczeństwo KSeF: kto może czytać faktury polskich firm

19 października 2026 Grzegorz GPS Świderski

Wstęp i metoda

Materiał przedstawia dziesięć tez o architekturze i bezpieczeństwie Krajowego Systemu e-Faktur (KSeF). Każda teza ma ten sam układ: teza w jednym zdaniu, dowód, czyli skąd to wiem, opis wyjaśniający znaczenie dla przedsiębiorcy oraz słabe punkty, czyli możliwe zarzuty i odpowiedzi na nie.

Rozróżniam cztery rodzaje dowodu, bo mają różną siłę.

1. Dowód typu A to pomiar techniczny, który każdy może powtórzyć na własnym komputerze: zapytanie DNS, sprawdzenie właściciela adresu IP, odczyt nagłówków HTTP i certyfikatu TLS.
2. Dowód typu B to dokumentacja urzędowa, czyli oficjalna specyfikacja API KSeF i akty prawne; sprawdzi go każdy, kto przeczyta źródło.
3. Dowód typu C to publiczne dane o podmiotach, takie jak rejestry i komunikaty spółek giełdowych; również sprawdzalne u źródła.
4. Typ D to wnioskowanie z dowodów A–C, którego ocena zależy od przyjętych założeń.

Zasada: twierdzenia typu A–C podaję jako fakty; twierdzenia typu D oznaczam jako wnioski. Gdzie dowodu bezpośredniego brak, piszę to wprost.

1. Bramkę wejściową KSeF obsługuje Imperva w chmurze

Teza: Ruch podatnika do KSeF nie trafia bezpośrednio do serwerów Ministerstwa Finansów. Najpierw przechodzi przez chmurową zaporę aplikacyjną Imperva Cloud WAF, która dopiero przekazuje go dalej do MF. Dotyczy to zarówno środowiska produkcyjnego, jak i środowisk testowych.

Dowód: Pierwszy audyt wykonałem 6 lutego 2026 r. metodą czarnej skrzynki, czyli z zewnątrz, mając dostęp wyłącznie do tego, co widzi każdy użytkownik Internetu. Pełny raport opublikowałem tego samego dnia, a zaktualizowałem 26 maja 2026 r. (https://informacje-lokalne.pl/audyt-techniczny-ksef-raport-pelny-2026-02-06/). Zbadałem wtedy nazwę produkcyjną ksef.mf.gov.pl oraz nazwy środowisk testowego i przedprodukcyjnego: api-test.ksef.mf.gov.pl i api-demo.ksef.mf.gov.pl. Pomiar powtórzyłem 19 października 2026 r. o godzinie 14:22 czasu polskiego (12:22 UTC) z komputera z systemem Windows, dołączając produkcyjny adres API: api.ksef.mf.gov.pl. Każdy z testów opisanych poniżej można powtórzyć samodzielnie jedną komendą.

Pierwszy test dotyczył systemu nazw domen (DNS), który zamienia nazwę serwisu na adres serwera. W lutym zapytanie o nazwę ksef.mf.gov.pl zwróciło nie adres serwera MF, lecz rekord CNAME, czyli alias wskazujący nazwę w domenie impervadns.net, należącej do Impervy. Tak samo odpowiedziały nazwy środowisk testowego i przedprodukcyjnego, a wszystkie prowadziły do tego samego adresu IP: 45.60.74.103. Pomiar z 19 października potwierdził ten stan. Polecenie „Resolve-DnsName ksef.mf.gov.pl” zwróciło alias nudnsjz.ng.impervadns.net, a ten adres 45.60.74.103. Produkcyjne API, api.ksef.mf.gov.pl, ma alias hju8yoo.ng.impervadns.net, prowadzący do tego samego adresu 45.60.74.103. W obu odpowiedziach jako administrator strefy impervadns.net figuruje hostmaster.incapsula.com. Wniosek z tego testu jest prosty: Ministerstwo Finansów samo skierowało swoje domeny, w tym domenę produkcyjnego API, do usługi Impervy.

Drugi test ustalał, do kogo należy ten adres. W lutym zapytanie whois o adres 45.60.74.103 pokazało, że należy on do systemu autonomicznego AS19551, zarejestrowanego na Imperva Inc. z siedzibą w Ashburn w stanie Wirginia w USA. System autonomiczny to blok adresów internetowych zarządzany przez jedną organizację. W październiku zapytałem amerykański rejestr adresów ARIN przez jego oficjalny interfejs RDAP. Adres 45.60.74.103 leży w bloku od 45.60.0.0 do 45.60.255.255 (65 536 adresów), zarejestrowanym pod identyfikatorem NET-45-60-0-0-1. Nazwa tej sieci w rejestrze brzmi THALES-IMPERVA-NA4-AGG-45-60. Rejestr wprost łączy więc adres, pod który trafia polski podatnik, z Impervą i jej właścicielem, francuskim koncernem Thales (więcej w punkcie 3).

Trzeci test sprawdzał, jak serwer przedstawia się klientowi w nagłówkach odpowiedzi HTTP. Polecenie „curl.exe -sI https://ksef.mf.gov.pl” wykonane 19 października zwróciło odpowiedź „HTTP/1.1 200 OK” z datą serwera „Mon, 19 Oct 2026 12:22:01 GMT”. W odpowiedzi znalazł się nagłówek „X-CDN: Imperva”, w którym serwer wprost podaje nazwę operatora, oraz nagłówek diagnostyczny Impervy o treści „X-Iinfo: 45-4053154-4053185 NNNY CT(3 9 0) RT(1792412521478 111) q(0 0 0 4) r(0 0) U6”. Serwer ustawił też trzy ciasteczka Impervy: „visid_incap_3145187”, „nlbi_3145187” i „incap_ses_682_3145187”. Przedrostek „incap” pochodzi od Incapsula, firmy przejętej przez Impervę w 2014 r., z której wywodzi się jej chmurowy WAF. Liczba 3145187, wspólna dla wszystkich trzech ciasteczek, to najpewniej numer, pod którym serwis MF jest zarejestrowany na koncie w Imperva. Ciasteczka te mają ustawioną domenę „.mf.gov.pl”, więc przeglądarka dołącza je do zapytań do wszystkich serwisów w domenie Ministerstwa Finansów, a nie tylko do KSeF. Czwarte ciasteczko, „TS010dbaa6”, ma przedrostek typowy dla zapory aplikacyjnej F5 BIG-IP i pochodzi najpewniej z urządzenia stojącego za bramką, po stronie MF. W lutym jego obecność potwierdzał nagłówek „Server: BigIP”, którego w październiku już nie było. Wyniki z lutego zawierały te same nagłówki „X-CDN: Imperva” i „X-Iinfo” oraz ciasteczka „incap_ses_” i „visid_incap_”.

Czwarty test dotyczył certyfikatu TLS, czyli cyfrowego dokumentu, którym serwer potwierdza swoją tożsamość przy nawiązywaniu szyfrowanego połączenia. W lutym serwer przedstawił certyfikat wystawiony dla „*.ksef.mf.gov.pl” na organizację Ministerstwo Finansów, podpisany przez urząd certyfikacji GeoTrust TLS RSA CA G1 z grupy DigiCert, ważny od 12 sierpnia 2025 r. do 12 sierpnia 2026 r. 19 października nawiązałem połączenie TLS 1.2 z nazwą ksef.mf.gov.pl, czyli z adresem 45.60.74.103 należącym do Impervy. Serwer przedstawił certyfikat o następujących danych: podmiot „CN=*.ksef.mf.gov.pl, O=MINISTERSTWO FINANSÓW, L=Warszawa, C=PL”, wystawca „CN=GeoTrust TLS RSA CA G1, OU=www.digicert.com, O=DigiCert Inc, C=US”, ważność od 8 grudnia 2025 r. do 8 grudnia 2026 r., odcisk (thumbprint) 6AF8575E9149E4B62C04027912951BFF43A75DEE. Certyfikat Ministerstwa Finansów jest więc przedstawiany klientom przez serwer Impervy, a połączenie szyfrowane zestawia się właśnie z tym serwerem. Co z tego wynika dla poufności danych, omawiam w punkcie 2.

Piąty test dotyczył samego systemu nazw Ministerstwa Finansów, czyli tego, kto odpowiada na pytanie „pod jakim adresem jest dana usługa MF”. Takich odpowiedzi udzielają tak zwane serwery autorytatywne domeny, wskazane w rekordach NS. 19 października 2026 r. polecenie „Resolve-DnsName mf.gov.pl -Type NS” zwróciło dwa serwery: ns1.a0.impervasecuredns.net i ns1.a1.impervasecuredns.net. Oba należą do usługi DNS Impervy. Zapytanie do publicznego serwera DNS Google (dns.google) dało ten sam wynik, a odpowiedzi przyszły z adresów 192.230.121.1 i 192.230.123.1. Rejestr ARIN przypisuje je do bloku 192.230.64.0–192.230.127.255 o nazwie THALES-IMPERVA-NA4-AGG-192-230-64, zarejestrowanego na Incapsula Inc. Polecenie „Resolve-DnsName mf.gov.pl -Type SOA” pokazało, że administratorem strefy jest hostmaster.mf.gov.pl. Treścią rekordów zarządza więc ministerstwo, ale serwery, które je udostępniają światu, prowadzi Imperva. Dotyczy to całej domeny mf.gov.pl, a nie tylko adresów KSeF. Ponadto w domenie nadrzędnej gov.pl nie ma dla mf.gov.pl rekordu DS, więc odpowiedzi DNS dla domeny Ministerstwa Finansów nie są chronione podpisem kryptograficznym DNSSEC. Tym samym poleceniem widać też, że pozostałe usługi KSeF wskazują adresy Impervy: serwis kodów QR qr.ksef.mf.gov.pl ma adres 45.60.187.129, a Aplikacja Podatnika ap.ksef.mf.gov.pl adres 45.60.186.93; oba leżą w bloku THALES-IMPERVA-NA4-AGG-45-60 (o tym, w jakim trybie Imperva obsługuje te dwa adresy, mówi punkt 4). Obrazowo: Imperva nie tylko pilnuje wejścia do KSeF, ale też prowadzi spis adresów wszystkich serwisów Ministerstwa Finansów.

Opis: Zapora aplikacyjna (WAF, Web Application Firewall) działa jak recepcja w biurowcu. Gość nie wchodzi prosto do mieszkania, tylko najpierw melduje się w recepcji, która go sprawdza i dopiero wpuszcza dalej. W przypadku KSeF recepcję prowadzi nie Ministerstwo Finansów, tylko prywatna firma zagraniczna. Dla przedsiębiorcy oznacza to, że każde jego połączenie z KSeF, w tym wysyłka i pobieranie faktur, przechodzi przez infrastrukturę Impervy.

Jak to sprawdzić samodzielnie: W systemie Windows wystarczy otworzyć PowerShell i wpisać kolejno „Resolve-DnsName ksef.mf.gov.pl” (alias i adres IP), „Invoke-RestMethod https://rdap.arin.net/registry/ip/45.60.74.103 | Select-Object name, handle, startAddress, endAddress” (właściciel adresu), „curl.exe -sI https://ksef.mf.gov.pl” (nagłówki) oraz „Resolve-DnsName mf.gov.pl -Type NS” (serwery nazw całej domeny MF). Certyfikat najprościej obejrzeć w przeglądarce po kliknięciu kłódki przy adresie ksef.mf.gov.pl. W systemach Linux i macOS odpowiednikami są „dig ksef.mf.gov.pl +noall +answer”, „whois 45.60.74.103”, „curl -sI https://ksef.mf.gov.pl” oraz „openssl s_client -connect ksef.mf.gov.pl:443 -servername ksef.mf.gov.pl”, która wyświetla certyfikat. Jeśli zwrócony adres IP jest inny niż 45.60.74.103, w drugim poleceniu należy wpisać ten zwrócony.

Słabe punkty i odpowiedź: Pomiary opisują stan z 6 lutego i 19 października 2026 r., a ministerstwo może zmienić konfigurację w każdej chwili. Zgodność obu pomiarów, wykonanych w odstępie ośmiu miesięcy, pokazuje jednak, że chodzi o rozwiązanie trwałe, a nie o tymczasowe ustawienie. Certyfikat zmienił się między pomiarami, ale nowy również jest przedstawiany przez serwer Impervy, więc wniosek pozostaje ten sam. Obecny certyfikat traci ważność 8 grudnia 2026 r.; kto będzie sprawdzał po tej dacie, zobaczy kolejny.

Audyt metodą czarnej skrzynki dowodzi, którędy płynie ruch, ale sam nie dowodzi, że ktokolwiek odczytał dane. Operatorem punktu wejścia do KSeF jest Imperva. Krytyk może odpowiedzieć, że Imperva pełni tylko rolę ochrony przed atakami DDoS i nie ma dostępu do treści. Na ten zarzut odpowiada punkt 2.

2. Bramka terminuje TLS i widzi metadane faktur w JSON

Teza: Szyfrowany tunel HTTPS, który przedsiębiorca nawiązuje z KSeF, kończy się na serwerze Impervy, a nie na serwerze Ministerstwa Finansów. Na serwerze Impervy ruch jest odszyfrowany: widać tam adresy wywoływanych funkcji, nagłówki, w tym tokeny dostępowe, oraz treść zapytań i odpowiedzi, w tym metadane faktur w formacie JSON. Dopiero potem bramka szyfruje ruch ponownie i przesyła go do MF. Fachowo nazywa się to terminacją TLS.

Dowód: Kluczowy test wykonałem 19 października 2026 r. o godzinie 14:29 czasu polskiego (12:29:17 UTC). Aby zrozumieć jego wymowę, trzeba wiedzieć, że połączenie HTTPS niesie dwie informacje o tym, do jakiego serwisu się łączymy. Pierwsza to pole SNI (Server Name Indication), wysyłane jawnie na samym początku połączenia, zanim powstanie szyfrowany tunel; służy serwerowi do wyboru certyfikatu. Druga to nagłówek Host, będący częścią właściwego zapytania HTTP, które wysyłane jest już wewnątrz zaszyfrowanego tunelu. Jeśli serwer odpowiada różnie w zależności od nagłówka Host, a wszystko inne pozostaje bez zmian, to znaczy, że ten nagłówek odczytał, a więc musiał najpierw odszyfrować zapytanie.

Test polegał na wysłaniu dwóch zapytań, które różniły się tylko nagłówkiem Host. Obydwa poszły na ten sam adres Impervy 45.60.74.103 (wymusza to opcja „–connect-to ::45.60.74.103:” programu curl), obydwa miały to samo pole SNI „ksef.mf.gov.pl” (curl pobiera je z adresu URL, niezależnie od nagłówka Host), a ten sam certyfikat „*.ksef.mf.gov.pl” obejmuje obie nazwy. Pierwsze polecenie brzmiało „curl.exe -sI –connect-to ::45.60.74.103: https://ksef.mf.gov.pl”, drugie było identyczne, z dodanym nagłówkiem „-H „Host: api-test.ksef.mf.gov.pl””.

Pierwsze zapytanie, z nagłówkiem Host równym ksef.mf.gov.pl, dostało odpowiedź „HTTP/1.1 200 OK”. Imperva ustawiła w niej ciasteczka z identyfikatorem 3145187 (visid_incap_3145187, nlbi_3145187, incap_ses_682_3145187), pojawiło się ciasteczko „TS010dbaa6” typowe dla urządzeń F5 BIG-IP, a nagłówek bezpieczeństwa HSTS miał wartość „max-age=16070400”. Drugie zapytanie, z nagłówkiem Host równym api-test.ksef.mf.gov.pl, dostało zupełnie inną odpowiedź: „HTTP/1.1 405 Method Not Allowed” z nagłówkiem „Allow: GET” i nagłówkiem „Server: Kestrel”, który wskazuje serwer aplikacyjny platformy Microsoft ASP.NET Core, czyli zaplecze testowego API KSeF. Imperva ustawiła tu ciasteczka z innym identyfikatorem, 3285211, i z inną domeną (.ksef.mf.gov.pl), nie było ciasteczka F5, a nagłówek HSTS miał wartość „max-age=31536000”. Obie odpowiedzi zawierały nagłówek „X-CDN: Imperva”.

Wniosek: zmiana nagłówka Host przy stałym adresie IP i SNI powoduje zmianę odpowiedzi oraz identyfikatorów serwisu w ciasteczkach Impervy. Sama różnica w odpowiedzi aplikacji nie lokalizuje jeszcze terminacji TLS, bo nagłówek Host mógłby odczytać także serwer zaplecza za pośrednikiem, który tylko przekazuje zaszyfrowany ruch. Rozstrzygają to jednak trzy inne obserwacje.

Po pierwsze, ciasteczka incap oraz nagłówki X-CDN i X-Iinfo dopisuje do odpowiedzi HTTP sama Imperva, a odpowiedź HTTP jest przesyłana wewnątrz szyfrowanego tunelu. Pośrednik, który tylko przekazuje zaszyfrowane pakiety, nie może niczego do niej dopisać.

Po drugie, identyfikator serwisu w ciasteczkach Impervy zmienia się razem z nagłówkiem Host: 3145187 dla ksef.mf.gov.pl, 3285211 dla api-test.ksef.mf.gov.pl i 3296082 dla api.ksef.mf.gov.pl (uzupełnienie na końcu materiału). Nagłówek Host odczytała więc Imperva, a nie zaplecze ministerstwa.

Po trzecie, na zapytanie o ścieżkę /_incapsula_resource, przesyłaną również wewnątrz tunelu, odpowiedziała maszyna Impervy, podając nazwę swojego węzła (punkt 8). Pośrednik nie może odpowiedzieć na zapytanie, którego nie odszyfrował. Terminacja TLS na infrastrukturze Impervy dla bramki API jest zatem ustalona pomiarem (typ A). Wnioskiem (typ D) pozostaje dopiero to, co dzieje się z odszyfrowanymi danymi. Dodatkowy pomiar produkcyjnego API z godziny 17:39 opisano w uzupełnieniu na końcu materiału.

Wynik jest zgodny z udokumentowaną architekturą Imperva Cloud WAF: odrębnym szyfrowanym połączeniem klienta z punktem obecności operatora i połączeniem tego punktu z serwerem źródłowym. Źródło: https://community-cybersec.thalesgroup.com/discussion/cloud-waf-fundamentals-understanding-key-concepts-architecture-and-global-security-questions-and-answers. Sam certyfikat wystawiony na Ministerstwo Finansów ani przynależność adresu IP nie wystarczają do wskazania operatora terminacji. Wniosek opiera się na łącznym zestawie obserwacji.

Opis: Połączenie szyfrowane działa jak zaklejona koperta. Przedsiębiorca sądzi, że kopertę otworzy dopiero adresat, czyli Ministerstwo Finansów. W rzeczywistości kopertę otwiera pośrednik, czyta treść, wkłada ją do nowej koperty i wysyła dalej. Na bramce Impervy widać w postaci jawnej wszystko, co niesie protokół HTTP. To adres wywoływanej funkcji API, na przykład wyszukiwania faktur. To parametry zapytania, na przykład zakres dat albo NIP kontrahenta. To odpowiedzi z listami metadanych faktur, których jawność na bramce opisałem w osobnym audycie (https://www.mpolska24.pl/post/21092/audyt-techniczny-jawnosc-metadanych-faktur-ksef-w-json-na-bramce-waf-obslugiwanej-przez-imperve). Wreszcie to nagłówek z tokenem dostępowym typu bearer. Token bearer działa jak klucz do mieszkania: kto go posiada, może z niego korzystać, dopóki nie wygaśnie, a serwer nie odróżni prawowitego właściciela od kogoś, kto klucz skopiował. Nieczytelna dla bramki pozostaje tylko treść zaszyfrowana dodatkowo na poziomie aplikacji, o czym mowa w punkcie 4.

Tokeny dostępowe. Według dokumentacji uwierzytelniania KSeF 2.0 z 10 lipca 2025 r. (https://github.com/CIRFMF/ksef-api/blob/main/uwierzytelnianie.md) po zalogowaniu program podatnika otrzymuje dwa tokeny. Token dostępowy (accessToken) w formacie JWT jest ważny przez kilkanaście minut, a token odświeżający (refreshToken) do 7 dni i może być używany wielokrotnie do uzyskiwania kolejnych tokenów dostępowych. Oba przesyła się w nagłówku „Authorization: Bearer”. Dokumentacja nie przewiduje powiązania tokenu z konkretnym klientem, na przykład przez wzajemne uwierzytelnienie certyfikatem (mTLS) czy mechanizm DPoP; jedynym opisanym ograniczeniem jest opcjonalna lista dozwolonych adresów IP. Każda faktura wysyłana przez interfejs API trafia tam w uwierzytelnionej sesji. Przez bramkę przechodzą więc tokeny wszystkich wystawców korzystających z programów księgowych.

Dla adresu Aplikacji Podatnika miejsce terminacji TLS pozostaje nieustalone (punkt 4). Polityka bezpieczeństwa tej aplikacji pozwala jej jednak łączyć się z login.mf.gov.pl, a ten ruch Imperva odszyfrowuje. Serwery ministerstwa łączą się przy tym na poziomie sieciowym wyłącznie z serwerami Impervy, a adres faktycznego klienta znają jedynie z nagłówka HTTP (np. X-Forwarded-For lub Incap-Client-IP), który dopisuje sama bramka po odszyfrowaniu połączenia TLS; w ten sam sposób jedyne opisane w dokumentacji MF zabezpieczenie bearer tokenu (opcjonalna lista dozwolonych adresów IP) opiera się całkowicie na zaufaniu do nagłówka wstrzykiwanego przez pośrednika (wniosek typu D, wynikający z zasady działania pośrednika). Przechwycony bearer token może pozwolić na uwierzytelnienie zapytań jako jego posiadacz; nie oznacza to jednak, że nadużycia nie da się wykryć przez analizę logów i anomalii. W połączeniu z punktem 4, czyli pobieraniem pojedynczych faktur bez szyfrowania aplikacyjnego, oznacza to ryzyko odczytu faktur w granicach uprawnień przechwyconej sesji, o ile obejmują one InvoiceRead. Samo uprawnienie do wystawiania nie dowodzi prawa odczytu.

Od 1 lutego 2026 r. każdy podatnik musi jednak odbierać faktury w KSeF, więc program, który obsługuje zarówno sprzedaż, jak i faktury kosztowe, potrzebuje obu uprawnień. Jak często łączy je w jednej sesji, tego nie ustalono; jest to wniosek typu D. Według tej samej dokumentacji odświeżony token dostępowy odzwierciedla aktualny zestaw uprawnień i ról, a raz wydany token dostępowy pozostaje ważny do terminu zapisanego w polu exp, nawet jeśli uprawnienia się zmienią. Unieważnianie sesji opisuje osobny dokument o zarządzaniu sesjami.

Słabe punkty i odpowiedź:

Pierwszy zarzut brzmi: „Banki i urzędy też używają zapór WAF i sieci CDN”. To prawda, ale teza nie dotyczy samego użycia WAF. Dotyczy połączenia trzech faktów: operatorem jest podmiot zagraniczny (punkt 3), część danych nie ma szyfrowania aplikacyjnego (punkt 4), a dane te obejmują faktury całej gospodarki.

Drugi zarzut: „Umowa zabrania Impervie wglądu w dane”. Umowa nie jest jawna, a zakaz umowny nie jest zabezpieczeniem technicznym. Bezpieczeństwo faktur opiera się w tej architekturze na dobrej woli pośrednika i na prawie, któremu ten pośrednik podlega, a nie na kryptografii.

Trzeci zarzut: operator może korzystać z rozwiązania typu Keyless SSL, w którym klucz prywatny certyfikatu pozostaje u klienta. Samo miejsce przechowywania tego klucza nie przesądza jednak o miejscu przetwarzania jawnej treści HTTP. W takiej architekturze klucz prywatny na serwerze klienta służy wyłącznie do autoryzacji początkowego uścisku dłoni (TLS handshake) i uzgodnienia tymczasowego klucza sesyjnego, który i tak trafia do pamięci serwera brzegowego WAF, aby ten mógł odszyfrować ruch HTTP i wykonać inspekcję. W architekturze z terminacją TLS u pośrednika pozostawienie klucza certyfikatu poza jego infrastrukturą nie uniemożliwia więc pośrednikowi odczytu danych sesji. Wniosek dotyczący KSeF opiera się na zestawie pomiarów i dokumentacji, nie na założeniu, że operator przechowuje klucz prywatny MF.

Granice ustalenia: łączny zestaw pomiarów dowodzi terminacji TLS w usłudze Imperva dla bramki API i techniczną dostępność niezaszyfrowanej dodatkowo treści HTTP dla komponentu kończącego TLS. Nie pokazuje, czy dane są zapisywane, jak długo ani które osoby mają do nich dostęp. To wymaga informacji o konfiguracji, uprawnieniach, umowie i wynikach kontroli.

3. Imperva: kto jest właścicielem i czyje prawo ją obowiązuje

Teza: Bramkę KSeF obsługuje Imperva Inc., amerykańska spółka założona przez Izraelczyków, z zapleczem inżynierskim w Izraelu. Od grudnia 2023 r. jej właścicielem jest francuski koncern zbrojeniowy Thales, kontrolowany przez państwo francuskie i grupę Dassault. Operator punktu wejścia do polskiego rejestru faktur podlega więc prawu amerykańskiemu i pozostaje w strukturze właścicielskiej, w której decydujący głos ma państwo francuskie.

Dowód: Wszystkie fakty w tym punkcie pochodzą z danych publicznych (dowód typu C): komunikatów spółek, rejestrów, aktów prawnych i prasy gospodarczej. Źródła podaję przy każdym akapicie. Wnioski prawne wyraźnie oznaczam jako wnioski (typ D).

Pochodzenie. Imperva powstała w 2002 r. pod nazwą WEBcohort. Założyli ją izraelscy specjaliści od bezpieczeństwa: Shlomo Kramer (wcześniej współzałożyciel Check Point, a jeszcze wcześniej żołnierz jednostki 8200, izraelskiej wojskowej jednostki wywiadu elektronicznego i cyberbezpieczeństwa; https://en.wikipedia.org/wiki/Shlomo_Kramer), Amichai Shulman i Mickey Boodaei. Siedziba spółki mieściła się w Kalifornii, a działy badawczo-rozwojowe w Tel Awiwie i Rechowot. W 2018 r. firma zatrudniała w Izraelu 400–500 osób (https://www.calcalistech.com/articles/0,7340,L-3747400,00.html, https://www.jns.org/imperva-to-be-acquired-by-thoma-bravo-for-2-1-billion/). W lutym 2014 r. Imperva przejęła izraelski start-up Incapsula, z którego wywodzi się jej chmurowa zapora Cloud WAF, ta sama, która obsługuje KSeF. Do 2019 r. spółka była notowana na nowojorskiej giełdzie Nasdaq. Potem kupił ją amerykański fundusz Thoma Bravo za około 2,1 mld USD.

Przejęcie przez Thales. W lipcu 2023 r. francuski koncern Thales ogłosił zakup Impervy, a 4 grudnia 2023 r. sfinalizował transakcję wartą około 3,6 mld USD. Według Thalesa to druga co do wielkości akwizycja w historii grupy; dzięki niej Ameryka Północna stała się drugim rynkiem działalności koncernu (https://www.thalesgroup.com/en/news-centre/press-releases/thales-completes-acquisition-imperva-creating-global-leader, https://securityjournalamericas.com/thales-billion-dollar-imperva/). Nowy właściciel jest widoczny także w danych technicznych. 19 października 2026 r. amerykański rejestr adresów ARIN podał dla bloku adresów, w którym leży bramka KSeF, nazwę sieci THALES-IMPERVA-NA4-AGG-45-60 (punkt 1).

Thales i jego właściciele. Thales to francuska grupa działająca w obronności, lotnictwie, przestrzeni kosmicznej i cyberbezpieczeństwie. W 2025 r. miała 22,1 mld euro przychodów. Uczestniczy między innymi w modernizacji francuskiej rakiety jądrowej ASMPA i w dostosowaniu pocisku M51 na okręty podwodne, czyli w programach francuskiego odstraszania nuklearnego. Ma też 35% udziałów w stoczni Naval Group (https://www.dontbankonthebomb.com/thales/). Największymi akcjonariuszami Thalesa są państwo francuskie (około 26,6% akcji i około 36% głosów) oraz Dassault Aviation (około 26,6% akcji). Oboje działają na podstawie porozumienia akcjonariuszy, zawartego w 2009 r., gdy Dassault odkupił udziały od Alcatel-Lucent (https://www.thalesgroup.com/en/investor/retail-investors/share-and-shareholding, https://www.defenseindustrydaily.com/Dassault-Takes-a-Major-Stake-in-Thales-05213/). Państwo ma więcej głosów niż akcji, ponieważ statut Thalesa (art. 17) przyznaje podwójne prawo głosu akcjom imiennym posiadanym nieprzerwanie co najmniej dwa lata. Z kolei Dassault Aviation jest kontrolowana przez rodzinny holding Groupe Industriel Marcel Dassault, który według stanu na 30 czerwca 2026 r. ma 66,86% akcji i 80,40% głosów (https://www.dassault-aviation.com/en/group/about-us/shareholding-structure-and-organization-chart/).

Statut Thalesa. Aktualny statut spółki, w wersji z 8 października 2024 r. opublikowanej na stronie Thalesa (https://www.thalesgroup.com/sites/default/files/2025-06/Articles%20of%20association%208th%20october%202024.pdf), potwierdza szczególną pozycję państwa francuskiego. Zgodnie z art. 6 w kapitale spółki znajduje się akcja specjalna, tak zwana złota akcja. Powstała ona z zamiany zwykłej akcji należącej do państwa na mocy dekretu nr 97-190 z 4 marca 1997 r. Akcja ta daje państwu trzy uprawnienia.

Po pierwsze, każde przekroczenie przez kogokolwiek, bezpośrednio lub pośrednio, samodzielnie lub w porozumieniu z innymi, progu 10% kapitału lub głosów, a także każdej kolejnej wielokrotności 10%, wymaga uprzedniej zgody ministra gospodarki.

Po drugie, na wniosek ministra obrony państwo powołuje dekretem swojego przedstawiciela do rady dyrektorów spółki, bez prawa głosu; potwierdza to art. 10.2 statutu.

Po trzecie, minister gospodarki może sprzeciwić się zbyciu lub obciążeniu aktywów wymienionych w załączniku do dekretu z 1997 r.

Statut zawiera jeszcze jeden przepis, rzadko spotykany w spółkach giełdowych. Art. 19 stanowi, że w celu realizacji przedmiotu działalności spółki można powołać do dwudziestu delegowanych urzędników państwowych lub wojskowych na stanowiska w zarządzie ogólnym oraz na stanowiska techniczne, finansowe i administracyjne w spółce. Siedziba Thalesa mieści się w Meudon pod Paryżem (art. 4), a spory dotyczące spółki rozstrzygają sądy francuskie (art. 21).

Z tych zapisów wynika, że państwo francuskie ma w Thalesie formalne, statutowe instrumenty wpływu. Kontroluje zmiany w akcjonariacie. Ma w radzie dyrektorów własnego przedstawiciela, wskazanego przez ministra obrony. Może też umieszczać w spółce urzędników i wojskowych, także na stanowiskach technicznych.

Trzeba jednak precyzyjnie zaznaczyć, że statut dotyczy spółki-matki Thales SA, a nie bezpośrednio Impervy Inc. Wpływ państwa francuskiego na Impervę jest pośredni i wynika ze struktury właścicielskiej i zarządczej grupy; to wniosek typu D. Publicznie nie wiadomo, czy w Impervie pracują delegowani urzędnicy lub wojskowi, ani czy załącznik do dekretu z 1997 r. obejmuje dziś aktywa z obszaru cyberbezpieczeństwa.

Jurysdykcja USA. Imperva Inc. jest spółką amerykańską, więc obowiązuje ją prawo USA. Najważniejsza jest tu ustawa CLOUD Act, podpisana 23 marca 2018 r. Zobowiązuje ona amerykańskich dostawców usług komunikacji elektronicznej do wydania na żądanie władz USA danych, które mają w posiadaniu lub pod kontrolą, niezależnie od tego, czy dane te znajdują się w USA, czy za granicą (https://www.wilmerhale.com/en/insights/client-alerts/congress-enacts-law-clarifying-reach-of-warrants-for-overseas-data). Drugim instrumentem jest sekcja 702 ustawy FISA o wywiadzie zagranicznym. W kwietniu 2024 r. Kongres znacznie poszerzył krąg podmiotów, które można zmusić do współpracy, o każdego, kto ma dostęp do urządzeń przenoszących lub przechowujących komunikację (https://www.eff.org/702-spying/702-recent-reauthorizations).

Umowa nie chroni przed nakazem amerykańskim z dwóch powodów. Pierwszy powód to tajność nakazu. Na podstawie § 2705(b) tytułu 18 Kodeksu Stanów Zjednoczonych sąd może, na wniosek organu ścigania, zakazać dostawcy informowania kogokolwiek o otrzymanym nakazie, na tak długo, jak uzna za stosowne (https://www.cacd.uscourts.gov/sites/default/files/16mj2316-1.pdf).

Imperva mogłaby więc wydać dane, nie mając prawa powiadomić o tym Ministerstwa Finansów. Żadna klauzula umowna o obowiązku notyfikacji nie zmienia tego zakazu. Drugi powód to ograniczony zakres sprzeciwu. CLOUD Act daje dostawcy ustawowe prawo do wniosku o uchylenie nakazu z powodu kolizji z prawem obcym tylko wtedy, gdy chodzi o prawo państwa, które zawarło z USA specjalną umowę wykonawczą na podstawie tej ustawy.

Pierwszą taką umowę zawarła Wielka Brytania (weszła w życie 3 października 2022 r.; https://www.justice.gov/archives/opa/pr/landmark-us-uk-data-access-agreement-enters-force). Polska takiej umowy nie ma, więc Imperva nie mogłaby skorzystać z tej procedury, powołując się na polskie prawo. Pozostałaby jej jedynie ogólna, pozaustawowa argumentacja o kurtuazji międzynarodowej przed sądem amerykańskim.

Stan sekcji 702 w październiku 2026 r. jest nietypowy. 5 czerwca 2026 r. Senat nie przegłosował jej przedłużenia (47 głosów za, 52 przeciw), a Izba Reprezentantów odrzuciła krótkie przedłużenie. W efekcie przepis wygasł 12 czerwca 2026 r. (https://rollcall.com/2026/06/05/fisa-reauthorization-stalls-in-early-morning-senate-vote/, https://www.eff.org/deeplinks/2026/06/victory-702-has-expired). Wygaśnięcie nie oznacza jednak końca nadzoru. Sąd FISC odnowił zezwolenia (certyfikaty) na prowadzenie programu 17 marca 2026 r., a według członków Kongresu działają one co najmniej do 17 marca 2027 r. (https://proton.me/blog/fisa-702-expiring-surveillance-reform).

Pogląd, że zezwolenia wydane przed wygaśnięciem ustawy zachowują moc, nie został rozstrzygnięty sądownie. Część operatorów telekomunikacyjnych zapowiadała, że po wygaśnięciu ustawy może odmawiać współpracy. Według stanu na 17 września 2026 r. Kongres nie uchwalił ponownie sekcji 702, a prace nad nią trwają (https://www.brennancenter.org/our-work/research-reports/section-702-foreign-intelligence-surveillance-act-fisa-2026-resource-page). CLOUD Act tych zmian nie dotyczą: pozostaje w pełni obowiązujący.

Jurysdykcja Francji. Thales jest spółką francuską, strategiczną dla obronności tego państwa i kontrolowaną przez państwo wspólnie z Dassault. Francuska ustawa o wywiadzie z 2015 r. (art. L811-3 Kodeksu bezpieczeństwa wewnętrznego) wymienia wprost, wśród celów, dla których służby mogą stosować techniki wywiadowcze, ochronę „głównych interesów gospodarczych, przemysłowych i naukowych Francji” (https://wiki.laquadrature.net/French_Intelligence_Laws.html).

Prawo francuskie uznaje więc wywiad gospodarczy za uprawnione zadanie państwa. Francuska ustawa o programowaniu wojskowym na lata 2024–2030 (ustawa nr 2023-703 z 1 sierpnia 2023 r.) rozszerzyła ponadto uprawnienia rządowej agencji cyberbezpieczeństwa ANSSI. Agencja może instalować urządzenia wykrywające zagrożenia i zbierać dane u operatorów telekomunikacyjnych, dostawców hostingu i operatorów centrów danych, a także nakazywać zmiany w rekordach DNS (https://cyber.gouv.fr/sites/default/files/document/FAQ_decret_LPM-2024-2030_consultations.pdf).

Uprawnienia te dotyczą operatorów działających we Francji. Imperva ma węzeł w Paryżu, a bramka KSeF działa w modelu Anycast (punkt 8). Połączenia z KSeF nawiązywane z Francji kończą się więc najpewniej w tym węźle, choć nie zostało to zmierzone. Ruch polskich podatników łączących się z Polski kończy się natomiast w Warszawie.

To, czy i jaką drogą francuskie służby mogłyby uzyskać dane od amerykańskiej spółki zależnej Thalesa, jest wnioskiem (typ D), który wymaga analizy prawnej. Należy też odnotować możliwość, której żadna umowa nie wyklucza: przepływ danych wewnątrz grupy kapitałowej mógłby nastąpić także bez nakazu sądowego, jeśli pozwalałyby na niego uprawnienia i konfiguracja. Nie oznacza to swobody prawnej takiego transferu ani jego niewykrywalności; nie ustalono, czy taka możliwość istnieje w konfiguracji KSeF. To również wniosek typu D, nie fakt.

Izrael. Zaplecze inżynierskie Impervy od początku znajduje się w Izraelu. Według izraelskiego rankingu firm Dun’s 100 izraelskie centrum rozwojowe Impervy zatrudnia ponad 500 osób w biurach w Tel Awiwie i Rechowot (https://www.duns100.co.il/en/Imperva_a_Thales_Company).

Według zestawienia CDNPlanet Imperva ma też w Tel Awiwie węzeł swojej sieci (punkt 8). Pomiar z 19 października 2026 r. pokazał jednak, że ruch do KSeF z polskiej sieci kończy się w węźle warszawskim (punkt 8). Nie ma też żadnej publicznej informacji, by dane z ruchu KSeF były analizowane w Izraelu, więc takie twierdzenie byłoby nieuprawnione.

Otwarte pozostaje inne pytanie: z jakich krajów pracownicy Impervy mają dostęp do konfiguracji serwisu Ministerstwa Finansów, do dzienników ruchu i do certyfikatów. To pytanie powinno paść pod adresem MF, bo odpowiedź na nie powinna wynikać z umowy.

Incydent z 2019 r. W sierpniu 2019 r. Imperva ujawniła, że część bazy danych klientów usługi Cloud WAF, dawniej Incapsula, została wyniesiona. Wyciekły adresy e-mail, skróty haseł, klucze API oraz certyfikaty SSL dostarczone przez klientów; dane obejmowały okres do 15 września 2017 r. O wycieku firmę zawiadomił podmiot zewnętrzny (https://www.helpnetsecurity.com/2019/08/28/imperva-incident/). Ryzyko powierzenia certyfikatów operatorowi zapory nie jest więc teoretyczne: zrealizowało się już raz, w tej samej firmie i tej samej usłudze, która dziś obsługuje KSeF.

Opis: Dla przedsiębiorcy płyną z tego trzy praktyczne wnioski.

Po pierwsze, ruch do KSeF przechodzi przez firmę, która może jednocześnie podlegać obowiązkom wobec władz USA i wpływom państwa francuskiego.

Po drugie, umowa zawarta przez polskie ministerstwo nie znosi obowiązków wynikających z prawa amerykańskiego; ustawowa procedura sprzeciwu z CLOUD Act nie obejmuje Polski, a nakaz może być objęty zakazem powiadomienia ministerstwa.

Po trzecie, właściciel Impervy jest jednym z największych europejskich dostawców uzbrojenia, a faktury w KSeF obejmują także polski przemysł obronny, jego dostawców i kontrahentów.

Słabe punkty i odpowiedź: Określenie „firma wywiadowcza” nie wynika z danych publicznych i krytyk łatwo je podważy. Precyzyjniejsze sformułowanie jest równie mocne: „spółka zależna francuskiego koncernu zbrojeniowego, kontrolowanego przez państwo francuskie, podlegająca prawu USA”.

Krytyk powie też, że polska administracja korzysta z usług Microsoftu, Google czy Amazona, które również podlegają CLOUD Act. To prawda, ale tutaj chodzi o punkt wejścia do centralnego rejestru wszystkich faktur gospodarki, a operator jest spółką zależną koncernu zbrojeniowego. Ponadto w punkcie 7 pokazuję, że inne państwa nie wybrały takiego rozwiązania.

Trzeba wreszcie uczciwie zaznaczyć, że zastosowanie CLOUD Act, sekcji 702 FISA i francuskiej ustawy o wywiadzie do operatora zapory WAF to wnioski prawne (typ D). Wymagają one opinii prawnika specjalizującego się w prawie danych. Krytyk może też wskazać, że sekcja 702 formalnie wygasła. Odpowiedź brzmi: wydane wcześniej zezwolenia działają do marca 2027 r., Kongres pracuje nad przywróceniem przepisu, a CLOUD Act obowiązuje niezależnie od losów sekcji 702.

4. Nierównomierna ochrona faktur szyfrowaniem aplikacyjnym

Teza: Faktura wysyłana do KSeF jest dodatkowo zaszyfrowana na poziomie aplikacji, więc bramka Impervy nie może jej odczytać, mimo że terminuje TLS. Tak samo chronione są paczki faktur pobierane z KSeF. Pojedyncza faktura pobierana po numerze KSeF wraca natomiast do podatnika chroniona wyłącznie protokołem TLS, który kończy się na bramce (punkt 2). Jej pełna treść jest więc na bramce jawna.

Dowód: Teza opiera się na oficjalnej dokumentacji API KSeF 2.0, którą Ministerstwo Finansów publikuje w serwisie GitHub (https://github.com/CIRFMF/ksef-api), oraz na oficjalnych bibliotekach klienckich MF w językach C# i Java, do których dokumentacja odsyła. To dowód typu B: każdy może go sprawdzić, czytając źródło. Analizę opublikowałem wcześniej w audycie poświęconym szyfrowaniu faktur XML (https://www.mpolska24.pl/post/21095/audyt-techniczny-ksef-szyfrowanie-e2e-faktury-xml).

Wysyłka faktury. Dokument „Sesja interaktywna” z 10 lipca 2025 r. opisuje to szczegółowo (https://github.com/CIRFMF/ksef-api/blob/main/sesja-interaktywna.md). Program podatnika losuje 256-bitowy klucz symetryczny i 128-bitowy wektor inicjujący, a następnie szyfruje fakturę algorytmem AES-256 w trybie CBC. Sam klucz symetryczny szyfruje kluczem publicznym Ministerstwa Finansów, algorytmem RSA-OAEP z funkcją skrótu SHA-256. Zaszyfrowany klucz trafia do KSeF przy otwarciu sesji, a zaszyfrowana faktura przy jej wysłaniu. Odczytać klucz może tylko posiadacz klucza prywatnego MF. Bramka Impervy widzi zatem tylko szyfrogram, którego nie potrafi odszyfrować. Klucze publiczne MF publikuje w postaci certyfikatów, z oznaczeniem przeznaczenia „SymmetricKeyEncryption” (https://github.com/CIRFMF/ksef-api/blob/main/bezpieczenstwo/klucze-publiczne-do-szyfrowania.md).

Pobieranie paczek. Eksport faktur (funkcja „POST /invoices/exports”) wymaga, by podatnik w zapytaniu przekazał pole „encryption”. Zawiera ono jego klucz symetryczny zaszyfrowany kluczem publicznym MF. KSeF szyfruje tym kluczem archiwum ZIP z fakturami, a program podatnika odszyfrowuje je po pobraniu algorytmem AES-256. Dokumentacja pobierania przyrostowego z 21 listopada 2025 r. opisuje to krok po kroku, łącznie z funkcjami odszyfrowania w bibliotekach MF (https://github.com/CIRFMF/ksef-api/blob/main/pobieranie-faktur/przyrostowe-pobieranie-faktur.md). Bramka znów widzi tylko szyfrogram.

Pobieranie pojedynczej faktury. Funkcja GET /invoices/ksef/{ksefNumber} zwraca fakturę o podanym numerze KSeF. Produkcyjna specyfikacja OpenAPI wprost określa odpowiedź jako application/xml i wymaga uprawnienia InvoiceRead (https://api.ksef.mf.gov.pl/docs/v2/openapi.json). Jest to mocniejsze potwierdzenie kontraktu niż sama sygnatura metody w bibliotece. Dokumentacja opisowa pokazuje wywołania GetInvoiceAsync i getInvoice bez przekazywania klucza szyfrującego ani osobnego odszyfrowania odpowiedzi (https://github.com/CIRFMF/ksef-api/blob/main/pobieranie-faktur/pobieranie-faktur.md). Z kontraktu wynika brak dodatkowej warstwy szyfrowania aplikacyjnego tej odpowiedzi. Przy terminacji TLS w Cloud WAF pełny XML jest więc dostępny komponentowi kończącemu TLS.

Metadane. Wyszukiwanie faktur (funkcja „POST /invoices/query/metadata”) zwraca listę metadanych w formacie JSON, również bez szyfrowania aplikacyjnego. Te same metadane trafiają do pliku „_metadata.json” wewnątrz zaszyfrowanej paczki eksportu. Ministerstwo chroni je więc szyfrowaniem w paczce, ale udostępnia jawnie w wyszukiwaniu.

Skrót faktury. Nawet przy szyfrowanej wysyłce przez bramkę przechodzą jawnie dwie informacje o fakturze. Według dokumentacji podatnik przesyła, obok szyfrogramu, skrót SHA-256 i rozmiar faktury w postaci jawnej, czyli sprzed zaszyfrowania. Skrót SHA-256 faktury to tak zwany wyróżnik faktury, który według rozporządzenia (§ 2 pkt 6 i § 9) jest składnikiem kodu QR umieszczanego na fakturze. Znaczenie tego faktu omawiam w punkcie 5.

Opis: Najważniejszy wniosek jest logiczny, a nie techniczny. Szyfrowanie aplikacyjne nałożone na TLS ma sens tylko wtedy, gdy projektant nie ufa czemuś, co znajduje się na drodze połączenia TLS, czyli właśnie miejscu, w którym TLS się kończy. Projektanci KSeF tę nieufność wyrazili, szyfrując wysyłkę faktur i paczki. Jednocześnie pozostawili bez takiej ochrony pobieranie pojedynczej faktury i wyszukiwanie metadanych. Można to porównać do sytuacji, w której listy do urzędu wysyła się w zamkniętym sejfie, zbiorcze odpowiedzi też wracają w sejfie, ale pojedynczy list wraca w zwykłej kopercie, którą otwiera recepcjonista. Pojedyncza faktura zawiera pełną treść: pozycje, ilości, ceny jednostkowe, warunki płatności i numer rachunku bankowego.

Obrazowo. Szyfrowanie aplikacyjne działa jak zaplombowana paczka, a metadane jak etykieta, którą kurier musi przeczytać, żeby paczkę doręczyć: kto nadaje, do kogo, numer przesyłki i wartość. Zapewnienie ministerstwa, że zapora „nie widzi treści”, opisuje więc tylko część obrotu, czyli wysyłkę faktur i paczki eksportu. Przy pobieraniu pojedynczej faktury paczka nie jest zaplombowana wcale, a etykieta jest czytelna przy każdym wyszukiwaniu faktur. W KSeF etykieta ma przy tym szczególną właściwość: sama otwiera paczkę. Zawiera bowiem dokładnie te dane, które pozwalają pobrać fakturę bez uwierzytelnienia (punkt 5).

Słabe punkty i odpowiedź: Termin „szyfrowanie E2E” (end-to-end) jest tu nieprecyzyjny. Szyfrowanie prowadzi od podatnika do Ministerstwa Finansów, które fakturę odszyfrowuje; nie jest to szyfrowanie między sprzedawcą a nabywcą. Ściślej jest mówić o „szyfrowaniu na poziomie aplikacji, nałożonym na TLS”.

Krytyk powie, że pobranie pojedynczej faktury wymaga tokenu dostępowego, więc nie każdy może to zrobić. To prawda, ale token także przechodzi przez bramkę w postaci jawnej (punkt 2). Zarzut nie zmienia faktu, że treść faktury jest na bramce czytelna.

Dowód dotyczy kontraktu produkcyjnego API, nie zapisu transmisji konkretnej faktury. Można go uzupełnić kontrolowanym pobraniem własnej faktury w środowisku testowym. Nie jest to jednak warunek stwierdzenia, że oficjalna specyfikacja przewiduje zwracanie pojedynczej faktury jako XML bez odrębnego szyfrowania aplikacyjnego.

Pozostałe drogi dostępu do treści faktury. Treść faktury można zobaczyć jeszcze na dwa sposoby: w Aplikacji Podatnika, czyli portalu internetowym KSeF pod adresem ap.ksef.mf.gov.pl (https://docs.b2brouter.net/fr/user-guide/tax-report/ksef/), oraz w serwisie weryfikacji faktur qr.ksef.mf.gov.pl, do którego prowadzi kod QR z faktury (https://github.com/CIRFMF/ksef-api/blob/main/kody-qr.md).

Obie drogi sprawdziłem 19 października 2026 r. metodą czarnej skrzynki, bez logowania i bez użycia konta w KSeF. Zapytanie do publicznego serwera DNS Google (dns.google) zwróciło dla qr.ksef.mf.gov.pl adres 45.60.187.129, a dla ap.ksef.mf.gov.pl adres 45.60.186.93. Rejestr ARIN przypisuje oba adresy do tego samego bloku co bramka API: 45.60.0.0–45.60.255.255, nazwa sieci THALES-IMPERVA-NA4-AGG-45-60, organizacja Incapsula Inc. Obie drogi przechodzą więc przez infrastrukturę Impervy. W odróżnieniu od ksef.mf.gov.pl i api.ksef.mf.gov.pl, te dwie nazwy wskazują adres Impervy bezpośrednio rekordem A, a nie przez alias w domenie impervadns.net.

W jakim trybie Imperva obsługuje portal i QR. Pomiary z 19 października 2026 r., powtórzone o godzinach 17:37 i 17:41 czasu polskiego, wykazały różnicę względem bramki API. Dla ap.ksef.mf.gov.pl zasób /_incapsula_resource?NWQ=1 zwrócił stronę Aplikacji Podatnika, ciasteczko f5_cspm i skrypt o tej samej nazwie. Dla qr.ksef.mf.gov.pl zwrócił 404 i nagłówek Server: Kestrel. Nie uzyskano charakterystycznej diagnostyki ani nagłówków Imperva Cloud WAF. Wyniki przemawiają za hipotezą ochrony sieciowej DDoS bez odszyfrowania, choć jej nie przesądzają. Wskazuje na nią także test nagłówka Host z 17:41. Na wspólnym adresie 45.60.74.103 zapora Impervy kieruje zapytania do różnych serwisów według nagłówka Host (punkt 2).

Zapytanie z nagłówkiem Host api.ksef.mf.gov.pl wysłane na adres portalu zwróciło natomiast stronę błędu 404, a nie odpowiedź API (405, Server: Kestrel). Również pośrednik kończący TLS może przekazywać odpowiedzi zaplecza bez własnych oznaczeń. Przynależność adresu IP do Impervy nie rozstrzyga miejsca terminacji TLS. Dla tych dwóch adresów pozostaje ono formalnie nieustalone, choć dowody przemawiają za przekazywaniem ruchu bez odszyfrowania.

Odmiennie jest dla login.mf.gov.pl: alias Impervy, jej ciasteczka i nagłówki oraz odpowiedź diagnostyczna war-prx12 tworzą mocne potwierdzenie obsługi przez Cloud WAF. Polityka CSP portalu dopuszcza połączenia z login.mf.gov.pl, ale sama nie dowodzi, jakie dane i tokeny są tam przesyłane podczas konkretnego logowania.

Postać faktury w przeglądarce. Podręcznik KSeF 2.0 opisuje pobieranie faktury w formacie XML lub PDF przez portal i serwis QR. To potwierdza funkcję udostępniania dokumentu, ale nie wskazuje operatora terminacji TLS. Sam fakt, że użytkownik nie wpisuje klucza kryptograficznego, nie wyklucza ponadto obsługi kryptografii przez oprogramowanie przeglądarki. Obserwacja żądań i odpowiedzi w narzędziach deweloperskich podczas pobierania własnej faktury może wskazać używane endpointy i postać danych na granicy aplikacji, lecz nie ustala samodzielnie, gdzie po drodze kończono TLS. W tym materiale nie przesądzamy więc, że treść faktury pobieranej tymi dwiema drogami jest dostępna Impervie, ani że pozostaje dla niej nieczytelna.

5. Pięć pól otwiera fakturę bez uwierzytelnienia

Teza: Przepisy pozwalają pobrać fakturę z KSeF bez logowania, po podaniu pięciu danych. Żadna z nich nie jest tajna: wszystkie widnieją na każdej kopii faktury i krążą w obrocie gospodarczym. Kto zna te pięć wartości, może odczytać pełną treść faktury. Ponieważ te same wartości występują w metadanych faktur, metadane stają się kluczem do faktury.

Dowód: Podstawą jest rozporządzenie Ministra Finansów i Gospodarki z 12 grudnia 2025 r. w sprawie korzystania z Krajowego Systemu e-Faktur, opublikowane w Dzienniku Ustaw 2025 r. pod pozycją 1815 (https://eli.gov.pl/eli/DU/2025/1815/ogl/pol/pdf). To dowód typu B. Paragraf 1 pkt 4 określa, że rozporządzenie ustala „zakres danych, których podanie umożliwia dostęp w Krajowym Systemie e-Faktur do faktur (…) bez konieczności uwierzytelniania”. Rozdział 3 nosi tytuł obejmujący „zakres danych, których podanie umożliwia dostęp do faktury w tym systemie”. Paragraf 8 wylicza pięć danych, po których podaniu dostęp do faktury jest możliwy. Są to: numer identyfikujący fakturę w KSeF, numer faktury nadany przez sprzedawcę, NIP lub inny identyfikator nabywcy, imię i nazwisko lub nazwa nabywcy oraz kwota należności ogółem.

Ministerstwo Finansów samo nazywa ten tryb dostępem anonimowym i szczegółowo go opisuje. Oficjalny „Podręcznik KSeF 2.0”, część II, z sierpnia 2026 r. (https://ksef.podatki.gov.pl/media/rronoxyt/podrecznik-ksef-20-cz-ii-wystawianie-i-otrzymywanie-faktur-w-ksef-06082026.pdf), stwierdza na s. 81, że dostęp do faktury jest możliwy „bez konieczności uwierzytelnienia się w systemie” na dwa sposoby: przez tzw. dostęp dwuetapowy z kodem QR oraz przez tzw. dostęp anonimowy. Słowo „anonimowy” nie jest więc publicystyczną przesadą, tylko terminem użytym przez ministerstwo.

Jak działa dostęp anonimowy. Według rozdziału 5.7 podręcznika (s. 91–94) usługa jest dostępna na stronie głównej Aplikacji Podatnika KSeF 2.0, w sekcji „Dostęp bez logowania”, pod przyciskiem „Anonimowe wyszukiwanie faktury” z opisem „Możliwość podglądu faktury bez konieczności logowania”. W pierwszym kroku wpisuje się numer KSeF. W drugim numer faktury nadany przez sprzedawcę, identyfikator podatkowy nabywcy, jego imię i nazwisko lub nazwę oraz kwotę należności ogółem, po czym wybiera się „Wyszukaj fakturę”. Po pomyślnym wyszukaniu system oferuje pobranie faktury w formacie PDF albo XML. Jeśli choć jedna dana jest błędna, pojawia się komunikat „Nie znaleziono faktury” i proces trzeba zacząć od nowa (s. 95). Aplikacja Podatnika działa pod adresem ap.ksef.mf.gov.pl, który należy do sieci Impervy (punkt 1). Pomiary z 19 października 2026 r. nie rozstrzygają jednak, czy Imperva odszyfrowuje ruch tego portalu (punkt 4). Nie można na ich podstawie zapewnić ani o dostępności, ani o niedostępności tych danych dla operatora. Ten sam komplet pięciu danych przechodzi natomiast jawnie przez bramkę API w każdej odpowiedzi z metadanymi faktur (opisuje to akapit „Metadane jako klucz”).

Jak działa dostęp przez kod QR. Według rozdziału 5.5 (s. 87–90) „każda osoba” po zeskanowaniu kodu QR może sprawdzić fakturę bez uwierzytelnienia. System wyświetla wtedy podstawowe dane: numer KSeF, NIP sprzedawcy, datę wystawienia, skrót dokumentu, datę nadania numeru KSeF, typ schemy i tryb wystawienia. Po wpisaniu trzech danych dostępowych z § 7 (numer faktury, identyfikator nabywcy, kwota należności ogółem) można pobrać całą fakturę w formacie XML lub PDF. Podręcznik opisuje tu jedno zabezpieczenie: po kilku błędnych próbach z rzędu następuje czasowa blokada pobrania danej faktury, nałożona „na poziomie skrótu faktury (SHA256)” (s. 90). Ministerstwo uznaje dostęp przez QR za „narzędzie udoskonalone” w porównaniu z dostępem anonimowym, bo nie wymaga ręcznego wpisywania numeru KSeF ani nazwy nabywcy (s. 95).

Skąd można znać te pięć danych. Numer faktury, NIP i nazwa nabywcy oraz kwota należności ogółem to obowiązkowe elementy każdej faktury, wydrukowane na niej. Numer KSeF jest nadawany przez system, ale też nie jest tajemnicą. Według § 9 ust. 1 pkt 2 tego samego rozporządzenia każda faktura używana poza KSeF, czyli wydruk czy plik PDF wysłany kontrahentowi, musi mieć numer KSeF zamieszczony bezpośrednio pod kodem QR. Numer KSeF zawiera NIP sprzedawcy i datę, a dalej część techniczną i sumę kontrolną (https://symfonia.pl/blog/prawo/ksef/numer-identyfikator-ksef-co-to-jest-jak-wyglada-i-kiedy-musisz-go-uzywac/). Numer ten trafia też do ewidencji JPK_VAT, do potwierdzeń UPO i do systemów księgowych. Wszystkie pięć danych zna więc każdy, kto widział kopię faktury: kontrahent, biuro rachunkowe, bank, firma windykacyjna, kurier z dokumentami, a także każdy, kto przechwyci e-mail z fakturą w PDF.

Pięć pól jako dane uwierzytelniające. Pięć danych z § 8 to nie PIN ani kod wygenerowany specjalnie do dostępu, lecz zwykłe dane operacyjne faktury. Państwo samo przewiduje ich obieg poza KSeF. Numer KSeF wykazuje się w ewidencji JPK_VAT, a zgodnie z zapowiedziami ministerstwa od 1 stycznia 2027 r. ma być podawany także przy płatnościach w mechanizmie podzielonej płatności (https://symfonia.pl/blog/prawo/ksef/numer-identyfikator-ksef-co-to-jest-jak-wyglada-i-kiedy-musisz-go-uzywac/). Numer faktury, NIP i nazwa kontrahenta oraz kwota brutto to podstawowe kolumny niemal każdego systemu księgowego, systemu ERP, rejestru zakupów, raportu kosztów czy eksportu do arkusza kalkulacyjnego.

Podręcznik MF opisuje ponadto „potwierdzenie transakcji”, które zawiera dane nabywcy, numer faktury, kwotę należności ogółem i kod QR. MF stwierdza tam wprost, że dane z tego potwierdzenia umożliwią dostęp do faktury w KSeF bez konieczności uwierzytelnienia (Podręcznik KSeF 2.0, cz. II, s. 27–28). Faktury są przy tym przechowywane w KSeF przez 10 lat (https://e-prawnik.pl/informacje/e-faktura-2.html), więc przez cały ten czas te same dane pozostają kluczem do nich.

W typowej firmie pełny plik XML faktury może leżeć w dobrze chronionym repozytorium, z kontrolą uprawnień i rejestrem dostępu. Zestawienie z kolumnami „kontrahent, NIP, numer faktury, kwota, numer KSeF” krąży jednak swobodnie, bo jest potrzebne do uzgodnień: księgowość eksportuje je do arkusza, raport trafia e-mailem do dyrektora, hurtownia danych przechowuje te kolumny latami, a numer faktury i kwota trafiają do zgłoszeń w systemie obsługi klienta.

Nie trzeba nawet jednego pliku ze wszystkimi pięcioma polami. Wystarczy połączyć dwa zbiory po numerze faktury, kontrahencie lub numerze KSeF, co jest elementarną operacją analizy danych. KSeF zmienia w ten sposób status zwykłych metadanych. Informacja, która wcześniej mówiła najwyżej, że firma X dostała fakturę nr 123 na 57 432 zł, po zebraniu pięciu pól staje się poświadczeniem pozwalającym pobrać oryginalny dokument z państwowego systemu. Dane, których nikt dotąd nie musiał chronić jak haseł, powinny być teraz tak chronione. To jest błąd konstrukcyjny mechanizmu, niezależny od tego, kto obsługuje bramkę.

Klucz, którego nie da się odwołać. Z tej konstrukcji wynika kilka konkretnych zagrożeń, niezależnych od Impervy.

Po pierwsze, poświadczenia nie można zmienić. Firma może po zwolnieniu pracownika zablokować mu konto i dostęp VPN, ale nie zmieni historycznego numeru faktury, NIP-u kontrahenta ani kwoty. Kto skopiował tabelę z pięcioma polami, zachowuje dostęp do tych faktur przez cały okres ich przechowywania w KSeF, czyli przez 10 lat liczonych od końca roku wystawienia faktury. W dobrej praktyce bezpieczeństwa poświadczenie, którego nie można unieważnić, uchodzi za błąd projektowy.

Po drugie, mechanizm omija wewnętrzne uprawnienia firm. Systemy ERP i narzędzia analityczne często pokazują analitykowi tylko kwoty i numery, bez pozycji faktury. Jeśli te same dane wystarczają do pobrania pełnej faktury ze strony ministerstwa, firmowe ograniczenia dostępu tracą znaczenie.

Po trzecie, ryzyko skupia się u pośredników. Biura rachunkowe, dostawcy oprogramowania księgowego i działy wsparcia technicznego przetwarzają takie zestawienia dla setek klientów; przejęcie jednego konta lub jednej bazy zgłoszeń otwiera dostęp do faktur wielu niezależnych firm.

Po czwarte, typowe zabezpieczenia przed wyciekiem danych (systemy DLP) zatrzymują wysyłkę plików faktur, ale przepuszczają niewielką tabelę tekstową, traktując ją jak niegroźny raport. Złośliwe oprogramowanie nie musi więc wykradać gigabajtów dokumentów; wystarczy mały plik z pięcioma kolumnami. Ten sam problem dotyczy dzienników systemów monitorujących oraz starych kopii zapasowych, w których takie zestawienia bywają słabiej chronione niż bieżące dokumenty.

Skutki pobrania pełnej faktury są znacznie poważniejsze niż skutki wycieku samych metadanych. Metadane mówią, że firma A zapłaciła firmie B określoną kwotę. Pełna faktura ujawnia konkretne towary, ilości, ceny jednostkowe, rabaty i warunki płatności. Konkurent może z niej odczytać rzeczywistą cenę, po jakiej rywal sprzedaje dużemu klientowi, i wykorzystać ją w przetargu. Seria zakupów specjalistycznych części może zdradzić awarię lub planowaną modernizację w zakładzie przemysłowym, zanim spółka poinformuje o niej rynek. Przestępcy mogą użyć autentycznych danych z faktury do oszustw polegających na podszyciu się pod dostawcę i prośbie o zmianę numeru rachunku (tzw. BEC); wiadomość, w której zgadza się numer faktury, towar i kwota co do grosza, usypia czujność. Faktury jednoosobowych działalności gospodarczych zawierają przy tym dane osobowe, więc masowe pobranie dokumentów oznacza także naruszenie ochrony danych osobowych.

Porównanie z § 7. Kod QR zawiera datę wystawienia, NIP sprzedawcy i wyróżnik faktury obliczony z XML przy użyciu SHA-256. Nie jest to niezależne losowe hasło: kto zna dokładne bajty dokumentu, może obliczyć jego skrót, a posiadacz QR może go skopiować. Długość 256 bitów nie oznacza automatycznie takiej samej entropii dokumentu.

Także numer KSeF z § 8 zawiera dwunastoznakowy segment techniczny w zapisie szesnastkowym; sam format dopuszcza 2^48 wartości, ale bez analizy generatora nie określa jego rzeczywistej nieprzewidywalności. Krytyka dostępu po pięciu polach nie wymaga dowodzenia, że można je łatwo odgadnąć. Dotyczy przede wszystkim pozyskania tych wartości z obiegu dokumentów lub raportów i wykorzystania ich do pobrania pełnej faktury.

Trzeba też pamiętać o ustaleniu z punktu 4. Przy wysyłce każdej faktury do KSeF jej skrót SHA-256, czyli właśnie wyróżnik, przechodzi przez bramkę Impervy w postaci jawnej. Bramka zna więc także jedyny tajny składnik drogi z § 7.

Metadane jako klucz. W punkcie 2 wykazałem, że bramka Impervy widzi w postaci jawnej odpowiedzi z metadanymi faktur, które zwraca wyszukiwanie „POST /invoices/query/metadata”. Co dokładnie zawierają te metadane, wynika z oficjalnej biblioteki Ministerstwa Finansów w języku C#. Klasa InvoiceSummary, opisująca pojedynczy rekord metadanych, ma między innymi pola: KsefNumber („Numer KSeF faktury”), InvoiceNumber („Numer faktury nadany przez wystawcę”), Buyer („Dane identyfikujące nabywcę”), GrossAmount („Łączna kwota brutto”), Seller („Dane identyfikujące sprzedawcę”), IssueDate („Data wystawienia faktury”) oraz InvoiceHash („Skrót SHA256 faktury”) (https://github.com/CIRFMF/ksef-client-csharp/blob/main/KSeF.Client.Core/Models/Invoices/InvoiceSummary.cs).

Niezależna biblioteka w języku Go pokazuje, że dane nabywcy w odpowiedzi to identyfikator (NIP lub inny) oraz nazwa (https://pkg.go.dev/github.com/onit-soft/goksef/goksef). Zestawienie z § 8 jest jednoznaczne. Numer KSeF to pole KsefNumber. Numer faktury to InvoiceNumber. Identyfikator nabywcy i jego nazwa to pole Buyer. Kwota należności ogółem odpowiada w typowej fakturze łącznej kwocie brutto, czyli GrossAmount. Dla typowej faktury rekord zawiera więc kategorie danych wymagane przez § 8. Przeniesienie tego wniosku na wszystkie rodzaje dokumentów wymaga sprawdzenia zgodności GrossAmount z wymaganą kwotą należności ogółem, w szczególności dla zaliczek, rozliczeń i korekt. Co więcej, ten sam rekord zawiera też wszystko, czego wymaga droga przez kod QR z § 7: datę wystawienia, NIP sprzedawcy i skrót SHA-256 faktury, czyli jej wyróżnik. Jedyny element o wysokiej entropii, który chroni drogę z § 7, metadane podają wprost.

Rekord metadanych zawierający wszystkie zgodne wartości wymagane przez formularze może zatem wystarczyć do pobrania pełnej faktury obiema drogami przewidzianymi w rozporządzeniu, także faktury, której nikt nigdy nie pobrał pojedynczo. Do pobrania faktury tymi drogami nie trzeba żadnego uprawnienia. Kto zebrał metadane z ruchu API, może więc skorzystać z Aplikacji Podatnika albo z serwisu qr.ksef.mf.gov.pl jak każdy inny użytkownik. Nieustalone miejsce terminacji TLS samych tych dwóch serwisów (punkt 4) nie usuwa tego ryzyka: posiadacz kompletu danych z API może wystąpić jako klient portalu lub serwisu QR.

Opis: oba mechanizmy opierają dostęp na znajomości informacji związanych z dokumentem. QR nie jest kluczem niemożliwym do skopiowania, a numer KSeF nie jest zwykłym kolejnym numerem wystawcy. Główne ryzyko polega na tym, że komplet danych biznesowych rozpowszechnianych poza repozytorium faktur może pełnić rolę poświadczenia dostępu do pełnego dokumentu. Nie trzeba łamać kryptografii, jeżeli wymagane wartości zostały już pozyskane z innego źródła.

Co może zrobić przedsiębiorca. Dopóki obowiązują obecne przepisy, każde zestawienie zawierające numer KSeF, numer faktury, dane nabywcy i kwotę należy chronić tak, jak chroni się dostęp do rachunku bankowego. W praktyce oznacza to cztery kroki.

Pierwszy: ustalić, gdzie w firmie i u jej usługodawców (biuro rachunkowe, dostawca oprogramowania, dział wsparcia) takie zestawienia powstają i są przechowywane.

Drugi: usunąć numer KSeF z raportów, arkuszy i hurtowni danych, w których nie jest potrzebny, a tam, gdzie jest potrzebny, ograniczyć dostęp do niego.

Trzeci: skonfigurować systemy zapobiegania wyciekom danych tak, by traktowały połączenie tych kolumn jak dane wrażliwe.

Czwarty: uświadomić pracownikom, że zwykła tabelka z tymi danymi może otworzyć pełną treść faktur firmy.

Słabe punkty i odpowiedź: Krytyk powie, że kto ma kopię faktury, ten i tak zna jej treść, więc dostęp z § 8 niczego nie ujawnia. Odpowiedź ma dwie części. Po pierwsze, pięć danych występuje także poza samą fakturą: w metadanych, w ewidencjach i w systemach pośredników, a stamtąd § 8 prowadzi do pełnego pliku XML. Po drugie, dostęp z § 8 daje oryginalny, ustrukturyzowany plik faktury, który łatwo przetwarzać maszynowo i masowo.

Krytyk może też powołać się na zabezpieczenia przed odgadywaniem danych. Podręcznik MF opisuje jedno: czasową blokadę po kilku błędnych próbach, ale wyłącznie przy dostępie przez kod QR, i to w odniesieniu do konkretnej faktury (s. 90). Przy dostępie anonimowym z § 8 podręcznik żadnej blokady ani limitu nie wymienia; mówi jedynie, że po błędnych danych proces trzeba zacząć od nowa (s. 95). Nawet gdyby limit istniał, utrudniałby jedynie zgadywanie. Nie zmienia to faktu, że kto zna pięć jawnych danych, na przykład z metadanych, nie musi niczego zgadywać i trafia za pierwszym razem.

6. Historia legislacyjna KSeF

Teza: KSeF powstawał ponad pięć lat, za dwóch rządów Morawieckiego i Tuska. Po drodze Senat odrzucił ustawę, a po audycie, który wykazał błędy systemu, termin wdrożenia przesunięto o ponad półtora roku i rozłożono na etapy. Obecna wersja, KSeF 2.0, to system o nowej architekturze, uruchomiony 1 lutego 2026 r. Ustawa przewiduje jedynie samą zasadę dostępu do faktury bez uwierzytelnienia. Najważniejsze dla bezpieczeństwa szczegóły, w tym lista pięciu danych z § 8, są zapisane w rozporządzeniu ministra i w dokumentacji technicznej. Nigdzie w aktach prawnych nie pada nazwa operatora bramki.

Dowód: Wszystkie daty pochodzą z aktów prawnych, druków sejmowych i komunikatów Ministerstwa Finansów oraz z prasy podatkowej, która je relacjonowała (dowód typu C). Źródło podaję przy każdym etapie.

Etap pierwszy: KSeF dobrowolny (2021–2022). 2 sierpnia 2021 r. Polska złożyła w Komisji Europejskiej wniosek o zgodę na wprowadzenie obowiązkowych e-faktur (https://e-prawnik.pl/informacje/e-faktura-2.html). 29 października 2021 r. Sejm uchwalił ustawę wprowadzającą Krajowy System e-Faktur, prezydent podpisał ją 15 listopada, a 18 listopada 2021 r. została opublikowana w Dzienniku Ustaw (https://ksiegowosc.infor.pl/tematy/e-faktura,3/). 27 grudnia 2021 r. Minister Finansów wydał pierwsze rozporządzenie w sprawie korzystania z KSeF (Dz.U. 2021 poz. 2481). Od 1 stycznia 2022 r. podatnicy mogli wystawiać faktury w KSeF dobrowolnie (https://ksef.podatki.gov.pl/informacje-ogolne-ksef-20/podstawy-prawne-oraz-kluczowe-terminy/).

Etap drugi: zgoda Unii Europejskiej (2022). Obowiązkowe e-faktury odbiegały od dyrektywy VAT, dlatego Polska potrzebowała odstępstwa, tak zwanej derogacji. Rada Unii Europejskiej udzieliła jej decyzją wykonawczą 2022/1003 z 17 czerwca 2022 r. Decyzja pozwalała stosować obowiązkowe e-faktury od 1 stycznia 2024 r. do 31 grudnia 2026 r., a jej przedłużenie wymagało wniosku i sprawozdania z działania systemu (https://www.ey.com/pl_pl/insights/tax/1-stycznia-2024-firmy-musza-byc-gotowe-na-efaktury).

Etap trzeci: ustawa o obowiązkowym KSeF i sprzeciw Senatu (2023). 16 czerwca 2023 r. Sejm uchwalił ustawę wprowadzającą obowiązek wystawiania faktur w KSeF od 1 lipca 2024 r. (Dz.U. 2023 poz. 1598). W nocy z 13 na 14 lipca 2023 r. Senat przyjął uchwałę o odrzuceniu ustawy w całości, stosunkiem głosów 50 do 44. Senacka komisja budżetu wskazywała głównie na niezgodność z art. 87 Konstytucji, bo wzór e-faktury miał być udostępniony jedynie na stronie internetowej, a nie w źródle prawa (https://akademialtca.pl/blog/ksef-w-senacie-dyskusja-w-komisji-i-uchwala-o-odrzuceniu-ustawy). 28 lipca 2023 r. Sejm odrzucił uchwałę Senatu i ustawa trafiła do prezydenta (https://www.pit.pl/aktualnosci/ksef-wejdzie-w-zycie-zgodnie-z-planem-ustawa-u-prezydenta-1008614).

Etap czwarty: zmiana rządu, audyt i odroczenie (2024). 19 stycznia 2024 r. nowy minister finansów Andrzej Domański ogłosił, że obowiązkowy KSeF nie wejdzie w życie w 2024 r., i zapowiedział zewnętrzny audyt. Uzasadniał to słowami: „Zdiagnozowaliśmy błędy, które uniemożliwiają wprowadzenie obligatoryjnego KSeF w zakładanym terminie” (https://ksiegowosc.infor.pl/ksef/6441489,czy-to-koniec-ksef-ministerstwo-finansow-zleci-przeprowadzenie-zewnet.html). Uzasadnienie rządowego projektu ustawy odraczającej (druk sejmowy nr 341) wskazywało na problemy z wydajnością systemu i powoływało się na wyniki audytu (https://api.sejm.gov.pl/sejm/term10/prints/341/341-uzasadnienie.docx). Ustawa z 9 maja 2024 r. (Dz.U. 2024 poz. 852) przesunęła obowiązek na 1 lutego 2026 r. Ministerstwo zapowiedziało, że do tego dnia udostępni system oparty na nowej architekturze (https://www.podatki.biz/artykuly/co-dalej-z-obowiazkowym-ksef-mf-odpowiada_34_56926.htm). Podsumowanie audytu MF opublikowało 24 kwietnia 2024 r. (https://ksef.podatki.gov.pl/wyjasnienia/podsumowanie-audytu-ksef-240424/).

Etap piąty: pakiet ViDA, nowa ustawa i rozporządzenie (2025). 11 marca 2025 r. Rada UE przyjęła pakiet VAT w erze cyfrowej (ViDA, dyrektywa 2025/516), który wszedł w życie 14 kwietnia 2025 r. Od tej chwili państwa członkowskie mogą wprowadzać obowiązkowe krajowe e-fakturowanie bez odrębnej zgody (https://www.deloitte.com/pl/pl/services/tax/perspectives/alerty-podatkowe/VAT-w-erze-cyfrowej-nowe-unijne-regulacje-oficjalnie-weszly-w-zycie.html). Kończący się 31 grudnia 2026 r. termin derogacji przestał więc być prawną przeszkodą. 5 sierpnia 2025 r. Sejm uchwalił ustawę ustalającą etapy wdrożenia (Dz.U. 2025 poz. 1203), którą prezydent podpisał 27 sierpnia 2025 r. (https://www.ey.com/en_gl/technical/tax-alerts/poland-signs-into-law-mandatory-national-e-invoicing-system). 12 grudnia 2025 r. Minister Finansów i Gospodarki wydał nowe rozporządzenie w sprawie korzystania z KSeF (Dz.U. 2025 poz. 1815), zawierające między innymi § 8 o dostępie anonimowym (https://eli.gov.pl/eli/DU/2025/1815/ogl/pol/pdf).

Etap szósty: obowiązkowy KSeF (2026–2027). 1 lutego 2026 r. obowiązek objął podatników ze sprzedażą powyżej 200 mln zł, a od tego samego dnia wszyscy podatnicy muszą odbierać faktury w KSeF. 1 kwietnia 2026 r. obowiązek wystawiania objął pozostałych podatników, a od 1 stycznia 2027 r. obejmie najmniejszych przedsiębiorców (Podręcznik KSeF 2.0, cz. II, s. 96; https://ksef.podatki.gov.pl/media/rronoxyt/podrecznik-ksef-20-cz-ii-wystawianie-i-otrzymywanie-faktur-w-ksef-06082026.pdf). 18 lutego 2026 r. Ministerstwo Finansów odpowiedziało Rzecznikowi Praw Obywatelskich na wątpliwości dotyczące KSeF. Powołało się na derogację UE i wskazało, że Polska nie jest pierwszym państwem z obowiązkowymi e-fakturami, wymieniając m.in. Włochy (od 2019 r.) i Węgry (od 2021 r.) (https://bip.brpo.gov.pl/sites/default/files/2026-02/Odpowiedz_MF_KSeF_18_02_2206.pdf).

Historia pięciu pól. Dostęp do faktury bez logowania, opisany w punkcie 5, nie jest nowością KSeF 2.0. Przewidywał go już projekt ustawy z 1 lutego 2021 r. w projektowanym art. 106nb ust. 4. Według dokumentacji konsultacji publicznych o zakres danych, które miały otwierać fakturę, pytały wtedy Konfederacja Lewiatan, Związek Cyfrowa Polska i Pracodawcy RP, a o sam dostęp bez uwierzytelnienia pytał Ernst & Young. Facturo.pl zakwestionowało pomysł w całości, pisząc, że dostęp do danych finansowych i osobowych w żadnym razie nie powinien być anonimowy, i zaproponowało dostęp po zalogowaniu. Ministerstwo odpowiedziało, że usunie przepis z projektu ustawy, a dane otwierające fakturę określi w rozporządzeniu. Problem bezpieczeństwa tego mechanizmu był więc znany, zanim KSeF w ogóle ruszył.

Ustawa z 29 października 2021 r. (Dz.U. 2021 poz. 2076, https://eli.gov.pl/eli/DU/2021/2076/ogl/pol/pdf) zachowała jednak samą konstrukcję. Art. 106g ust. 3c stanowi, że „dostęp do faktury ustrukturyzowanej jest możliwy przez podanie danych tej faktury”, a art. 106r pkt 4 przekazał ministrowi finansów określenie w rozporządzeniu, jakie to mają być dane. Sejm przegłosował więc mechanizm, ale nie jego treść. 27 grudnia 2021 r. Minister Finansów wydał rozporządzenie (Dz.U. 2021 poz. 2481, https://eli.gov.pl/eli/DU/2021/2481/ogl/pol/pdf), podpisane z upoważnienia ministra przez Sebastiana Skuzę. Jego § 6 wymienia dokładnie te same pięć danych co dzisiejszy § 8: numer KSeF, numer faktury, identyfikator nabywcy, jego nazwę oraz kwotę należności ogółem. Rozporządzenie weszło w życie 1 stycznia 2022 r. Pięć pól działa więc w KSeF od pierwszego dnia jego istnienia.

Ustawa z 16 czerwca 2023 r. o obowiązkowym KSeF (Dz.U. 2023 poz. 1598, https://eli.gov.pl/eli/DU/2023/1598/ogl/pol/pdf) nie tylko utrzymała ten mechanizm, ale opisała go wprost. Nowe brzmienie art. 106r pkt 4 mówi o „zakresie danych, których podanie umożliwia dostęp w Krajowym Systemie e-Faktur do faktury ustrukturyzowanej (…) bez konieczności uwierzytelniania”. Ta sama ustawa wprowadziła odrębny dostęp przez kod QR (art. 106r pkt 5). Sejm uchwalił ją 240 głosami za, przy 203 przeciw i 9 wstrzymujących się (https://www.money.pl/gospodarka/wielkie-zmiany-przy-wystawianiu-faktur-nowy-obowiazek-od-2024-r-6909688371092032a.html). Po zmianie rządu w 2024 r. system zatrzymano, poddano audytowi i w dużej części przebudowano, ale ten mechanizm pozostał. Ustawa z 5 sierpnia 2025 r. zachowała delegację z art. 106r pkt 4, a rozporządzenie z 12 grudnia 2025 r., podpisane z upoważnienia ministra przez podsekretarz stanu Hannę Majszczyk, powtórzyło w § 8 te same pięć danych.

Wniosek: pięciopolowy klucz do faktury przeszedł przez trzy ustawy, dwa rozporządzenia, dwa rządy i jedną gruntowną przebudowę systemu, mimo że ryzyko zgłoszono w konsultacjach już w 2021 r. Nie jest to więc przeoczenie jednej ekipy, lecz decyzja podtrzymywana przez kolejne. Przy każdej z tych okazji można było zastąpić dane biznesowe elementem trudnym do odgadnięcia, na przykład losowym kodem dostępu, kodem jednorazowym, odwoływalnym tokenem lub ograniczeniem czasowym. Pokazuje to zresztą sam KSeF, w którym dostęp przez kod QR opiera się na 256-bitowym skrócie faktury (punkt 5).

Brak wyłączenia dla obronności. Ustawa o VAT (art. 106ga ust. 2) zwalnia z obowiązku KSeF faktury ze względu na status stron albo procedurę rozliczenia. Zwolnienie obejmuje podatników zagranicznych, którzy nie mają w Polsce siedziby ani stałego miejsca prowadzenia działalności uczestniczącego w sprzedaży. Obejmuje też faktury dla konsumentów, faktury w szczególnych procedurach OSS i IOSS oraz faktury małych przedsiębiorców z innych państw Unii korzystających z procedury SME. Na podstawie upoważnienia z tej ustawy minister finansów wydał 7 grudnia 2025 r. rozporządzenie w sprawie przypadków, w których nie ma obowiązku wystawiania faktur ustrukturyzowanych (Dz.U. 2025 poz. 1740, https://eli.gov.pl/eli/DU/2025/1740/ogl/pol/pdf).

Jego § 2 wymienia sześć przypadków: przejazdy płatnymi autostradami, bilety na przewóz osób, opłaty trasowe za kontrolę ruchu lotniczego rozliczane przez EUROCONTROL oraz zwolnione z VAT usługi finansowe i ubezpieczeniowe na fakturach o węższym zakresie danych. Pozostałe dwa to przypadki samofakturowania, gdy właściwa strona nie ma polskiego NIP. Żaden przepis ustawy ani rozporządzenia nie wyłącza faktur ze względu na obronność, bezpieczeństwo państwa czy informacje niejawne. Minister miał więc narzędzie, którym mógł wyłączyć taką kategorię, ale z niego nie skorzystał (dowód typu B). Faktury zagranicznych dostawców uzbrojenia bez polskiej siedziby lub stałego miejsca prowadzenia działalności nie trafiają do KSeF, ale wynika to z tych samych zasad, które obejmują każdego zagranicznego sprzedawcę, a nie ze szczególnego wyjątku dla wojska.

Potwierdzenie resortu obrony. Ministerstwo Obrony Narodowej i Agencja Uzbrojenia potwierdziły portalowi WNP.pl: „Wszystkie faktury od dostawców krajowych są przekazywane Agencji Uzbrojenia za pośrednictwem KSeF” (tekst Katarzyny Bartman z 25 września 2026 r., https://www.wnp.pl/bezpieczenstwo/ksef-zdradza-wrazliwe-dane-zbrojeniowki-wojska-i-sluzb-tysiace-faktur-tworza-efekt-mozaiki,1102792.html). Treść i szczegółowość tych faktur mają być zgodne z prawem podatkowym i z ustawą o ochronie informacji niejawnych. Faktura dla wojska nie staje się przy tym automatycznie niejawna, bo klauzulę nadaje się według treści informacji i skutków jej ujawnienia.

W praktyce informacje objęte klauzulą muszą więc pozostać w chronionym obiegu, a faktura może zawierać tylko taki opis transakcji, jakiego wymaga prawo podatkowe. Publicznych wytycznych ministerstwa finansów dla takich faktur nie znalazłem. Nawet przy najskromniejszym opisie do KSeF trafiają dane stron, daty, kwoty i jawna część opisu. W metadanych, które przechodzą jawnie przez bramkę API (punkt 4), są numer faktury, sprzedawca, nabywca, data i kwota brutto.

Platforma PEF to osobny system. Platforma Elektronicznego Fakturowania służy do przesyłania faktur w zamówieniach publicznych na podstawie ustawy z 9 listopada 2018 r. o elektronicznym fakturowaniu w zamówieniach publicznych (tekst jednolity Dz.U. 2020 poz. 1666, https://eli.gov.pl/eli/DU/2020/1666/ogl/pol/pdf). Jej art. 3 ust. 2 wyłącza z jej stosowania zamówienia, które Prawo zamówień publicznych wyłącza w art. 12 ust. 1 i art. 13 ust. 1. Są to między innymi zamówienia objęte klauzulą tajności lub wymagane istotnym interesem bezpieczeństwa państwa.

Należą do nich też zamówienia związane z produkcją broni, amunicji i materiałów wojennych lub handlem nimi (art. 346 Traktatu o funkcjonowaniu Unii Europejskiej) oraz zamówienia do celów wywiadu i kontrwywiadu (https://www.garrigues.com/pl/pl-PL/news/kiedy-polska-moze-pominac-unijne-procedury-zamowieniowe). To wyłączenie dotyczy sposobu udzielania zamówienia i platformy PEF, a nie podatkowego obowiązku wystawienia faktury w KSeF. Wojsko może więc kupić uzbrojenie poza zwykłym przetargiem, ale faktura za nie i tak trafia do KSeF. Porównanie obu ustaw pokazuje, że polski ustawodawca znał kategorię zamówień obronnych wymagających ochrony przy elektronicznym fakturowaniu. W 2018 r. wyłączył ją z PEF, a w ustawach o KSeF z lat 2021–2025 i w rozporządzeniu z 2025 r. takiego wyłączenia nie przewidział.

Znaczenie dla bezpieczeństwa. Eksperci cytowani przez WNP.pl wskazali na tak zwany efekt mozaiki. Był wśród nich doradca podatkowy Piotr Juszczyk z inFaktu, Tomasz Janas z PKF Polska i płk dr Piotr Potejko z Uniwersytetu Warszawskiego, były dyrektor w ABW. Juszczyk ujął to tak: „Pojedyncza faktura mówi niewiele, ale szereg faktur z wielu miesięcy pozwala odtworzyć tempo dostaw”. Z takiej serii da się też odczytać ceny, dostawców i wąskie gardła produkcji. Juszczyk zwrócił uwagę również na to, że ministerstwo może wyłączać faktury rozporządzeniem, a dla dostaw obronnych i niejawnych tego nie zrobiło (tekst z 5 października 2026 r., https://www.wnp.pl/bezpieczenstwo/wojskowe-dane-znalazly-sie-w-polsce-na-widoku-niemcy-i-francja-robia-to-inaczej,1104503.html). W połączeniu z punktami 2 i 4 oznacza to, że metadane faktur polskiego przemysłu obronnego dla MON i Agencji Uzbrojenia przechodzą jawnie przez bramkę spółki zależnej koncernu Thales, który sam jest producentem uzbrojenia i elektroniki wojskowej (punkt 3). Przejście danych przez bramkę wynika z pomiaru i dokumentacji (typy A i B). Ocena, czy ktoś z tego korzysta, jest wnioskowaniem (typ D) i takich dowodów materiał nie przedstawia.

Gdzie w tej historii jest Imperva. W żadnym z wymienionych aktów prawnych, druków sejmowych ani komunikatów nie pada nazwa operatora bramki. Pierwszy znany mi pomiar, który ją ujawnił, to mój audyt z 6 lutego 2026 r. (punkt 1). Od tego czasu parlamentarzyści kilkakrotnie pytali Ministerstwo Finansów o Impervę. Za każdym razem ministerstwo odmówiło konkretów.

Interpelacja posła Janusza Kowalskiego. 23 stycznia 2026 r. do Sejmu wpłynęła interpelacja nr 14817 „w sprawie architektury komunikacyjnej KSeF oraz jej wpływu na suwerenność danych i bezpieczeństwo centralnego systemu fiskalnego państwa” (https://api.sejm.gov.pl/sejm/term10/interpellations/14817). Odpowiedź z 17 lutego 2026 r., podpisaną przez podsekretarza stanu Zbigniewa Stawickiego, opublikowano w serwisie Sejmu (https://api.sejm.gov.pl/sejm/term10/interpellations/attachment/ATTDREJXG/i14817-o1.pdf). Nie wymienia ona żadnego dostawcy ani nie potwierdza, ani nie zaprzecza udziału Impervy. Na pytanie o zewnętrzną warstwę WAF i CDN ministerstwo odpowiedziało, że są to „informacje wrażliwe z punktu widzenia bezpieczeństwa teleinformatycznego systemu”. Na pytanie o zależność od dostawcy napisało jedynie, że „analizowane były różne możliwości i scenariusze”. Nie odpowiedziało, gdzie ruch jest odszyfrowywany. Podało tylko, że dane są przechowywane w „bezpiecznej infrastrukturze resortu finansów”.

Stanowisko MF dla Demagoga. W analizie z 25 lutego 2026 r. serwis Demagog przytoczył odpowiedź ministerstwa z 20 lutego 2026 r. (https://demagog.org.pl/analizy_i_raporty/system-ksef-czy-nasze-dane-sa-bezpieczne/). Według MF wszystkie elementy systemu znajdują się w Polsce i są kontrolowane przez resort, dane są szyfrowane, a klucze ma wyłącznie system KSeF. Zapora WAF miała widzieć jedynie zaszyfrowane dane i nie mieć dostępu do treści faktur. Na pytanie o fizyczną lokalizację zapory ministerstwo odpowiedziało, że szczegółów architektury nie ujawnia ze względów bezpieczeństwa. Sam Demagog zaznaczył, że deklaracji ministerstwa nie zweryfikował.

Interwencja posłów Włodzimierza Skalika i Sławomira Zawiślaka. 20 lutego 2026 r., w dniu pikiety przeciwko KSeF, posłowie Konfederacji Korony Polskiej złożyli w Ministerstwie Finansów interwencję poselską (https://gorliceiokolice.eu/2026/02/ksef-interwencja-poslow-konfederacji-korony-polskiej-wlodzimierza-skalika-i-slawomira-zawislaka/). Pytania przygotowałem i opublikowałem jako „Scenariusz interwencji poselskiej – architektura i bezpieczeństwo KSeF” (https://naszeblogi.pl/75760-scenariusz-interwencji-poselskiej-architektura-i-bezpieczenstwo-ksef). Odpowiedź Ministra Finansów i Gospodarki nosi datę 3 marca 2026 r. i znak sprawy DAK1.054.32.2026. Podpisał ją z upoważnienia ministra Zbigniew Stawicki, podsekretarz stanu i zastępca szefa Krajowej Administracji Skarbowej. Pismo opublikowałem w całości (https://x.com/gps65/status/2032110579876291032). Ma trzy zdania merytoryczne. Ministerstwo pisze w nim, że KSeF „stanowi kluczowy element infrastruktury informatycznej administracji publicznej” i „podlega najwyższym standardom bezpieczeństwa”. Dalej stwierdza: „W związku z powyższym detale operacyjne, informacje dotyczące architektury systemu oraz szczegóły współpracy z dostawcami pozostają objęte ograniczeniami informacyjnymi ze względów bezpieczeństwa”. Na żadne z zadanych pytań pismo nie odpowiada.

Oświadczenie senatora Grzegorza Biereckiego. 16 marca 2026 r. senator skierował do ministra finansów 13 pytań, między innymi o to, jakie podmioty przetwarzają dane z KSeF, gdzie mają siedzibę, kto jest ich właścicielem, ile kosztują usługi i jaką rolę odgrywa Imperva Thales. Poprosił o odpowiedź w trybie niejawnym, zgodnie z ustawą o ochronie informacji niejawnych. Odpowiedź z końca maja 2026 r., podpisana przez podsekretarza stanu Zbigniewa Stawickiego, przyszła w trybie jawnym i nie zawierała tych danych. Ministerstwo napisało, że „detale operacyjne pozostają objęte ograniczeniami informacyjnymi ze względów bezpieczeństwa” (https://wpolsce24.tv/polska/tajna-gra-rzadu-wokol-ksef-senator-bierecki-reaguje,80270).

Interpelacja posła Bartłomieja Pejo. 24 czerwca 2026 r. wpłynęła interpelacja nr 18034 „w sprawie dostępu zagranicznych podmiotów i służb do faktur polskich przedsiębiorców” (https://api.sejm.gov.pl/sejm/term10/interpellations/18034). Poseł zapytał wprost, czy zagraniczna bramka WAF widzi metadane i czy może odszyfrować faktury w drodze powrotnej. Zapytał też, jak kontroluje się, czy Imperva nie zapisuje i nie przekazuje danych, oraz czy polskie służby opiniowały wybór operatora. Odpowiedź z 10 sierpnia 2026 r. podpisał sekretarz stanu Marcin Łoboda, szef Krajowej Administracji Skarbowej (https://api.sejm.gov.pl/sejm/term10/interpellations/attachment/ATTDWUHSE/i18034-o1.pdf). Nie odnosi się ona ani do bramki WAF, ani do Impervy, ani do metadanych. Stwierdza, że szczegóły współpracy z dostawcami nie są ujawniane, bo „komunikowanie informacji technicznych mogłoby osłabić poziom ochrony systemów IT administracji publicznej”.

Co wynika z tych odpowiedzi.

Po pierwsze, od lutego do sierpnia 2026 r., w pięciu odpowiedziach (dla posłów Kowalskiego i Pejo, posłów Skalika i Zawiślaka, senatora Biereckiego oraz serwisu Demagog), ministerstwo ani razu nie potwierdziło i ani razu nie zaprzeczyło, że bramkę obsługuje Imperva.

Po drugie, ściśle rzecz biorąc, ministerstwo nie powołuje się na żadną konkretną tajemnicę ustawową. Nie wskazuje ani klauzuli z ustawy o ochronie informacji niejawnych, ani przepisu, który by tego zakazywał. Pisze o „względach bezpieczeństwa” i „ograniczeniach informacyjnych”, a prośbę senatora o odpowiedź w trybie niejawnym pominęło. Formuła o „ograniczeniach informacyjnych ze względów bezpieczeństwa” powtarza się niemal dosłownie w piśmie do posłów Skalika i Zawiślaka z 3 marca 2026 r. i w odpowiedzi dla senatora Biereckiego z końca maja 2026 r., co wskazuje na stałą, przyjętą w resorcie formułę odmowy.

Po trzecie, jedyne merytoryczne zapewnienie, że zapora „widzi jedynie zaszyfrowane dane”, przeczy pomiarowi z punktu 2 i dokumentacji samego ministerstwa opisanej w punkcie 4. Zapora kieruje zapytania według nagłówka Host, który podróżuje wewnątrz szyfrowanego tunelu. Pojedyncza faktura i metadane nie mają szyfrowania aplikacyjnego.

Zasada Kerckhoffsa. Odmowa ministerstwa nie znajduje uzasadnienia w podstawowej zasadzie inżynierii bezpieczeństwa. Sformułował ją w 1883 r. kryptolog Auguste Kerckhoffs: system powinien pozostać bezpieczny nawet wtedy, gdy przeciwnik zna wszystkie jego szczegóły z wyjątkiem kluczy. Claude Shannon ujął to krócej: „wróg zna system”. Tę samą zasadę, pod nazwą „otwartego projektu”, przyjmuje amerykański instytut normalizacyjny NIST w wytycznych dotyczących bezpieczeństwa serwerów (NIST SP 800-123, https://csrc.nist.gov/pubs/sp/800/123/final): bezpieczeństwo systemu nie powinno zależeć od utrzymania w tajemnicy jego implementacji ani jego elementów. Przeciwne podejście nazywa się „bezpieczeństwem przez zaciemnianie” (security through obscurity) i w branży uchodzi za błąd. Zasada Kerckhoffsa nie nakazuje przy tym ujawniać każdego szczegółu operacyjnego. Wyklucza natomiast, by bezpieczeństwo systemu zależało od ich tajemnicy.

W przypadku KSeF utajnianie jest przy tym bezskuteczne. Informacja, której ministerstwo odmawia, czyli kto obsługuje bramkę, jest rozgłaszana publicznie każdemu komputerowi, który łączy się z KSeF: w rekordach DNS, w rejestrze adresów ARIN, w nagłówkach HTTP i w certyfikacie TLS (punkt 1). Ministerstwo jest też niekonsekwentne. Szczegóły kryptografii, czyli algorytmy, klucze publiczne i sposób szyfrowania faktur, publikuje samo w serwisie GitHub (punkt 4), bo bez tego żaden program księgowy nie połączyłby się z KSeF. Tajemnicą objęło natomiast jedynie to, kto i gdzie odszyfrowuje ruch. Utajnienie faktów, które każdy może zmierzyć, nikogo nie chroni przed atakiem. Może natomiast chronić przed pytaniami o odpowiedzialność za przyjęte rozwiązanie; to już jednak wniosek (typ D), a nie fakt.

Pozostaje jeszcze jedna droga: wniosek o udostępnienie informacji publicznej, na przykład o nazwę operatora bramki, datę i tryb zawarcia umowy oraz jej treść. Odmowa udostępnienia wymaga wydania decyzji administracyjnej (art. 16 ustawy o dostępie do informacji publicznej), od której przysługuje odwołanie, a następnie skarga do wojewódzkiego sądu administracyjnego. O zasadności zasłaniania się „względami bezpieczeństwa” rozstrzygnąłby wtedy niezależny sąd.

Opis: Z historii KSeF płyną trzy wnioski dla przedsiębiorców.

Po pierwsze, system przeszedł przez dwa rządy i obie większości parlamentarne, więc nie jest projektem jednej partii; odpowiedzialność za jego kształt jest wspólna.

Po drugie, zarzut Senatu z 2023 r., że istotne elementy systemu określa się poza źródłami prawa, pozostaje aktualny w innej formie: o tym, kto i jak przetwarza ruch do KSeF, nie mówi żadna ustawa ani rozporządzenie, a mechanizmy bezpieczeństwa opisuje dokumentacja techniczna publikowana w serwisie GitHub.

Po trzecie, zakres danych otwierających dostęp anonimowy (§ 8) ustalił minister w rozporządzeniu wydanym na podstawie delegacji z art. 106r ustawy o VAT; Sejm nie głosował nad treścią tego przepisu.

Słabe punkty i odpowiedź: Odpowiedzi na interpelacje posłów Kowalskiego i Pejo pochodzą z oficjalnego serwisu Sejmu, a odpowiedź dla posłów Skalika i Zawiślaka jest cytowana z oryginału pisma. Odpowiedź dla senatora Biereckiego znana jest z relacji mediów. Treść podsumowania audytu KSeF z 2024 r. nie była przedmiotem tej analizy, dlatego materiał nie przesądza, czy audyt obejmował bezpieczeństwo i architekturę bramki. Krytyk może też zauważyć, że rozporządzenia wykonawcze to normalny sposób regulowania szczegółów technicznych. To prawda, ale tu chodzi o regułę decydującą o tym, kto może bez logowania pobrać fakturę dowolnej firmy, a więc o ingerencję w tajemnicę przedsiębiorstwa.

7. Polska jako wyjątek na tle innych krajów

Teza: Zbadałem systemy centralnego gromadzenia faktur w 30 innych krajach. Tylko dwa państwa, Polska i Tajwan, oddały punkt wejścia do systemu i serwery nazw zagranicznemu pośrednikowi, który kończy szyfrowane połączenia na własnych urządzeniach. Tylko w Polsce tym pośrednikiem jest spółka zależna koncernu zbrojeniowego kontrolowanego przez obce państwo. Dwa kraje, Grecja i Meksyk, utrzymują usługi w chmurze Microsoft Azure, ale certyfikat i zakończenie połączenia należą tam do urzędu podatkowego. Pozostałe 27 krajów prowadzi punkty wejścia w sieciach państwowych lub krajowych.

Dowód: Podstawą są moje audyty techniczne systemów e-faktur innych krajów, opublikowane od 5 lutego do 7 marca 2026 r. (dowód typu A). Objęły one Hiszpanię (https://informacje-lokalne.pl/audyt-techniczny-hiszpania-2026-02-05/), Rumunię (https://informacje-lokalne.pl/audyt-techniczny-rumunia-2026-02-05/), Włochy (https://informacje-lokalne.pl/audyt-techniczny-wlochy-2026-02-05/), Francję (https://informacje-lokalne.pl/audyt-techniczny-francja-2026-02-05/), Węgry (https://informacje-lokalne.pl/audyt-techniczny-wegry-2026-02-11/), Albanię (https://informacje-lokalne.pl/audyt-techniczny-albania-2026-02-11/), Turcję (https://informacje-lokalne.pl/audyt-techniczny-turcja-2026-02-12/), Ukrainę (https://informacje-lokalne.pl/audyt-techniczny-ukraina-2026-02-12/), Rosję (https://informacje-lokalne.pl/audyt-techniczny-rosja-2026-02-12/), Brazylię (https://informacje-lokalne.pl/audyt-techniczny-brazylia-2026-02-16/), Meksyk (https://informacje-lokalne.pl/audyt-techniczny-meksyk-2026-02-16/), Chile (https://informacje-lokalne.pl/audyt-techniczny-chile-2026-02-16/), Kolumbię (https://informacje-lokalne.pl/audyt-techniczny-kolumbia-2026-02-16/), Argentynę (https://informacje-lokalne.pl/audyt-techniczny-argentyna-2026-02-16/), Grecję (https://informacje-lokalne.pl/audyt-techniczny-grecja-2026-03-07/) oraz Pakistan (https://niepoprawni.pl/blog/gps65/ksef-w-pakistanie). Zastosowałem w nich te same metody co dla KSeF: DNS, właściciel adresu, nagłówki HTTP i certyfikat TLS.

19 października 2026 r. wykonałem dodatkowo pomiar kontrolny. Objął on ponownie część tych krajów oraz czternaście nowych: Portugalię, Chorwację, Serbię, Arabię Saudyjską, Indie, Egipt, Koreę Południową, Chiny, Tajwan, Wietnam, Indonezję, Peru, Ekwador i Kenię. Dla każdego kraju sprawdziłem adres punktu wejścia przez publiczny serwer DNS Google (dns.google), w tym ewentualne aliasy CNAME prowadzące do dostawców CDN lub WAF, a w razie potrzeby także serwery nazw domeny. Następnie ustaliłem, kto ogłasza w Internecie trasę do tego adresu, czyli do czyjej sieci trafia ruch. Posłużyły do tego dane routingu BGP z serwisu RIPEstat (https://stat.ripe.net) oraz rejestry adresów RIPE i ARIN. Dla porównania ta sama metoda pokazuje dla KSeF adres 45.60.74.103, ogłaszany przez system autonomiczny AS19551 należący do Incapsula Inc., czyli Impervy. Tam, gdzie pomiar kontrolny objął kraje z moich wcześniejszych audytów, wyniki są zgodne.

Kraje, w których ruch trafia do sieci państwowych. We Włoszech portal faktur ivaservizi.agenziaentrate.gov.it ma adres 217.175.50.82 w sieci SOGEI-NET, należącej do państwowej spółki informatycznej Sogei. Na Węgrzech interfejs systemu Online Számla (api.onlineszamla.nav.gov.hu, 84.206.52.73) działa w sieci NISZ, państwowego operatora teleinformatycznego (AS31581). W Rumunii interfejs systemu e-Factura (api.anaf.ro, 217.156.52.1) leży w sieci Ministerstwa Finansów. W Hiszpanii serwisy agencji podatkowej (www1.agenciatributaria.gob.es, 195.77.198.17) mają adresy zarejestrowane na samą agencję AEAT. We Francji portal Chorus Pro (chorus-pro.gouv.fr, 185.24.185.61) działa w Międzyresortowej Sieci Państwa (Réseau Interministériel de l’État), prowadzonej przez rządową agencję DINUM. W Chorwacji system fiskalizacji (cis.porezna-uprava.hr, 185.20.29.1) działa w sieci państwowej agencji APIS IT. W Serbii system e-faktur (efaktura.mfin.gov.rs, 195.222.97.192) działa w sieci rządowego Urzędu ds. Technologii Informacyjnych i e-Administracji. W Portugalii portal faktur (faturas.portaldasfinancas.gov.pt, 89.115.248.139) ma adresy przydzielone urzędowi podatkowemu w sieci krajowego operatora Vodafone Portugal.

Poza Europą obraz jest taki sam. W Turcji portal e-faktur (earsivportal.efatura.gov.tr, 212.133.164.81) działa w sieci administracji skarbowej (AS31674). W Pakistanie system IRIS (iris.fbr.gov.pk, 192.58.97.62) działa we własnej sieci Federalnej Rady Dochodów (AS138424). W Indiach portal e-faktur (einvoice1.gst.gov.in, 164.100.69.11) działa w sieci rządowego National Informatics Centre. W Chile serwis urzędu podatkowego SII (palena.sii.cl, 200.10.251.213) działa we własnej sieci urzędu (AS15208). W Brazylii portal e-faktur (www.nfe.fazenda.gov.br, 200.198.239.19) działa w sieci federalnej spółki informatycznej SERPRO. W Egipcie interfejs systemu e-faktur (api.invoicing.eta.gov.eg, 164.160.67.14) działa w sieci egipskiej spółki e-finance, obsługującej państwowe systemy finansowe.

Przypadek Arabii Saudyjskiej wymaga ostrożności. Brama integracyjna ZATCA (gw-fatoora.zatca.gov.sa) ma alias wskazujący domenę cdn.cloudflare.net, co na pierwszy rzut oka sugeruje amerykańskiego pośrednika Cloudflare. Docelowy adres 82.197.55.5 należy jednak do saudyjskiego urzędu podatkowego, a trasę do niego ogłasza własny system autonomiczny urzędu (AS203378). Cloudflare obsługuje tam więc tylko DNS, a ruch trafia bezpośrednio do sieci urzędu.

Azja, Ameryka Łacińska i Afryka. W Korei Południowej serwis Hometax (www.hometax.go.kr, 116.67.103.140), przez który wystawia się e-faktury, działa w sieci państwowej Narodowej Służby Zasobów Informacyjnych (AS17841). W Wietnamie portal e-faktur (hoadondientu.gdt.gov.vn, 103.9.200.142) działa we własnej sieci Generalnego Departamentu Podatków (AS131363). W Indonezji system Coretax (coretaxdjp.pajak.go.id, 43.242.132.12) działa we własnej sieci Dyrekcji Generalnej Podatków (AS58476). W Kenii system eTIMS (etims.kra.go.ke, 196.61.52.224) działa we własnej sieci urzędu skarbowego KRA (AS328089). W Peru system e-faktur SUNAT (e-factura.sunat.gob.pe, 170.231.170.142) działa w sieci krajowego operatora ON Empresas, a w Ekwadorze system urzędu SRI (cel.sri.gob.ec, 181.188.238.10) w sieci krajowego operatora Otecel (Movistar Ecuador). W Chinach serwis weryfikacji faktur (inv-veri.chinatax.gov.cn) przechodzi przez chińską sieć CDN wswebcdn.com, a adres 49.79.232.156 leży w sieci państwowego operatora China Telecom (AS4134). Chiny korzystają więc z pośrednika, ale krajowego.

Tajwan: ten sam model co w Polsce. Portal e-faktur tajwańskiego ministerstwa finansów (www.einvoice.nat.gov.tw) oraz jego interfejs API (api.einvoice.nat.gov.tw) mają adresy 162.159.140.140 i 172.66.0.138. Trasy do nich ogłasza amerykańska firma Cloudflare (AS13335), która jako pośrednik CDN i WAF kończy szyfrowane połączenia na własnych serwerach. Serwery nazw domeny einvoice.nat.gov.tw (rene i michelle.ns.cloudflare.com) oraz nadrzędnej domeny rządowej nat.gov.tw (millie i arch.ns.cloudflare.com) również prowadzi Cloudflare. To jedyny w próbie kraj, który, podobnie jak Polska, oddał zagranicznemu pośrednikowi zarówno ruch, jak i DNS systemu e-faktur. Zasadnicza różnica dotyczy właściciela pośrednika. Cloudflare to amerykańska spółka giełdowa. Imperva należy do koncernu zbrojeniowego, w którym państwo francuskie ma złotą akcję i przedstawiciela wskazywanego przez ministra obrony (punkt 3).

Kraje korzystające z chmury Microsoft Azure. W Grecji publiczny interfejs systemu myDATA (mydatapi.aade.gr), do którego trafiają dane o fakturach, ma adres 20.76.97.27 w sieci Microsoft Corporation (AS8075), geolokalizowany do Amsterdamu; trasa prowadzi przez sieć szkieletową Microsoftu. Certyfikat TLS jest jednak wystawiony na grecki urząd podatkowy AADE, w odpowiedziach nie ma śladów zewnętrznej zapory (Imperva, Cloudflare, Akamai, F5, Azure Front Door), a serwery nazw domeny aade.gr prowadzi krajowy operator OTEnet. W Meksyku serwis weryfikacji faktur urzędu SAT (verificacfdi.facturaelectronica.sat.gob.mx, 13.65.246.176) oraz portal faktur elektronicznych i serwis weryfikacji po kodzie QR działają w chmurze Azure; pomiar kontrolny pokazał aliasy na maszyny w regionie South Central US, czyli w Teksasie. Odpowiedź serwera pochodzi z jego własnej aplikacji (Microsoft IIS, ASP.NET), certyfikat wystawiono na SAT, a serwery nazw domeny sat.gob.mx należą do samego urzędu. W obu krajach mamy więc do czynienia z wynajmem infrastruktury chmurowej, a nie z oddaniem ruchu zewnętrznemu operatorowi bezpieczeństwa. Oba systemy działają jednak na infrastrukturze amerykańskiej firmy podlegającej CLOUD Act.

Opis: Pomiar potwierdza, że polskie rozwiązanie jest odstępstwem, a nie standardem branżowym, jak sugerują obrońcy KSeF. Państwa, które Ministerstwo Finansów samo podaje jako wzór, czyli Włochy i Węgry (odpowiedź MF dla RPO, punkt 6), prowadzą punkty wejścia w sieciach własnych spółek państwowych: Sogei i NISZ. Spośród 30 zbadanych krajów 27 kieruje ruch bezpośrednio do sieci państwowych lub krajowych, a dwa wynajmują infrastrukturę chmurową, zachowując certyfikat i DNS u siebie. Model polski, czyli zagraniczny pośrednik, który odszyfrowuje ruch i prowadzi DNS, ma w próbie tylko jeden odpowiednik: Tajwan. Żaden inny kraj nie powierzył tej roli spółce zależnej koncernu zbrojeniowego kontrolowanego przez obce państwo.

Grecja i Meksyk pokazują jednak, że zależność systemów podatkowych od amerykańskich firm chmurowych nie jest wyłącznie polską przypadłością. Różnica między modelami jest mierzalna. W Grecji i Meksyku szyfrowane połączenie kończy się na usłudze urzędu, opatrzonej certyfikatem urzędu i działającej na wynajętej infrastrukturze Microsoftu. W Polsce kończy się na współdzielonej platformie zewnętrznego operatora bezpieczeństwa, który z założenia odszyfrowuje i analizuje ruch, a do tego prowadzi DNS ministerstwa. W obu modelach dostawca podlega jednak prawu USA i tę wspólną cechę trzeba uczciwie odnotować.

Słabe punkty i odpowiedź: Twierdzenie, że Polska jako jedyna na świecie oddała swój system zagranicznej firmie w chmurze, byłoby w tak szerokim brzmieniu nieprawdziwe: Grecja i Meksyk korzystają z chmury Microsoftu, a Tajwan oddał ruch i DNS firmie Cloudflare. Ścisłe sformułowanie brzmi: spośród 30 zbadanych krajów tylko Polska i Tajwan oddały punkt wejścia i DNS zagranicznemu pośrednikowi, który odszyfrowuje ruch, i tylko w Polsce jest nim spółka koncernu zbrojeniowego kontrolowanego przez obce państwo. Na pytanie o Tajwan odpowiedź jest więc prosta: stosuje on ten sam model, ale jego pośrednik nie należy do koncernu zbrojeniowego kontrolowanego przez obce państwo. Różnica z Grecją i Meksykiem jest mierzalna: tam certyfikat, aplikacja i kontrola DNS należą do urzędu, w Polsce do dostawcy.

Próba 30 krajów obejmuje państwa Unii Europejskiej z obowiązkowymi systemami centralnymi oraz najważniejsze systemy centralne Ameryki Łacińskiej, Azji, Bliskiego Wschodu i Afryki. Nie jest to spis zupełny wszystkich państw świata, dlatego wnioski dotyczą 30 zbadanych krajów. Wynik dla Tajwanu można dodatkowo sprawdzić poleceniem „curl.exe -sI https://www.einvoice.nat.gov.tw”; nagłówki „server: cloudflare” i „cf-ray” w odpowiedzi potwierdzają pośrednictwo Cloudflare w ruchu.

Metoda ma dwa ograniczenia. Po pierwsze, dla każdego kraju badano jeden lub kilka adresów; inne usługi tego samego systemu mogą działać inaczej. Po drugie, pomiar z zewnątrz pokazuje, do czyjej sieci trafia ruch i kto przedstawia certyfikat, ale nie wyklucza, że urząd używa we własnej sieci zagranicznego oprogramowania zabezpieczającego. To jednak inna sytuacja niż w Polsce: produkt zainstalowany u siebie obsługuje urząd, a nie dostawca. Brak śladów zewnętrznej zapory w nagłówkach nie jest też ścisłym dowodem jej braku, choć w Polsce te same ślady są widoczne od razu.

8. Debata publiczna ominęła sedno problemu

Teza: przez pierwsze pół roku obowiązkowego KSeF temat Impervy trafił do mediów i do parlamentu, ale w zbadanych publikacjach żaden niezależny specjalista ani żadna instytucja z branży cyberbezpieczeństwa nie odnieśli się publicznie do trzech ustaleń tego materiału. Chodzi o terminację TLS na bramce zagranicznego pośrednika, brak szyfrowania aplikacyjnego pojedynczej faktury i metadanych oraz dostęp do pełnej faktury na podstawie pięciu pól.

Dowód: temat nie został przemilczany całkowicie, dlatego teza jest węższa niż „pół roku ciszy”. Liczy się to, czego dotyczyły wypowiedzi ekspertów, a nie samo to, że się pojawiły. Przegląd publikacji wykonano 19 października 2026 r.

Demagog, 25 lutego 2026 r. W analizie z 25 lutego 2026 r. (https://demagog.org.pl/analizy_i_raporty/system-ksef-czy-nasze-dane-sa-bezpieczne/) jedynym zewnętrznym ekspertem był Mateusz Chrobok. Wypowiedział się wyłącznie o tym, gdzie fizycznie stoi serwer. Ocenił, że bez wiedzy o infrastrukturze trudno to potwierdzić, choć „wiele na to wskazuje”, że w Polsce, bo pakiety nie mają dużych opóźnień. Serwis Niebezpiecznik, cytowany za wpisem na X, zauważył tylko, że rozstrzygnięcie zależy od projektu systemu. Żadnemu ekspertowi artykuł nie przypisuje wypowiedzi o terminacji TLS.

Infor.pl za „Dziennikiem Gazetą Prawną”. W tekście na Infor.pl, powołującym się na „Dziennik Gazetę Prawną” (https://ksiegowosc.infor.pl/ksef/7507260,ksef-i-dane-z-faktur-skarbowka-uspokaja-eksperci-ostrzegaja-przed-ryzykiem.html), ministerstwo odpowiada na zarzuty słowami „To nieprawda”. Twierdzi, że WAF widzi tylko zaszyfrowane dane. Cytowany ekspert, Adrian Lapierre z ITrust, mówi ogólnie, że zabezpieczenia można kiedyś złamać, i porównuje KSeF do Enigmy. Nie odnosi się do architektury bramki.

Spider’s Web, 8 maja 2026 r. Artykuł Marcina Kusza (https://spidersweb.pl/2026/05/czym-jest-imperva-ksef-faktury.html) nie cytuje żadnego niezależnego eksperta. Opiera się na ogólnych zasadach działania WAF i na oświadczeniach resortu. Terminację TLS wymienia jedynie jako czynnik, który „w zależności od konfiguracji” może mieć znaczenie, choć konfigurację tę można publicznie zmierzyć (punkt 2). Część wpisów w tej sprawie nazywa „histerycznymi”.

Cloud Forum, 30 kwietnia 2026 r. Tekst Jacka Frankowskiego (https://www.cloudforum.pl/ksef-od-1-kwietnia-2026-bezpieczenstwo-danych/) wprost stwierdza, że WAF terminuje TLS i widzi metadane. Nie wymienia jednak z nazwiska żadnego eksperta, a ustalenia techniczne przejmuje z obywatelskiego audytu z 6 lutego 2026 r.

WNP.pl, 25 września i 5 października 2026 r. Dwa teksty Katarzyny Bartman o fakturach wojska i przemysłu obronnego w KSeF (punkt 6) to najpoważniejsze z przejrzanych publikacji. Wypowiadają się w nich trzej specjaliści: doradca podatkowy, audytor i były oficer ABW. Ostrzegają przed efektem mozaiki i brakiem wyłączenia dla dostaw niejawnych, a także przed ryzykiem związanym z uprawnieniami i tokenami. Autorka odnotowuje moje wpisy na X i stwierdza, że moje tezy o dostępie obcych wywiadów pozostają nieudowodnione. Teksty nie wspominają jednak ani Impervy, ani Thalesa, ani terminacji TLS, więc pomiarów, na których te tezy się opierają, nie sprawdzają. Ministerstwo Finansów odpowiedziało, że „System działa stabilnie”, że nie odnotowano incydentów ani nieuprawnionego dostępu, a szczegóły zabezpieczeń, w tym audyty, są poufne. Ocena ryzyka, że ktoś ma dostęp, i ocena faktu, przez czyją infrastrukturę dane fizycznie przechodzą, to dwie różne kwestie. Teksty WNP.pl zajęły się pierwszą, a pomiary z tego materiału dotyczą drugiej.

Politycy. Formalne pytania do ministerstwa kierowali poseł Janusz Kowalski (interpelacja nr 14817 z 23 stycznia 2026 r., odpowiedź 17 lutego 2026 r.), poseł Bartłomiej Pejo (interpelacja nr 18034 z 24 czerwca 2026 r., odpowiedź 10 sierpnia 2026 r.), posłowie Włodzimierz Skalik i Sławomir Zawiślak oraz senator Grzegorz Bierecki (punkt 6). Publicznie zastrzeżenia zgłaszali też posłowie Krzysztof Bosak i Ryszard Wilk. Wszyscy należą do opozycji.

Czego nie znaleziono. W żadnej z tych publikacji ani w odpowiedziach ministerstwa nie pada analiza dostępu bez uwierzytelnienia z § 8 rozporządzenia. Nikt nie opisał, że pojedyncza faktura pobierana przez API nie ma szyfrowania aplikacyjnego, i nikt nie przeprowadził testu nagłówka Host. Jedyne merytoryczne zapewnienie ministerstwa, że zapora „widzi jedynie zaszyfrowane dane”, przeczy pomiarowi z punktu 2 i dokumentacji resortu z punktu 4. Żaden cytowany ekspert tego zapewnienia nie zweryfikował ani nie obronił. Zbadane wypowiedzi ekspertów odpowiadały więc na pytanie, gdzie stoi serwer. Dla omawianego ryzyka jest ono drugorzędne, bo TLS kończy się na brzegu sieci pośrednika niezależnie od tego, gdzie stoi serwer KSeF. Wynik ten dotyczy zbadanych publikacji i nie wyklucza istnienia innych.

Gdzie stoi serwer, a gdzie odszyfrowuje się ruch. Argument, że krótkie opóźnienia dowodzą lokalizacji serwera w Polsce, zakłada model jednego serwera pod jednym adresem. Imperva działa inaczej. Według forum technicznego Thalesa łańcuch aliasów CNAME prowadzi do adresu typu Anycast. Część adresów Impervy jest przy tym „zarejestrowana w USA”, choć ogłasza się je w innych regionach (https://community-cybersec.thalesgroup.com/discussion/cloud-waf-fundamentals-understanding-key-concepts-architecture-and-global-security-questions-and-answers). Rejestracja adresu 45.60.74.103 w amerykańskim rejestrze ARIN (punkt 1) wskazuje więc jego właściciela, a nie miejsce, w którym stoi obsługująca go maszyna. W modelu Anycast ten sam adres IP ogłasza się jednocześnie z wielu centrów danych, nazywanych punktami obecności (PoP). Routing internetu (BGP) kieruje każdego klienta do węzła najbliższego w sensie topologii sieci, która nie musi pokrywać się z geografią. Według zestawienia CDNPlanet Imperva ma węzły między innymi w Warszawie, Frankfurcie, Paryżu, Londynie, Dublinie, Amsterdamie i Mediolanie, a poza Europą między innymi w Tel Awiwie (https://www.cdnplanet.com/cdns/imperva/). Na takim węźle kończy się sesja TLS (punkt 2). Pomiar opóźnienia z Polski mierzy więc odległość do najbliższego węzła Impervy, a nie do serwera KSeF. Klient tego serwera w ogóle nie widzi, bo łączy się wyłącznie z pośrednikiem. Z krótkiego czasu odpowiedzi wynika najwyżej tyle, że polski klient trafia do węzła w Polsce lub w jej pobliżu.

Pomiar węzła. Imperva standardowo udostępnia na domenach obsługiwanych przez jej zaporę Cloud WAF zasób diagnostyczny, który pokazuje, z jakim węzłem połączył się klient. Jest to adres zakończony na „/_incapsula_resource?NWQ=1”, opisany na tym samym forum Thalesa. 19 października 2026 r. wykonano ten test z dwóch punktów pomiarowych. Z zagranicznego serwera chmurowego zapytanie o https://ksef.mf.gov.pl/_incapsula_resource?NWQ=1 zwróciło odpowiedź „You reached dub-prx6 at 45.60.74.103 proxy_id:1381”. Zapytanie o https://api.ksef.mf.gov.pl/_incapsula_resource?NWQ=1 zwróciło „You reached dub-prx12 at 45.60.74.103 proxy_id:1387”. Z komputera podłączonego do polskiej sieci oba zapytania zwróciły „You reached war-prx12 at 45.60.74.103 proxy_id:682”. Ten sam adres IP, 45.60.74.103, obsłużyły więc w tej samej chwili różne maszyny, o różnych identyfikatorach i różnych przedrostkach nazw, zależnie od tego, skąd przyszło zapytanie.

To bezpośredni dowód (typ A), że bramka KSeF działa w modelu Anycast i że miejsce, w którym kończy się szyfrowanie ruchu do KSeF, zależy od położenia klienta w sieci, a nie od granic Polski. Odczytanie przedrostków „war” jako Warszawy i „dub” jako Dublina jest wnioskiem z nazw (typ D), zgodnym z listą węzłów CDNPlanet. Nie są to kody lotnisk, bo lotnisko w Warszawie ma kod WAW, więc Imperva używa własnych skrótów miast. Wynik jest spójny z argumentem o krótkich opóźnieniach: polski klient trafia do węzła w Warszawie. Ten sam system obsłużył jednak klienta spoza Polski w Irlandii. Każdy może powtórzyć ten test w PowerShell poleceniem „curl.exe -s „https://api.ksef.mf.gov.pl/_incapsula_resource?NWQ=1″”, które nie wymaga konta ani logowania. Uruchomienie go przez sieć VPN z wyjściem w innym kraju pokaże, który węzeł obsługuje KSeF dla klientów z tego kraju.

Konsekwencje pomiaru. Deklaracja ministerstwa, że wszystkie elementy systemu znajdują się w Polsce (punkt 6), może być prawdziwa dla serwerów resortu. Pomiar pokazuje jednak, że nie obejmuje ona wszystkich miejsc, w których kończy się szyfrowanie ruchu do KSeF. Ma to cztery skutki.

Po pierwsze, polski podatnik łączący się z polskiej sieci trafia, jak pokazał pomiar, do węzła warszawskiego. Ruch programów księgowych i systemów ERP działających w zagranicznych centrach danych trafia natomiast do zagranicznych węzłów Impervy i tam jest odszyfrowywany. Dotyczy to na przykład usług w Irlandii, gdzie duże regiony chmurowe mają Amazon i Microsoft. Pomiar z Dublina pokazuje taki przypadek bezpośrednio. Które polskie programy księgowe działają w zagranicznych centrach danych, tego nie ustalono (typ D).

Po drugie, nawet polski ruch nie zawsze trafia do Warszawy. Przed pracami serwisowymi w warszawskim centrum danych 3 i 4 sierpnia 2025 r. Imperva zapowiedziała, że przekieruje ruch klientów Cloud WAF „do najbliższego centrum danych” (https://status.imperva.com/incidents/3fzzzjw657ct). Komunikat nie dotyczy KSeF i nie wiadomo, czy KSeF był wtedy obsługiwany przez Impervę. Pokazuje jednak mechanizm: podczas serwisu lub awarii węzła sesje TLS polskich klientów kończą się za granicą.

Po trzecie, węzeł wybiera dostawca, a nie klient. Według forum Thalesa klienci Impervy nie mogą wybrać PoP. Na potrzeby wymogów zgodności istnieją jednak wydzielone części sieci („network slices”), które kierują ruch wyłącznie do wskazanych węzłów. W Australii Imperva oferuje opcję, przy której odszyfrowanie i zakończenie ruchu „zawsze” odbywa się w australijskich węzłach (https://www.imperva.com/blog/deploy-a-cloud-waf-ddos-solution-while-complying-with-australian-data-sovereignty/). Wynik z Dublina pokazuje, że KSeF nie jest ograniczony do węzła w Polsce. Pomiar z jednego punktu nie rozstrzyga natomiast, czy jest ograniczony do węzłów w Unii Europejskiej. Pytanie o to, czy ministerstwo kupiło taką opcję dla Polski, mieści się w zakresie informacji, których resort odmawia (punkt 6).

Po czwarte, miejsce przetwarzania nie jest miejscem przechowywania. Od 2018 r. Imperva przechowuje logi w regionalnych klastrach: unijnym, amerykańskim oraz azjatycko-pacyficznym. Region przypisuje się domyślnie według lokalizacji serwera źródłowego, a administrator klienta może go zmienić (https://www.imperva.com/blog/archive/data-privacy-how-we-restructured-our-incapsula-architecture-to-provide-regional-isolation-control/). Wcześniej stronę zdarzeń i alerty obsługiwał centralnie zespół maszyn w węźle w USA. Z publicznych źródeł nie wynika, gdzie fizycznie stoi klaster unijny ani jakie dane z ruchu KSeF do niego trafiają.

Lokalizacja a jurysdykcja. Nawet pełna wiedza o położeniu maszyn nie rozstrzyga, czyje prawo do nich sięga. CLOUD Act nakazuje dostawcy podlegającemu prawu USA wydać dane, które ma w posiadaniu, pieczy lub pod kontrolą, niezależnie od tego, czy znajdują się w Stanach Zjednoczonych, czy poza nimi (18 U.S.C. § 2713; punkt 3). O zakresie tego prawa decyduje więc kontrola, a nie terytorium. Z tego wynika ogólniejsza teza interpretacyjna. W architekturze chmurowej granica państwa przestaje być barierą techniczną, a jej miejsce zajmuje struktura kontroli. Suwerenność cyfrowa oznacza wówczas panowanie nad całym cyklem życia informacji: nad tym, kto ją odszyfrowuje, zapisuje w logach, replikuje i analizuje. Nie oznacza panowania nad miejscem, w którym informacja chwilowo przechodzi przez procesor. Szybki ping i lokalna trasa tego nie mierzą. Pomiary z tego materiału pokazują tylko tyle, że w przypadku KSeF ten cykl zaczyna się na infrastrukturze kontrolowanej przez Impervę, w miejscu, które zależy od routingu, a nie od decyzji państwa polskiego.

Bariera nie leży w dostępie do danych. Każde ustalenie z punktów 1, 2, 4 i 5 uzyskano bez konta w KSeF, z publicznego DNS, nagłówków odpowiedzi, dokumentacji ministerstwa i Dziennika Ustaw. Obawa przed odpowiedzialnością karną z art. 267 kodeksu karnego nie wyjaśnia więc milczenia o tych faktach, bo takie pomiary nie są uzyskiwaniem dostępu do systemu. Polskie prawo zna przy tym ograniczoną „bezpieczną przystań”. Od 2017 r. art. 269c kodeksu karnego wyłącza karalność czynów z art. 267 § 2 i art. 269a, ale tylko wtedy, gdy ktoś działa wyłącznie w celu zabezpieczenia systemu, niezwłocznie powiadomi jego dysponenta i nie wyrządzi szkody (https://arslege.pl/kodeks-karny/k1/a104233/). Dyrektywa NIS2 (2022/2555, art. 12) wymaga ponadto, by państwo wyznaczyło CSIRT jako koordynatora zgłaszania podatności. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa weszła w życie 3 kwietnia 2026 r. (https://www.gov.pl/web/cyfryzacja/nowelizacja-ustawy-o-krajowym-systemie-cyberbezpieczenstwa-zaczyna-obowiazywac). Zarzut braku jakiejkolwiek ochrony badaczy jest zatem nieścisły. Trafny jest zarzut, że ochrona jest wąska i warunkowa, a aktywne testowanie produkcyjnego KSeF poza tymi warunkami pozostaje ryzykowne.

Hipotezy wyjaśniające (typ D). Poniższe wyjaśnienia są hipotezami, a nie ustaleniami. Nie wykluczają się wzajemnie, nie są przypisane żadnej konkretnej osobie i każda wymagałaby osobnego badania, na przykład ankietowego albo analizy powiązań kontraktowych. Pierwsza grupa ma charakter poznawczy i organizacyjny. Problem leży na styku prawa, kryptografii, sieci, zarządzania uprawnieniami i księgowości, a specjaliści zwykle oceniają tylko swój wycinek.

Działa dyfuzja odpowiedzialności („ktoś na pewno już to sprawdził”) i efekt autorytetu, przez który rozwiązanie wdrożone przez ministerstwo ocenia się łagodniej niż identyczne rozwiązanie startupu. Terminacja TLS na chmurowym WAF jest normą w handlu elektronicznym, więc wielu specjalistów wykreśliło ją z modelu zagrożeń bez pytania, czy ta sama miara pasuje do centralnego rejestru transakcji gospodarki.

Do tej grupy należą też przewaga zgodności z procedurami (compliance) nad modelowaniem zagrożeń i mylenie legalności z bezpieczeństwem. Skoro dostęp po pięciu polach wynika z rozporządzenia, traktuje się go jak wymaganie, a nie jak decyzję kryptograficzną. Dochodzą brak perspektywy napastnika, który pyta, gdzie komplet pięciu pól leży poza KSeF (punkt 5), oraz brak spektakularnego incydentu.

Druga grupa ma charakter społeczny. Obejmuje obawę przed ośmieszeniem i przed etykietą „teorii spiskowej” przy tematach dotyczących obcych służb, efekt stadny i ocenianie argumentu według statusu jego autora. Obejmuje też polaryzację polityczną. Fakt, że pytania zadawali wyłącznie politycy opozycji, mógł sprawić, że część środowiska uznała temat za polityczny, a nie techniczny.

Trzecia grupa ma charakter ekonomiczny. Obejmuje zależność firm doradczych, audytorskich i integratorskich od kontraktów publicznych, relacje partnerskie z dostawcami chmury i WAF, przenikanie się kadr administracji i rynku (regulatory capture) oraz niechęć do podważania decyzji, w których podejmowaniu lub weryfikacji ktoś wcześniej uczestniczył.

Czwarta grupa dotyczy mediów. Analiza wymagająca łączenia DNS, TLS, API i przepisów o VAT jest kosztowna, a przynosi mniej odsłon niż wiadomość o awarii. Dochodzą ryzyko prawne, zależność od dostępu do źródeł w urzędach oraz zjawisko, w którym nikt nie chce być pierwszy, choć wielu chętnie będzie drugich.

Najmocniejsza hipoteza mówi o świadomym przemilczeniu jako sumie indywidualnych, racjonalnych decyzji, bez potrzeby jakiejkolwiek zmowy. Jest ona jednak najtrudniejsza do sprawdzenia, bo jej przewidywania pokrywają się z przewidywaniami pozostałych hipotez.

Opis: brak publicznej oceny ekspertów nie jest dowodem ani na to, że problem nie istnieje, ani na to, że jest poważny. Ustalenia z punktów 1–5 opierają się na pomiarach i dokumentach (typy A i B), a nie na ich odbiorze. Każdy może je powtórzyć poleceniami podanymi w tym materiale. Dla przedsiębiorcy wniosek jest praktyczny: skoro nikt z zewnątrz nie przedstawił publicznie niezależnej oceny tej architektury, firma musi sama uwzględnić opisane ryzyka we własnym modelu zagrożeń (punkt 5). Może też wnosić o udostępnienie informacji o audytach bezpieczeństwa KSeF i o umowie z operatorem bramki (punkt 6). Z zasady Kerckhoffsa wynika, że jawność takiej oceny nie osłabia systemu, który jest dobrze zaprojektowany.

Słabe punkty i odpowiedź: można argumentować, że eksperci milczą, bo nie widzą problemu. Terminacja TLS u zaufanego dostawcy WAF jest praktyką branżową, a dostęp po pięciu polach to świadomy kompromis wygody. To uprawniona hipoteza konkurencyjna i trzeba ją brać pod uwagę. Gdyby jednak była prawdziwa, należałoby się spodziewać publicznej obrony tej architektury z uzasadnieniem. Należałoby się też spodziewać sprostowania jedynego zapewnienia ministerstwa, które przeczy pomiarom. W zbadanych publikacjach nie ma ani jednego, ani drugiego. Ocena, czy zaufanie do zagranicznego pośrednika jest dopuszczalne, jest decyzją polityczną, a nie czysto techniczną, ale i ona wymaga jawnego sformułowania.

Drugi zarzut brzmi: hipotezy o motywach są niesprawdzalne i ocierają się o argument ad personam. Dlatego oznaczono je jako typ D, nie przypisano ich żadnej osobie i nie od nich zależy żadna teza techniczna tego materiału.

Trzeci zarzut: przegląd publikacji jest niepełny. To prawda, wynik ma charakter negatywny i dotyczy zbadanych źródeł. Wystarczy jedna rzetelna, publiczna analiza tych trzech ustaleń przez niezależnego specjalistę, żeby teza wymagała korekty, i taka korekta byłaby pożądana.

9. Co strumień faktur mówi o firmie: przykład przemysłu obronnego

Teza: faktury polskiego przemysłu obronnego trafiają do KSeF bez żadnego wyjątku (punkt 6). Ich metadane, a w części przypadków także pełna treść, przechodzą jawnie przez bramkę operatora spoza polskiej jurysdykcji (punkty 2–4). Dla firmy oznacza to, że informacje handlowe, których nie ujawnia żaden komunikat o kontrakcie, są technicznie dostępne podmiotowi należącemu do koncernu zbrojeniowego, który z polskimi producentami konkuruje. Chodzi o rzeczywiste tempo dostaw, ceny jednostkowe i strukturę poddostawców. Wartość tych danych nie zależy od tego, czy faktura zawiera jakikolwiek tajny parametr techniczny.

Dowód: kontrakty są jawne. 24 sierpnia 2026 r. Agencja Uzbrojenia, działająca w imieniu konsorcjum Polski, Litwy, Łotwy i Norwegii, podpisała z MESKO S.A. umowę na przenośne zestawy przeciwlotnicze Piorun. Umowa ma wartość około 8 mld zł, obejmuje kilka tysięcy pocisków i kilkaset mechanizmów startowych, dostawy potrwają do 2030 r., a finansowanie pochodzi z unijnego programu SAFE (https://defence24.pl/przemysl/historyczny-kontrakt-na-tysiace-piorunow-nowy-kontrahent).

15 maja 2025 r. Agencja podpisała z WB Electronics umowę ramową na około tysiąc zestawów amunicji krążącej Warmate, czyli około 10 tysięcy dronów, obowiązującą do końca 2035 r. Minister obrony powiedział przy tym: „Umowy wykonawcze będą podpisywane cyklicznie, po to, by najczęściej kupować najnowszą wersję” (https://forsal.pl/kraj/bezpieczenstwo/artykuly/9799982,10-tysiecy-dronowkamikadze-mon-stawia-na-warmate.html).

28 maja 2026 r., w ramach SAFE, podpisano kolejne umowy z grupą WB. Obejmują one ponad 400 zestawów Warmate po 10 dronów, 190 zestawów rozpoznawczych FlyEye po 4 bezzałogowce oraz 12 modułów ogniowych systemu Gladius (https://spidersweb.pl/2026/05/tysiace-dronow-z-safe-dla-wojska-polskiego.html, https://defence24.pl/przemysl/gladius-flyeye-i-warmate-najwieksze-umowy-na-systemy-bezzalogowe). Agencja Uzbrojenia potwierdziła, że wszystkie faktury od dostawców krajowych otrzymuje przez KSeF (punkt 6).

Co widzi bramka, a czego nie. Trzeba tu odróżnić dwa poziomy danych, bo od tego zależą skutki.

Poziom pierwszy to metadane. Przechodzą jawnie przez bramkę API za każdym razem, gdy program sprzedawcy lub nabywcy wyszukuje faktury (punkt 4). Zawierają numer faktury, sprzedawcę, nabywcę, datę wystawienia i kwotę brutto, ale nie zawierają pozycji faktury.

Poziom drugi to pełna treść. Ustawa o VAT (art. 106e ust. 1) wymaga, by faktura podawała nazwę towaru, miarę i ilość, cenę jednostkową netto i wartość sprzedaży netto. Pełna treść przechodzi przez bramkę jawnie wtedy, gdy program pobiera fakturę pojedynczo przez API. Nie przechodzi jawnie przy wysyłce ani przy pobieraniu szyfrowanych paczek eksportu (punkt 4). Którą metodę stosują programy Agencji Uzbrojenia i jej dostawców, tego z zewnątrz nie wiadomo.

Niezależnie od tego rekord metadanych typowej faktury może zawierać komplet pięciu danych, które pozwalają pobrać pełną fakturę bez uwierzytelnienia (punkt 5). Tokeny dostępowe przechodzą przez bramkę w postaci jawnej (punkt 2). Token producenta z prawem odczytu (InvoiceRead) może dawać dostęp do jego faktur wystawionych i otrzymanych, w granicach kontekstu, zakresu uprawnień i czasu ważności sesji. Program obsługujący zarówno sprzedaż, jak i odbiór faktur kosztowych potrzebuje obu uprawnień, ale jak często łączy je w jednej sesji, tego nie ustalono (typ D). Pełna treść jest więc dla posiadacza metadanych lub tokenów osiągalna, ale wymagałaby aktywnego zapytania do systemu ministerstwa, a nie tylko biernej obserwacji ruchu.

Przykład pierwszy: MESKO i Piorun. Już na poziomie metadanych seria faktur MESKO dla Agencji Uzbrojenia z kolejnych miesięcy pokazuje rytm i skumulowaną wartość dostaw. Pokazuje też, jaką część kontraktu o wartości około 8 mld zł zrealizowano i czy tempo rośnie, czy występują przerwy. Na poziomie pełnej treści widać więcej: ile pocisków i ile mechanizmów startowych dostarczono w danym miesiącu oraz jakie były ich ceny jednostkowe. Widać też, jak cena zmienia się wraz ze skalą zamówienia. Jeszcze więcej mówią faktury poddostawców wystawiane dla MESKO. Jeśli wraz ze wzrostem dostaw rośnie sprzedaż określonej firmy do MESKO albo pojawia się nowy podwykonawca, da się odtworzyć łańcuch dostaw i jego wąskie gardła.

Nie trzeba do tego znać konstrukcji pocisku. Istotny jest tu fakt dotyczący właściciela bramki. Koncern Thales produkuje w zakładach w Belfaście własne pociski przeciwlotnicze krótkiego zasięgu Starstreak (https://imeche.org/news/news-article/pm-announces-contract-for-200-starstreak-missiles, https://m.fin24.com/news24/world/news/merchants-of-death-ukraine-war-has-thales-missile-factory-working-at-full-tilt-20240321). Spółka, przez której infrastrukturę przechodzą dane o dostawach Piorunów, należy więc do grupy oferującej produkt z tego samego segmentu rynku. To strukturalny konflikt interesów, opisany na podstawie faktów (typy B i C). Nie stanowi on dowodu, że te dane są wykorzystywane.

Przykład drugi: WB Group, Warmate i FlyEye. Publicznie wiadomo, ile zestawów Polska zamówiła. Strumień faktur pokazuje, ile z tego rzeczywiście wyprodukowano i dostarczono w danym miesiącu, jak szybko rośnie produkcja i ile kosztują kolejne partie. Skoro umowy wykonawcze mają być zawierane cyklicznie po to, by kupować najnowsze wersje, w pozycjach kolejnych faktur mogą się pojawiać nowe oznaczenia wersji, nowe składy zestawów lub nowe kategorie podzespołów. Zmianę produktu da się wtedy dostrzec, zanim zostanie publicznie opisana.

Faktury dostawców elektroniki, optyki, napędów, akumulatorów i łączności pokazują, które polskie firmy są dla programu kluczowe i jak bardzo producent zależy od pojedynczych dostawców. Na rynku bezzałogowców i amunicji krążącej Polska konkuruje między innymi z przemysłem izraelskim, a Imperva powstała i prowadzi działalność badawczą w Izraelu (punkt 3). Ten związek opisuje motyw i zdolność. Nie jest dowodem na przepływ danych (typ D).

Praktyczne skutki dla firmy.

Pierwszym skutkiem jest osłabienie pozycji w przetargach eksportowych. Konkurent, który zna rzeczywiste ceny jednostkowe i ich zależność od wielkości serii, nie musi zgadywać, jaka cena jest dla polskiej firmy realna.

Drugim jest odsłonięcie łańcucha dostaw. Kto wie, którzy poddostawcy są kluczowi, może próbować ich przejąć, podkupić albo uzależnić. Może też wybrać najsłabsze ogniwo jako cel ataku informatycznego lub sabotażu, bo mały poddostawca jest zwykle chroniony słabiej niż duży producent (typ D).

Trzecim skutkiem jest ujawnienie zdolności produkcyjnych i ich granic. Daje to przewagę negocjacyjną każdemu zagranicznemu kontrahentowi i partnerowi przemysłowemu.

Czwartym jest ułatwienie precyzyjnych oszustw. Autentyczne numery faktur, kwoty i dane kontrahentów pozwalają przygotować wiarygodną prośbę o zmianę rachunku do zapłaty, skierowaną do działu finansowego producenta lub poddostawcy (punkt 5). Ten sam mechanizm dotyczy firm cywilnych. Seria faktur dostawcy energetyki, chemii czy logistyki zdradza marże, kluczowych klientów i plany inwestycyjne. Przemysł obronny jest po prostu przypadkiem, w którym skutki wykraczają poza interes jednej firmy.

Asymetria dostępu. Polskie organy państwa mają dostęp do danych z KSeF tylko w trybie ustawowym. Wynika to z odpowiedzi ministerstwa z 2 kwietnia 2026 r. na interpelację nr 15908 posła Janusza Kowalskiego (https://api.sejm.gov.pl/sejm/term10/interpellations/attachment/ATTDSWJ53/i15908-o1.pdf). Organy KAS korzystają z tych danych na podstawie art. 297h Ordynacji podatkowej „w celu realizacji ich ustawowych zadań”. Inne uprawnione organy korzystają z nich na zasadach z art. 297, 299g i 299h tej ustawy. Każdy dostęp pracownika KAS wymaga wskazania celu i zgody przełożonego, jest „na bieżąco monitorowany w systemie” i podlega okresowemu audytowi. Dane są objęte tajemnicą skarbową, a za jej naruszenie grozi odpowiedzialność karna. Operator bramki nie jest pracownikiem KAS.

Nie ustalono jednak pełnego zakresu jego obowiązków prawnych, umownych i mechanizmów kontroli, więc nie można uznać go za podmiot wolny od ograniczeń. Bierna obserwacja metadanych i tokenów na bramce nie zostawia śladu w systemach ministerstwa, a użycie przechwyconego tokenu mogłoby przejść uwierzytelnianie jako działanie jego posiadacza, choć nie wyklucza to wykrycia anomalii (punkt 2). To wnioski typu D, wynikające z zasady działania pośrednika. Polska służba, która chce poznać faktury polskiej firmy, musi więc złożyć uzasadniony wniosek i zostawia ślad. Zewnętrzna obserwacja nie pozwala ustalić, jakie obowiązki i procedury dotyczą dostępu operatora bramki. Nieznajomość tych ograniczeń nie jest dowodem ich nieistnienia.

Opis: dla przedsiębiorcy wniosek jest praktyczny i nie wymaga przesądzania, czy ktoś te dane faktycznie czyta. Model zagrożeń buduje się na zdolności i motywie, a obie te przesłanki są tu udokumentowane. Firma może ograniczyć ryzyko w czterech kierunkach.

Po pierwsze, warto zapytać dostawcę oprogramowania, czy pobiera faktury pojedynczo przez API, czy szyfrowanymi paczkami eksportu, bo tylko druga metoda nie odsłania treści na bramce (punkt 4).

Po drugie, można ograniczyć szczegółowość opisu pozycji do tego, czego wymaga art. 106e ustawy o VAT, oraz tam, gdzie pozwala na to umowa, wystawiać faktury zbiorcze za okres zamiast faktur do każdej partii. Zmniejsza to rozdzielczość czasową danych, ale nie usuwa ilości ani cen. Zakres takich zmian należy uzgodnić z doradcą podatkowym i pełnomocnikiem do spraw ochrony informacji niejawnych.

Po trzecie, metadane faktur trzeba w firmie chronić jak dane uwierzytelniające (punkt 5).

Po czwarte, rozwiązanie systemowe ma charakter prawny. Ustawa o VAT pozwala ministrowi wyłączyć określone faktury rozporządzeniem, a dla dostaw obronnych i niejawnych tego nie zrobiono (punkt 6). Organizacje branżowe przemysłu obronnego mogą o takie wyłączenie wystąpić.

Słabe punkty i odpowiedź: pierwszy zarzut brzmi, że nie ma dowodu, by jakiekolwiek państwo czytało te faktury. To prawda i ten punkt takiego dowodu nie przedstawia. Opisuje zdolność techniczną, kanały prawne (punkt 3) i wartość danych. Na takich przesłankach opiera się każda analiza ryzyka, ponieważ wykorzystanie danych wywiadowczych z zasady nie zostawia publicznych śladów. Inżynieria bezpieczeństwa formułuje to jako zasadę. Zabezpieczenie nie może polegać na tym, że ktoś, kto ma dostęp, z niego nie skorzysta, bo zabrania mu tego umowa. Musi polegać na tym, że dostępu nie ma. Architektura zerowego zaufania opisana w wytycznych NIST SP 800-207 (https://csrc.nist.gov/pubs/sp/800/207/final) zakłada, że napastnik może być obecny w środowisku. Każe projektować system tak, żeby takie założenie nie prowadziło do ujawnienia danych. Z tej zasady nie wynika, że dostęp jest wykorzystywany. Wynika z niej tylko, że bezpieczeństwo KSeF nie powinno zależeć od odpowiedzi na to pytanie. Precedensy historyczne trzeba przy tym przytaczać ostrożnie.

Parlament Europejski w rezolucji z 5 września 2001 r. (sprawozdanie A5-0264/2001) uznał istnienie globalnego systemu przechwytywania komunikacji Echelon. Co do używania go do szpiegostwa gospodarczego posłowie nie byli jednak zgodni, a komisja nie wykazała operacji na dużą skalę (https://statewatch.org/news/2001/september/european-parliament-adopts-echelon-spy-system-report-report-on-the-existence-of-a-global-system-for-the-interception-of-private-and-commercial/).

Mocniejszym argumentem jest prawo obowiązujące: francuska ustawa o wywiadzie wymienia ochronę interesów gospodarczych jako uprawniony cel działań służb (punkt 3).

Drugi zarzut brzmi, że USA i Francja są sojusznikami. Sojusz wojskowy nie znosi jednak konkurencji przemysłowej. Koncern Thales sam sprzedaje uzbrojenie, w tym pociski przeciwlotnicze, a informacje o cenach i zdolnościach mają wartość negocjacyjną także między sojusznikami.

Trzeci zarzut brzmi, że część tych informacji i tak jest publiczna, w komunikatach, sprawozdaniach finansowych i rejestrach eksportu. Te źródła podają jednak sumy roczne i wartości kontraktów. Faktury dają szereg czasowy z dokładnością do dnia i, na poziomie pełnej treści, ceny jednostkowe, więc jest to informacja jakościowo inna.

Czwarty zarzut brzmi, że metadane nie zawierają ilości ani cen jednostkowych. To prawda, co punkt otwarcie przyznaje. Odsłonięcie pozycji faktury zależy od sposobu pobierania faktur przez programy stron albo od aktywnego użycia metadanych lub tokenów. Sam szereg dat, stron i kwot brutto wystarcza jednak do odtworzenia rytmu dostaw i struktury poddostawców.

10. Kryterium premiera: Pegasus a KSeF

Teza: 12 października 2026 r. premier Donald Tusk nazwał sprawę Pegasusa „zbrodnią stanu”, uzasadniając to tym, że osoby odpowiedzialne za bezpieczeństwo państwa oddały wrażliwe dane obywateli obcemu państwu, nie mając nad nimi kontroli. Zastosowane konsekwentnie, to samo kryterium obejmuje architekturę KSeF.

Dowód: Tego samego dnia Prokuratura Krajowa przedstawiła ustalenia biegłych Agencji Bezpieczeństwa Wewnętrznego (https://xyz.pl/?p=260710). Według nich CBA nie miało pełnej kontroli nad działaniem systemu. Część infrastruktury pozostawała wyłącznie pod kontrolą producenta, dane przesyłano przez zarządzaną przez niego sieć z zagranicznymi adresami IP, a zdalne wsparcie dawało producentowi możliwość dostępu do infrastruktury przechowującej materiały z kontroli operacyjnych. Prokuratura zastrzegła jednak, że opinie biegłych nie przesądzają, czy producent faktycznie uzyskał dostęp do materiałów z konkretnych kontroli. Premier mówił o oddaniu tysięcy lub dziesiątek tysięcy wrażliwych danych obywateli obcemu państwu bez kontroli i zakończył słowami: „mówimy o zbrodni stanu i za to będą odpowiadać”.

Opis: Zestawienie obu spraw ma wspólny rdzeń. W obu państwo dopuściło zagranicznego dostawcę do infrastruktury przetwarzającej wrażliwe dane. W obu dostawca ma techniczną zdolność dostępu do tych danych (dla KSeF wykazują to punkty 2, 4 i 5). W obu państwo nie ma pełnej kontroli nad tym dostępem, a w przypadku KSeF ministerstwo odmawia nawet ujawnienia, kto jest dostawcą (punkt 6). Podobne są też drogi od dostawcy do obcego państwa: wobec producenta Pegasusa jest to jurysdykcja Izraela, wobec Impervy jurysdykcja USA i wpływ właścicielski państwa francuskiego przez Thales (punkt 3). Różnica dotyczy skali. Pegasus objął według premiera tysiące lub dziesiątki tysięcy danych obywateli, a KSeF obejmuje praktycznie całą gospodarkę: kontrahentów, ceny, wolumeny i zależności dostaw.

Zasada, którą przypomniała prokuratura, działa w obie strony. Zdolność dostępu dostawcy nie jest dowodem, że obcy wywiad z niej skorzystał. Dotyczy to Pegasusa tak samo jak KSeF. Jeżeli jednak w sprawie Pegasusa sama zdolność dostępu i brak kontroli wystarczają premierowi do najcięższej oceny politycznej, to od krytyków KSeF nie można żądać dowodów dalej idących. Odpowiedzialność za architekturę KSeF obciąża przy tym oba rządy: system przygotowano za rządu Mateusza Morawieckiego, a w obecnej postaci uruchomiono za rządu Donalda Tuska (punkt 6).

Słabe punkty i odpowiedź: Krytyk wskaże, że zarzuty w sprawie Pegasusa opierają się na naruszeniu konkretnego przepisu: system przetwarzający informacje niejawne nie uzyskał wymaganej akredytacji bezpieczeństwa, a KSeF ma podstawę ustawową, a dane podatkowe nie są informacjami niejawnymi, lecz objęte tajemnicą skarbową. To prawda i ta różnica ma znaczenie prawne. Premier nie mówił jednak o akredytacji, tylko o oddaniu danych obcemu państwu bez kontroli. Argument dotyczy spójności tego kryterium, a nie odpowiedzialności karnej konkretnych osób, którą trzeba by wykazać na podstawie konkretnych decyzji i naruszeń.

Uzupełnienie pomiarów i zakres weryfikacji z 19 października 2026 r.

Pomiary uzupełniające wykonałem na swoim komputerze w PowerShell, korzystając z curl.exe 8.21. Odczyty wykonano o 17:37, 17:39 i 17:41 czasu polskiego (UTC+02:00). Zapytania nie wymagały logowania ani przekazywania tokenów dostępowych.

Pomiar o 17:37. Nazwy ksef.mf.gov.pl, api.ksef.mf.gov.pl i login.mf.gov.pl wskazywały przez aliasy w domenie impervadns.net na 45.60.74.103. Wszystkie trzy zwracały charakterystyczne nagłówki i ciasteczka Impervy. Zasób /_incapsula_resource?NWQ=1 zwracał dla każdej z nich: PoP-Name: war, Proxy-Name: prx12, Proxy-Id: 682 oraz komunikat „You reached war-prx12 at 45.60.74.103 proxy_id:682”. Oznaczenie war jest zgodne z identyfikacją węzła jako warszawskiego; sam pomiar identyfikuje nazwę podaną przez usługę.

Pomiar o 17:39. Zachowano adres IP 45.60.74.103 oraz SNI api.ksef.mf.gov.pl, a zmieniano tylko nagłówek Host. Dla api.ksef.mf.gov.pl otrzymano 405, Server: Kestrel i identyfikator 3296082 w ciasteczkach Impervy. Dla ksef.mf.gov.pl otrzymano 200, stronę główną i identyfikator 3145187. Dla api-test.ksef.mf.gov.pl otrzymano 405, Server: Kestrel i identyfikator 3285211. Wszystkie odpowiedzi zawierały X-CDN: Imperva. Zmieniała się więc zarówno odpowiedź aplikacji, jak i oznaczenie serwisu w warstwie Impervy.

Ocena dowodu. Sama zależność odpowiedzi aplikacji od Host nie lokalizuje terminacji TLS, ponieważ nagłówek może zostać odczytany na zapleczu. Lokalizuje ją natomiast to, że identyfikator serwisu w ciasteczkach wystawianych przez Impervę zmienia się razem z nagłówkiem Host. Rozstrzyga też to, że nagłówki i ciasteczka Impervy oraz jej odpowiedź diagnostyczna znajdują się wewnątrz zaszyfrowanej odpowiedzi HTTP (punkt 2). Terminacja TLS w usłudze Imperva dla produkcyjnego API jest więc ustalona pomiarem. Wniosek o technicznej dostępności niezaszyfrowanej dodatkowo treści HTTP dotyczy komponentu kończącego TLS; nie dowodzi jej zapisywania, dostępu określonych pracowników ani przekazywania służbom.

Pomiar o 17:41. Dla ap.ksef.mf.gov.pl wymuszono połączenie z 45.60.186.93 i zachowano SNI portalu. Własny Host dał 200, stronę aplikacji i mechanizm f5_cspm; Host api.ksef.mf.gov.pl dał odmienną stronę błędu 404. Dla qr.ksef.mf.gov.pl wymuszono 45.60.187.129 i zachowano SNI serwisu QR; oba warianty Host zwróciły 404 oraz Server: Kestrel. Nie uzyskano diagnostyki Impervy. W każdej próbie curl raportował oczekiwany REMOTE_IP oraz TLS_VERIFY=0 (w curl wartość 0 oznacza poprawną weryfikację certyfikatu). Poprawna weryfikacja certyfikatu nie identyfikuje operatora terminacji TLS.

Granica rozpoznania portalu i QR. Z wynikami zgodne są co najmniej dwa warianty: przekazywanie przez Impervę zaszyfrowanego ruchu do infrastruktury MF albo terminacja w konfiguracji, która nie ujawnia charakterystycznych nagłówków i diagnostyki. Test nie rozstrzyga między nimi ostatecznie, ale wynik testu nagłówka Host przemawia za pierwszym wariantem. Nie można więc zapewniać, że Imperva odczytuje treść w tych dwóch serwisach, ani że nie ma takiej możliwości. Wiążące ustalenie wymaga informacji o konfiguracji lub obserwacji po stronie infrastruktury.

Znaczenie dla głównej tezy. Niepewność dotycząca portalu i QR nie usuwa ryzyka wynikającego z metadanych dostępnych na bramce API. Podmiot posiadający komplet wartości wymaganych przez mechanizm anonimowy może sam wystąpić jako klient portalu. Taki scenariusz jest aktywnym pobraniem dokumentu, a nie biernym odczytem transmisji i nie jest dowodem faktycznego nadużycia.

Pozostałe ograniczenia oceny. Przechwycony token działa w granicach uprawnień i czasu ważności; samo uprawnienie wystawiania nie dowodzi prawa odczytu, a łączenie obu uprawnień w jednej sesji jest prawdopodobne w programach obsługujących sprzedaż i zakupy, choć jego częstości nie ustalono (typ D). Poprawne uwierzytelnienie przechwyconym tokenem nie oznacza niewykrywalności nadużycia. Porównanie zagranicznych systemów opisuje ich zbadane punkty wejścia, a nie pełną kontrolę nad całym przetwarzaniem. Certyfikat urzędu, krajowy adres IP i brak nagłówków WAF nie dowodzą wyłącznej kontroli urzędu nad terminacją. Podczas weryfikacji z 19 października 2026 r. nie powtarzano pełnego audytu dla wszystkich trzydziestu państw.

Interpretacja danych i standardów. Szereg faktur może dostarczać cennych przesłanek o dostawach i zależnościach przemysłowych, lecz zaliczki, korekty, pakiety usług i opóźnienia rozliczeń ograniczają dokładność odtwarzania produkcji. Same faktury nie określają pełnej marży bez danych kosztowych. Zasada Kerckhoffsa nie wymaga ujawniania każdego szczegółu operacyjnego, a NIST SP 800-207 nie ustanawia bezwzględnego zakazu technicznego dostępu dostawcy do przetwarzanych danych. Postulat ograniczenia takiego dostępu należy uzasadniać modelem zagrożeń. Brak jawnej umowy nie dowodzi ani braku prawnych ograniczeń operatora, ani braku kontroli państwa.

Źródła wykorzystane w dodatkowej weryfikacji: produkcyjna specyfikacja API https://api.ksef.mf.gov.pl/docs/v2/openapi.json; dokumentacja pobierania https://github.com/CIRFMF/ksef-api/blob/main/pobieranie-faktur/pobieranie-faktur.md; dokumentacja uwierzytelniania https://github.com/CIRFMF/ksef-api/blob/main/uwierzytelnianie.md; rozporządzenie https://eli.gov.pl/eli/DU/2025/1815/ogl/pol/pdf; NIST https://csrc.nist.gov/pubs/sp/800/207/final; komunikat Prokuratury Krajowej o granicach ustaleń w sprawie Pegasusa https://www.gov.pl/web/prokuratura-krajowa/pegasus-opinia. Stan analizy: 19 października 2026 r.

Autorstwo i weryfikacja

Autor: Grzegorz GPS Świderski. Materiał powstał na podstawie moich licznych artykułów i obywatelskich audytów technicznych KSeF publikowanych od lutego 2026 r. Wykorzystałem też pomiary, które wykonałem z sieci w Polsce 19 października 2026 r.

Wykorzystanie narzędzi AI: przy redakcji, analizie źródeł i kontroli spójności korzystałem z modeli językowych: Claude Opus 5.5 firmy Anthropic, ChatGPT-6 Astra firmy OpenAI oraz Gemini Aragon firmy Google. Modele sprawdzały twierdzenia w źródłach pierwotnych, wskazywały nieścisłości i proponowały ostrożniejsze sformułowania. Część pomiarów kontrolnych spoza Polski wykonał model Claude (punkt 8).