Cyber Resilience Act (CRA): obowiązki, terminy i przygotowanie produktu

Stan prawny i perspektywa artykułu: 29 kwietnia 2026 r. Opisujemy obowiązki, które będą stosowane etapami. Rozróżniamy uchwalone przepisy, przygotowywane rozwiązania wykonawcze i własne rekomendacje organizacyjne. Materiał objaśnia regulację; kwalifikacja konkretnego produktu wymaga analizy jego funkcji, sposobu udostępniania i dokumentacji.

Cyber Resilience Act włącza cyberbezpieczeństwo do warunków wprowadzania urządzeń i oprogramowania na rynek UE. Łączy projekt produktu, obsługę podatności, wsparcie i dowody zgodności. Sam test penetracyjny, skaner lub klauzula umowna nie wystarczą.

Najbliższy termin istotny dla producentów to 11 września 2026 r., kiedy zaczną być stosowane obowiązki zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów. Większość wymagań produktowych zacznie być stosowana 11 grudnia 2027 r. Przygotowania warto prowadzić dwoma torami: gotowość do reagowania w 2026 r. i zgodność produktu w 2027 r. Wcześniejsze uruchomienie dobrych praktyk może ułatwić oba zadania, ale nie zmienia ustawowych dat.

Czym jest CRA i jaki problem rozwiązuje

CRA to rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847, nazywane aktem o cyberodporności. Jako rozporządzenie ustanawia bezpośrednio stosowane reguły unijne. Państwa członkowskie nadal organizują nadzór i egzekwowanie, dlatego wspólny tekst prawa nie usuwa całego krajowego otoczenia instytucjonalnego.

Kupujący łatwo porówna rozdzielczość kamery lub liczbę portów routera. Trudniej oceni bezpieczeństwo zależności i zdolność producenta do naprawy błędu po latach. Koszt słabej konstrukcji ponoszą często użytkownicy oraz inne systemy zaatakowane przez przejęty produkt.

CRA ma przesunąć część tej odpowiedzialności na podmiot wprowadzający produkt na rynek. Wymagania obejmą projektowanie, rozwój, produkcję i obsługę podatności. Sam moment sprzedaży nie zakończy odpowiedzialności. Istotne będą też instrukcje, dostępne aktualizacje i informacja o okresie wsparcia. Podstawą są art. 13 oraz załączniki I i II.

Zgodność nie gwarantuje braku ataków: bezpieczeństwo zależy również od konfiguracji, środowiska i nowych zagrożeń. Regulacja wymaga odpowiedniej ochrony oraz zdolności reagowania. Formalna zgodność i rzeczywista odporność powinny się wspierać, ale nie są synonimami.

Jakie produkty obejmuje regulacja

Punktem odniesienia jest produkt z elementami cyfrowymi, którego zamierzone lub racjonalnie przewidywalne użycie obejmuje bezpośrednie albo pośrednie połączenie danych z urządzeniem lub siecią. Zakres określają art. 2 i definicje w art. 3. Nie należy zawężać go do urządzeń stale podłączonych do publicznego internetu.

Produkt może być sprzętem, oprogramowaniem albo połączeniem obu. W grę wchodzą między innymi urządzenia sieciowe, sterowniki, aplikacje instalowane lokalnie i komponenty udostępniane oddzielnie. Firmware, czyli oprogramowanie wbudowane w urządzenie, jest częścią analizy jego bezpieczeństwa. Połączenie przez lokalną sieć, interfejs serwisowy lub inny produkt może być równie istotne jak bezpośrednie połączenie z chmurą.

Drugą osią jest udostępnianie na rynku w ramach działalności gospodarczej. Odpłatność konkretnego pobrania nie rozstrzyga samodzielnie sprawy. Model biznesowy może obejmować usługi, dane lub płatne funkcje. Jednocześnie samo napisanie programu na własne potrzeby nie oznacza automatycznie wprowadzenia produktu do obrotu. Trzeba opisać rzeczywisty przepływ produktu i role uczestników.

Istnieją wyłączenia związane z odrębnymi systemami prawnymi, między innymi dla określonych wyrobów medycznych, pojazdów i produktów lotniczych. Szczególne zasady dotyczą produktów przeznaczonych wyłącznie do bezpieczeństwa narodowego lub obronności oraz przetwarzania informacji niejawnych. Katalog należy sprawdzać w art. 2, wraz z aktami uzupełniającymi. Nie wolno zamieniać go w ogólne stwierdzenie, że cała branża medyczna lub motoryzacyjna jest wyłączona.

