Klient czy software house? Kto jest producentem systemu dedykowanego według Cyber Resilience Act?

Najpierw trzeba ustalić, czy CRA obejmuje dany system

Cyber Resilience Act nie tworzy osobnej kategorii „systemu dedykowanego”.

Rozporządzenie stosuje się do udostępnianych na rynku produktów z elementami cyfrowymi, których przeznaczenie lub racjonalnie przewidywalne wykorzystanie obejmuje bezpośrednie albo pośrednie, logiczne albo fizyczne połączenie danych z urządzeniem lub siecią. „Produkt z elementami cyfrowymi” obejmuje oprogramowanie lub sprzęt oraz powiązane rozwiązania w zakresie zdalnego przetwarzania danych, a także komponenty oprogramowania lub sprzętu oddzielnie wprowadzane do obrotu. [art. 2 ust. 1 oraz art. 3 pkt 1 CRA]

Samo zamówienie aplikacji lub systemu informatycznego nie przesądza więc o stosowaniu CRA.

FAQ przygotowane przez służby Komisji Europejskiej wyjaśnia między innymi, że samodzielna usługa SaaS lub inne rozwiązanie chmurowe zaprojektowane i rozwijane poza odpowiedzialnością producenta produktu z elementami cyfrowymi nie są same w sobie produktem objętym CRA. Sytuacja jest inna, jeżeli usługa spełnia definicję zdalnego przetwarzania danych z art. 3 pkt 2.

Przy analizie zakresu trzeba również sprawdzić wyłączenia przewidziane w art. 2. Dotyczą one między innymi określonych produktów podlegających wskazanym regulacjom dotyczącym wyrobów medycznych, pojazdów, lotnictwa i wyposażenia morskiego. CRA zawiera też szczególne wyłączenia dotyczące identycznych części zamiennych oraz produktów opracowanych lub zmodyfikowanych wyłącznie na potrzeby bezpieczeństwa narodowego lub obronności.

Dlatego pytanie o producenta powinno być poprzedzone pytaniem o zakres CRA.

Producentem nie musi być firma, która wykonała development

Art. 3 pkt 13 CRA definiuje producenta jako osobę fizyczną lub prawną, która opracowuje lub wytwarza produkt z elementami cyfrowymi albo zleca jego zaprojektowanie, opracowanie lub wytworzenie i wprowadza produkt do obrotu pod własną nazwą handlową lub znakiem towarowym. Nie ma przy tym znaczenia, czy produkt jest oferowany za opłatą, monetyzowany w inny sposób czy udostępniany bezpłatnie.

Definicja składa się zatem z dwóch istotnych elementów. Pierwszy dotyczy udziału w powstaniu produktu, również przez zlecenie prac innemu podmiotowi. Drugi dotyczy wprowadzenia produktu do obrotu pod własną nazwą lub znakiem.

Samo autorstwo kodu nie rozstrzyga statusu producenta.

Jeżeli software house rozwija własny produkt i wprowadza go do obrotu pod własną marką, może spełniać definicję producenta. Jeżeli natomiast klient zleca stworzenie produktu wykonawcy, a następnie wprowadza produkt do obrotu pod własną nazwą lub znakiem towarowym, producentem może być klient.

„Wprowadzenie do obrotu” i „udostępnienie na rynku” to nie to samo

CRA rozróżnia dwa pojęcia, które przy projektach wykonywanych na zamówienie mają praktyczne znaczenie.

Wprowadzenie do obrotu oznacza pierwsze udostępnienie produktu z elementami cyfrowymi na rynku Unii.

Udostępnienie na rynku oznacza dostarczenie produktu do celów dystrybucji lub używania na rynku Unii w ramach działalności handlowej, odpłatnie lub nieodpłatnie. [art. 3 pkt 21 i 22 CRA]

Producent z art. 3 pkt 13 jest powiązany z wprowadzeniem produktu do obrotu pod własną nazwą handlową lub znakiem towarowym. Nie wystarczy więc sprawdzić, kto programował produkt. Trzeba ustalić również, kto i w jakim modelu wprowadza go na rynek.

