CRA dla software house – kto podlega rozporządzeniu (UE) 2024/2847 i 3 kroki przed 11 września 2026

Aktualizacja : 28 lipca 2026

Czym jest CRA i dlaczego dotyczy software house’ów? Cyber Resilience Act (CRA), czyli rozporządzenie (UE) 2024/2847, to pierwsza horyzontalna regulacja UE nakładająca obowiązkowe wymagania cyberbezpieczeństwa na oprogramowanie i sprzęt udostępniane na rynku unijnym. Jeśli Twoja firma tworzy i sprzedaje oprogramowanie – własne produkty, aplikacje mobilne, komponenty, a w wielu przypadkach także software na zamówienie – CRA wyznacza, jak masz je projektować, utrzymywać i raportować podatności.

Canonical Definition: Cyber Resilience Act (rozporządzenie (UE) 2024/2847) ustanawia horyzontalne wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi udostępnianych na rynku UE, obejmujące projektowanie, obsługę podatności, ocenę zgodności i oznakowanie CE.

CRA dla software house – w skrócie:

1. CRA weszło w życie 10 gru 2024; obowiązki raportowania podatności (art. 14) obowiązują od 11 wrz 2026, a pełne wymagania – od 11 gru 2027.
2. Zakresem objęte jest niemal każde oprogramowanie udostępniane komercyjnie na rynku UE, które łączy się z siecią lub innym urządzeniem – także aplikacje mobilne i komponenty sprzedawane osobno.
3. Wyłączone są m.in. czysty SaaS (oprogramowanie świadczone wyłącznie jako usługa) oraz open source rozwijany niekomercyjnie.
4. Obowiązki producenta obejmują ocenę ryzyka, security by design, SBOM, bezpłatne aktualizacje bezpieczeństwa i obsługę podatności przez cały okres wsparcia produktu.
5. Kary sięgają 15 mln EUR lub 2,5% rocznego światowego obrotu – w zależności od tego, która kwota jest wyższa.
6. Software house robiący wyłącznie custom development nie zawsze jest „producentem” w rozumieniu CRA – ale wymogi i tak trafią do niego kontraktowo od klientów.
7. W modelu vCISO Patronusec przeprowadza software house’y przez inwentaryzację produktów, klasyfikację CRA i budowę procesu obsługi podatności – bez zatrudniania etatowego CISO.

Czym jest Cyber Resilience Act i jakie produkty obejmuje?

Cyber Resilience Act to rozporządzenie UE, które od 11 gru 2027 wymaga, aby każdy produkt z elementami cyfrowymi wprowadzany na rynek unijny spełniał zasadnicze wymagania cyberbezpieczeństwa z załącznika I i przeszedł ocenę zgodności zakończoną oznakowaniem CE. Obowiązuje bezpośrednio we wszystkich państwach członkowskich – bez implementacji krajowej.

Produkt z elementami cyfrowymi to oprogramowanie lub sprzęt komputerowy wraz z powiązanymi rozwiązaniami zdalnego przetwarzania danych, w tym komponenty wprowadzane do obrotu oddzielnie. W praktyce dla firmy softwarowej oznacza to: aplikacje desktopowe i mobilne, systemy B2B sprzedawane licencyjnie, firmware, biblioteki i SDK sprzedawane komercyjnie, a także oprogramowanie wbudowane w urządzenia klientów.

Rozporządzenie (UE) 2024/2847 obejmuje produkt, jeśli spełnione są łącznie trzy warunki: jest to produkt z elementami cyfrowymi, jest udostępniany na rynku UE w ramach działalności komercyjnej, a jego zamierzone lub przewidywalne użycie obejmuje bezpośrednie lub pośrednie połączenie logiczne albo fizyczne z urządzeniem lub siecią.