Wynikiem analizy powinna być karta produktu: funkcje, odbiorcy, model gospodarczy i uzasadnienie ewentualnego wyłączenia. Diagram porządkuje pytania, nie zastępuje kwalifikacji prawnej. Niejednoznaczności warto rozstrzygnąć przed podjęciem kosztownych decyzji projektowych.

Kto odpowiada za zgodność

Producentem nie musi być fabryka ani osoba, która napisała kod. Istotne jest również zlecenie zaprojektowania lub wytworzenia produktu i wprowadzanie go pod własną nazwą lub znakiem towarowym. Firma zamawiająca gotowe urządzenie i sprzedająca je pod własną marką powinna dokładnie sprawdzić, czy przejmuje rolę producenta.

Importer wprowadza do Unii produkt pochodzący z państwa trzeciego. Dystrybutor uczestniczy w dalszym udostępnianiu. Ich obowiązki obejmują odpowiednie sprawdzenia, reakcję na niezgodność i współpracę z organami. Art. 19-22 wyjaśniają także sytuacje, w których importer, dystrybutor lub inna osoba staje się producentem, na przykład wskutek określonego przemianowania albo istotnej modyfikacji.

Umowa może rozdzielić zadania między partnerami, ale nie usuwa ustawowej roli producenta. Zlecenie testów laboratorium nie przenosi całej odpowiedzialności na laboratorium. Podobnie dostawca biblioteki nie odpowiada automatycznie za sposób, w jaki producent połączył ją z pozostałymi elementami systemu.

Mikroprzedsiębiorstwa i małe firmy nie otrzymują ogólnego zwolnienia z CRA. Przewidziano rozwiązania wspierające i proporcjonalność, ale podstawowe pytanie nadal dotyczy produktu oraz roli firmy. W niewielkim zespole kilka funkcji może pełnić jedna osoba; istotne jest, aby odpowiedzialność, zastępstwo i dostęp do narzędzi rzeczywiście istniały.

SaaS, chmura i open source

Samodzielna usługa SaaS, czyli oprogramowanie udostępniane jako usługa, nie jest automatycznie objęta CRA tylko dlatego, że korzysta z internetu. Osobno trzeba przeanalizować rozwiązania zdalnego przetwarzania danych stanowiące część produktu. Definicja obejmuje odpowiednio zaprojektowane przetwarzanie zdalne, bez którego produkt nie mógłby wykonywać jednej ze swoich funkcji.

Dla przykładu kamera i chmura nie zawsze są dwoma niezależnymi zakupami. Jeżeli zdalna analiza jest zaprojektowana przez producenta lub na jego odpowiedzialność jako element funkcji kamery, granica produktu może obejmować ten element. Nie wynika z tego, że cała infrastruktura dowolnego dostawcy chmury automatycznie staje się produktem tego producenta. Potrzebna jest analiza funkcjonalna i odpowiedzialności.

Komisja opublikowała projekt wytycznych 3 marca 2026 r.. Dotyczy on między innymi zdalnego przetwarzania, open source i okresów wsparcia. W naszej kwietniowej perspektywie jest to materiał pomocniczy w fazie projektu, a nie ostateczna, wiążąca interpretacja zastępująca rozporządzenie.

Wolne i otwarte oprogramowanie udostępniane poza działalnością gospodarczą korzysta z wyłączenia. Nie jest to jednak zwolnienie każdego programu z publicznym repozytorium. Licencja, sposób finansowania, rola podmiotu i działalność wokół produktu muszą być rozpatrywane łącznie. Samo udostępnienie kodu nie przesądza ani o objęciu regulacją, ani o wyłączeniu.

CRA wprowadza również odrębną rolę opiekuna oprogramowania otwartego. Art. 24 przewiduje dla takich podmiotów dostosowane obowiązki, w tym politykę cyberbezpieczeństwa i współpracę z organami. Nie należy utożsamiać opiekuna z każdym wolontariuszem zgłaszającym poprawkę. Tak samo producent wykorzystujący otwartą bibliotekę w produkcie komercyjnym nie może uznać, że wyłączenie jej autora obejmuje cały sprzedawany produkt.

Harmonogram: trzy różne etapy przygotowań

CRA wszedł w życie 10 grudnia 2024 r. Nie oznacza to, że od tego dnia stosuje się wszystkie obowiązki. Art. 71 rozdziela rozpoczęcie stosowania poszczególnych części. Z perspektywy kwietnia 2026 r. nadchodzą trzy istotne etapy.