Klient może być producentem, a software house jego podwykonawcą

Taki model nie jest obcy unijnemu prawu produktowemu.

Blue Guide 2022 wskazuje, że producent może sam zaprojektować i wytworzyć produkt, ale może również zlecić jego zaprojektowanie lub wytworzenie z zamiarem wprowadzenia go do obrotu pod własną nazwą lub znakiem towarowym.

W przypadku podwykonawstwa producent powinien zachować kontrolę nad produktem i zapewnić sobie dostęp do informacji potrzebnych do wykonania obowiązków wynikających z właściwych przepisów. Zlecenie części lub wszystkich prac nie zwalnia go z odpowiedzialności za zgodność produktu.

Blue Guide nie jest przepisem CRA i nie zastępuje analizy konkretnego przypadku. Jest jednak istotnym materiałem interpretacyjnym dotyczącym unijnego prawa produktowego, a FAQ Komisji dotyczące CRA samo odwołuje się do tego przewodnika.

Dla projektu realizowanego przez software house oznacza to, że trzeba rozróżnić co najmniej dwa modele:

Tabela nie zastępuje analizy konkretnego projektu. Pokazuje natomiast, dlaczego utożsamienie producenta z wykonawcą kodu może prowadzić do błędnej kwalifikacji.

System używany wewnętrznie nie zawsze jest poza CRA

FAQ Komisji, odwołując się do Blue Guide, wskazuje, że do wprowadzenia do obrotu nie dochodzi, gdy produkt jest wytwarzany na własny użytek. Jako przykład podaje narzędzia developerskie i konfiguracyjne opracowane przez producenta dla własnych potrzeb, jeżeli nie są następnie wprowadzane na rynek jako oddzielne produkty.

„Własny użytek” nie jest jednak równoznaczny z każdym przypadkiem, w którym końcowy użytkownik nie odsprzedaje systemu dalej.

Jeżeli w projekcie uczestniczy niezależny software house, trzeba zbadać charakter jego roli. Może on dostarczać własny produkt klientowi, ale może też wykonywać prace jako podwykonawca podmiotu, który pozostaje producentem.

Z tego powodu samo zdanie „system będzie używany wyłącznie wewnętrznie” nie wystarcza do stwierdzenia, że CRA nie ma zastosowania. Nie można też przyjąć odwrotnej reguły, według której udział zewnętrznego software house'u automatycznie oznacza, że to właśnie on jest producentem.

Oprogramowanie na zamówienie nie ma ogólnego wyłączenia

CRA przewiduje szczególne zasady dla produktów dostosowanych do określonego celu konkretnego użytkownika biznesowego. Nie ustanawia jednak generalnego zwolnienia dla oprogramowania tworzonego na zamówienie.

Motyw 64 i załącznik I pozwalają producentowi i użytkownikowi biznesowemu uzgodnić inne warunki w odniesieniu do dwóch wymagań:

• bezpiecznej konfiguracji domyślnej,

• bezpłatnego udostępniania aktualizacji zabezpieczeń.

FAQ Komisji wskazuje jako możliwe przykłady produktu tailor-made sprzęt lub oprogramowanie stworzone dla jednego konkretnego użytkownika biznesowego oraz produkt opracowany do integracji ze szczególnym, kontrolowanym środowiskiem klienta, na przykład zamkniętą siecią.

Nie wystarczy natomiast niewielka konfiguracja produktu oferowanego wielu klientom. FAQ podaje przykład platformy CRM sprzedawanej wielu przedsiębiorstwom oraz platform dostosowywanych za pomocą pluginów lub API, które zasadniczo pozostają tym samym produktem. Producent korzystający z odstępstw dla produktu tailor-made powinien również wykazać tę kwalifikację w dokumentacji technicznej.

Są to wyjaśnienia służb Komisji, a nie dodatkowa definicja ustawowa.

Importer, dystrybutor lub podmiot modyfikujący produkt również może przejąć obowiązki producenta