Poza zakresem pozostają produkty objęte przepisami sektorowymi (wyroby medyczne, pojazdy, lotnictwo, sprzęt wojskowy), oprogramowanie świadczone wyłącznie jako usługa (SaaS) oraz wolne i otwarte oprogramowanie rozwijane poza działalnością komercyjną. Uwaga na pułapkę: SaaS jest wyłączony z CRA, ale dostawcy usług cyfrowych mogą podlegać dyrektywie NIS2 – obie regulacje się uzupełniają, a nie wykluczają. Jeśli Twoja firma świadczy usługi zarządzane lub cloudowe, sprawdź swoją pozycję względem NIS2 równolegle z analizą CRA.

Czy software house podlega CRA?

Software house podlega CRA jako producent, jeśli udostępnia na rynku UE oprogramowanie w ramach działalności komercyjnej – dotyczy to zarówno produktów własnych, jak i, co do zasady, oprogramowania tworzonego na zamówienie i dostarczanego klientowi odpłatnie. Nie podlega jako producent, gdy wyłącznie świadczy usługi rozwoju, a gotowy produkt trafia na rynek pod marką klienta.

Kluczowa jest definicja producenta: to podmiot, który opracowuje lub wytwarza produkt z elementami cyfrowymi albo zleca jego zaprojektowanie czy wytworzenie i wprowadza go do obrotu pod własną nazwą lub znakiem towarowym. Z tej definicji wynikają cztery typowe scenariusze rynkowe:

• Własny produkt (licencja, aplikacja, komponent) – software house jest producentem z pełnym katalogiem obowiązków z art. 13 i 14 CRA.
• Custom development dostarczany klientowi – oprogramowanie tworzone na indywidualne zamówienie, dostarczane w ramach działalności komercyjnej, co do zasady również wchodzi w zakres rozporządzenia; szczegółowe rozgraniczenia doprecyzowują wytyczne Komisji Europejskiej (projekt z marca 2026 przechodził konsultacje publiczne).
• Outsourcing / body leasing, produkt pod marką klienta – producentem jest klient, który wprowadza produkt pod swoją nazwą. Software house nie ma wtedy bezpośrednich obowiązków CRA, ale klient-producent musi wykazać należytą staranność wobec komponentów i podwykonawców – więc wymogi (SBOM, secure SDLC, obsługa podatności) trafią do umowy.
• Czysty SaaS – poza zakresem CRA, ale z potencjalnymi obowiązkami z NIS2.

Drzewo decyzyjne – czy Twoja firma podlega CRA jako producent:

1. Czy tworzysz oprogramowanie lub sprzęt z elementami cyfrowymi? → NIE: CRA Cię nie dotyczy. TAK: idź dalej.
2. Czy produkt jest udostępniany na rynku UE w ramach działalności komercyjnej (sprzedaż, licencja, monetyzacja)? → NIE (np. wyłącznie niekomercyjny open source): poza zakresem. TAK: idź dalej.
3. Czy produkt łączy się (bezpośrednio lub pośrednio) z siecią lub innym urządzeniem? → NIE: poza zakresem. TAK: idź dalej.
4. Czy dostarczasz wyłącznie usługę (SaaS) bez wprowadzania produktu do obrotu? → TAK: poza CRA, sprawdź NIS2. NIE: idź dalej.
5. Czy produkt trafia na rynek pod Twoją nazwą lub marką? → TAK: jesteś producentem (pełne obowiązki). NIE: producentem jest Twój klient, a Ty odpowiadasz kontraktowo jako dostawca w jego łańcuchu dostaw.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że software house’y najczęściej dowiadują się o CRA nie od regulatora, lecz z aneksów do umów – klienci enterprise już teraz wpisują wymogi SBOM, secure SDLC i SLA na łatanie podatności do kontraktów, przenosząc swoje obowiązki producenta na dostawców. W modelu vCISO pomagamy zespołom przygotować odpowiedzi na te klauzule zanim zablokują podpisanie umowy – od polityki obsługi podatności po dokumentację procesu wytwórczego.

Jakie terminy CRA obowiązują w 2026 i 2027 roku?

