Piątek, na którym skończyło się czytanie ze zrozumieniem

W piątek 11 września 2026 roku, gdzieś między poranną kawą a pierwszym standupem, w kilkuset polskich firmach produkujących oprogramowanie, sterowniki, kamery, terminale płatnicze i systemy automatyki wydarzyło się dokładnie nic. Nikt nie dostał maila z Brukseli. Nie zadzwonił żaden inspektor. Nie przyszła żadna decyzja. A jednak tego dnia zmienił się status prawny każdej z tych firm — i każdego produktu, który kiedykolwiek sprzedały na rynek Unii Europejskiej.

Tego samego dnia Europejska Agencja ds. Cyberbezpieczeństwa uruchomiła Single Reporting Platform — jednolitą platformę zgłoszeniową przewidzianą w art. 16 rozporządzenia (UE) 2024/2847, znanego szerzej jako Cyber Resilience Act, czyli akt o cyberodporności. Komisja Europejska zaktualizowała swoją stronę poświęconą obowiązkom raportowania z datą 11 września 2026 r. i jednym zdaniem, które od tej chwili organizuje życie całej branży: od tego dnia producenci są zobowiązani zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty mające wpływ na bezpieczeństwo produktów z elementami cyfrowymi.

Przez niemal dwa lata CRA funkcjonowało w polskiej debacie jako sprawa odległa. Rozporządzenie weszło w życie 10 grudnia 2024 r., pełne stosowanie przewidziano na 11 grudnia 2027 r., a między tymi datami rozciągał się komfortowy horyzont, w którym dało się mówić „zdążymy", „to jeszcze nie teraz", „poczekamy na normy zharmonizowane". Art. 71 ust. 2 rozporządzenia wyłamał z tego harmonogramu jeden fragment i przesunął go o piętnaście miesięcy wcześniej. Tym fragmentem jest art. 14 — i to właśnie on ruszył siedem dni temu.

Różnica między 11 września 2026 a 11 grudnia 2027 nie jest różnicą kalendarzową. Jest różnicą kategorii. Wymagania zasadnicze z załącznika I to projekt, który się planuje, budżetuje i wdraża w cyklach kwartalnych. Obowiązek zgłoszenia w 24 godziny to zdolność operacyjna, którą albo się ma w momencie zdarzenia, albo nie ma jej wcale — i żadne późniejsze nadrabianie tego nie naprawi.

Co dokładnie zaczęło obowiązywać

Art. 14 CRA wprowadza dwie odrębne kategorie zdarzeń podlegających zgłoszeniu i warto je rozdzielić, bo w praktyce mylą się nawet zespołom, które regulację czytały.

Pierwsza to aktywnie wykorzystywana podatność w produkcie z elementami cyfrowymi. Nie każda podatność — tylko taka, co do której producent ma wiarygodne przesłanki, że ktoś już ją wykorzystuje w realnym ataku. Zwykłe zgłoszenie od badacza bezpieczeństwa, wynik skanu, wpis w bazie CVE bez dowodów eksploatacji — to jeszcze nie uruchamia zegara. Ale telefon od klienta, który mówi „ktoś wszedł nam przez wasz moduł", log wskazujący na udany exploit albo wzmianka o gotowym narzędziu krążącym w sieci — uruchamia.

Druga kategoria to poważny incydent mający wpływ na bezpieczeństwo produktu. Tu punkt ciężkości jest inny: chodzi o zdarzenie po stronie producenta lub jego infrastruktury, które negatywnie rzutuje na bezpieczeństwo produktów już znajdujących się u klientów. Kompromitacja systemu budowania oprogramowania, przejęcie repozytorium, podmiana aktualizacji, wyciek kluczy podpisujących — klasyczne scenariusze ataku na łańcuch dostaw, których polska branża doświadczyła w ostatnich latach więcej, niż publicznie przyznaje.

Obie kategorie łączy jedna cecha, którą trzeba sobie uczciwie powiedzieć: to producent ocenia, czy próg został przekroczony, a potem ponosi odpowiedzialność za tę ocenę. Nie ma organu, który zadzwoni i powie „to już poważne". Jest za to art. 64, o którym będzie dalej.

