Kupujemy router, kamerę IP, serwer NAS, komputer albo inteligentne urządzenie podłączone do Internetu. Sprzęt działa, producent zapewnia kilka aktualizacji, a po pewnym czasie wsparcie się kończy. Urządzenie nadal może działać bez zarzutu, ale z punktu widzenia cyberbezpieczeństwa zaczyna się problem. Pojawiają się nowe podatności, zmieniają się metody ataków, a użytkownik często nawet nie wie, że jego sprzęt od miesięcy lub lat nie otrzymuje już poprawek bezpieczeństwa. Unia Europejska chce ten model zasadniczo zmienić. Temu właśnie służy Cyber Resilience Act, czyli unijne rozporządzenie dotyczące cyberbezpieczeństwa produktów z elementami cyfrowymi.
Cyber Resilience Act, w skrócie CRA, to Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/2847. Jego założenie jest stosunkowo proste, choć konsekwencje będą bardzo szerokie: produkt cyfrowy ma być bezpieczny nie tylko w chwili sprzedaży, lecz przez cały przewidywany okres jego użytkowania. Producent nie może więc traktować cyberbezpieczeństwa jako dodatku, który można uwzględnić dopiero wtedy, gdy pojawi się poważny problem. Bezpieczeństwo ma być elementem projektowania, produkcji, dystrybucji, aktualizacji i obsługi produktu przez cały jego cykl życia.
Regulacja weszła w życie 10 grudnia 2024 roku, ale jej stosowanie zostało rozłożone w czasie. Jedna z najważniejszych dat przypada na 11 września 2026 roku. Od tego momentu zaczynają obowiązywać określone wymogi związane z raportowaniem aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktów. Zasadnicza część wymagań CRA będzie natomiast stosowana od 11 grudnia 2027 roku. Dla producentów, importerów i dystrybutorów oznacza to, że przygotowania nie mogą rozpocząć się dopiero pod koniec 2027 roku. W praktyce wiele firm już teraz musi uporządkować dokumentację, polityki bezpieczeństwa, proces aktualizacji i sposób zarządzania podatnościami.
Zakres CRA jest bardzo szeroki. Rozporządzenie dotyczy tak zwanych produktów z elementami cyfrowymi. W uproszczeniu chodzi o sprzęt lub oprogramowanie, którego przewidywane użycie obejmuje bezpośrednie albo pośrednie połączenie z urządzeniem lub siecią. To sprawia, że nowe regulacje mogą obejmować komputery, routery, przełączniki sieciowe, firewalle, urządzenia Wi-Fi, kamery IP, rejestratory monitoringu, serwery NAS, urządzenia IoT, systemy operacyjne, aplikacje i wiele innych produktów wyposażonych w funkcje cyfrowe. Nie oznacza to oczywiście, że każde urządzenie elektroniczne automatycznie podlega CRA, ale w przypadku współczesnej infrastruktury IT zakres zastosowania rozporządzenia będzie bardzo duży.
Jedną z najważniejszych idei CRA jest zasada „security by design”, czyli bezpieczeństwa uwzględnianego już na etapie projektowania. Dotychczas producenci bardzo często koncentrowali się na funkcjonalności, cenie i szybkości wprowadzenia produktu na rynek. Bezpieczeństwo bywało traktowane jako kwestia dodatkowa. CRA ma wymusić inne podejście. Producent powinien przeprowadzać ocenę ryzyka cyberbezpieczeństwa i uwzględniać jej wyniki w czasie projektowania, rozwijania, wytwarzania, dostarczania i utrzymywania produktu. W praktyce oznacza to, że pytanie „czy urządzenie działa?” przestaje być wystarczające. Równie ważne staje się pytanie „czy urządzenie zostało zaprojektowane tak, aby ograniczać ryzyko ataku?”.
Z tym wiąże się druga ważna zasada, czyli „security by default”. Produkt powinien być bezpieczny w konfiguracji domyślnej. Użytkownik nie powinien być zmuszony do wykonywania skomplikowanych czynności, aby dopiero po kilku godzinach konfiguracji urządzenie osiągnęło podstawowy poziom bezpieczeństwa. Przez lata rynek IT znał przypadki urządzeń wyposażonych w proste domyślne hasła, identyczne dane logowania, otwarte usługi sieciowe lub przestarzałe protokoły aktywne już po wyjęciu sprzętu z pudełka. Cyber Resilience Act ma ograniczać takie praktyki.
Bardzo istotnym elementem nowych przepisów jest także kwestia aktualizacji bezpieczeństwa. W praktyce to właśnie tutaj użytkownicy mogą najbardziej odczuć wpływ CRA. Dziś nierzadko zdarza się, że urządzenie technicznie działa przez osiem czy dziesięć lat, ale producent przestaje wydawać dla niego aktualizacje znacznie wcześniej. Z punktu widzenia użytkownika sprzęt jest sprawny, natomiast z punktu widzenia bezpieczeństwa staje się coraz bardziej ryzykowny. CRA zmierza do tego, aby producenci jasno określali okres wsparcia produktu i zapewniali w tym czasie właściwą obsługę podatności oraz poprawki bezpieczeństwa.
Nie oznacza to jednak, że każdy produkt będzie musiał otrzymywać aktualizacje dokładnie przez pięć lat. Zasada jest bardziej złożona. Producent powinien określić okres wsparcia z uwzględnieniem przewidywanego czasu użytkowania produktu, charakteru urządzenia, oczekiwań użytkowników i warunków eksploatacji. Co do zasady okres ten powinien wynosić co najmniej pięć lat, chyba że przewidywany czas użytkowania produktu jest krótszy. To ważne, ponieważ w obiegu pojawiło się uproszczenie, że CRA narzuca bezwzględne pięć lat aktualizacji dla każdego sprzętu. Takie stwierdzenie nie jest precyzyjne.
Zmieni się również sposób informowania klienta. Użytkownik powinien otrzymywać jasną informację o okresie wsparcia produktu. Ma to duże znaczenie przy zakupach sprzętu IT. Dzisiaj łatwo porównać dwa urządzenia pod względem procesora, pamięci RAM, pojemności dysku czy liczby portów. Trudniej natomiast odpowiedzieć na pytanie, jak długo producent będzie łatał podatności bezpieczeństwa. W przyszłości może to stać się jednym z podstawowych parametrów zakupowych. Router kosztujący 350 zł, ale wspierany krótko, może być w praktyce gorszym wyborem niż model za 500 zł, którego producent gwarantuje wieloletnie aktualizacje.
Cyber Resilience Act wprowadza również rozbudowane wymagania dotyczące zarządzania podatnościami. Producent powinien być w stanie identyfikować luki, dokumentować je, analizować ich wpływ, przygotowywać środki naprawcze, publikować aktualizacje bezpieczeństwa i odpowiednio komunikować się z użytkownikami. Ma to szczególne znaczenie w świecie, w którym współczesne oprogramowanie rzadko powstaje całkowicie od zera. Programy, systemy i urządzenia wykorzystują dziesiątki, a często setki bibliotek i komponentów tworzonych przez inne podmioty. Podatność w jednym z nich może wpływać na bezpieczeństwo wielu różnych produktów. Producent nie może więc patrzeć wyłącznie na własny kod. Musi uwzględniać bezpieczeństwo całego łańcucha dostaw oprogramowania.
To właśnie łańcuch dostaw może być jednym z największych wyzwań. Router może korzystać z systemu Linux, biblioteki kryptograficznej, serwera WWW, sterowników tworzonych przez zewnętrznych producentów i wielu modułów Open Source. Jeżeli w którymś z tych komponentów pojawi się krytyczna podatność, jej skutki mogą dotyczyć całego urządzenia. CRA wprowadza więc większą odpowiedzialność za monitorowanie bezpieczeństwa wykorzystywanych komponentów.
Szczególne znaczenie mają obowiązki raportowania, które zaczynają obowiązywać wcześniej niż zasadnicza część rozporządzenia. Od 11 września 2026 roku producenci będą musieli reagować bardzo szybko na określone aktywnie wykorzystywane podatności oraz poważne incydenty. Pierwsze ostrzeżenie ma być przekazane w ciągu 24 godzin od uzyskania wiedzy o zdarzeniu, a bardziej szczegółowe zgłoszenie w terminie 72 godzin. To oznacza, że organizacja nie może dopiero po ataku zastanawiać się, kto odpowiada za zgłoszenie, gdzie znajdują się dane techniczne i kto podejmuje decyzje. Procedury reakcji na incydenty muszą być przygotowane wcześniej.
Warto również wyjaśnić, czym różni się zwykła podatność od podatności aktywnie wykorzystywanej. Każdego dnia na świecie odkrywane są nowe błędy bezpieczeństwa. Nie wszystkie są od razu używane przez cyberprzestępców. Sytuacja staje się dużo poważniejsza wtedy, gdy istnieją wiarygodne dowody, że luka jest rzeczywiście wykorzystywana do przeprowadzania ataków. W takim przypadku nie mówimy już jedynie o potencjalnym zagrożeniu, ale o realnym ryzyku dla użytkowników.
CRA łączy cyberbezpieczeństwo również z systemem oceny zgodności. Producent przed wprowadzeniem produktu na rynek będzie musiał przeprowadzić odpowiednią procedurę oceny zgodności, przygotować dokumentację techniczną oraz deklarację zgodności UE. W przypadku produktów objętych CRA cyberbezpieczeństwo staje się więc elementem regulacyjnej oceny produktu i może mieć wpływ na oznakowanie CE. To ważna zmiana, ponieważ CE kojarzono dotychczas głównie z bezpieczeństwem fizycznym, elektrycznym czy kompatybilnością elektromagnetyczną. W praktyce dochodzi kolejny bardzo istotny wymiar – bezpieczeństwo cyfrowe.
Nie wszystkie produkty będą jednak traktowane identycznie. CRA przewiduje szczególne kategorie produktów ważnych i krytycznych z punktu widzenia cyberbezpieczeństwa. W zależności od kategorii różnić się mogą wymagania dotyczące oceny zgodności. Dla części produktów wystarczające mogą być określone procedury prowadzone przez producenta, natomiast dla bardziej wrażliwych rozwiązań konieczna może być ocena z udziałem strony trzeciej albo wykorzystanie właściwego systemu certyfikacji.
Najwięcej obowiązków spoczywa oczywiście na producencie. To on odpowiada za ocenę ryzyka, bezpieczny projekt, dokumentację, obsługę podatności, aktualizacje, monitorowanie komponentów, wymagane informacje dla użytkowników i właściwe procedury zgodności. Nie oznacza to jednak, że importer lub dystrybutor mogą całkowicie przerzucić odpowiedzialność na producenta. Importer, szczególnie gdy sprowadza sprzęt spoza Unii Europejskiej, ma własne obowiązki związane z weryfikacją zgodności produktu. Dystrybutor również powinien działać z należytą starannością i sprawdzać określone elementy dokumentacji oraz oznakowania.
Dla sprzedawców i integratorów IT może to oznaczać istotną zmianę podejścia do budowania oferty. Coraz ważniejsze będą pytania o to, kto jest producentem i importerem, jaki jest deklarowany okres wsparcia, jak wygląda polityka aktualizacji, czy producent posiada procedurę zgłaszania podatności i jak szybko reaguje na problemy bezpieczeństwa. W dłuższej perspektywie może się okazać, że samo porównanie ceny i parametrów technicznych nie wystarczy do odpowiedzialnego wyboru sprzętu.
Dobrym przykładem jest router wykorzystywany w małej firmie. Urządzenie może działać przez siedem lat. Internet będzie dostępny, Wi-Fi będzie działać, VPN będzie się zestawiał, a diody na obudowie będą świecić dokładnie tak samo jak pierwszego dnia. Jeżeli jednak producent zakończył wsparcie po dwóch latach, a w kolejnych latach odkryto kilka krytycznych podatności, router może stać się jednym z najsłabszych punktów całej infrastruktury. Dla użytkownika wizualnie nic się nie zmienia. Z punktu widzenia cyberbezpieczeństwa ryzyko rośnie.
Podobnie jest z kamerami IP. Kamera może bez problemu pracować przez dekadę. Jeżeli jednak firmware zawiera podatność pozwalającą na zdalne przejęcie urządzenia, taki sprzęt może stać się bramą do firmowej sieci. Dlatego pytanie „czy kamera jeszcze działa?” powinno zostać zastąpione pytaniem „czy kamera nadal jest wspierana i bezpieczna?”.
Jeszcze poważniejsze konsekwencje mogą dotyczyć serwerów NAS. Na takich urządzeniach przechowywane są dokumenty, bazy danych, kopie zapasowe, dane księgowe, projekty, informacje o klientach i często praktycznie całe cyfrowe archiwum firmy. Jeżeli urządzenie przestaje otrzymywać poprawki bezpieczeństwa, dalsza eksploatacja powinna być analizowana pod kątem ryzyka, a nie wyłącznie sprawności technicznej.
Cyber Resilience Act może wpłynąć także na sposób prowadzenia zamówień publicznych. Urzędy, szkoły, jednostki samorządu terytorialnego i inne instytucje kupują ogromne ilości sprzętu. Do tej pory specyfikacje bardzo często skupiały się na przekątnej ekranu, procesorze, pamięci RAM, pojemności, liczbie portów czy długości gwarancji. W przyszłości coraz większego znaczenia mogą nabierać również okres wsparcia bezpieczeństwa, polityka aktualizacji, możliwość zgłaszania podatności czy dokumentacja dotycząca cyklu życia produktu. To może ograniczyć zakupy urządzeń, które są tanie na początku, ale szybko stają się problemem bezpieczeństwa.
Warto także odróżnić CRA od dyrektywy NIS2. Te dwa pojęcia często pojawiają się obok siebie i bywają mylone. W największym uproszczeniu NIS2 koncentruje się przede wszystkim na cyberbezpieczeństwie organizacji i podmiotów, natomiast Cyber Resilience Act dotyczy produktów z elementami cyfrowymi. Można powiedzieć, że NIS2 zadaje pytanie: „czy organizacja jest właściwie zabezpieczona?”, a CRA: „czy produkt został zaprojektowany, wyprodukowany, utrzymywany i aktualizowany w bezpieczny sposób?”. Te regulacje nie konkurują ze sobą. W praktyce wzajemnie się uzupełniają.
Istotnym zagadnieniem jest również Open Source. CRA nie oznacza, że każdy programista publikujący darmowy kod na otwartym repozytorium automatycznie otrzymuje pełen zestaw obowiązków producenta. Rozporządzenie przewiduje szczególne podejście do wolnego i otwartego oprogramowania, zwłaszcza gdy nie jest ono udostępniane w ramach działalności komercyjnej. Jednocześnie wprowadza pojęcie podmiotów wspierających rozwój oprogramowania Open Source wykorzystywanego komercyjnie. Ma to znaczenie, bo ogromna część współczesnych systemów IT bazuje właśnie na otwartych komponentach.
Dla przedsiębiorców najważniejsze pytanie brzmi jednak: co zrobić już teraz? Przede wszystkim warto zacząć od inwentaryzacji produktów i systemów. Producent powinien wiedzieć, które jego produkty mogą podlegać CRA, jak wyglądają procesy aktualizacji i zarządzania podatnościami oraz czy posiada odpowiednią dokumentację. Importer powinien przeanalizować pochodzenie sprzętu i zakres własnej odpowiedzialności. Dystrybutor powinien zwracać większą uwagę na dokumentację producenta i realny cykl wsparcia oferowanych urządzeń. Firmy kupujące sprzęt powinny natomiast zacząć traktować długość wsparcia jako jeden z podstawowych parametrów zakupowych.
To właśnie może być największa zmiana, jaką przyniesie Cyber Resilience Act. Przez lata rynek IT przyzwyczajał nas do porównywania cyferek: procesorów, gigabajtów, przepustowości, liczby rdzeni i portów. Cyberbezpieczeństwo było znacznie trudniejsze do zmierzenia. CRA nie sprawi, że nagle wszystkie produkty staną się odporne na ataki. Może jednak wymusić większą transparentność i odpowiedzialność producentów.
Najtańszy sprzęt nie zawsze jest najtańszy w całym okresie użytkowania. Urządzenie droższe o 20 czy 30 procent, ale wspierane przez wiele lat, może w praktyce okazać się bardziej opłacalne niż tańszy sprzęt, który po krótkim czasie przestaje otrzymywać poprawki. Coraz większego znaczenia będzie nabierał więc całkowity koszt posiadania, czyli TCO, a w jego ramach nie tylko zużycie energii czy koszt serwisu, ale także długość bezpiecznego cyklu życia produktu.
Nie oznacza to również, że 11 grudnia 2027 roku cały starszy sprzęt trzeba będzie natychmiast wymienić. Taka interpretacja byłaby błędna. Cyber Resilience Act nie jest datą ważności wszystkich komputerów, routerów i urządzeń IoT znajdujących się już na rynku. Zasady przejściowe są bardziej złożone, a znaczenie ma między innymi moment wprowadzenia produktu do obrotu oraz ewentualne istotne modyfikacje. Osobno należy traktować wcześniej zaczynające obowiązywać wymogi raportowania.
Najważniejszy efekt CRA może więc nie być wcale prawny, lecz mentalny. Do tej pory kupując urządzenie pytaliśmy przede wszystkim: „czy spełnia moje wymagania?”. W najbliższych latach coraz częściej powinniśmy pytać również: „czy będzie bezpieczne przez cały okres, przez który chcę go używać?”.
Cyber Resilience Act wprowadza zasadę, że bezpieczeństwo produktu cyfrowego nie kończy się w chwili wystawienia faktury. Producent ma odpowiadać za sposób zaprojektowania urządzenia, za podatności, za aktualizacje i za bezpieczeństwo w całym okresie wsparcia. Importerzy i dystrybutorzy otrzymują własne obowiązki, a użytkownicy mogą zyskać większą przejrzystość dotyczącą tego, jak długo kupowany sprzęt będzie rzeczywiście wspierany.
W świecie, w którym niemal każdy element infrastruktury – od komputera i routera po kamerę, drukarkę czy serwer NAS – staje się częścią sieci, taki sposób myślenia jest coraz bardziej potrzebny. Sprzęt może być technicznie sprawny, a jednocześnie niebezpieczny. Cyber Resilience Act ma sprawić, że ten drugi aspekt nie będzie już traktowany jako problem, którym użytkownik musi radzić sobie sam.