Art. 21 CRA przewiduje, że importer lub dystrybutor jest traktowany jak producent i podlega art. 13 i 14, jeżeli wprowadza produkt do obrotu pod własną nazwą lub znakiem towarowym albo dokonuje istotnej modyfikacji produktu już wprowadzonego do obrotu.

Art. 22 obejmuje z kolei osobę inną niż producent, importer lub dystrybutor, która dokonuje istotnej modyfikacji produktu i następnie udostępnia go na rynku. Taki podmiot jest traktowany jak producent w zakresie określonym w tym przepisie.

CRA definiuje „istotną modyfikację” jako zmianę dokonaną po wprowadzeniu produktu do obrotu, która wpływa na jego zgodność z zasadniczymi wymaganiami cyberbezpieczeństwa z części I załącznika I albo powoduje zmianę przeznaczenia, w odniesieniu do którego produkt został oceniony.

Nie każda aktualizacja spełnia więc ten test. FAQ podaje przykładowo aktualizację starszego smart TV usuwającą błąd jako zmianę, która nie musi stanowić istotnej modyfikacji, oraz późniejsze dodanie funkcji sterowania systemem smart home jako przykład zmiany mogącej taką modyfikację stanowić.

Większość obowiązków producenta zacznie być stosowana 11 grudnia 2027 r.

Większość CRA stosuje się od 11 grudnia 2027 r. Obowiązki wynikające z art. 13 nie są więc jeszcze, według stanu na 25 września 2026 r., zasadniczo stosowane. [art. 71 ust. 2 CRA]

Po rozpoczęciu pełnego stosowania CRA producent będzie musiał zapewnić, aby produkt został zaprojektowany, opracowany i wyprodukowany zgodnie z zasadniczymi wymaganiami cyberbezpieczeństwa.

Art. 13 ust. 2 nakazuje przeprowadzenie oceny ryzyka w cyberprzestrzeni i uwzględnienie jej wyników podczas planowania, projektowania, opracowywania, produkcji, dostarczania i utrzymania produktu. Przed wprowadzeniem go do obrotu producent musi również sporządzić dokumentację techniczną i przeprowadzić odpowiednią procedurę oceny zgodności.

Dla projektu realizowanego na zamówienie ma to konkretną konsekwencję. Jeżeli producentem ma być klient, proces developmentu powinien zapewnić mu informacje potrzebne do wykonania obowiązków producenta. Nie da się wiarygodnie przygotować pełnej dokumentacji, oceny ryzyka czy procesu obsługi podatności dopiero po zakończeniu projektu, jeżeli potrzebne dane pozostają wyłącznie po stronie wykonawcy.

To jest rekomendacja organizacyjna wynikająca z konstrukcji obowiązków CRA, a nie odrębny obowiązek opisany w rozporządzeniu jako wymóg dotyczący umowy klienta z software house'em.

Producent odpowiada za obsługę podatności przez okres wsparcia

Art. 13 ust. 8 wymaga, aby od momentu wprowadzenia produktu do obrotu i przez cały okres wsparcia producent zapewniał skuteczne postępowanie w przypadku wykrycia podatności produktu lub jego komponentów.

Załącznik I część II przewiduje między innymi:

• identyfikowanie i dokumentowanie podatności oraz komponentów produktu,

• sporządzenie SBOM obejmującego co najmniej zależności najwyższego poziomu,

• reagowanie na podatności odpowiednio do ryzyka,

• regularne testy i przeglądy bezpieczeństwa,

• politykę skoordynowanego ujawniania podatności,

• bezpieczną dystrybucję aktualizacji zabezpieczeń.

CRA nie wymaga przy tym osobnej poprawki dla każdej wykrytej podatności bez względu na jej znaczenie. Aktualne FAQ Komisji wskazuje, że producent powinien ocenić znaczenie podatności dla produktu i wynikające z niej ryzyko. Środkiem zaradczym może być między innymi patch, obejście problemu, zmiana konfiguracji lub odpowiednia informacja dla użytkowników.

Pięć lat nie jest uniwersalnym okresem wsparcia