Warto też odnotować, kogo art. 14 na razie nie dotyczy. Zgodnie z art. 71 ust. 2 obowiązki raportowania spoczywające na opiekunach oprogramowania open source — tak zwanych stewardach, uregulowane w art. 24 ust. 3 — zaczną obowiązywać dopiero 11 grudnia 2027 r., razem z resztą rozporządzenia. Producent komercyjny, który buduje swój produkt na komponentach open source, tej ulgi nie ma. Odpowiada za cały produkt, łącznie z każdą biblioteką, którą do niego wciągnął.

Dwadzieścia cztery, siedemdziesiąt dwie, czternaście

Arytmetyka art. 14 jest krótka i nie podlega negocjacji, więc warto ją zapamiętać jak numer telefonu alarmowego.

Wczesne ostrzeżenie — 24 godziny od momentu, w którym producent powziął wiedzę o aktywnie wykorzystywanej podatności lub poważnym incydencie. To zgłoszenie minimalne: co się stało, jakiego produktu dotyczy, czy są już podjęte działania. Nie musi zawierać analizy przyczyn źródłowych ani gotowej poprawki. Musi po prostu być.

Pełne zgłoszenie — 72 godziny. Tu wymagany jest już opis podatności lub incydentu, ocena jego wagi i wpływu, informacja o dostępnych środkach zaradczych oraz — w przypadku podatności — wskazanie, czy istnieje obejście, które klient może zastosować od razu.

Raport końcowy — 14 dni od udostępnienia środka naprawczego w przypadku aktywnie wykorzystywanej podatności, albo miesiąc od zgłoszenia siedemdziesięciodwugodzinnego w przypadku poważnego incydentu. Raport końcowy zamyka sprawę: opisuje podatność wraz z jej charakterystyką techniczną, wskazuje wektor eksploatacji i dokumentuje wdrożoną poprawkę.

Największym praktycznym problemem nie są te liczby, tylko zdanie, które je poprzedza: „od momentu powzięcia wiedzy". W wielu firmach nie da się dziś odpowiedzieć na pytanie, kiedy organizacja dowiedziała się o czymkolwiek. Informacja o eksploatacji trafia do inżyniera wsparcia w zgłoszeniu z helpdesku, leży w kolejce trzy dni, potem idzie do developera, który uznaje, że to konfiguracja u klienta, a po tygodniu ktoś z produktu zaczyna kojarzyć fakty. W świecie sprzed 11 września to była nieefektywność. Od 11 września to jest przekroczenie terminu ustawowego o sześć dni — i w razie postępowania trzeba będzie udowodnić, kiedy dokładnie ta wiedza powstała. Bez rejestru zgłoszeń z twardymi znacznikami czasu takiego dowodu nie ma.

Kto jest producentem, chociaż jest przekonany, że nie jest

Najczęstsze nieporozumienie wokół CRA brzmi tak: „my nie produkujemy sprzętu, więc nas to nie dotyczy". Rozporządzenie definiuje produkt z elementami cyfrowymi szeroko — obejmuje zarówno urządzenia, jak i samo oprogramowanie, w tym oprogramowanie sprzedawane jako produkt niezależny od sprzętu.

Producentem w rozumieniu CRA jest zatem polski software house, który sprzedaje licencje na swój system dziedzinowy do jednostek samorządu. Jest nim dostawca systemu obiegu dokumentów wdrażanego w sądach i urzędach. Jest nim producent sterowników do przepompowni, firma dostarczająca oprogramowanie SCADA do ciepłowni, twórca aplikacji mobilnej do obsługi mieszkańca, integrator, który wypuszcza własną nakładkę pod swoją marką, i importer sprowadzający kamery przemysłowe spoza Unii i sprzedający je pod własnym logo. Produkty czysto usługowe, dostarczane wyłącznie jako zdalna usługa chmurowa, są w innej sytuacji prawnej — ale granica bywa cienka i sam fakt, że coś nazywa się „usługą", nie przesądza o niczym. Jeśli klient instaluje u siebie agenta, bibliotekę, aplikację desktopową albo firmware, rozmowa o CRA staje się nieunikniona.

