Jest połowa listopada 2026 roku. Dyrektor techniczny firmy, która sprzedaje aplikację do zarządzania flotą i małe urządzenie telematyczne, dostaje od dużego dystrybutora z Niemiec ankietę dostawcy. Pytanie numer siedem brzmi: „Czy posiadacie certyfikat CE zgodny z Cyber Resilience Act? Prosimy o przesłanie kopii”. Dział sprzedaży chce odpowiedzieć do piątku. Ktoś z zarządu proponuje, żeby znaleźć firmę, która „zrobi certyfikację CE” i wystawi dokument.
Problem polega na tym, że dla większości oprogramowania takiego certyfikatu nikt nie wystawi, bo nie jest potrzebny. Oznakowanie CE z CRA to w typowym przypadku samodeklaracja producenta, podpisana pod dokumentacją techniczną i pod procesem obsługi podatności, który ma działać przez cały okres wsparcia. A jedna część tego procesu, zgłaszanie aktywnie wykorzystywanych podatności, obowiązuje już od dwóch miesięcy, także dla produktów, które ta firma sprzedaje od lat.
Ten artykuł jest dla CTO i osób odpowiedzialnych za compliance w firmach, które tworzą i sprzedają oprogramowanie lub urządzenia z oprogramowaniem na rynku UE. Broni jednej tezy, z którą część doradców się nie zgodzi: przygotowania do Cyber Resilience Act trzeba zacząć od okresu wsparcia i zdolności zgłaszania, a nie od pytania o certyfikację CE. Kto zaczyna od certyfikatu, wydaje budżet na najmniej pilny element i zostawia bez właściciela ten, który już dziś jest obowiązkiem prawnym. Opieramy się na tekście rozporządzenia (UE) 2024/2847, na dokumencie „FAQs on the Cyber Resilience Act” służb Komisji Europejskiej (wersja 1.4 z 4 września 2026 roku) i na stronach Komisji poświęconych wdrożeniu CRA.
Dlaczego pytanie „czy macie certyfikat CE” jest złym początkiem przygotowań do CRA?
Bo zakłada, że CRA jest regulacją certyfikacyjną, a w większości przypadków jest regulacją cyklu życia produktu. Rozporządzenie stawia producentowi dwa rodzaje wymagań. Pierwsze dotyczą właściwości produktu (załącznik I część I): brak znanych podatności możliwych do wykorzystania w chwili udostępnienia, bezpieczna konfiguracja domyślna, możliwość usuwania podatności przez aktualizacje, kontrola dostępu, szyfrowanie, minimalizacja danych, ograniczenie powierzchni ataku. Drugie dotyczą procesów (załącznik I część II): identyfikacja komponentów i podatności, usuwanie ich bez zbędnej zwłoki, regularne testy, publikowanie informacji o naprawionych podatnościach, polityka skoordynowanego ujawniania, bezpieczna dystrybucja aktualizacji.
Pierwszą grupę da się sprawdzić w chwili wydania wersji. Drugą trzeba utrzymywać latami. Oznakowanie CE potwierdza, że oba warunki są spełnione, ale nie zastępuje żadnego z nich. Według FAQ Komisji znak CE na produkcie nie może pojawić się, zanim producent przeprowadzi procedurę oceny zgodności z wynikiem pozytywnym, a dla zdecydowanej większości oprogramowania tę procedurę przeprowadza sam producent.
Jest też drugi powód, dla którego certyfikat to zły punkt startu: kolejność terminów. Pełne wymagania, w tym ocena zgodności i oznakowanie CE, obowiązują od 11 grudnia 2027 roku. Ale art. 14, czyli obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów, stosuje się od 11 września 2026 roku. Art. 69 ust. 3 rozciąga go na wszystkie produkty objęte CRA, także wprowadzone na rynek przed grudniem 2027 roku. Firma z naszego przykładu jest więc dziś związana obowiązkiem zgłoszenia w ciągu 24 godzin, jeśli dowie się, że ktoś wykorzystuje podatność w jej urządzeniu, a nie ma jeszcze żadnego obowiązku posiadania znaku CE.
Odpowiedź na ankietę dystrybutora powinna zatem brzmieć mniej więcej tak: „Produkt należy do kategorii domyślnej CRA. Ocenę zgodności przeprowadzimy według modułu A przed 11 grudnia 2027 roku. Proces zgłaszania podatności zgodny z art. 14 działa od września 2026 roku; punkt kontaktowy i polityka ujawniania są tutaj. Okres wsparcia dla obecnej generacji urządzenia kończy się w miesiącu X roku Y”. Taka odpowiedź mówi kupującemu więcej niż kopia jakiegokolwiek certyfikatu.
Które oprogramowanie podlega Cyber Resilience Act, a które nie?
Art. 2 ust. 1 obejmuje produkty z elementami cyfrowymi udostępniane na rynku, których przewidziane zastosowanie lub dające się racjonalnie przewidzieć użycie obejmuje bezpośrednie lub pośrednie, logiczne lub fizyczne połączenie z urządzeniem albo siecią. FAQ Komisji rozkłada to na trzy łączne warunki: produkt spełnia definicję produktu z elementami cyfrowymi, jest udostępniany na rynku i ma (choćby pośrednie) połączenie danych.
Definicja produktu (art. 3 pkt 1) obejmuje oprogramowanie i sprzęt wraz z ich rozwiązaniami zdalnego przetwarzania danych, a także komponenty wprowadzane na rynek osobno. W praktyce to aplikacja mobilna pobierana ze sklepu, program instalowany ze strony producenta, firmware sprzedawany osobno, sterowniki dostarczane z drukarką, system operacyjny laptopa, układ scalony i maszyna przemysłowa. „Połączenie pośrednie” jest szerokie: FAQ podaje jako przykład edytor tekstu offline albo kalkulator, które same nie nawiązują połączenia, ale działają w systemie operacyjnym, który to robi. Poza zakresem są tylko produkty, których przewidziane użycie w ogóle nie obejmuje połączenia: zmywarka czy ekspres do kawy z firmware bez żadnej łączności.
„Udostępnianie na rynku” to dostarczanie produktu w ramach działalności handlowej, odpłatnie lub nieodpłatnie (art. 3 pkt 22). Producentem jest ten, kto opracowuje lub wytwarza produkt albo zleca jego zaprojektowanie, opracowanie lub wytworzenie, i wprowadza go pod własną nazwą lub znakiem towarowym, za opłatą, w zamian za monetyzację albo bezpłatnie. Darmowa aplikacja z reklamami albo bezpłatny klient do płatnej usługi nie wychodzi więc z zakresu przez to, że nie ma ceny.
Wyłączenia są konkretne. CRA nie stosuje się do produktów objętych rozporządzeniami o wyrobach medycznych (2017/745) i wyrobach do diagnostyki in vitro (2017/746), o homologacji pojazdów (2019/2144), do produktów certyfikowanych według rozporządzenia lotniczego (2018/1139) i do wyposażenia morskiego (dyrektywa 2014/90/UE). Rozporządzenie delegowane (UE) 2025/1535 wyłączyło dodatkowo produkty objęte rozporządzeniem 168/2013 o pojazdach dwu- i trzykołowych, z wyjątkiem rowerów ze wspomaganiem kategorii L1e. CRA nie dotyczy też produktów opracowanych lub zmodyfikowanych wyłącznie do celów bezpieczeństwa narodowego lub obronności. Produkty podwójnego zastosowania podlegają mu normalnie.
Dwa wyłączenia mają duże znaczenie dla zespołów inżynierskich. Pierwsze to wytwarzanie na własny użytek: według FAQ narzędzia programistyczne i konfiguracyjne, które producent tworzy dla siebie, nie są objęte CRA, dopóki nie zostaną wprowadzone na rynek jako osobne produkty. Drugie to wersje testowe: art. 4 ust. 3 pozwala udostępniać niedokończone oprogramowanie (alfa, beta, release candidate) przez czas potrzebny na testy, z widocznym oznaczeniem, że nie spełnia wymagań rozporządzenia. Motyw 37 dodaje, że użytkowników nie wolno zmuszać do przejścia na taką wersję.
Co z SaaS, aplikacjami w chmurze i oprogramowaniem na zamówienie?
To pytanie zadaje każdy CTO firmy produktowej i odpowiedź jest mniej wygodna, niż się wydaje. Motyw 12 rozporządzenia mówi wprost, że usługi chmurowe zaprojektowane i opracowane poza odpowiedzialnością producenta produktu z elementami cyfrowymi nie są objęte CRA, a modele SaaS, PaaS i IaaS obejmuje dyrektywa NIS2. Czysty SaaS, czyli aplikacja dostępna wyłącznie przez przeglądarkę, bez instalowanego klienta, nie jest więc produktem w rozumieniu CRA.
Granica przebiega przez definicję zdalnego przetwarzania danych (art. 3 pkt 2): przetwarzanie na odległość, dla którego oprogramowanie zostało zaprojektowane przez producenta lub na jego odpowiedzialność i bez którego produkt nie mógłby wykonywać jednej ze swoich funkcji. Motyw 12 podaje przykład funkcji chmurowych producenta urządzeń inteligentnego domu, które pozwalają sterować urządzeniem zdalnie. Jeśli sprzedajesz aplikację mobilną albo desktopową, a Twój backend jest niezbędny do działania jej funkcji, backend wchodzi do zakresu razem z aplikacją. Ocena ryzyka, ochrona danych, obsługa podatności i dokumentacja muszą obejmować oba elementy. Komisja zapowiedziała w FAQ osobne wytyczne do zdalnego przetwarzania danych; wytyczne opublikowane 27 lipca 2026 roku (dokument C(2026) 5252, niewiążący) obejmują, według komunikatu Komisji, właśnie zakres w odniesieniu do zdalnego przetwarzania danych i wolnego oprogramowania.
Konsekwencja dla architektury jest praktyczna. Firma, która ma produkt SaaS i równolegle aplikację mobilną z funkcjami działającymi wyłącznie przez jej API, ma de facto dwa reżimy: NIS2 dla usługi (jeśli spełnia progi wielkości z dyrektywy) i CRA dla aplikacji wraz z częścią backendu, która jest jej zdalnym przetwarzaniem danych. Warto to rozpisać na diagramie komponentów, zanim ktoś przyjmie, że „jesteśmy SaaS, więc nas to nie dotyczy”.
Drugi przypadek, ważny dla software house’ów i ich klientów, to oprogramowanie szyte na miarę. FAQ Komisji (pkt 4.2.5) wymienia jako przykład produktu „tailor-made” oprogramowanie opracowane na potrzeby konkretnego użytkownika biznesowego i produkty integrowane w kontrolowanych środowiskach klienta, objęte szczególnymi warunkami umowy. To ważny sygnał: Komisja zakłada, że takie oprogramowanie mieści się w CRA, jeśli jest dostarczane w ramach działalności handlowej. Rozporządzenie pozwala w tym przypadku umownie odejść tylko od dwóch wymagań: bezpiecznej konfiguracji domyślnej i bezpłatnych aktualizacji bezpieczeństwa. Wszystko inne obowiązuje. Platforma CRM sprzedawana wielu firmom z drobnymi dostosowaniami nie jest produktem szytym na miarę.
Kto jest wtedy producentem: wykonawca czy zamawiający? Zależy od tego, kto wprowadza produkt pod własną nazwą. Jeśli klient zleca budowę i sprzedaje produkt pod swoją marką, producentem jest klient, bo definicja obejmuje zlecenie zaprojektowania lub wytworzenia. Jeśli software house dostarcza system pod własną nazwą jednemu klientowi, sytuacja jest mniej oczywista i wymaga analizy prawnej konkretnej umowy. Pisaliśmy o tym przy okazji wymagań security by design i zero trust wobec dostawcy; tutaj wystarczy zapamiętać, że to pytanie trzeba rozstrzygnąć w umowie, a nie po pierwszym incydencie.
Kiedy open source podlega CRA i kim jest opiekun oprogramowania otwartego?
Wolne i otwarte oprogramowanie podlega CRA tylko wtedy, gdy jest udostępniane na rynku, czyli dostarczane w ramach działalności handlowej. Motyw 18 doprecyzowuje: wolne oprogramowanie, którego producent nie monetyzuje, nie jest dostarczane w ramach działalności handlowej. Komponent przeznaczony do integracji przez innych producentów jest udostępniany na rynku tylko wtedy, gdy monetyzuje go jego pierwotny producent. Samo to, że projekt otrzymuje wsparcie finansowe od firm, że firmy do niego kontrybuują albo że ma regularne wydania, nie przesądza o charakterze handlowym. Rozporządzenie nie stosuje się też do osób, które kontrybuują kod do projektów, za które nie odpowiadają.
Między producentem a niehandlowym projektem rozporządzenie tworzy trzecią kategorię: opiekuna oprogramowania otwartego (w angielskiej wersji „open-source software steward”). To osoba prawna inna niż producent, która systematycznie i stale wspiera rozwój konkretnego wolnego oprogramowania przeznaczonego do celów komercyjnych i zapewnia jego prawidłowe funkcjonowanie (art. 3 pkt 14). Motyw 19 wymienia fundacje i podmioty publikujące wolne oprogramowanie w kontekście biznesowym, także non-profit. Opiekun ma lekki reżim z art. 24: politykę cyberbezpieczeństwa dla bezpiecznego rozwoju i obsługi podatności, współpracę z organami nadzoru rynku i, od 11 grudnia 2027 roku, obowiązki zgłaszania w zakresie, w jakim uczestniczy w rozwoju produktu. Opiekun nie umieszcza oznakowania CE i, zgodnie z art. 64 ust. 10, nie podlega karom administracyjnym.
Dla producenta, który buduje na open source, najważniejszy jest jednak art. 13 ust. 5. Producent musi zachować należytą staranność przy integrowaniu komponentów od stron trzecich, także wolnego oprogramowania, które nie zostało udostępnione na rynku. Odpowiada za produkt w całości, łącznie ze wszystkimi bibliotekami. Gdy znajdzie podatność w komponencie, zgłasza ją osobie lub podmiotowi, który go utrzymuje, a jeśli sam przygotował poprawkę, udostępnia jej kod (art. 13 ust. 6). FAQ podaje przykłady działań w ramach należytej staranności: sprawdzenie historii aktualizacji komponentu, przegląd baz podatności, analiza składu oprogramowania, testy bezpieczeństwa, izolowanie najbardziej krytycznych komponentów, sprawdzenie okresu wsparcia komponentu i przegląd jego SBOM, jeśli jest dostępny.
To przesuwa ciężar w stronę, którą wiele firm niedoszacowuje. Jeśli biblioteka, z której korzystasz, przestanie być utrzymywana w trakcie Twojego okresu wsparcia, a pojawi się w niej podatność, FAQ (pkt 4.3.7) mówi jasno: musisz ją usunąć innymi środkami, na przykład wymieniając komponent albo samodzielnie przygotowując poprawkę. Wybór zależności staje się decyzją o zobowiązaniu na pięć lub więcej lat.
Czy Twój produkt jest ważny albo krytyczny i co to zmienia w ocenie zgodności?
Klasa produktu decyduje o tym, czy w ogóle potrzebujesz jednostki notyfikowanej. Rozporządzenie zna cztery poziomy: kategorię domyślną, produkty ważne klasy I i klasy II (załącznik III) oraz produkty krytyczne (załącznik IV). O przypisaniu decyduje podstawowa funkcjonalność produktu, a nie to, jakie komponenty zawiera. Techniczne opisy kategorii określa rozporządzenie wykonawcze Komisji (UE) 2025/2392 z 28 listopada 2025 roku.
Klasa I obejmuje dziewiętnaście kategorii, między innymi: systemy zarządzania tożsamością i uprzywilejowanym dostępem, samodzielne i wbudowane przeglądarki, menedżery haseł, oprogramowanie antywirusowe, produkty z funkcją VPN, systemy zarządzania siecią, systemy SIEM, menedżery uruchamiania systemu, oprogramowanie PKI i do wystawiania certyfikatów, systemy operacyjne, routery, modemy i przełączniki, mikroprocesory i mikrokontrolery z funkcjami bezpieczeństwa, produkty inteligentnego domu z funkcjami bezpieczeństwa (zamki, kamery, nianie elektroniczne, alarmy) oraz podłączone do internetu zabawki z funkcjami interaktywnymi lub lokalizacją. Klasa II to hiperwizory i środowiska uruchomieniowe kontenerów, zapory sieciowe i systemy wykrywania lub zapobiegania włamaniom oraz mikroprocesory i mikrokontrolery odporne na manipulacje. Produkty krytyczne to urządzenia sprzętowe ze skrzynkami zabezpieczającymi, bramy inteligentnych liczników i inne urządzenia do zaawansowanych celów bezpieczeństwa oraz karty inteligentne i elementy zabezpieczające.
Dwie zasady z FAQ chronią przed nadinterpretacją. Wbudowanie produktu ważnego w inny produkt nie czyni tego drugiego ważnym: aplikacja z wiadomościami z wbudowaną przeglądarką nie jest przeglądarką, a laptop z elementem zabezpieczającym nie jest kartą inteligentną. Działa to też w drugą stronę: dodatkowe funkcje nie wyprowadzają produktu z kategorii. System operacyjny z kalkulatorem dalej jest systemem operacyjnym. Oprogramowanie SOAR, które potrafi pełnić funkcje SIEM, zwykle nie jest SIEM, bo jego podstawowa funkcja jest inna.
| Kategoria | Przykłady z rozporządzenia i FAQ | Dopuszczalne procedury oceny zgodności | Udział jednostki notyfikowanej |
|---|---|---|---|
| Domyślna | aplikacja mobilna, gra, edytor, większość oprogramowania biznesowego | moduł A (kontrola wewnętrzna) lub B+C, H | nie jest wymagany |
| Ważna, klasa I | system operacyjny, przeglądarka, menedżer haseł, VPN, SIEM, router | moduł A tylko przy pełnym zastosowaniu norm zharmonizowanych, wspólnych specyfikacji lub certyfikacji na poziomie co najmniej „istotny”; w przeciwnym razie B+C lub H | zależy od norm |
| Ważna, klasa II | hiperwizor, środowisko uruchomieniowe kontenerów, zapora, IDS/IPS | B+C, H lub europejski program certyfikacji | wymagany |
| Krytyczna | karta inteligentna, element zabezpieczający, brama inteligentnego licznika | B+C, H lub certyfikacja, jeśli Komisja ją wskaże | wymagany |
| Wolne oprogramowanie w klasie I lub II | np. otwarty system operacyjny monetyzowany przez producenta | moduł A, pod warunkiem publicznego udostępnienia dokumentacji technicznej | nie jest wymagany |
Najbardziej niewygodne pole w tej tabeli to klasa I. Dla niej moduł A jest dostępny tylko wtedy, gdy producent zastosował w całości normy zharmonizowane. Normy powstają na podstawie wniosku normalizacyjnego M/606, który według FAQ obejmuje 15 norm horyzontalnych (pogrupowanych w trzy dokumenty) i 26 norm wertykalnych dla kategorii z załączników III i IV. Pierwotne terminy przyjęcia przez europejskie organizacje normalizacyjne to 30 sierpnia 2026 roku dla norm o procesie wytwarzania i o obsłudze podatności, 30 października 2027 roku dla normy o właściwościach produktu z załącznika I część I i 30 października 2026 roku dla norm wertykalnych. 10 listopada 2026 roku Komisja zmieniła wniosek, wydłużając o trzy miesiące termin dla wszystkich norm wertykalnych i części horyzontalnych. Moduł A dla klasy I wymaga norm, do których odesłanie opublikowano w Dzienniku Urzędowym UE. Zanim zaplanujesz samoocenę produktu klasy I, sprawdź, czy dla Twojej kategorii takie odesłanie już istnieje. Jeśli nie, zaplanuj budżet i czas na jednostkę notyfikowaną. Przepisy o jednostkach notyfikowanych stosuje się od 11 czerwca 2026 roku, a lista będzie w bazie NANDO.
Jak wygląda oznakowanie CE na oprogramowaniu i czym nie jest?
Oznakowanie CE to według FAQ Komisji „prosta wizualna samodeklaracja producenta”, że produkt spełnia wszystkie mające zastosowanie przepisy harmonizacyjne UE, w tym CRA. Nie jest certyfikatem, znakiem jakości ani dowodem, że ktoś zewnętrzny sprawdził produkt. Nawet w modułach B+C i H, gdzie uczestniczy jednostka notyfikowana, to producent umieszcza znak i podpisuje deklarację zgodności, biorąc za nią odpowiedzialność.
Dla oprogramowania art. 30 ust. 1 przewiduje dwie formy: znak umieszcza się w deklaracji zgodności UE albo na stronie internetowej towarzyszącej produktowi. W drugim przypadku odpowiednia sekcja strony musi być łatwo i bezpośrednio dostępna dla konsumentów. Dla urządzeń obowiązują zwykłe zasady: znak widoczny, czytelny i trwały, co do zasady nie mniejszy niż 5 mm. Przy modułach z jednostką notyfikowaną obok znaku umieszcza się numer tej jednostki.
Deklaracja zgodności może mieć postać pełną (wzór w załączniku V) albo uproszczoną (załącznik VI), czyli jedno zdanie z adresem strony, pod którym jest pełna deklaracja. Jeśli produkt podlega kilku aktom harmonizacyjnym, na przykład CRA i rozporządzeniu o maszynach, producent sporządza jedną deklarację dla wszystkich. Dokumentacja techniczna (załącznik VII) nie musi być udostępniana klientom ani publicznie, z wyjątkiem wolnego oprogramowania w klasie I lub II ocenianego modułem A. Musi jednak być gotowa na żądanie organu nadzoru rynku i przechowywana co najmniej 10 lat od wprowadzenia produktu na rynek albo przez okres wsparcia, jeśli jest dłuższy (art. 13 ust. 13).
Fraza „certyfikacja CE”, którą wpisują w wyszukiwarkę osoby z działów zakupów i sprzedaży, jest dla większości oprogramowania myląca. Gdy klient prosi o „certyfikat CE”, odpowiedzią jest deklaracja zgodności, opis kategorii produktu, informacja o zastosowanej procedurze i, jeśli uczestniczyła jednostka notyfikowana, certyfikat badania typu UE. Kupowanie „certyfikatu” od firmy, która nie jest jednostką notyfikowaną dla CRA, nie zmienia niczego w statusie prawnym produktu. Warto też pamiętać o ograniczeniu czasowym: znaku CE na podstawie CRA nie da się umieścić przed przeprowadzeniem procedury oceny zgodności, a ta dotyczy wymagań stosowanych od 11 grudnia 2027 roku.
Co dokładnie trzeba zgłaszać od 11 września 2026 roku?
Dwa rodzaje zdarzeń. Pierwszy to aktywnie wykorzystywana podatność, czyli taka, w przypadku której istnieją wiarygodne dowody, że ktoś działający w złych zamiarach wykorzystał ją w systemie bez zgody właściciela (art. 3 pkt 42). Drugi to poważny incydent mający wpływ na bezpieczeństwo produktu: taki, który wpływa lub może wpłynąć na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności ważnych danych lub funkcji, albo który doprowadził lub może doprowadzić do wprowadzenia lub wykonania złośliwego kodu w produkcie lub w systemach użytkownika (art. 14 ust. 5).
Terminy są te same dla obu, z jedną różnicą w raporcie końcowym:
- 24 godziny od momentu, w którym producent się dowiedział: wczesne ostrzeżenie, ze wskazaniem państw, w których produkt jest udostępniany, a przy incydencie także informacją, czy podejrzewa się działanie bezprawne;
- 72 godziny: zgłoszenie z ogólnymi informacjami o produkcie, charakterze podatności lub incydentu, podjętych środkach i środkach, które mogą zastosować użytkownicy, oraz oceną wrażliwości przekazywanych informacji;
- 14 dni od udostępnienia poprawki lub środka zaradczego: raport końcowy dla podatności (opis, waga, wpływ, informacje o atakującym, szczegóły aktualizacji);
- miesiąc od zgłoszenia 72-godzinnego: raport końcowy dla incydentu (opis, prawdopodobna przyczyna, zastosowane i trwające środki).
Zgłoszenia trafiają przez jednolitą platformę zgłaszania prowadzoną przez ENISA, działającą od 11 września 2026 roku, do CSIRT koordynatora w państwie głównej siedziby producenta, z jednoczesnym dostępem ENISA. Główna siedziba to państwo, w którym zapadają decyzje dotyczące cyberbezpieczeństwa produktów; producent spoza UE ustala właściwe państwo według kolejności z art. 14 ust. 7 (upoważniony przedstawiciel, importer, dystrybutor, użytkownicy). Niezależnie od zgłoszenia producent musi poinformować użytkowników, których to dotyczy, o podatności lub incydencie i o środkach, które mogą zastosować, w miarę możliwości w ustrukturyzowanym formacie nadającym się do automatycznego przetwarzania (art. 14 ust. 8). Jeśli tego nie zrobi w odpowiednim czasie, może to zrobić CSIRT.
Trzy doprecyzowania z FAQ zmieniają sposób, w jaki warto zorganizować dyżur. Po pierwsze, zero-day zgłoszony w programie bug bounty albo znaleziony przez laboratorium na zlecenie producenta, bez dowodów złośliwego wykorzystania, nie podlega obowiązkowemu zgłoszeniu; można go zgłosić dobrowolnie (art. 15). Po drugie, podatność w komponencie zewnętrznym, która w Twoim produkcie nie daje się wykorzystać, nie jest aktywnie wykorzystywana, ale trzeba ją zgłosić opiekunowi komponentu. Po trzecie, przy produktach wprowadzonych na rynek przed grudniem 2027 roku producent musi zgłosić, nawet jeśli nie jest w stanie zbadać podatności, bo na przykład nie da się już odtworzyć środowiska budowania. Pozostałe obowiązki z części II załącznika I jego starych produktów nie obejmują.
Najczęściej niedoszacowywany element to nie sam formularz, tylko pytanie, kto i jak „dowiaduje się”. Zegar 24 godzin biegnie od chwili, w której producent dowiedział się o aktywnym wykorzystaniu. Informacja może przyjść od klienta, z raportu firmy badającej zagrożenia, od rządowego CERT, od etycznego hakera albo z własnej telemetrii. Jeśli zgłoszenie klienta ląduje w kolejce helpdesku i czeka trzy dni na pierwszą linię wsparcia, firma ma problem prawny, a nie tylko operacyjny. Dlatego punkt kontaktowy do zgłaszania podatności (wymagany przez art. 13 ust. 17 i załącznik II) musi mieć ścieżkę eskalacji do osoby, która w ciągu godzin oceni dowody. Hasło reagowanie na incydenty w naszym słowniku opisuje, jak taki proces wygląda w ogólnym ujęciu; CRA dodaje do niego twardy termin zewnętrzny.
Mikro- i małe przedsiębiorstwa nie podlegają karom za niedotrzymanie terminu 24-godzinnego wczesnego ostrzeżenia (art. 64 ust. 10 lit. a). To ulga w sankcji, nie zwolnienie z obowiązku: zgłoszenie 72-godzinne i raport końcowy obowiązują ich tak samo.
Dlaczego okres wsparcia jest decyzją cenową, a nie zapisem w regulaminie?
Bo przez cały ten okres producent musi skutecznie obsługiwać podatności produktu i jego komponentów, a koszt tego zobowiązania rośnie z każdym rokiem i każdą wersją. Art. 13 ust. 8 mówi, że okres wsparcia ma odzwierciedlać czas, przez jaki produkt będzie używany, z uwzględnieniem rozsądnych oczekiwań użytkowników, charakteru produktu i innych przepisów UE. Ma wynosić co najmniej pięć lat. Krócej tylko wtedy, gdy produkt ma być używany krócej niż pięć lat; wtedy okres wsparcia odpowiada przewidywanemu czasowi użytkowania.
FAQ i motyw 60 dodają, że pięć lat to minimum, a nie domyślna wartość. Routery, modemy, przełączniki, systemy operacyjne, narzędzia do edycji wideo i przede wszystkim systemy sterowania przemysłowego są używane dłużej, więc dla nich okres wsparcia powinien być odpowiednio dłuższy. Krótszy okres jest uzasadniony na przykład dla aplikacji o z góry ograniczonym czasie życia albo dla oprogramowania, które z natury działa tylko w modelu subskrypcji i przestaje być dostępne po jej wygaśnięciu. Przy wolnym oprogramowaniu monetyzowanym przez płatne wsparcie okres wsparcia odpowiada czasowi aktywnej subskrypcji.
Do tego dochodzą trzy zobowiązania, które łatwo przeoczyć:
- Data końca wsparcia, co najmniej z miesiącem i rokiem, musi być jasno podana w chwili zakupu (art. 13 ust. 19). Tam, gdzie to technicznie możliwe, produkt powinien wyświetlić użytkownikowi informację, że okres wsparcia się skończył.
- Każda aktualizacja bezpieczeństwa musi pozostać dostępna co najmniej 10 lat od wydania albo do końca okresu wsparcia, jeśli jest dłuższy (art. 13 ust. 9).
- Informacje, na podstawie których ustalono okres wsparcia, idą do dokumentacji technicznej (art. 13 ust. 8), więc organ nadzoru może zapytać, dlaczego przyjąłeś właśnie pięć lat dla produktu, który klienci używają osiem.
Dlaczego to decyzja cenowa? Weź urządzenie przemysłowe sprzedawane przez dziesięć lat produkcji, z okresem wsparcia ustalonym na siedem lat dla każdej partii. FAQ (pkt 4.5.3) wyjaśnia, że okres wsparcia ustala się dla jednostek wprowadzanych na rynek, więc partia z ostatniego roku produkcji ciągnie zobowiązanie o siedem lat dalej. W praktyce firma utrzymuje zdolność do wydawania poprawek bezpieczeństwa przez siedemnaście lat od premiery. To koszt zespołu, środowisk budowania, kluczy podpisujących, monitoringu zależności i dyżuru. Jeśli nie jest wliczony w cenę produktu albo w umowę serwisową, płaci go marża.
Art. 13 ust. 10 daje dla oprogramowania jedną ulgę: producent, który wydał kolejne istotnie zmodyfikowane wersje, może dostarczać poprawki bezpieczeństwa tylko dla ostatniej, pod warunkiem że użytkownicy starszych wersji mogą przejść na nią bezpłatnie i bez dodatkowych kosztów dostosowania sprzętu lub oprogramowania. To mocny argument za polityką wersjonowania, w której aktualizacja do najnowszej wersji jest darmowa i nie wymaga nowego sprzętu. Opisaliśmy, jak projektować wydania, żeby nie psuć integracji klientów, w artykule o wersjonowaniu semantycznym; w świecie CRA ma to również wymiar prawny, bo załącznik I wymaga, by aktualizacje bezpieczeństwa tam, gdzie to technicznie wykonalne, wydawać oddzielnie od funkcjonalnych.
Okres wsparcia wpływa też na umowy z dostawcami. Roczna umowa utrzymaniowa z software house’em nie pokrywa pięcioletniego zobowiązania producenta. Przeliczenie, ile naprawdę kosztuje utrzymanie aplikacji po wdrożeniu przy różnych poziomach SLA, pokazaliśmy w tekście o kosztach utrzymania aplikacji; dla produktów objętych CRA horyzont tego wyliczenia trzeba wydłużyć do końca okresu wsparcia ostatniej sprzedanej partii.
Czego CRA naprawdę wymaga od SBOM?
Mniej i jednocześnie więcej, niż sugeruje wiele materiałów marketingowych. Załącznik I część II pkt 1 wymaga od producenta identyfikacji i dokumentowania podatności i komponentów, w tym przez sporządzenie SBOM (w polskiej wersji rozporządzenia: „zestawienia podstawowych materiałów do produkcji oprogramowania”) w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu.
Trzy rzeczy wynikają z tego wprost. Po pierwsze, minimum to zależności najwyższego poziomu, nie pełne drzewo przechodnie. Po drugie, rozporządzenie nie narzuca formatu; art. 13 ust. 24 pozwala Komisji określić format i elementy SBOM aktem wykonawczym. Do tego czasu używa się formatów powszechnie stosowanych w branży, takich jak SPDX albo CycloneDX. Po trzecie, i to najczęstsze nieporozumienie, CRA nie nakazuje publikowania SBOM. SBOM jest częścią dokumentacji technicznej (załącznik VII), a organ nadzoru rynku może go zażądać na uzasadniony wniosek. Załącznik II przewiduje informację dla użytkownika o tym, gdzie jest SBOM, tylko „jeżeli producent zdecyduje się” go udostępnić.
Wcześniejsze teksty, w tym nasz przewodnik po SBOM z grudnia 2025 roku, kładły nacisk na „dostarczanie” SBOM. Precyzyjniej: CRA wymaga go sporządzić i utrzymywać, a decyzja o udostępnieniu klientom jest biznesowa. Klienci objęci NIS2 albo DORA często i tak będą o niego prosić w ankietach dostawców, więc warto mieć gotową wersję do przekazania.
Dlaczego „więcej”? Bo SBOM wygenerowany raz przy wydaniu nie spełnia celu przepisu. Celem jest zdolność do odpowiedzi na pytanie „czy nasz produkt zawiera komponent X w wersji Y” w ciągu godzin, kiedy pojawia się nowa podatność, i do powiązania tego z obowiązkiem zgłoszenia, jeśli podatność jest aktywnie wykorzystywana. To wymaga SBOM wersjonowanego razem z każdym wydaniem, przechowywanego przez okres wsparcia i podłączonego do monitorowania baz podatności. Załącznik I wymaga też „skutecznych i regularnych testów i przeglądów bezpieczeństwa”; najtaniej zapisać to jako kryterium ukończenia każdej zmiany. Jak to zrobić bez dokładania osobnego etapu testów, opisaliśmy w tekście o Definition of Done.
Jakie kary grożą i od kiedy można je nakładać?
Art. 64 przewiduje trzy progi administracyjnych kar pieniężnych, w każdym przypadku wyższa z dwóch kwot:
- do 15 mln euro lub 2,5% łącznego rocznego światowego obrotu z poprzedniego roku obrotowego za niezgodność z zasadniczymi wymaganiami z załącznika I oraz obowiązkami z art. 13 i 14;
- do 10 mln euro lub 2% za naruszenie innych obowiązków wskazanych w art. 64 ust. 3, między innymi obowiązków importerów i dystrybutorów, zasad deklaracji zgodności, oznakowania CE i dokumentacji technicznej;
- do 5 mln euro lub 1% za podanie jednostkom notyfikowanym lub organom nadzoru rynku nieprawidłowych, niepełnych lub wprowadzających w błąd informacji.
Zasady nakładania kar i wskazanie organów należą do państw członkowskich. Przy ustalaniu wysokości kary organ bierze pod uwagę charakter, wagę i czas trwania naruszenia, wcześniejsze kary i wielkość przedsiębiorstwa, ze szczególnym uwzględnieniem mikro, małych i średnich firm oraz start-upów. Kary mogą być nakładane obok innych środków, w tym nakazu wycofania produktu z rynku.
Jest tu niuans, który warto znać, ale na którym nie warto budować strategii. Art. 71 ust. 2 stosuje art. 14 od 11 września 2026 roku, a resztę rozporządzenia, w tym art. 64, od 11 grudnia 2027 roku. Literalnie oznacza to, że obowiązek zgłaszania obowiązuje już dziś, a unijna podstawa kar administracyjnych zaczyna działać od grudnia 2027 roku. To nie czyni obowiązku pustym. Brak zgłoszenia to naruszenie prawa, które organ i klienci zobaczą przy pierwszym incydencie. Ponadto odpowiedzialność za szkodę wynika z innych przepisów, w tym z nowej dyrektywy o odpowiedzialności za produkty (2024/2853), której relację z CRA omawia FAQ Komisji. O tym, jak ten niuans wpływa na Twoje ryzyko w konkretnym państwie, powinien wypowiedzieć się prawnik znający krajowe przepisy wykonawcze.
Bardziej realnym kosztem niż kara jest wycofanie produktu. Art. 13 ust. 21 wymaga, by producent, który wie lub ma powody sądzić, że produkt lub jego procesy nie są zgodne z wymaganiami, natychmiast podjął działania naprawcze albo wycofał produkt. FAQ wskazuje, że może to dotyczyć zwłaszcza sprzętu z podatnością, której nie da się usunąć. Dla firmy sprzedającej urządzenia to ryzyko większe niż jakakolwiek grzywna.
Jak rozłożyć przygotowania do 11 grudnia 2027 roku?
Zostało niewiele ponad dwanaście miesięcy. Kolejność ma znaczenie, bo część elementów jest obowiązkowa już dziś, a część zależy od norm, których jeszcze nie ma. Poniższy plan zakłada produkt kategorii domyślnej albo klasy I, rozwijany przez własny zespół z udziałem dostawców.
| Obszar | Podstawa prawna | Kiedy musi działać | Co musi istnieć | Właściciel |
|---|---|---|---|---|
| Zgłaszanie podatności i incydentów | art. 14, art. 69 ust. 3 | od 11.09.2026 (już) | konto na platformie ENISA, procedura 24/72 h, ścieżka eskalacji, szablony zgłoszeń i komunikatów dla użytkowników | CISO lub szef bezpieczeństwa produktu |
| Punkt kontaktowy i polityka ujawniania | art. 13 ust. 17, zał. I cz. II pkt 5–6 | potrzebne do zgłaszania już teraz; formalnie od 11.12.2027 | publiczny adres do zgłoszeń, polityka skoordynowanego ujawniania, czas reakcji | bezpieczeństwo produktu |
| Klasyfikacja produktu | art. 7–8, rozp. 2025/2392 | I kwartał 2027 | opis podstawowej funkcjonalności, przypisanie kategorii, decyzja o module | CTO z compliance |
| Okres wsparcia | art. 13 ust. 8–9, 19 | przed ustaleniem cen na 2027/2028 | uzasadniony okres per produkt, koszt w budżecie, data końca w materiałach sprzedażowych | zarząd, product management |
| Ocena ryzyka | art. 13 ust. 2–4 | II kwartał 2027 | udokumentowana ocena obejmująca backend zdalnego przetwarzania i komponenty | architekt bezpieczeństwa |
| SBOM i należyta staranność | zał. I cz. II pkt 1, art. 13 ust. 5–6 | II kwartał 2027 | SBOM per wydanie, monitoring podatności zależności, polityka wyboru komponentów | DevSecOps |
| Rozdzielenie aktualizacji | zał. I cz. II pkt 2, 7–8 | III kwartał 2027 | kanał poprawek bezpieczeństwa niezależny od funkcjonalnych, podpisywanie, automatyczne aktualizacje z opcją rezygnacji | inżynieria wydań |
| Dokumentacja techniczna i deklaracja | art. 13 ust. 12–13, art. 28, 31, zał. V, VII | III–IV kwartał 2027 | dokumentacja wg załącznika VII, deklaracja zgodności, strona z CE dla oprogramowania | compliance |
| Jednostka notyfikowana (jeśli wymagana) | art. 32 | rezerwacja w I połowie 2027 | umowa z jednostką z bazy NANDO, harmonogram badania typu | CTO |
W tej tabeli widać tezę artykułu. Dwie pierwsze pozycje to obowiązek albo jego bezpośredni warunek już teraz. Okres wsparcia trzeba ustalić, zanim powstanie cennik na lata, w których produkt zostanie objęty CRA. Dokumentacja i znak CE są na końcu, bo są podsumowaniem pracy wykonanej wcześniej, a nie jej początkiem. Jeśli w Twojej organizacji kolejność jest odwrotna, budżet trafia do wykonawcy dokumentacji, a dyżur zgłoszeniowy nie ma właściciela.
Dwie uwagi o niepewności. Po pierwsze, terminy norm zostały właśnie przesunięte, więc producent produktu klasy I, który liczy na moduł A, powinien mieć plan awaryjny z jednostką notyfikowaną. Po drugie, wytyczne Komisji z lipca 2026 roku zawierają, według komunikatu, 67 przykładów i schematów dla mniejszych firm; warto przejść je z prawnikiem przy klasyfikacji produktu, bo są niewiążące, ale pokazują, jak Komisja czyta przepisy.
Co zmienia CRA w umowie z dostawcą i zespołem zewnętrznym?
Producent odpowiada za produkt w całości, niezależnie od tego, kto napisał kod. Jeśli korzystasz z zewnętrznego software house’u, kontraktorów albo modelu body leasingu, obowiązki z CRA zostają przy Tobie. Umowa musi więc przenieść na dostawcę te części pracy, bez których nie dotrzymasz terminów, a jednocześnie nie może udawać, że przenosi odpowiedzialność, której prawo nie pozwala przenieść.
Pięć zapisów ma znaczenie praktyczne. Pierwszy: czas reakcji dostawcy na zgłoszenie podatności liczony w godzinach, zgodny z Twoim terminem 24 godzin, a nie w dniach roboczych z typowej umowy SLA. Drugi: obowiązek dostarczania SBOM dla każdego wydania i informowania o komponentach, których okres wsparcia kończy się przed Twoim. Trzeci: Twoja zdolność do wydania poprawki bez dostawcy, czyli dostęp do kodu, środowiska budowania, kluczy podpisujących i dokumentacji. Czwarty: okres, przez jaki dostawca jest zobowiązany do wsparcia przy obsłudze podatności, dopasowany do Twojego okresu wsparcia albo z jasnym planem przejęcia. Piąty: obowiązek współpracy przy zgłoszeniach i raportach końcowych, łącznie z przekazaniem danych technicznych potrzebnych w raporcie 14-dniowym.
Przy oprogramowaniu embedded to szczególnie ważne, bo okres wsparcia urządzeń jest długi, a zależność od dostawcy firmware’u duża. Pisaliśmy o tym szerzej w tekście o outsourcingu oprogramowania embedded, a decyzje, które trzeba podjąć przed budową urządzenia IoT, w tym o aktualizacjach OTA i wycofaniu z rynku, zebraliśmy w artykule o konsultingu IoT.
Jedno ostrzeżenie dla firm, które same są dostawcami. Art. 22 stanowi, że osoba inna niż producent, importer lub dystrybutor, która dokonuje istotnej zmiany produktu i udostępnia go na rynku, staje się producentem w zakresie tej zmiany, a jeśli zmiana wpływa na cyberbezpieczeństwo całego produktu, w zakresie całego produktu. Istotna zmiana to taka, która wpływa na zgodność z wymaganiami części I załącznika I albo zmienia przewidziane zastosowanie (art. 3 pkt 30). Integrator, który przerabia cudzy produkt i sprzedaje go dalej pod własną nazwą, powinien to policzyć, zanim podpisze umowę.
Jakie są kluczowe wnioski dla CTO i działu compliance?
Cyber Resilience Act jest dla producentów oprogramowania przede wszystkim przepisem o tym, jak długo i jak szybko muszą reagować na podatności, a dopiero na końcu przepisem o oznakowaniu CE. Dla większości produktów znak CE to samodeklaracja wystawiana przez producenta, bez jednostki notyfikowanej. Jego wartość zależy wyłącznie od procesu, który za nim stoi.
Zapamiętaj sześć rzeczy. Po pierwsze, obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów działa od 11 września 2026 roku, z terminami 24 godzin, 72 godzin, 14 dni i miesiąca, i obejmuje także produkty sprzedawane przed grudniem 2027 roku. Po drugie, sprawdź zakres uczciwie: aplikacja z niezbędnym backendem to produkt wraz ze zdalnym przetwarzaniem danych, a oprogramowanie na zamówienie dla klienta biznesowego mieści się w CRA z dwoma wyjątkami umownymi. Po trzecie, ustal klasę produktu według podstawowej funkcjonalności; tylko klasa I bez norm zharmonizowanych, klasa II i produkty krytyczne wymagają jednostki notyfikowanej. Po czwarte, okres wsparcia to co najmniej pięć lat, z datą końca podaną przy zakupie i aktualizacjami dostępnymi przez dziesięć lat, więc wlicz go w cenę. Po piąte, SBOM trzeba sporządzać i utrzymywać przy każdym wydaniu, ale CRA nie każe go publikować. Po szóste, kary sięgają 15 mln euro lub 2,5% obrotu, ale większym ryzykiem dla producenta urządzeń jest nakaz wycofania produktu.
Jeśli potrzebujesz ludzi, którzy zbudują proces obsługi podatności, generowanie SBOM w pipeline, oddzielny kanał poprawek bezpieczeństwa i dyżur gotowy na 24-godzinne zgłoszenie, zobacz, jak pracują nasi inżynierowie DevOps i DevSecOps: specjalista może rozpocząć pracę w Twoim zespole w ciągu 2 tygodni, a gwarancja wymiany obejmuje pierwsze 2 tygodnie współpracy. Możesz też umówić rozmowę, żeby przejść przez plan przygotowań do 11 grudnia 2027 roku dla Twojego produktu.