Art. 13 ust. 8 stanowi, że okres wsparcia wynosi co najmniej pięć lat. Jeżeli oczekuje się, że produkt będzie użytkowany krócej niż pięć lat, okres wsparcia odpowiada przewidywanemu czasowi użytkowania.

Nie oznacza to jednak, że pięć lat jest automatycznie wystarczające dla każdego produktu używanego dłużej.

Producent ma ustalić okres wsparcia z uwzględnieniem między innymi uzasadnionych oczekiwań użytkowników, charakteru i przeznaczenia produktu oraz odpowiednich przepisów Unii dotyczących jego cyklu życia. Może też brać pod uwagę okresy wsparcia podobnych produktów, dostępność środowiska operacyjnego i okresy wsparcia kluczowych komponentów zewnętrznych.

FAQ Komisji wyjaśnia, że ustawienie pięciu lat nie jest wystarczające samo w sobie, jeżeli produkt racjonalnie ma pozostawać w użyciu dłużej. W takich przypadkach analiza kryteriów z art. 13 ust. 8 może prowadzić do ustalenia dłuższego okresu wsparcia.

Obowiązki raportowe obowiązują już teraz

CRA ma kilka różnych dat rozpoczęcia stosowania.

Rozdział IV dotyczący jednostek oceniających zgodność stosuje się od 11 czerwca 2026 r. Art. 14 dotyczący obowiązków raportowych producentów stosuje się od 11 września 2026 r. Pozostałe przepisy stosuje się zasadniczo od 11 grudnia 2027 r.

Na dzień 25 września 2026 r. producent objęty art. 14 musi zgłaszać aktywnie wykorzystywane podatności zawarte w produkcie z elementami cyfrowymi oraz poważne incydenty mające wpływ na bezpieczeństwo produktu, o których się dowiedział.

Pierwsze ostrzeżenie należy przekazać bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin od uzyskania wiedzy. Kolejne zgłoszenie jest wymagane najpóźniej w ciągu 72 godzin od momentu uzyskania wiedzy o podatności albo incydencie. Termin 72 godzin nie biegnie więc od zgłoszenia 24-godzinnego.

Dla aktywnie wykorzystywanej podatności raport końcowy przekazuje się nie później niż 14 dni po udostępnieniu środka naprawczego lub łagodzącego. Dla poważnego incydentu termin wynosi jeden miesiąc od zgłoszenia 72-godzinnego.

Zgłoszenia są składane przez Single Reporting Platform ustanowioną przez ENISA. Platforma działa od 11 września 2026 r.

Art. 14 ust. 8 nakłada ponadto obowiązek informowania użytkowników dotkniętych aktywnie wykorzystywaną podatnością lub poważnym incydentem, a w stosownych przypadkach wszystkich użytkowników. Informacja powinna obejmować podatność lub incydent oraz, jeżeli jest to potrzebne, środki łagodzące i naprawcze, które użytkownik może zastosować.

Reporting obejmuje także produkty wprowadzone do obrotu przed pełnym stosowaniem CRA

Art. 69 zawiera przepisy przejściowe.

Co do zasady produkt wprowadzony do obrotu przed 11 grudnia 2027 r. podlega wymaganiom CRA dopiero wtedy, gdy po tej dacie zostanie poddany istotnej modyfikacji.

Art. 14 jest jednak wyjątkiem. Obowiązki raportowe stosuje się również do produktów objętych zakresem CRA, które zostały wprowadzone do obrotu przed 11 grudnia 2027 r. [art. 69 ust. 2 i 3 CRA]

Nie oznacza to przyspieszenia wszystkich pozostałych obowiązków producenta dla takich produktów.

Umowa nie decyduje, kto jest producentem

Umowa między klientem a software house'em może określić własność kodu, zakres utrzymania, odpowiedzialność za aktualizacje, testy bezpieczeństwa czy obsługę podatności. Nie może jednak sama zmienić definicji producenta wynikającej z CRA.