To ma bardzo konkretne przełożenie na polski rynek. Znaczna część oprogramowania obsługującego dziś polskie gminy, spółki komunalne, szpitale i sądy pochodzi od dostawców zatrudniających od kilkunastu do stu kilkudziesięciu osób. Firm, które mają świetnych programistów, dobrą znajomość dziedziny — i zwykle zero sformalizowanego procesu obsługi podatności. To one od 11 września mają dobę na wykonanie czynności, której nigdy wcześniej nie ćwiczyły.

Pułapka legacy, czyli produkty starsze niż obowiązek

Jest w tym wszystkim element, który umyka najczęściej i potrafi być najdroższy. Obowiązki raportowania z art. 14 stosuje się od 11 września 2026 r. do wszystkich produktów z elementami cyfrowymi objętych zakresem CRA, które zostały udostępnione na rynku unijnym również przed dniem pełnego stosowania rozporządzenia.

Innymi słowy: system, który sprzedaliście w 2019 roku i który do dziś pracuje w trzydziestu urzędach, jest objęty obowiązkiem zgłoszenia. Firmware kamery z 2021 roku, wciąż wiszącej na słupie przy oczyszczalni, jest objęty. Moduł, którego autor odszedł z firmy trzy lata temu i którego nikt od tamtej pory nie otwierał, jest objęty. Wymagania zasadnicze z załącznika I dotyczą produktów wprowadzanych do obrotu po pełnym uruchomieniu rozporządzenia — ale obowiązek zgłoszenia, że coś, co już jest u klientów, jest właśnie aktywnie atakowane, sięga wstecz.

To wywraca praktyczny sens pytania „jakie produkty musimy przygotować pod CRA". Właściwe pytanie brzmi: jakie produkty mamy w ogóle w rynku i czy potrafimy je wszystkie wymienić z pamięci wraz z wersjami. Doświadczenie z audytów pokazuje, że większość dostawców nie potrafi. Ewidencja wdrożeń rozjeżdża się z rejestrem umów, rejestr umów z systemem serwisowym, a system serwisowy z rzeczywistością u klienta, który pięć lat temu dostał wersję z indywidualną modyfikacją i nikt już nie pamięta, czym się różniła.

Jedna platforma, wszystkie CSIRT-y

Mechanika zgłoszenia została zaprojektowana tak, żeby producent nie musiał raportować dwadzieścia siedem razy. Zgłoszenie składa się raz, przez platformę SRP prowadzoną przez ENISA. Adresatem jest zespół CSIRT państwa członkowskiego, w którym producent ma główną siedzibę, a informacja — poza sytuacjami wyjątkowymi — trafia równolegle do ENISA. CSIRT, który zgłoszenie otrzymał jako pierwszy, przekazuje je bez zbędnej zwłoki pozostałym zespołom CSIRT na terytoriach, gdzie produkt był udostępniany.

Dla producenta z główną siedzibą w Polsce oznacza to, że adresatem merytorycznym jest CSIRT NASK, czyli zespół realizujący zadania CERT Polska. Ta sama instytucja, która pełni funkcję koordynatora w procesie skoordynowanego ujawniania podatności i która od 2 września 2026 r. udostępnia w serwisie moje.cert.pl moduł „Podatności w używanych technologiach", podający spersonalizowany strumień informacji o nowych lukach w technologiach faktycznie używanych przez zarejestrowany podmiot, wraz ze wstępną oceną ryzyka.

Przewidziano też wentyl bezpieczeństwa. W wyjątkowych okolicznościach, na uzasadnionych podstawach związanych z cyberbezpieczeństwem, CSIRT może wstrzymać rozpowszechnienie zgłoszenia do pozostałych zespołów — chodzi o sytuacje, w których natychmiastowe rozesłanie informacji o niezałatanej, aktywnie wykorzystywanej luce zwiększyłoby ryzyko zamiast je zmniejszać. Komisja przyjęła 11 grudnia 2025 r. akt delegowany doprecyzowujący warunki stosowania tego wyjątku. Producent nie ma na to wpływu i nie może na tym budować strategii; to jest decyzja organu, nie strony.