Obowiązki wrześniowe nie oznaczają, że cały załącznik I zacznie być stosowany we wrześniu. Jednocześnie trudno rzetelnie raportować, jeśli firma nie wie, jakie wersje produktu sprzedała lub kto analizuje zgłoszenia. Wcześniejsze uruchomienie inwentaryzacji i procedur jest więc rekomendacją operacyjną, a nie zmianą terminu prawnego.

Prace normalizacyjne również wymagają czasu. Zlecenie Komisji M/606, przyjęte w 2025 r., uruchamia przygotowanie norm wspierających CRA. Projekt normy, opublikowana norma i norma zharmonizowana z odniesieniem w Dzienniku Urzędowym to różne etapy. Sam napis „zgodnie z normą” nie powinien przesłaniać sprawdzenia, jakie wymagania i domniemania zgodności rzeczywiście obejmuje.

Co zmieni się w projektowaniu i utrzymaniu

Art. 13 i załącznik I wiążą wymagania z oceną ryzyka cyberbezpieczeństwa. Producent powinien rozumieć zamierzone zastosowanie, racjonalnie przewidywalne użycie i możliwe zagrożenia. W praktyce oznacza to opis granic zaufania, interfejsów, uprawnień, danych oraz skutków utraty dostępności lub integralności. Zakup narzędzia nie zastąpi tych decyzji.

Wymagania dotyczą między innymi bezpiecznej konfiguracji domyślnej, ochrony przed nieuprawnionym dostępem, poufności i integralności danych, ograniczania powierzchni ataku oraz możliwości bezpiecznego usunięcia danych. Stosuje się je odpowiednio do ryzyka i właściwości produktu. Nie każdy produkt wymaga identycznego zestawu mechanizmów, ale pominięcia trzeba umieć uzasadnić.

Wprowadzenie produktu bez znanych podatności możliwych do wykorzystania nie oznacza obietnicy całkowitego braku błędów. Wymaga rozumienia rzeczywistego narażenia. Lista alarmów skanera nie jest ani gotową oceną ryzyka, ani automatycznym dowodem niezgodności. Trzeba sprawdzić wersję, osiągalność podatnego kodu, warunki wykorzystania i skutki; zachować uzasadnienie decyzji.

SBOM, czyli zestawienie komponentów oprogramowania, pomaga ustalić, co znajduje się w produkcie. Załącznik I część II wymaga identyfikowania i dokumentowania komponentów oraz podatności, w tym maszynowo czytelnego zestawienia obejmującego przynajmniej zależności najwyższego poziomu. Nie jest to automatyczny obowiązek publicznego ujawnienia całego kodu źródłowego ani publikowania pełnego SBOM wszystkim odbiorcom.

Sam plik SBOM szybko się starzeje. Użyteczny proces łączy go z konkretnym wydaniem, konfiguracją i bazą komponentów. Po informacji o podatności trzeba ustalić produkty dotknięte problemem, ocenić ryzyko, opracować poprawkę i sprawdzić jej dostarczenie. SPDX i CycloneDX mogą pomóc w wymianie danych, ale wybór formatu nie potwierdza sam w sobie zgodności z CRA.

Obsługa podatności obejmie regularne testy i przeglądy bezpieczeństwa, koordynowane ujawnianie oraz punkt kontaktowy. Zespół reagowania na bezpieczeństwo produktu bywa nazywany PSIRT. Małej firmie nie musi być potrzebny osobny dział; potrzebuje natomiast osoby decyzyjnej, sposobu przyjmowania zgłoszeń i zastępstwa podczas urlopu.

Mechanizm aktualizacji trzeba zaprojektować razem z produktem. Przy urządzeniu warto przeanalizować autentyczność pakietu, utratę zasilania podczas instalacji, odzyskiwanie sprawności i ochronę kluczy. Podpisane aktualizacje czy kontrolowany powrót wersji są przykładami środków technicznych, nie uniwersalnym nakazem zastosowania jednej architektury. W instalacjach przemysłowych planowanie okna serwisowego może być równie istotne jak pobranie poprawki.

Dokumentacja techniczna z załącznika VII powinna odzwierciedlać rzeczywisty produkt i wyniki pracy. Warto powiązać wymaganie, ryzyko, zastosowany środek i dowód w jednym rejestrze. Taki rejestr ułatwia zmianę dostawcy, badanie incydentu i kolejne wydanie. Dokument sporządzony dopiero dzień przed oceną często ujawnia brak danych, których nie da się szybko odtworzyć.