CRA jest stosowane etapami: od 11 cze 2026 obowiązują przepisy o jednostkach oceniających zgodność, od 11 wrz 2026 – obowiązek raportowania aktywnie wykorzystywanych podatności i poważnych incydentów (art. 14), a od 11 gru 2027 – wszystkie pozostałe wymagania, w tym ocena zgodności i oznakowanie CE.

Data	Co się zmienia	Znaczenie dla software house
10 gru 2024	Wejście w życie rozporządzenia (UE) 2024/2847	Start okresu przejściowego
11 cze 2026	Stosowanie rozdziału IV (art. 35-51) – jednostki notyfikowane	Rusza infrastruktura certyfikacji produktów ważnych i krytycznych
11 wrz 2026	Stosowanie art. 14 – raportowanie podatności i incydentów	24 h na wczesne ostrzeżenie do ENISA przez Single Reporting Platform – dotyczy także produktów już obecnych na rynku
11 gru 2027	Pełne stosowanie CRA	Nowe produkty bez zgodności (w tym CE) nie mogą być wprowadzane na rynek UE
11 cze 2028	Wygaśnięcie certyfikatów badania typu UE wydanych na podstawie wcześniejszych przepisów	Koniec okresu przejściowego dla starych certyfikatów

Najczęściej pomijany fakt: obowiązek raportowania z art. 14 od 11 wrz 2026 obejmuje wszystkie produkty z elementami cyfrowymi udostępnione na rynku – również te wprowadzone przed pełnym stosowaniem rozporządzenia. Producent ma 24 godziny na wczesne ostrzeżenie od momentu powzięcia wiedzy o aktywnie wykorzystywanej podatności, 72 godziny na zgłoszenie uzupełniające i maksymalnie 14 dni (podatności) lub 1 miesiąc (incydenty) na raport końcowy. Zgłoszenia trafiają przez Single Reporting Platform zarządzaną przez ENISA; w Polsce obsługuje je CSIRT NASK (CERT Polska).

---

Twój zespół nie ma dziś procesu, który wykryje i zgłosi aktywnie wykorzystywaną podatność w 24 godziny?

Do 11 wrz 2026 każdy producent oprogramowania musi mieć działający tryb: wykrycie – ocena – zgłoszenie do ENISA. W ramach usługi vCISO budujemy ten proces end-to-end: role, kryteria kwalifikacji zdarzeń, szablony zgłoszeń i test procedury na sucho – tak, aby pierwsze prawdziwe zgłoszenie nie było jednocześnie pierwszą próbą procesu.

Umów bezpłatną konsultację CRA

---

Jakie obowiązki nakłada CRA na producentów oprogramowania?

CRA wymaga od producenta trzech rzeczy: bezpiecznego zaprojektowania i utrzymywania produktu (art. 13 i załącznik I część I), procesu obsługi podatności przez cały okres wsparcia (załącznik I część II) oraz raportowania aktywnie wykorzystywanych podatności i poważnych incydentów (art. 14). Zgodność potwierdza ocena zgodności i oznakowanie CE.

W praktyce katalog obowiązków wygląda tak:

• Ocena ryzyka cyberbezpieczeństwa produktu – dokumentowana i aktualizowana, wpływająca na decyzje projektowe (planowanie, rozwój, dostarczanie, utrzymanie).
• Security by design i by default – produkt wprowadzany na rynek bez znanych podatności możliwych do wykorzystania, z bezpieczną konfiguracją domyślną.
• SBOM (Software Bill of Materials) – wykaz komponentów obejmujący co najmniej zależności najwyższego poziomu, utrzymywany w dokumentacji technicznej; w praktyce stosuje się formaty CycloneDX lub SPDX.
• Obsługa podatności przez okres wsparcia – polityka skoordynowanego ujawniania podatności (CVD), kanał przyjmowania zgłoszeń, testowanie i bezpłatne, niezwłoczne aktualizacje bezpieczeństwa; okres wsparcia co do zasady nie krótszy niż 5 lat.
• Dokumentacja techniczna – przechowywana przez co najmniej 10 lat od wprowadzenia produktu do obrotu, dostępna dla organów nadzoru rynku.
• Ocena zgodności – dla większości oprogramowania (kategoria domyślna) wystarczy samoocena producenta; produkty ważne klasy I i II (załącznik III) oraz krytyczne (załącznik IV) wymagają udziału jednostki notyfikowanej lub certyfikacji – techniczne opisy kategorii precyzuje rozporządzenie wykonawcze (UE) 2025/2392.