Polski kontekst: pięćdziesiąt pięć tysięcy powodów do pośpiechu

Skala problemu, w którym ten obowiązek osadzono, jest łatwa do zmierzenia. CERT Polska podał na początku września, że w ciągu pierwszych sześciu miesięcy 2026 roku odnotowano na świecie blisko 55 tysięcy nowych podatności — więcej niż przez cały rok 2024, przy realnej perspektywie pobicia rekordu z 2025 roku jeszcze w trzecim kwartale. Sztuczna inteligencja skraca dystans między publikacją informacji o luce a pierwszą próbą jej wykorzystania; to, co dawniej było oknem kilkunastu dni, dziś bywa oknem kilkunastu godzin.

Jednocześnie polski rynek wchodzi w ten obowiązek w momencie wyjątkowo obciążonym regulacyjnie. Do 3 października 2026 r. podmioty kluczowe i ważne muszą złożyć wniosek o wpis do wykazu prowadzonego na podstawie znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa — zostało piętnaście dni. Do 3 kwietnia 2027 r. te same podmioty mają wdrożyć system zarządzania bezpieczeństwem informacji. W tle biegną terminy aktu o sztucznej inteligencji, a sektor finansowy trzeci rok układa się z DORA.

Skutek jest taki, że CRA konkuruje o uwagę zarządów z trzema innymi zegarami — i w większości firm przegrywa, bo nie ma za sobą ani wpisu do rejestru, ani kontroli sektorowej, ani żadnego zdarzenia, które by o sobie przypomniało. Przypomni o sobie dopiero w dniu, w którym klient napisze, że przez wasz produkt ktoś wszedł mu do sieci. Wtedy zegar będzie już biegł od kilku godzin, a nikt w firmie nie będzie wiedział, że biegnie.

Kary są wysokie, ale nie one są tu najgroźniejsze

Art. 64 CRA konstruuje sankcje w sposób znajomy każdemu, kto przeszedł przez wdrożenie RODO. Za naruszenie wymagań zasadniczych z załącznika I oraz obowiązków z art. 13 i 14 — a więc również obowiązku zgłoszenia — grozi administracyjna kara pieniężna do 15 mln euro lub 2,5 procent całkowitego rocznego światowego obrotu, w zależności od tego, która kwota jest wyższa. Za naruszenie pozostałych obowiązków rozporządzenia pułap wynosi 10 mln euro lub 2 procent obrotu. Za przekazanie organom informacji nieprawdziwych, niekompletnych lub wprowadzających w błąd — 5 mln euro lub 1 procent.

Te liczby robią wrażenie na slajdach, ale w realnym rachunku ryzyka polskiego dostawcy systemów dziedzinowych są to na razie liczby abstrakcyjne. Znacznie bliżej skóry leżą dwie inne konsekwencje.

Pierwsza to utrata rynku zamówień publicznych. Zamawiający w samorządach i podmiotach publicznych coraz częściej wpisują do specyfikacji wymagania wynikające z regulacji unijnych, bo sami są za nie rozliczani. Dostawca, który nie potrafi wykazać, że ma proces obsługi podatności zgodny z art. 14, zaczyna wypadać z postępowań, zanim jeszcze ktokolwiek nałoży na niego jakąkolwiek karę. Rynek wyprzedza organ nadzoru o kilkanaście miesięcy — tak samo, jak stało się przy RODO w latach 2018–2019.

Druga to odpowiedzialność kontraktowa wobec klienta. Gmina, która przez waszą niezgłoszoną lukę straci dostępność systemu, będzie miała w ręku argument, którego dotąd nie miała: obiektywny, ustawowy, datowany obowiązek, którego dostawca nie dopełnił. To zmienia pozycję negocjacyjną w sporze o karę umowną znacznie skuteczniej niż jakakolwiek grzywna z Brukseli.

Druga strona lady: co powinien zrobić nabywca

CRA nakłada obowiązki na producentów, ale jego skutki najsilniej odczują podmioty, które te produkty kupują i eksploatują — a więc urzędy gmin, spółki wodociągowe, ciepłownie, zakłady gospodarki odpadami, szpitale i sądy. Dla nich art. 14 jest przede wszystkim nowym źródłem informacji, które trzeba umieć odebrać i przetworzyć.