Wsparcie i koniec życia produktu

Okres wsparcia ma odzwierciedlać przewidywany czas używania produktu oraz kryteria z art. 13 ust. 8. Co do zasady powinien wynosić co najmniej pięć lat; jeżeli oczekiwany czas używania jest krótszy, wsparcie odpowiada temu czasowi. Pięć lat nie jest automatycznym maksimum ani bezpiecznym wyborem dla każdego urządzenia przemysłowego.

Producent powinien jasno podać koniec okresu wsparcia i uzasadnić jego ustalenie. W modelu ekonomicznym trzeba uwzględnić testowanie poprawek, utrzymanie środowiska budowania, kompetencje zespołu i współpracę z dostawcami. Sprzedaż długo po rozpoczęciu życia modelu wymaga szczególnej uwagi: klient kupuje konkretny produkt, a nie historyczny plan utrzymania producenta.

Należy odróżnić opracowywanie nowych poprawek od dostępności już wydanych aktualizacji. Art. 13 ust. 9 przewiduje utrzymywanie udostępnionych aktualizacji bezpieczeństwa przez co najmniej dziesięć lat od wydania albo przez pozostały okres wsparcia, zależnie od tego, który jest dłuższy. Archiwum aktualizacji i infrastruktura ich dystrybucji są zatem osobnym zobowiązaniem operacyjnym.

Aktualizacje bezpieczeństwa powinny być rozpowszechniane bez zbędnej zwłoki i zasadniczo bezpłatnie. Załącznik I przewiduje szczególną możliwość innego uzgodnienia przy produkcie wykonanym na zamówienie dla użytkownika biznesowego. Nie należy rozciągać tego wyjątku na wszystkie produkty B2B. Poprawki bezpieczeństwa trzeba również, gdy jest to technicznie wykonalne, oddzielać od zmian funkcjonalnych.

Zakończenie wsparcia nie oznacza nakazu automatycznego wyłączenia każdego urządzenia. Użytkownik powinien jednak znać ryzyko dalszego używania. Firma powinna zaplanować komunikację, migrację, bezpieczne usunięcie danych i zależność od usług zdalnych. Udostępnienie kodu po zakończeniu wsparcia może być rozważanym rozwiązaniem, ale nie jest uniwersalnym obowiązkiem nałożonym przez CRA.

Kategorie produktów, ocena zgodności i CE

Nie wszystkie produkty będą oceniane identycznie. CRA wyróżnia ważne produkty z załącznika III, podzielone na klasy I i II, oraz produkty krytyczne z załącznika IV. Pozostałe produkty również podlegają wymaganiom, jeśli mieszczą się w zakresie regulacji. Klasyfikacja odnosi się do funkcji produktu, a nie do tego, jak ważny jest klient lub jak duży obrót ma producent.

Rozporządzenie wykonawcze (UE) 2025/2392 doprecyzowuje opisy techniczne kategorii. Przy kwalifikacji trzeba zestawić jego opisy z załącznikami CRA i rzeczywistą podstawową funkcjonalnością produktu. Sam fakt użycia ważnego komponentu nie zawsze przenosi jego kategorię na całe urządzenie.

Art. 32 przewiduje różne procedury. Dla produktów spoza szczególnych kategorii dostępna jest między innymi wewnętrzna kontrola. Dla klasy I możliwość tej ścieżki zależy od spełnienia wskazanych warunków, w tym odpowiedniego zastosowania norm lub innych przewidzianych instrumentów. Dla klasy II zasadą jest udział strony trzeciej. Art. 32 ust. 5 przewiduje jednak szczególną ścieżkę dla produktów będących wolnym i otwartym oprogramowaniem z załącznika III: przy publicznie dostępnej dokumentacji technicznej w momencie wprowadzania do obrotu można skorzystać z procedur ust. 1, w tym kontroli wewnętrznej. Szczególne reguły dotyczą produktów krytycznych i europejskich systemów certyfikacji.

Przykładowo załącznik III zalicza menedżery haseł i samodzielne przeglądarki do klasy I, a zapory sieciowe oraz systemy wykrywania i zapobiegania włamaniom do klasy II. Załącznik IV obejmuje między innymi karty inteligentne i podobne urządzenia, w tym elementy bezpieczne. Nazwa handlowa nie wystarcza: trzeba sprawdzić pełny opis kategorii.

