Co mówią te dwie liczby
Producent płytek, modułów komunikacyjnych czy SoM-ów jest dostawcą komponentu dla innych producentów. Jeśli integrator znajdzie podatność w module, w BSP albo w stosie sieciowym, CRA nakazuje mu zgłosić ją producentowi komponentu (art. 13 ust. 6). Musi więc wiedzieć, dokąd napisać. W tym segmencie plik security.txt ma prawie co czwarta firma (18 z 75). To najlepszy wynik w przeglądzie, ale wciąż trzy firmy na cztery nie podają tej informacji w standardowym miejscu.
Segment IoT i smart home/budynek jest w próbie największy (392 firmy). Plik ma w nim 50 firm, czyli mniej więcej co ósma. To urządzenia pracujące u klientów latami, więc błąd w firmware może wyjść na jaw długo po sprzedaży.
Przedziały 95% (15,8…34,8% dla embedded, 9,8…16,4% dla IoT) nakładają się nieznacznie, a grupa embedded jest mała, więc różnicę traktujemy jako wyraźny sygnał, nie dokładny pomiar. Przegląd nie wyjaśnia, skąd się bierze.
Pomiar w skrócie
- Co sprawdzaliśmy: czy producent publikuje plik security.txt zgodny z RFC 9116, czyli plik tekstowy pod adresem /.well-known/security.txt, który mówi, gdzie zgłosić podatność.
- Kogo: 1 691 producentów z 30 krajów Europy, którzy pod własną marką wytwarzają sprzęt lub oprogramowanie z elementami cyfrowymi. Firmy pochodzą z publicznych list wystawców targów (m.in. embedded world, SPS, Hannover Messe, MTP Poznań) i członków stowarzyszeń branżowych, bez doboru pod kątem bezpieczeństwa. Wybraliśmy 1 752 firmy, a 61 wyłączyliśmy, bo ich strony nie odpowiadały.
- Kiedy i jak: stan na 30.09.2026 (Expires sprawdzone ponownie 1.10.2026); jedna domena na firmę, 1…2 zapytania HTTPS GET (do 4 z wariantem www.), najpierw /.well-known/security.txt, potem /security.txt. Bez logowania, testów podatności i skanowania portów. Plik liczy się, gdy serwer zwraca kod 200, a w treści jest pole Contact. Plik kompletny ma dodatkowo pole Policy i ważne pole Expires.
Ograniczenia. To przegląd, a nie badanie reprezentatywne. Wystawcy targów to częściej większe firmy, a Niemcy stanowią 48,7% próby. Odpowiedzi 403, 429 i 5xx (62 domeny) liczymy jako brak pliku, choć mogą oznaczać blokadę automatów; bez nich wynik ogólny wynosi 17,2% zamiast 16,6%. Sprawdzamy obecność pól, a nie to, czy adres z pola Contact działa. Publikujemy tylko wyniki zbiorcze, bez nazw firm.
Najważniejsze: brak security.txt nie oznacza niezgodności z CRA. Firma może przyjmować zgłoszenia przez stronę PSIRT, formularz albo adres podany gdzie indziej. security.txt to jedyny sygnał, który da się u każdej firmy sprawdzić z zewnątrz w ten sam sposób.
Wyniki
Segmenty
Tuż za embedded jest automatyka przemysłowa i OT (23,3%, 67 z 287). Poniżej średniej dla całej próby (16,6%) wypadają IoT (12,8%), ładowanie EV i urządzenia energetyczne (10,0%) oraz inne urządzenia podłączone (7,8%). Sprzęt sieciowy i telekomunikacyjny ma 18,8% (9 z 48), ale przy tak małej grupie przedział jest szeroki (10,2…31,9%) i wynik nie odróżnia się wyraźnie od średniej.
Plik kompletny i częściowy
Plik security.txt ma 16,6% sprawdzonych firm (280 z 1 691), ale kompletny, czyli z polem Policy i ważną datą Expires, tylko 7,7% (130). Pole Policy ma 8,9% firm, ważne Expires 14,2%. Ponad połowa znalezionych plików (150 z 280) nie spełnia więc kryterium kompletności. Co siódmy plik (14,3%, 40 z 280) ma problem z datą ważności. Podpis OpenPGP ma 34 pliki, a wzmiankę o CRA tylko 10 (0,6% firm).
Polska i Niemcy
Wśród 15 krajów z co najmniej 20 firmami w próbie Polska ma obok Włoch (3,9%) najniższy wynik: 4,0% (5 ze 126). Niemcy: 19,9% (164 z 823). Polskie firmy pochodzą częściowo z innych źródeł, dlatego porównaliśmy też wyłącznie wystawców tych samych targów międzynarodowych: 4,8% (2 z 42) wobec 19,9% (155 z 778), (test Fishera, p = 0,014). Polska część próby jest mała, więc to wyraźny sygnał, a nie dokładny pomiar. Różnice między Niemcami, Austrią, Szwajcarią i Holandią mieszczą się w niepewności i nie tworzą rankingu.
Jak wygląda poprawny plik
Przykład pliku zgodnego z RFC 9116 (domena przykładowa):