Jeżeli producent zgłosi aktywnie wykorzystywaną podatność w produkcie, który u was pracuje, informacja o tym prędzej czy później do was dotrze — przez samego producenta, przez CSIRT albo przez publiczny komunikat. Pytanie brzmi, czy w waszej organizacji istnieje ktoś, kto tę informację odbierze poza godzinami pracy, oceni jej wpływ na wasze konkretne wdrożenie i uruchomi procedurę. Jeżeli nie, to obowiązek producenta wygeneruje wam wiedzę, z którą nic nie zrobicie — a w razie incydentu będziecie mieli udokumentowane, że wiedzieliście.

Drugi wniosek dotyczy umów. Warto już teraz przejrzeć kontrakty serwisowe z dostawcami oprogramowania pod kątem trzech rzeczy: czy dostawca zobowiązał się informować was o podatnościach w swoim produkcie i w jakim terminie; czy macie zagwarantowany kanał kontaktu działający poza godzinami pracy; oraz czy w umowie jest cokolwiek o obowiązku dostarczenia poprawki w określonym czasie. W większości umów zawartych przed 2025 rokiem nie ma żadnego z tych trzech elementów, a aneksowanie ich przy okazji przedłużenia jest znacznie tańsze niż negocjowanie w dniu ataku.

Trzeci wniosek jest najbardziej niewygodny. Część oprogramowania pracującego dziś w polskiej administracji pochodzi od dostawców, którzy nie istnieją, nie rozwijają już produktu albo nie odpowiadają na korespondencję. Dla takiego produktu art. 14 nigdy nie zadziała, bo nie ma kto zgłosić. To nie jest problem regulacyjny, tylko problem inwentaryzacyjny — i rozwiązać go można wyłącznie planem wymiany, a nie kolejną klauzulą w umowie.

Czego naprawdę wymaga gotowość na zgłoszenie w dobę

Zgłoszenie w 24 godziny wygląda na zadanie komunikacyjne. W rzeczywistości jest testem czterech rzeczy, których nie da się zaimprowizować w dniu zdarzenia.

Po pierwsze, kanału przyjmowania informacji o podatnościach. Musi istnieć jeden publicznie znany adres — security@, strona z polityką ujawniania, punkt w dokumentacji produktu — i musi być on monitorowany również wtedy, gdy autor maila pisze po angielsku, bez tematu, o drugiej w nocy. Badacz bezpieczeństwa, który nie znajdzie kanału, nie będzie go szukał. Opublikuje to na konferencji albo sprzeda.

Po drugie, rejestru produktów i wersji. Bez wiedzy, które wersje i u których klientów są w rynku, nie da się w ciągu doby ocenić zasięgu ani przygotować sensownego zgłoszenia. To jest ta sama praca inwentaryzacyjna, którą wymusza wdrożenie SZBI — i dobra wiadomość jest taka, że robi się ją raz, a używa w trzech reżimach naraz.

Po trzecie, decyzji o tym, kto klasyfikuje. Ocena, czy podatność jest aktywnie wykorzystywana i czy incydent jest poważny, musi mieć przypisanego właściciela z imienia i nazwiska, zastępcę oraz jasne kryterium eskalacji. Jeżeli klasyfikacja wymaga zebrania zarządu, zegar przegra z kalendarzem.

Po czwarte, przećwiczonej ścieżki do platformy. Konto w SRP, przypisane role, wiedza, kto ma do niej dostęp i co zrobić, gdy ta osoba jest na urlopie. Firmy, które przeszły przez wdrożenie obowiązków zgłoszeniowych z ustawy o krajowym systemie cyberbezpieczeństwa, znają ten wzorzec: sam formularz zajmuje dwadzieścia minut, a uzgodnienie w firmie, kto ma prawo go wysłać, potrafi zająć dwa dni. Doba nie zostawia miejsca na taką dyskusję.