Status trzeba ustalić na podstawie rzeczywistego modelu. Znaczenie ma między innymi to, kto opracowuje produkt lub zleca jego opracowanie, kto wprowadza go do obrotu i pod czyją nazwą lub znakiem towarowym jest on wprowadzany.

Umowa ma natomiast duże znaczenie dla tego, czy podmiot będący producentem będzie w stanie wykonać swoje obowiązki.

Jeżeli klient ma być producentem, a software house pozostaje podwykonawcą, warto kontraktowo zapewnić klientowi dostęp do informacji potrzebnych między innymi do:

• oceny ryzyka,

• dokumentacji technicznej,

• identyfikacji komponentów i prowadzenia SBOM,

• obsługi i analizy podatności,

• testów bezpieczeństwa,

• przygotowania aktualizacji,

• realizacji obowiązków raportowych,

• utrzymania produktu przez wymagany okres wsparcia.

Zakres takich postanowień nie wynika wprost z katalogu klauzul narzuconych przez CRA. Jest konsekwencją obowiązków przypisanych producentowi oraz, w modelu podwykonawstwa, potrzeby zachowania przez niego odpowiedniej kontroli i dostępu do informacji.

Co ustalić przed rozpoczęciem projektu

Przed podpisaniem umowy na stworzenie produktu warto sprawdzić:

1. Czy rozwiązanie jest produktem z elementami cyfrowymi objętym CRA?

2. Czy występuje któreś z wyłączeń z art. 2?

3. Czy produkt będzie udostępniany na rynku w rozumieniu CRA?

4. Kto po raz pierwszy wprowadzi go do obrotu i pod czyją nazwą lub znakiem?

5. Czy software house dostarcza własny produkt, czy działa jako podwykonawca klienta?

6. Czy rozwiązanie rzeczywiście jest wytwarzane wyłącznie na własny użytek?

7. Kto będzie posiadał informacje potrzebne do oceny ryzyka, dokumentacji technicznej i obsługi podatności?

8. Kto będzie odpowiadał operacyjnie za aktualizacje, zgłoszenia z art. 14 i komunikację z użytkownikami?

9. Jaki okres wsparcia wynika z charakteru produktu i kryteriów z art. 13 ust. 8?

10. Czy późniejsze zmiany produktu mogą stanowić istotną modyfikację?

Ta lista nie stanowi katalogu obowiązków ustanowionego przez CRA. Ma pomóc zebrać fakty potrzebne do prawidłowej kwalifikacji produktu i stron projektu.

Klient czy software house?

Cyber Resilience Act nie przypisuje roli producenta automatycznie autorowi kodu.

Jeżeli produkt znajduje się w zakresie CRA, punktem wyjścia jest art. 3 pkt 13. Trzeba ustalić, kto opracowuje lub wytwarza produkt albo zleca jego zaprojektowanie, opracowanie lub wytworzenie, a następnie kto wprowadza go do obrotu pod własną nazwą handlową lub znakiem towarowym.

W zależności od modelu producentem może być software house rozwijający i oferujący własny produkt albo klient, który zleca development i wprowadza produkt na rynek pod własną marką. W drugim przypadku software house może działać jako podwykonawca bez przejęcia statusu producenta. Dalsze zmiany w łańcuchu dostaw lub istotna modyfikacja produktu mogą dodatkowo uruchomić art. 21 albo 22 CRA.

Kwalifikację warto więc wykonać przed rozpoczęciem developmentu. Pozwala to zaprojektować umowę, dostęp do dokumentacji, proces bezpieczeństwa i późniejsze utrzymanie zgodnie z rolami, które rzeczywiście wynikają z CRA.

Stan prawny i dokumentacyjny: 25 września 2026 r.

Uwaga: FAQ służb Komisji, Blue Guide 2022 oraz wytyczne Komisji C(2026) 5252 są materiałami pomocniczymi i nie stanowią wiążącej wykładni CRA. Samo FAQ wyraźnie zastrzega, że nie przedstawia oficjalnego stanowiska Komisji ani autorytatywnej interpretacji prawa. Wytyczne Komisji z 27 lipca 2026 r. również zostały opublikowane jako niewiążące.