Cyber Resilience Act — czy Twoje oprogramowanie lub urządzenie podlega CRA i jak je prawidłowo zakwalifikować?

Cyber Resilience Act będzie jedną z największych zmian dla producentów oprogramowania i sprzętu wprowadzanych na rynek Unii Europejskiej. Dla branży technologicznej szczególnie istotny jest fakt, że regulacja nie jest kolejną dyrektywą wymagającą odrębnego wdrożenia w każdym państwie. CRA jest rozporządzeniem unijnym i będzie stosowany bezpośrednio.

Główne obowiązki zaczną być stosowane 11 grudnia 2027 r. Nie oznacza to jednak, że firmy mogą bezpiecznie odłożyć analizę na przyszły rok.

Pierwsze obowiązki zaczynają działać znacznie wcześniej. Już od 11 września 2026 r., a więc za kilka dni, stosowany będzie art. 14 dotyczący raportowania określonych aktywnie wykorzystywanych podatności i poważnych incydentów wpływających na bezpieczeństwo produktów z elementami cyfrowymi.

Dla producentów oprogramowania oznacza to konieczność odpowiedzi na znacznie bardziej podstawowe pytanie: czy ich produkt w ogóle znajduje się w zakresie Cyber Resilience Act?

Co obejmuje Cyber Resilience Act?

CRA dotyczy produktów z elementami cyfrowymi udostępnianych na rynku Unii.

Pojęcie to obejmuje produkty programowe i sprzętowe oraz związane z nimi rozwiązania zdalnego przetwarzania danych. Mogą nim być również komponenty software’owe i hardware’owe wprowadzane do obrotu oddzielnie. (Cyfrowa Strategia Europy)

Regulacja jest zatem bardzo szeroka. Może obejmować aplikacje desktopowe, systemy operacyjne, oprogramowanie zabezpieczające, narzędzia sieciowe, urządzenia IoT, routery, inteligentne urządzenia domowe, biblioteki dystrybuowane komercyjnie i wiele innych produktów.

Nie należy jednak zakładać, że każde świadczenie usługi informatycznej jest automatycznie produktem objętym CRA. Kluczowe jest prawidłowe ustalenie charakteru rozwiązania.

Dlaczego kwalifikacja jest potrzebna już teraz?

11 września 2026 r. zaczynają być stosowane obowiązki raportowe.

Co szczególnie istotne, Komisja wskazuje, że obowiązki raportowe mogą dotyczyć również produktów z elementami cyfrowymi udostępnionych na rynku przed pełnym rozpoczęciem stosowania CRA. Główne wymagania produktowe rozpoczną się 11 grudnia 2027 r., ale art. 14 jest wyjątkiem obowiązującym wcześniej.

Firma posiadająca już sprzedawany produkt nie powinna więc zakładać, że cały temat CRA może przeanalizować dopiero pod koniec 2027 r. Potrzebna jest wcześniejsza inwentaryzacja produktów i kwalifikacja.

Produkt z elementami cyfrowymi

Podstawowym pytaniem jest to, czy dane rozwiązanie jest produktem z elementami cyfrowymi. CRA obejmuje software i hardware wprowadzany albo udostępniany na rynku.

Przykładowo klasyczna aplikacja sprzedawana klientom jako licencjonowane oprogramowanie będzie zasadniczo znacznie łatwiejsza do zakwalifikowania niż usługa polegająca wyłącznie na wykonywaniu indywidualnych prac programistycznych.

Trzeba również przeanalizować komponenty. Firma może nie sprzedawać kompletnej aplikacji końcowemu konsumentowi, ale udostępniać bibliotekę albo moduł używany przez innych producentów. Taki komponent również może znajdować się w zakresie regulacji.

Co ze zdalnym przetwarzaniem danych?

CRA uwzględnia rozwiązania zdalnego przetwarzania danych stanowiące część produktu.

Komisja wyjaśnia je jako zdalne przetwarzanie, dla którego oprogramowanie zostało zaprojektowane i rozwinięte przez producenta lub na jego odpowiedzialność i którego brak uniemożliwiłby produktowi wykonanie jednej z jego funkcji.

Ma to duże znaczenie dla współczesnych urządzeń. Inteligentne urządzenie może posiadać lokalny firmware, ale część funkcji realizować za pomocą chmury producenta. Takie zdalne elementy nie powinny być analizowane jako całkowicie odrębny świat.

W praktyce trzeba zbadać architekturę całej usługi.

Czy SaaS podlega CRA?