Najskuteczniejszym testem gotowości jest ćwiczenie stołowe na jeden scenariusz: o godzinie 16:40 w piątek klient przysyła loga wskazujące na udany atak przez wasz moduł. Kto to przeczyta? Kto zaklasyfikuje? Kto podejmie decyzję o zgłoszeniu? Kto je wyśle i o której? Firmy, które to ćwiczenie przeprowadziły, zwykle wychodzą z niego z listą ośmiu do dwunastu braków, z których żaden nie wymaga dużych pieniędzy, a wszystkie wymagają decyzji.

Dlaczego z Fib.Code

Fib.Code łączy trzy kompetencje, które przy CRA muszą wystąpić razem: znajomość regulacji unijnych i krajowych w warstwie tekstu prawnego, praktykę budowania systemów zarządzania bezpieczeństwem informacji zgodnych z ISO/IEC 27001 oraz doświadczenie inżynierskie w zarządzaniu podatnościami i obsłudze incydentów. Pracujemy zarówno po stronie producentów oprogramowania i automatyki, jak i po stronie ich klientów — samorządów, spółek komunalnych, podmiotów leczniczych i jednostek wymiaru sprawiedliwości — co daje nam widok z obu stron tej samej umowy.

Nasze podejście opiera się na trzech zasadach. Najpierw inwentaryzacja, potem procedura — żadna polityka obsługi podatności nie ma sensu, dopóki nie wiadomo, jakie produkty i w jakich wersjach są w rynku. Jeden proces, wiele reżimów — obowiązki z art. 14 CRA, wymogi zgłoszeniowe z ustawy o krajowym systemie cyberbezpieczeństwa i art. 33 RODO obsługuje się jedną ścieżką operacyjną z trzema wyjściami, a nie trzema osobnymi procedurami, które i tak nikt nie przeczyta. Ćwiczenie zamiast dokumentu — o skuteczności procedury rozstrzyga nie jej objętość, tylko to, czy zespół przeszedł ją na sucho przed pierwszym prawdziwym zdarzeniem.

Produktem końcowym jest komplet rzeczy do użycia, nie do archiwizacji: rejestr produktów i wersji, publiczny kanał przyjmowania zgłoszeń wraz z polityką ujawniania, macierz decyzyjna klasyfikacji zdarzeń z przypisanymi rolami, gotowe szablony zgłoszenia 24-, 72-godzinnego i raportu końcowego, przećwiczona ścieżka do platformy ENISA oraz protokół z ćwiczenia stołowego, który stanowi dowód należytej staranności na wypadek postępowania.

Co zrobić w poniedziałek

Jedno spotkanie, sześćdziesiąt minut, cztery osoby: osoba odpowiedzialna za produkt, osoba odpowiedzialna za bezpieczeństwo lub IT, ktoś z zarządu i ktoś, kto zna umowy z klientami. Pięć pytań do odpowiedzenia na miejscu, bez odkładania na później.

Pierwsze — czy jesteśmy producentem w rozumieniu CRA i przy których dokładnie produktach. Drugie — czy potrafimy dziś wymienić wszystkie wersje naszych produktów pracujące u klientów, a jeśli nie, do kiedy będziemy potrafili. Trzecie — jaki jest nasz kanał przyjmowania zgłoszeń o podatnościach i kto go czyta w piątek po siedemnastej. Czwarte — kto imiennie decyduje, że podatność jest aktywnie wykorzystywana, i kto go zastępuje. Piąte — kto ma dostęp do platformy SRP i kiedy przeprowadzimy ćwiczenie na jednym scenariuszu.

Termin realizacji do końca września, właściciel wskazany na spotkaniu. To nie jest projekt na kwartał. To jest pięć decyzji, których brak kosztuje dopiero w dniu, w którym zabraknie na nie czasu.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: Cyber Resilience Act — twoje urządzenie z pluskwą wkrótce zniknie z rynku UE, Wykaz KSC: 80 tysięcy podmiotów i termin 3 października 2026, Cyberatak na elektrociepłownię: prywatny APN i droga do sieci OT — razem tworzą obraz jednego zjawiska: odpowiedzialność za bezpieczeństwo przesuwa się w górę łańcucha dostaw, od użytkownika do tego, kto produkt zbudował.