W praktyce decyzja o ścieżce wymaga sprawdzenia aktualnego, właściwego dla daty stanu norm, aktów wykonawczych i zakresu jednostki. Nie należy obiecywać klientowi gotowej „certyfikacji CRA” bez ustalenia, o którą procedurę i kategorię chodzi. Równie mylące byłoby twierdzenie, że każdy producent będzie musiał kupić zewnętrzny certyfikat.

Oznakowanie CE wskazuje zgodność z mającymi zastosowanie wymaganiami unijnego prawodawstwa. Towarzyszą mu deklaracja zgodności UE i dokumentacja. CE nie jest rankingiem bezpieczeństwa, gwarancją braku podatności ani osobnym znakiem jakości nadawanym zawsze przez urząd. Dla produktu podlegającego kilku aktom trzeba skoordynować wymagania i dowody zamiast traktować każdą regulację jako oddzielną naklejkę.

Raportowanie podatności i incydentów

Od 11 września 2026 r. art. 14 będzie wymagał zgłoszeń dotyczących aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu. Są to dwa różne zdarzenia. Wynik skanowania wskazujący potencjalną podatność nie jest sam w sobie dowodem jej aktywnego wykorzystania.

Zgłoszenie będzie kierowane jednocześnie do właściwego CSIRT pełniącego rolę koordynatora i ENISA za pośrednictwem pojedynczej platformy sprawozdawczej przewidzianej w art. 16. CSIRT to zespół reagowania na incydenty bezpieczeństwa komputerowego; ENISA jest unijną agencją cyberbezpieczeństwa. W kwietniu opisujemy docelowy mechanizm prawny, nie zakładamy, że produkcyjny interfejs platformy już działa.

Termin 72 godzin nie oznacza dodatkowych 72 godzin po ostrzeżeniu. Oba początkowe terminy liczy się od uzyskania wiedzy. Termin 14 dni nie jest uniwersalnym terminem naprawy, a miesiąc nie powinien być mechanicznie zamieniany na 30 dni. Reguły z art. 14 pozwalają nie powtarzać informacji już przekazanych; organ może także poprosić o informacje uzupełniające.

Poważny incydent nie ogranicza się do kradzieży danych osobowych. Ustawowe przesłanki obejmują między innymi negatywny lub potencjalnie negatywny wpływ na zdolność produktu do ochrony istotnych danych i funkcji albo wprowadzenie złośliwego kodu. Sam próg CVSS, czyli techniczna ocena dotkliwości podatności, nie zastępuje tej analizy.

Producent ma również obowiązki wobec dotkniętych użytkowników: informacje o podatności lub incydencie i dostępnych środkach. Zawiadomienie organu nie zastępuje komunikatu pomagającego klientowi zabezpieczyć urządzenie. Jednocześnie nie należy publikować szczegółów wykorzystania w sposób niekontrolowany. Komunikację trzeba skoordynować z usuwaniem problemu i odpowiednimi zespołami reagowania.

Warto przeprowadzić ćwiczenie: informacja pojawia się w piątek wieczorem, osoba odpowiedzialna jest na urlopie, a dotknięte wersje pochodzą od podwykonawcy. Kto oceni przesłanki, znajdzie numery wersji i przygotuje zgłoszenie? Terminy nie zamieniają się w dni robocze. To przykład organizacyjnego problemu, którego nie rozwiąże samo utworzenie adresu security@.

Produkty już sprzedawane i istotne modyfikacje

Art. 69 przewiduje, że produkty wprowadzone do obrotu przed 11 grudnia 2027 r. co do zasady będą podlegały wymaganiom CRA, jeżeli po tej dacie zostaną istotnie zmodyfikowane. Osobno potraktowano art. 14: obowiązki raportowania obejmą także wcześniejsze produkty mieszczące się w zakresie regulacji.

Nie należy z tego wyprowadzać zwolnienia wszystkich przyszłych egzemplarzy modelu zaprojektowanego w 2025 r. W prawie produktowym trzeba odróżnić premierę modelu od wprowadzenia konkretnego produktu do obrotu. Nowa partia sprzedawana po rozpoczęciu stosowania wymagań może wymagać pełnej zgodności, mimo że konstrukcja ma już kilka lat.