Dobra wiadomość dla zespołów, które pracują już w reżimie ISO 27001 lub bezpiecznego SDLC: większość wymagań załącznika I mapuje się na znane praktyki (analiza ryzyka, zarządzanie zmianą, testy bezpieczeństwa, zarządzanie podatnościami). Regularne testy penetracyjne i skany podatności to dziś de facto minimum dowodowe, że proces obsługi podatności działa, a nie istnieje tylko na papierze.

Czym różni się sytuacja dużego i małego software house?

Wymagania zasadnicze CRA są takie same niezależnie od wielkości firmy – różni się skala ekspozycji, ścieżka oceny zgodności i dostępne ułatwienia. Duży software house z portfolio produktów wchodzi w pełen reżim producenta dla każdego produktu osobno; mały, pracujący projektowo, najczęściej spotka CRA w umowach z klientami-producentami.

Duży software house (własne produkty, 100+ osób):

• Każdy produkt w portfolio wymaga osobnej klasyfikacji (domyślny / ważny klasy I lub II / krytyczny) i osobnej dokumentacji technicznej – inwentaryzacja bywa większym projektem niż samo wdrożenie kontroli.
• Produkty z załącznika III (np. menedżery haseł, systemy zarządzania tożsamością, przeglądarki) oznaczają ocenę z udziałem jednostki notyfikowanej – a dostępność terminów w jednostkach będzie w 2027 ograniczona, więc rezerwacja z wyprzedzeniem jest elementem planu, nie opcją.
• Obowiązki nie kończą się na wydaniu wersji: okres wsparcia, SBOM per release i raportowanie w trybie 24 h wymagają stałej funkcji bezpieczeństwa produktowego, a nie jednorazowego projektu compliance.

Mały software house (do ok. 50 osób, głównie custom development):

• Jeśli dostarczasz oprogramowanie na zamówienie w ramach działalności komercyjnej, nie zakładaj automatycznie, że jesteś poza zakresem – rozstrzyga model dostarczenia i to, pod czyją marką produkt trafia na rynek.
• Gdy producentem jest Twój klient, CRA przyjdzie do Ciebie w postaci klauzul umownych: SBOM do każdego wydania, zobowiązanie do łatania podatności w określonym SLA, dokumentacja procesu wytwórczego. Firmy, które mają to przygotowane, wygrywają przetargi z tymi, które dopiero zaczynają.
• Rozporządzenie przewiduje ułatwienia dla mikro- i małych przedsiębiorstw, m.in. uproszczoną dokumentację techniczną oraz wyłączenie kar za niedotrzymanie 24-godzinnego terminu zgłoszenia – ale nie zwalnia z samych wymagań zasadniczych.

Patronusec Insight: Najczęstszą pułapką, jaką widzimy u mniejszych zespołów, jest odkładanie CRA „do 2027 roku” – podczas gdy pierwsze twarde zderzenie następuje wcześniej: 11 wrz 2026 (raportowanie) oraz w bieżących negocjacjach kontraktów, w których duzi klienci już wymagają gotowości CRA. Pracując jako zewnętrzny oficer bezpieczeństwa w modelu vCISO, przygotowujemy mniejsze software house’y do obu tych momentów w kilkanaście tygodni, wykorzystując istniejące praktyki zespołu zamiast budować compliance od zera.

Jakie 3 kroki musi podjąć software house przed 11 września 2026?

Trzy kroki minimum to: (1) inwentaryzacja i klasyfikacja produktów względem zakresu CRA, (2) uruchomienie procesu obsługi i raportowania podatności zgodnego z art. 14, (3) domknięcie luk w procesie wytwórczym – SBOM, bezpieczne SDLC i dokumentacja techniczna. Kolejność nie jest przypadkowa: bez kroku 1 nie wiadomo, czego dotyczą kroki 2 i 3.