Nie każdy SaaS powinien być automatycznie kwalifikowany jako produkt z elementami cyfrowymi. CRA jest regulacją produktową, a nie ogólną regulacją wszystkich usług cyfrowych.

Jeżeli przedsiębiorca oferuje wyłącznie usługę uruchomioną na własnych serwerach, sytuacja wymaga dokładnej oceny. Jeżeli jednak usługa jest powiązana z produktem programowym albo sprzętowym w taki sposób, że zdalne przetwarzanie jest elementem niezbędnym dla jego funkcji, może być objęta zakresem produktu.

Kwalifikacja nie powinna więc polegać na prostym pytaniu „czy jest to SaaS?”, lecz na analizie architektury, modelu udostępnienia i funkcji.

Kim jest producent?

Większość obowiązków CRA skierowana jest do producenta. Producentem jest podmiot, który opracowuje lub wytwarza produkt z elementami cyfrowymi albo zleca jego zaprojektowanie lub wytworzenie i wprowadza go na rynek pod własną nazwą lub znakiem towarowym.

To bardzo ważne dla software house’ów. Firma może stworzyć aplikację technicznie, ale producentem w rozumieniu CRA może zostać klient, jeżeli produkt jest następnie wprowadzany na rynek pod marką klienta.

Nie oznacza to, że software house nie ponosi żadnych obowiązków kontraktowych. Klient prawdopodobnie będzie wymagał od niego bezpieczeństwa procesu developmentu, informacji o podatnościach, dokumentacji technicznej i współpracy przy raportowaniu.

Prawna rola regulatorowa i odpowiedzialność kontraktowa nie są jednak tym samym.

White label i sprzedaż pod własną marką

Szczególnego ryzyka wymagają modele white label. Przedsiębiorca może kupić gotowy produkt od innej firmy, umieścić własne logo i oferować go jako własne rozwiązanie.

W zależności od konstrukcji współpracy może przejąć rolę producenta. Nie powinien zakładać, że wszystkie obowiązki pozostają u rzeczywistego twórcy kodu. Przed wprowadzeniem rozwiązania pod własną marką trzeba ustalić role stron również z perspektywy CRA.

Importer i dystrybutor

CRA nakłada obowiązki nie tylko na producentów. Importer to podmiot z UE wprowadzający na rynek produkt z elementami cyfrowymi pochodzący od producenta spoza Unii. Importer będzie musiał weryfikować zgodność produktu, dokumentację, procedurę oceny zgodności oraz oznakowanie CE.

Dystrybutor udostępniający produkt na rynku bez zmiany jego właściwości również posiada własne obowiązki kontrolne. Firma, która nie tworzy żadnego kodu, może więc podlegać CRA jako uczestnik łańcucha dostaw.

Oprogramowanie open source

CRA wprowadza szczególne podejście do wolnego i otwartego oprogramowania. Samo tworzenie kodu open source bez komercyjnego udostępniania produktu nie oznacza automatycznie pełnych obowiązków producenta.

Komisja wskazuje, że bezpłatne i otwarte oprogramowanie jest objęte głównymi obowiązkami, gdy jest udostępniane na rynku w ramach działalności komercyjnej. Jednocześnie CRA wprowadza szczególną kategorię open-source software steward, obejmującą określone osoby prawne systematycznie wspierające rozwój takich produktów przeznaczonych do działalności komercyjnej.

Firma wykorzystująca komponenty open source we własnym produkcie nie powinna jednak zakładać, że odpowiedzialność za bezpieczeństwo automatycznie przechodzi na społeczność tworzącą bibliotekę.

Producent końcowego produktu nadal musi analizować ryzyko związane z komponentami.

Produkt zwykły, ważny czy krytyczny?

Nie wszystkie produkty objęte CRA podlegają identycznej procedurze oceny zgodności.

Rozporządzenie wprowadza kategorie ważnych produktów z elementami cyfrowymi klasy I i II oraz produktów krytycznych. Produkty należące do tych kategorii wskazane są w odpowiednich załącznikach, a szczegółowe opisy techniczne zostały rozwinięte w aktach wykonawczych.

Kwalifikacja ma ogromne znaczenie, ponieważ wpływa na sposób wykazywania zgodności. Producent zwykłego produktu może w wielu przypadkach korzystać z samooceny.

W przypadku ważnych produktów klasy II i produktów krytycznych może być wymagana ocena przez jednostkę zewnętrzną albo odpowiedni system certyfikacji.

Dla produktów klasy I możliwość samooceny zależy między innymi od zastosowania odpowiednich norm zharmonizowanych, wspólnych specyfikacji albo certyfikacji.