Istotna modyfikacja to pojęcie prawne związane między innymi ze zmianą wpływającą na zgodność z wymaganiami albo zmianą zamierzonego zastosowania. Nie każda poprawka błędu staje się automatycznie takim zdarzeniem. Dodanie zdalnego sterowania do wcześniej lokalnego urządzenia zasługuje jednak na inną ocenę niż drobna korekta opisu w interfejsie.

Praktycznie warto prowadzić rejestr wydań oraz decyzji o charakterze zmian. Powinien wskazywać funkcje, interfejsy, wpływ na ryzyko i odpowiedzialny podmiot. Dokumentacja pozwoli później odtworzyć, dlaczego aktualizację potraktowano jako utrzymaniową albo uruchomiono nową ocenę zgodności. Nie wystarczy nazwać dużej zmiany „łatką”, by rozstrzygnąć jej status.

CRA wobec innych regulacji

CRA nie zastępuje całego prawa cyberbezpieczeństwa. Ten sam podmiot może mieć równocześnie obowiązki dotyczące produktu, działalności organizacji, danych osobowych i określonego sektora. Wspólny rejestr zdarzeń pomaga, ale kwalifikacja i terminy mogą pozostać różne.

Zgodność z ISO/IEC 27001 lub wdrożenie procesu NIS2 może dostarczyć użytecznych elementów, ale nie potwierdza automatycznie zgodności konkretnego produktu z CRA. Podobnie oznakowanie CE wynikające z wcześniejszych przepisów nie rozstrzyga przyszłego spełnienia wymagań CRA.

Współdzielenie pracy ma sens: inwentaryzacja, kontrola dostępu, zarządzanie dostawcami i obsługa incydentów mogą zasilać kilka procesów. Trzeba jednak przypisać każde wymaganie do właściwej podstawy prawnej. Jedno zdarzenie może uruchomić więcej niż jeden obowiązek zgłoszenia; założenie „wysłaliśmy jeden formularz, więc wszystko załatwione” wymaga sprawdzenia, nie intuicji.

Pięć przykładów praktycznych

Poniższe sytuacje są hipotetyczne. Pokazują tok analizy, nie gotową kwalifikację każdego produktu o podobnej nazwie. W każdym przypadku rozstrzygają funkcje, sposób udostępniania i odpowiedzialność stron.

1. Czujnik IoT z aplikacją i chmurą. Firma sprzedaje czujnik zalania, aplikację i usługę powiadomień. Powinna opisać granicę produktu, sprawdzić rolę zdalnego przetwarzania i uwzględnić aktualizacje urządzenia oraz aplikacji. Jeżeli kończy umowę z dostawcą chmury, musi wiedzieć, co stanie się z funkcjami użytkownika. Najważniejszy rezultat przygotowań to spójny plan wsparcia, obejmujący zależności, a nie trzy nieskoordynowane deklaracje zespołów.

2. Urządzenie przemysłowe z interfejsem serwisowym. Sterownik działa w wydzielonej sieci, bez stałego internetu. To nie wystarcza do wykluczenia CRA. Analiza obejmuje także przewidywalne połączenia, dostęp serwisowy i możliwy wpływ na proces. Aktualizacje wymagają uzgodnionego postoju, więc producent powinien przewidzieć środki łagodzące do czasu instalacji. Hipotetyczny dziesięcioletni okres używania wymaga uzasadnionego modelu utrzymania; nie można bez refleksji przyjąć pięciu lat wsparcia tylko dlatego, że taki okres pojawia się w przepisach.

3. Aplikacja instalowana u klienta. Dostawca sprzedaje program do zarządzania produkcją, który komunikuje się z serwerem i importuje pliki. Brak własnego urządzenia nie wyłącza oprogramowania z analizy. Firma potrzebuje identyfikacji wydań, dokumentacji zależności i kanału dostarczania poprawek. Umowa powinna wyjaśniać odpowiedzialność za instalację oraz wspierane konfiguracje, ale nie może zastąpić obowiązków producenta. Kluczowe pytanie brzmi, czy poprawkę da się wdrożyć bez przymusowego zakupu niezwiązanej funkcji.

4. Samodzielny SaaS do rezerwacji sal. Klient korzysta przez przeglądarkę, nie otrzymuje od dostawcy odrębnego urządzenia. Należy sprawdzić, czy usługa jest samodzielna, czy stanowi zdalny element innego produktu. Nawet jeśli CRA nie obejmie samej usługi, pozostają zobowiązania kontraktowe, RODO i ewentualnie regulacje sektorowe. Jeśli firma później doda sprzedawany terminal lub instalowany agent, analizę zakresu trzeba powtórzyć. Wyłączenie jednej oferty nie staje się trwałym zwolnieniem całej firmy.