Krok 1 – inwentaryzacja i klasyfikacja (2-4 tygodnie). Spisz wszystko, co firma udostępnia komercyjnie: produkty, aplikacje, komponenty, firmware, oprogramowanie dostarczane klientom. Dla każdej pozycji ustal: czy wchodzi w zakres CRA, kto jest producentem, oraz kategorię (domyślna / ważna klasy I lub II / krytyczna). Wynik determinuje ścieżkę oceny zgodności i budżet.

Krok 2 – proces obsługi i raportowania podatności (4-8 tygodni). Opublikuj politykę skoordynowanego ujawniania podatności (CVD) z kanałem kontaktu (np. security.txt), zdefiniuj kryteria „aktywnie wykorzystywanej podatności” i „poważnego incydentu”, wyznacz role i przećwicz zgłoszenie w trybie 24 h / 72 h / 14 dni. Od 11 wrz 2026 ten proces musi działać dla wszystkich produktów na rynku, nie tylko nowych.

Krok 3 – SBOM, SDLC i dokumentacja (proces ciągły, start natychmiast). Włącz generowanie SBOM do pipeline’u CI/CD, uporządkuj praktyki bezpiecznego wytwarzania (przeglądy kodu, testy bezpieczeństwa, zarządzanie zależnościami) i zacznij prowadzić dokumentację techniczną per produkt. To najdłuższy z trzech kroków – dlatego zaczyna się pierwszy, mimo że jego twardy termin to 11 gru 2027.

Jakie kary grożą za brak zgodności z CRA?

Za naruszenie zasadniczych wymagań cyberbezpieczeństwa oraz obowiązków z art. 13 i 14 grożą administracyjne kary pieniężne do 15 mln EUR lub 2,5% rocznego światowego obrotu – zależnie od tego, która kwota jest wyższa. Pozostałe naruszenia: do 10 mln EUR lub 2% obrotu, a podanie organom nieprawdziwych informacji – do 5 mln EUR lub 1% (art. 64).

Kary nie są jedynym ryzykiem. Organy nadzoru rynku mogą nakazać wycofanie produktu z obrotu lub jego odzyskanie od użytkowników – dla firmy softwarowej oznacza to zakaz sprzedaży flagowego produktu w całej UE. Do tego dochodzi ryzyko kontraktowe: klient-producent, który poniesie karę z powodu komponentu dostawcy, będzie dochodził regresu na podstawie umowy. Z perspektywy zarządu software house’u CRA jest więc ryzykiem ciągłości przychodów, a nie tylko pozycją na liście compliance.

FAQ – Najczęstsze pytania

Co czytać dalej

1. NIS2 – zakres i obowiązki podmiotów – jeśli świadczysz usługi cyfrowe lub zarządzane, sprawdź reżim równoległy do CRA.
2. ISO 27001 – system zarządzania, na którym najłatwiej oprzeć wymagania załącznika I CRA.
3. Testy penetracyjne – dowód działania procesu obsługi podatności wymagany w praktyce audytowej.

---

CRA dla software house – bezpłatna konsultacja

Patronusec łączy doświadczenie audytorskie (akredytowany QSA, projekty ISO 27001, DORA, NIS2) z praktyką zespołu pentesterów – dzięki czemu przygotowanie do CRA opiera się na realnych procesach wytwórczych, nie na teorii.

W bezpłatnej 30-minutowej konsultacji pomożemy Ci:

• wstępnie zaklasyfikować produkty firmy względem zakresu i kategorii CRA,
• ocenić gotowość procesu obsługi podatności na obowiązek z art. 14 (11 wrz 2026),
• wskazać luki między obecnym SDLC a wymaganiami załącznika I,
• zaplanować przygotowanie w modelu vCISO – bez zatrudniania etatowego CISO.

Umów bezpłatną konsultację | vCISO | NIS2 | Testy penetracyjne