Dlaczego nie warto czekać na 2027 r.?

Proces zgodności CRA dotyczy całego cyklu życia produktu. Nie wystarczy przygotować deklaracji kilka tygodni przed datą pełnego rozpoczęcia stosowania rozporządzenia.

Producent powinien przeprowadzić ocenę ryzyka cyberbezpieczeństwa i uwzględniać jej wyniki podczas planowania, projektowania, developmentu, produkcji, dostarczania i utrzymania produktu.

Jeżeli aplikacja jest obecnie rozwijana bez odpowiedniego systemu zarządzania podatnościami, dokumentacji komponentów i bezpiecznego cyklu developmentu, odtworzenie wymaganej dokumentacji za rok może być bardzo kosztowne.

CRA powinien więc zacząć wpływać na proces R&D wcześniej niż 11 grudnia 2027 r.

Zasadnicze wymagania cyberbezpieczeństwa

CRA wymaga, aby produkt zapewniał poziom cyberbezpieczeństwa odpowiedni do ryzyka.

Produkt powinien być projektowany i wytwarzany w taki sposób, aby ograniczać podatności, posiadać bezpieczną konfigurację oraz odpowiednie mechanizmy ochrony. Załącznik I rozporządzenia określa szczegółowe wymagania dotyczące właściwości produktu i obsługi podatności.

Producent nie powinien traktować bezpieczeństwa jako opcjonalnej funkcji dodawanej po zakończeniu developmentu. CRA w praktyce wspiera model secure by design i secure by default.

Ocena ryzyka cyberbezpieczeństwa

Jednym z podstawowych dokumentów będzie ocena ryzyka cyberbezpieczeństwa konkretnego produktu. Nie powinna być jedną ogólną oceną całej spółki.

Trzeba zidentyfikować funkcje produktu, możliwe zagrożenia, podatności, sposób użytkowania, możliwe skutki ataku i zabezpieczenia. Analiza powinna obejmować również komponenty osób trzecich.

W przypadku rozbudowanego systemu szczególne znaczenie będzie miała dokumentacja architektury, przepływów danych i zależności.

Vulnerability handling

CRA wprowadza obowiązki dotyczące zarządzania podatnościami przez okres wsparcia produktu. Firma powinna posiadać proces przyjmowania zgłoszeń, oceny podatności, ich naprawiania i udostępniania aktualizacji.

Nie powinno to być działanie ad hoc realizowane dopiero po otrzymaniu krytycznej informacji. Należy ustalić odpowiedzialność zespołów, terminy i kanały komunikacji.

System zarządzania podatnościami jest szczególnie istotny właśnie teraz z uwagi na obowiązki raportowe rozpoczynające się 11 września 2026 r.

Raportowanie od 11 września 2026 r.

Art. 14 CRA zaczyna być stosowany 11 września 2026 r.

Obejmuje on obowiązki producentów związane z raportowaniem określonych aktywnie wykorzystywanych podatności oraz poważnych incydentów mających wpływ na bezpieczeństwo produktu.

Oznacza to, że firma posiadająca produkt już obecny na rynku powinna przed tą datą ustalić wewnętrzną procedurę eskalacji. Programista, helpdesk albo security researcher może jako pierwszy otrzymać informację o problemie. Jeżeli informacja pozostanie przez kilka dni w skrzynce osoby technicznej, organizacja może stracić możliwość terminowego wykonania obowiązku.

Konieczne jest więc określenie osób odpowiedzialnych, kanału zgłoszenia i procesu kwalifikacji.

Dokumentacja techniczna

Producent będzie zobowiązany przygotować dokumentację pozwalającą wykazać zgodność produktu. Powinna ona pozostawać spójna z rzeczywistą architekturą, analizą ryzyka i procesem developmentu.

W praktyce mogą być potrzebne opisy produktu, architektury, funkcji bezpieczeństwa, procesu aktualizacji, komponentów, wyników testów i zastosowanych norm.

Dokumentacja nie powinna być tworzona dopiero po ukończeniu produktu. Najłatwiej budować ją równolegle z developmentem.

Oznakowanie CE i deklaracja zgodności

Po wykazaniu zgodności produkt objęty CRA będzie podlegał wymaganiom dotyczącym unijnej deklaracji zgodności oraz oznakowania CE. Komisja podkreśla, że oznakowanie CE będzie sygnalizowało zgodność produktu z wymaganiami CRA.