5. Biblioteka open source w komercyjnym urządzeniu. Wolontariusze rozwijają bibliotekę, a producent używa jej w routerze. Status projektu i status routera trzeba ocenić oddzielnie. Producent potrzebuje wiedzy o wersji i planu reagowania, gdy opiekun zakończy pracę. Może finansować poprawkę, utrzymywać własną gałąź albo zastąpić komponent. Przerzucenie całego ryzyka na autora bez umowy i zasobów nie stworzy zdolności do utrzymania produktu. Przydatnym dowodem jest przetestowana procedura aktualizacji zależności.

Korzyści, koszty i trudności

Dla użytkownika wartością jest większa przewidywalność: dostępne wsparcie, bezpieczniejsze ustawienia i możliwość otrzymania poprawki. Dla nabywcy biznesowego wspólne wymagania mogą ułatwić porównanie dostawców. To oczekiwane efekty regulacji, a nie gwarancja, że każdy zakup stanie się prosty lub każdy atak zniknie.

Producent z dojrzałym procesem bezpieczeństwa może wykorzystać istniejące kompetencje jako przewagę. Uporządkowana dokumentacja i zależności pomagają też poza formalną oceną: skracają diagnozę błędu, zmniejszają uzależnienie od jednej osoby i ułatwiają rozmowy z klientami. Wspólne zasady rynku mogą ograniczyć część rozbieżnych wymagań zakupowych.

Koszty są jednak realne. Obejmują pracę projektową, testy, utrzymanie wydań, dokumentację, obsługę zgłoszeń i ewentualną ocenę zewnętrzną. W małej firmie stały koszt procesu może stanowić większy udział w przychodach niż u dużego producenta. Nie da się podać jednej uczciwej ceny „wdrożenia CRA” bez znajomości produktu i dojrzałości organizacji.

Możliwe są trudne decyzje o wycofaniu starej linii, ograniczeniu liczby konfiguracji lub podniesieniu ceny. Te skutki należy traktować jako ryzyka biznesowe, nie pewne konsekwencje każdego wdrożenia. Dobrze dobrana automatyzacja może obniżyć powtarzalny koszt, lecz nie zastąpi odpowiedzialności za decyzje i nie naprawi braku dostępu do kodu dostawcy.

Kontrowersje budzi również równowaga między szybkim raportowaniem a ochroną wrażliwych informacji o nieusuniętej podatności. Korzyścią jest szansa na szybszą koordynację; wyzwaniem pozostaje bezpieczny obieg informacji i praca pod presją czasu. Warto odróżnić zasadną krytykę konstrukcji procesu od twierdzenia, że samo raportowanie usuwa problem techniczny.

Dla open source szansą może być większe zainteresowanie finansowaniem utrzymania. Ryzykiem jest przenoszenie nieproporcjonalnych oczekiwań na społeczności. Rozsądne przygotowanie powinno wzmacniać relacje z dostawcami i opiekunami zamiast ograniczać się do wysyłania formularza z żądaniem potwierdzenia pełnej zgodności.

Nadzór i konsekwencje naruszeń

Organy nadzoru rynku będą mogły żądać informacji, oceniać zgodność i nakazywać działania naprawcze. W zależności od sytuacji możliwe będą ograniczenia udostępniania, wycofanie z obrotu lub odzyskanie produktu od użytkowników. Z biznesowego punktu widzenia zatrzymanie sprzedaży lub koszt działań naprawczych może być równie istotny jak kara pieniężna.

Art. 64 przewiduje różne pułapy kar: do 15 mln euro lub 2,5% światowego rocznego obrotu za wskazane najpoważniejsze naruszenia; do 10 mln euro lub 2% za inne wymienione obowiązki; do 5 mln euro lub 1% za określone nieprawidłowe informacje. Dla przedsiębiorstwa stosuje się wyższą z odpowiednich kwot. Są to górne granice, nie automatyczny cennik za każdy błąd.

Przy wymiarze kary znaczenie mają okoliczności, waga i czas naruszenia oraz wielkość podmiotu. Przepis zawiera też szczególne wyłączenia dotyczące opiekunów open source i uchybienia terminowi wczesnego ostrzeżenia przez mikro- i małych producentów. Nie należy traktować ich jako ogólnego zwolnienia z obowiązków, wszystkich terminów lub wszystkich konsekwencji. Szczegółową ocenę sankcji trzeba oprzeć na pełnym art. 64 i właściwych przepisach krajowych.

