CRA. Odporność produktów z elementami cyfrowymi
Michał Nowakowski · 23 sierpnia 2026
CRA. Trzy literki, które dzisiaj może niespecjalnie budzą w nas niepokój, ale sytuacja może się zmienić w przyszłym roku. Dlaczego?
CRA. Trzy literki, które dzisiaj może niespecjalnie budzą w nas niepokój, ale sytuacja może się zmienić w przyszłym roku. Dlaczego?
Cyberresilience Act, bo o nim mowa to rozporządzenie unijne, które po cichu może wprowadzić zamieszanie, gdy w pełni zacznie obowiązywać od 11 grudnia 2027 roku (a częściowo już we wrześniu br.). Czego właściwie dotyczy? W skrócie - bezpieczeństwa tzw. produktów z elementami cyfrowymi. Jakich produktów?
Jakimś cudem umknął mi fakt, że pod koniec lipca Komisja (UE) opublikowała wytyczne w sprawie stosowania CRA, w którym poruszono bardzo wiele wątków, w tym rozumienie centralnego zagadnienia, czyli znaczenia „produktu z elementami cyfrowymi”. Na pozór jest to dość proste, bo według samego rozporządzenia jest to:
„oprogramowanie komputerowe lub sprzęt komputerowy oraz powiązane z nimi rozwiązania w zakresie zdalnego przetwarzania danych, w tym komponenty oprogramowania lub sprzętu, które są oddzielnie wprowadzane do obrotu” Ale jak się domyślacie sprawa tak oczywista nie jest. Wczoraj zacząłem się zastanawiać nad konkretnymi przypadkami, które mogą pojawić się w zderzeniu z CRA. Co w sytuacji, gdy udostępniam swoim klientom rozwiązanie SaaS, np. poprzez aplikację webową i na jakiejś licencji. Czy to oznacza, że będę musiał zapewnić wszystko o czym mowa w załącznikach CRA (to główny trzon obowiązków)?
Postanowiłem zderzyć swoje wątpliwości z asystentem AI, z którego korzystam i „wspólnie” rozłożyliśmy to na kilka przypadków, o których będę chciał jeszcze opowiedzieć. Zanim do tego przejdziemy, to musimy sobie odpowiedzieć na pytanie jakie przesłanki muszą być spełnione, aby w ogóle mówić o produkcie z elementem cyfrowym No więc:
✅ musimy mieć produkt sprzętowy (hardware) lub oprogramowanie (software); co istotne, komponent (np. biblioteka) też jest oddzielnym produktem, jeżeli jest oddzielnie wprowadzany do obrotu. A jeżeli z produktem powiązane jest zdalne przetwarzanie danych, to wchodzi ono w granice tego produktu - ale z zastrzeżeniem - nie jest to warunek, bo produkt bez żadnego backendu podlega CRA tak samo,
✅ produkt ma bezpośrednie lub pośrednie, logiczne lub fizyczne połączenie danych z urządzeniem lub siecią; przesłanka jest bardzo pojemna i wystarczy port USB do wgrywania aktualizacji,
✅ rozwiązanie jest dostarczane użytkownikowi i wykonuje się po jego stronie (to kryterium pochodzi z wytycznych Komisji, nie wprost z rozporządzenia, ale w praktyce to ono najczęściej przesądzi, czy podlegamy CRA),
✅ produkt jest udostępniany na rynku UE w ramach naszej działalności komercyjnej i to zarówno odpłatnie, jak i nieodpłatnie; forma prawna i „bezpłatność" nie mają znaczenia, a niekomercyjny open source wypada z CRA właśnie na tej przesłance, a nie przez jakieś osobne wyłączenie,
❌ nie występuje żadne z wyłączeń (m.in. wyroby medyczne, homologacja pojazdów, lotnictwo, wyposażenie morskie).
Co więc może być produktem z elementami cyfrowymi, a co niekoniecznie? Oprogramowanie, które jest udostępniane użytkownikowi, np. w formie SDK (software development kit), biblioteki czy wtyczki do przeglądarki i wykonywane u niego będzie podlegało CRA.
Mało tego - nasz backend też może „wpaść” w CRA, choć na szczęście nie każdy. Wytyczne Komisji nakazują spełnić przesłanki z trzyelementowego testu, tj.
✅ przetwarzanie odbywa się na odległość,
✅ bez tego przetwarzania produkt nie zrealizuje którejś ze swoich funkcji,
✅ oprogramowanie stworzyliśmy my jako producent lub powstało na naszą odpowiedzialność.
Dopiero wtedy backend wchodzi w granice produktu (jako tzw. RDPS - Remote Data Processing Solutions). Telemetria wysyłana w jedną stronę (tylko do producenta, np. na potrzeby poprawy jakości rozwiązania) czy systemy, z którymi produkt bezpośrednio się nie komunikuje - już nie.
Niekoniecznie będziemy stosować CRA, jeżeli mówimy o rozwiązaniu, które „wykonuje się u nas”, a więc np. strony internetowe, rozwiązania SaaS’owe i tym podobne. Ale i tutaj możemy zrobić pewne zastrzeżenia, bo chciałem Wam pokazać cztery warianty, które postanowiłem rozkminić z modelem Opus 5. Rozważałem następujący wariant:
Mamy oprogramowanie, które sprzedajemy w formie licencji i w modelu SaaS, a więc klient z niego korzysta, ale – komplikując rozwiązanie - dodatkowo integruje się to rozwiązanie z jego systemami wewnątrz firmy, np. ERP. Forma prawna akurat jest tutaj do zignorowania, bo nie wpływa ona na kwalifikację CRA, ważniejsze staje się pytanie czy w ramach integracji rozwiązania (naszego) cokolwiek trafia do infrastruktury klienta i kod jest tam wykonywany. To zaś oznacza, że możemy rozważyć następujące warianty:
❌ Klient wywołuje żądania poprzez API (interfejsy dostępowe) własnym kodem, ale wszystko rozstrzyga się na serwerach dostawcy SaaS; ten dostawca nie dostarcza produktu z elementami cyfrowymi, ale klient też nie, bo swój kod integracyjny pisze na własny użytek, a więc niczego nie wprowadza do obrotu. W tym wariancie CRA nie dotyczy nikogo. Chyba że klient wbuduje nasze rozwiązanie we własny produkt, który sam sprzedaje lub w inny sposób dystrubuje - wtedy to on jest producentem i to on odpowiada, a my staniemy się jego dostawcą, od którego zażąda SBOM-u (Software Bill of Materials) i informacji o podatnościach.
✅ My dostarczamy SDK lub bibliotekę, ale to klient u siebie wykonuje całość; zgodnie z wytycznymi SDK czy biblioteka dostarczana klientom to produkt z elementami cyfrowymi wprost, ze wszystkimi obowiązkami po naszej stronie. To najpewniejszy element całej tej układanki, który powoduje, że po prostu nie uciekniemy przed CRA.
✅ Jakiś rodzaj connector’a lub agent, to przypadek, gdy jakiś komponent instalujemy na infrastrukturze klienta, a on pośredniczy pomiędzy tym co udostępniamy my a tym co dostaje klient. To również wariant, w którym raczej będziemy stosować CRA, także w odniesieniu do naszego backendu.
✅ Jeżeli rozwiązanie udostępniamy klientowi do „ogarnięcia”, to nie ma wątpliwości, że jest to rozwiązanie podlegające CRA.
Oczywiście warianty możemy mnożyć, ale te powyżej wydają się najbardziej powszechne. Jak widzicie wątpliwości może pojawić się sporo, a mając produkt z elementami cyfrowymi, możemy wpaść w CRA. Mało tego, nie opowiedziałem o wszystkim!
Te konkretne obowiązki, to nie tylko to co nas czeka w grudniu przyszłego roku, ale także raportowanie do ENISA i CSIRT w zakresie m.in. podatności i incydentów. To obowiązek już od września br., choć nie ma jeszcze kanałów zgłaszania, więc można założyć, że będzie to obowiązek na razie martwy. Wrócę do tego jeszcze we właściwym czasie, a zainteresowanych odsyłam do art. 14.
Na pocieszenie powiem, że przepisy o karach to też dopiero grudzień 2027, więc to na co się narażamy to stan niezgodności, ale bez sankcji administracyjnych. Co wcale nie oznacza, że nic nie ryzykujemy.