Dla części producentów oprogramowania będzie to nowa sytuacja. CE kojarzy się zwykle z urządzeniami fizycznymi, ale CRA obejmuje również software. Dlatego już podczas kwalifikacji należy ustalić, jakie obowiązki formalne będą dotyczyć danego produktu.

Informacje dla użytkownika

Produkt powinien być wyposażony w informacje i instrukcje umożliwiające jego bezpieczną instalację i używanie. Załącznik II CRA określa wymagania dotyczące informacji przekazywanych użytkownikowi.

Może to oznaczać konieczność zmiany instrukcji, dokumentacji internetowej i interfejsu produktu. Producent powinien informować między innymi o istotnych warunkach bezpieczeństwa i okresie wsparcia.

Okres wsparcia

CRA zmienia podejście do odpowiedzialności producenta po sprzedaży. Producent musi zarządzać podatnościami również w okresie wsparcia.

Dlatego już na etapie projektowania produktu należy ustalić, jak długo będzie on utrzymywany i aktualizowany. Nie jest dobrym rozwiązaniem sprzedawanie produktu bez jasnego planu bezpieczeństwa po zakończeniu pierwszego roku.

Okres wsparcia powinien uwzględniać charakter produktu i racjonalny okres jego używania.

Co powinna zawierać analiza kwalifikacyjna CRA?

Pierwszym etapem powinien być opis rozwiązania. Należy ustalić, czy jest ono software’em, sprzętem, komponentem, usługą czy połączeniem tych elementów.

Kolejnym krokiem jest analiza sposobu udostępnienia na rynku i ustalenie, kto jest producentem. Następnie trzeba sprawdzić wyłączenia, model open source oraz zdalne przetwarzanie danych.

Jeżeli CRA ma zastosowanie, konieczna jest kwalifikacja produktu jako zwykłego, ważnego klasy I, ważnego klasy II albo krytycznego. Dopiero z tej kwalifikacji wynika odpowiednia ścieżka oceny zgodności.

Jak przygotować firmę do CRA?

Pierwszym krokiem nie powinno być przygotowanie ogólnej polityki. Najpierw trzeba stworzyć inwentaryzację produktów.

Dla każdego rozwiązania należy określić jego status, rolę spółki, etap życia, komponenty i kanały dystrybucji. Następnie można ustalić lukę między obecnym procesem developmentu a wymaganiami CRA.

W wielu firmach najważniejsze zmiany będą dotyczyć secure development lifecycle, zarządzania podatnościami, dokumentacji komponentów, raportowania i utrzymywania produktu przez określony okres.

Dlaczego kwalifikacja CRA ma znaczenie również dla software house’u?

Software house może nie być producentem produktu klienta, ale będzie musiał dostarczać informacje potrzebne producentowi do wykazania zgodności.

W nowych kontraktach klienci mogą wymagać dokumentacji komponentów, testów, terminowego informowania o podatnościach i wsparcia w przygotowaniu dokumentacji technicznej.

Może pojawić się także odpowiedzialność za koszt dostosowania produktu do CRA. Dlatego umowy wdrożeniowe zawierane już w 2026 r. powinny określać, kto odpowiada za wymagania CRA.

Bez takiej regulacji pod koniec projektu może powstać spór, czy przygotowanie dokumentacji zgodności znajdowało się w cenie.

Podsumowanie

Cyber Resilience Act nie powinien być traktowany jako problem na koniec 2027 r. Pierwsze obowiązki dotyczące raportowania zaczynają obowiązywać już 11 września 2026 r.

Przedsiębiorstwa technologiczne powinny więc już teraz ustalić, które ich rozwiązania są produktami z elementami cyfrowymi i jaką rolę pełni firma w łańcuchu dostaw. Konieczne może być rozróżnienie producenta, importera i dystrybutora, ustalenie zasad dotyczących open source oraz zakwalifikowanie produktu do właściwej kategorii.

Kwalifikacja jest punktem wyjścia do dalszego wdrożenia. Dopiero później można określić wymagany proces oceny zgodności, dokumentację, analizę ryzyka, zasady zarządzania podatnościami i obowiązki informacyjne.

Dla software house’ów CRA będzie miał znaczenie nawet wtedy, gdy formalnym producentem jest klient. Wymagania dotyczące bezpieczeństwa i dokumentacji będą bowiem coraz częściej przenoszone na wykonawców w kontraktach IT.

Im wcześniej organizacja ustali, które produkty obejmuje CRA, tym łatwiej będzie wbudować zgodność w proces rozwoju, zamiast próbować odtworzyć całą dokumentację tuż przed 11 grudnia 2027 r.