Plan przygotowań: pierwsze 30, 60 i 90 dni

Poniższy plan jest rekomendacją organizacyjną na start pod koniec kwietnia 2026 r. Nie stanowi ustawowego harmonogramu ani gwarancji zgodności. Jego celem jest uzyskanie sprawdzalnych rezultatów przed wrześniowym obowiązkiem raportowania i rozpoczęcie przygotowań produktowych na 2027 r.

Pierwsze 30 dni: poznać zakres i wyznaczyć odpowiedzialność. Właściciel produktu z zespołem technicznym sporządza listę produktów, wersji i modeli sprzedaży. Osoba odpowiedzialna za kwestie prawne pomaga przypisać role i wyłączenia. Kierownictwo wskazuje właściciela procesu, zastępstwo i budżet. Rezultatem powinny być karty zakresu, wstępna klasyfikacja i lista brakujących informacji, a nie tylko prezentacja szkoleniowa.

Do 60 dni: połączyć produkt z procesem reagowania. Zespół inżynierski wiąże wydania z zależnościami i sposobem aktualizacji. Zakupy lub osoba prowadząca dostawców ustala okresy wsparcia i kanały bezpieczeństwa. Powstaje procedura przyjmowania zgłoszeń, oceny przesłanek i przygotowania informacji dla organów oraz użytkowników. Trzeba rozpoznać produkty, których nie da się dziś zaktualizować bez przebudowy sprzętu.

Do 90 dni: przećwiczyć działanie i zatwierdzić program zmian. Zespół wykonuje ćwiczenie z podatnością lub incydentem, dokumentuje moment uzyskania wiedzy i przygotowuje próbne zgłoszenia. Nie wysyła fikcyjnego incydentu do produkcyjnego kanału. Kierownictwo zatwierdza priorytety, zasoby i harmonogram doprowadzenia produktów do wymagań 2027 r. Zespół sprawdza, które normy i ścieżki oceny mogą być właściwe.

Najczęstsze nieporozumienia warto sprawdzić podczas przeglądu: „jesteśmy za mali”, „nie mamy internetu”, „korzystamy z open source”, „mamy ISO”, „wystarczy poczekać do 2027 roku”. Żadne z tych zdań samo nie rozstrzyga obowiązków. Równie błędne jest utożsamianie każdego alarmu skanera ze zgłoszeniem do ENISA albo traktowanie 14 dni jako terminu naprawy wszystkich podatności.

Podsumowanie

Pod koniec kwietnia 2026 r. najbardziej użyteczna kolejność działań to ustalenie zakresu, przygotowanie raportowania i uruchomienie programu zgodności produktowej. Trzeba jednocześnie obserwować rozwój norm i wytycznych, zachowując rozróżnienie między projektem a obowiązującym przepisem. Przygotowanie zakończy się sukcesem wtedy, gdy firma będzie potrafiła bezpiecznie rozwijać i utrzymywać produkt, a dokumentacja będzie wiernym opisem tej zdolności.

Źródła

• Rozporządzenie (UE) 2024/2847, tekst polski. W szczególności art. 2-3, 13-16, 19-24, 27-32, 64, 69 i 71 oraz załączniki I-IV i VII.
• Rozporządzenie wykonawcze (UE) 2025/2392, opisy techniczne kategorii produktów ważnych i krytycznych, 28 listopada 2025 r.
• Rozporządzenie delegowane (UE) 2025/1535, wyłączenie określonych produktów objętych rozporządzeniem 168/2013; nie jest to zwolnienie całej branży.
• Komisja Europejska: projekt wytycznych CRA, 3 marca 2026 r.. Źródło informacji o statusie prac, nie ostateczna wykładnia.
• Komisja Europejska: podsumowanie CRA, aktualizacja 3 grudnia 2025 r.. Pomoc w nawigacji; rozstrzygający pozostaje akt prawny.
• Rolling Plan for ICT Standardisation 2026: cyberbezpieczeństwo, kontekst zlecenia normalizacyjnego M/606.
• Dyrektywa NIS2, 2022/2555, RODO, 2016/679, RED, 2014/53/UE, DORA, 2022/2554 i AI Act, 2024/1689. Podstawy porównania zakresów, nie pełny poradnik stosowania każdego aktu.