CRA Otrzymuje Instrukcję Obsługi: Co Wytyczne Komisji Oznaczają dla Ciebie

Cyber Resilience Act posiada swój tekst od końca 2024 roku. Brakowało mu jednak instrukcji obsługi. 3 marca 2026 roku Komisja Europejska opublikowała dokładnie to: projekt komunikatu Ares(2026)2319816 — około 70 stron praktycznych wytycznych dotyczących interpretacji rozporządzenia.

Są to wytyczne na podstawie Artykułu 26, na które branża czekała. Oto co zawierają i co oznaczają dla Ciebie.

Wprowadzenie

Projekt komunikatu Ares(2026)2319816, datowany na 3 marca 2026 roku, jest pierwszym kompleksowym dokumentem wytycznych Komisji Europejskiej dotyczącym Cyber Resilience Act. Na około 70 stronach omawia pytania, które nie dawały spokoju zespołom ds. zgodności: Co oznacza „zdalne przetwarzanie danych"? Czy produkty starszego pokolenia wymagają pełnego przeprojektowania? Kiedy aktualizacja oprogramowania staje się nowym produktem?

Niniejszy artykuł distyluje dziewięć najważniejszych rozstrzygnięć w praktyczne wytyczne dla producentów, importerów i dystrybutorów produktów z elementami cyfrowymi.

1. SaaS i Chmura: Test RDPS

Komisja wprowadza rygorystyczny test trzech pytań, pozwalający ustalić, czy komponent chmurowy lub SaaS kwalifikuje się jako „rozwiązanie do zdalnego przetwarzania danych" (RDPS), a tym samym wchodzi w zakres oceny zgodności produktu.

flowchart TD
    A["Czy rozwiązanie przetwarza dane
'na odległość'?"] -->|Nie| B["Nie jest RDPS"]
    A -->|Tak| C["Czy produkt utraciłby podstawową funkcję
bez tego rozwiązania?"]
    C -->|Nie| D["Nie jest RDPS
(traktuj jako komponent,
zachowaj należytą staranność zgodnie z Art. 13(5))"]
    C -->|Tak| E["Zaprojektowane przez producenta
lub na jego odpowiedzialność?"]
    E -->|Nie| F["Nie jest RDPS
(zewnętrzny SaaS = komponent,
zachowaj należytą staranność zgodnie z Art. 13(5))"]
    E -->|Tak| G["RDPS: w zakresie oceny
zgodności produktu"]

Wytyczne ilustrują to pięcioma konkretnymi scenariuszami: aplikacja bankowa, inteligentny termostat, czytnik e-booków, robot przemysłowy i urządzenie sieci komórkowej.

2. Produkty Starszego Pokolenia

Produkty już obecne na rynku UE przed grudniem 2027 roku nie wymagają przeprojektowania od podstaw. Nie są jednak zwolnione z obowiązków.

Komisja wyjaśnia trzy kwestie:

Nie jest wymagana historyczna rekonstrukcja. Nie trzeba odtwarzać dokumentacji projektowej sprzed lat. Liczy się bieżąca ocena ryzyka cyberbezpieczeństwa wykazująca, że produkt spełnia zasadnicze wymagania stosownie do jego zamierzonego przeznaczenia.

Rodziny produktów mogą być grupowane. Jeśli wiele produktów starszego pokolenia posiada tę samą architekturę i profil ryzyka, można przeprowadzić jedną ocenę ryzyka obejmującą całą rodzinę, zamiast oceniać każdy wariant produktu (SKU) osobno.

Pełna zgodność nadal obowiązuje. Produkty starszego pokolenia nadal wymagają oznakowania CE, Deklaracji Zgodności oraz aktywnego zarządzania podatnościami w przyszłości. Ulga dotyczy historii dokumentacji, a nie samych obowiązków.

Szczegółowy opis procesu oceny zgodności zawiera nasz Przewodnik po Decyzjach dotyczących Oceny Zgodności. Planowanie okresu wsparcia dla produktów starszego pokolenia omówiono w artykule Planowanie Okresu Wsparcia.

3. Oprogramowanie i „Nieskończone Kopie"

Kiedy oprogramowanie jest „wprowadzane na rynek"? Komisja potwierdza: jednorazowo. Pierwsza dystrybucja cyfrowa stanowi wprowadzenie na rynek. Kolejne drobne aktualizacje (np. z wersji v1.0.0 do v1.0.1) nie resetują zegara regulacyjnego.

Dotyczy to wyłącznie samodzielnego oprogramowania dystrybuowanego cyfrowo. Produkty sprzętowe z wbudowanym oprogramowaniem podlegają standardowym zasadom wprowadzania na rynek towarów fizycznych.

4. Kiedy Aktualizacje Stają Się „Istotnymi Modyfikacjami"

Ta sekcja jest najbardziej praktyczną częścią całego dokumentu. Komisja podaje konkretne przykłady odróżniające rutynowe aktualizacje od zmian wymagających nowej oceny zgodności.

Komisja proponuje cztery pytania, które każdy producent powinien zadać przed wydaniem aktualizacji:

1. Czy aktualizacja wprowadza nowe wektory zagrożeń?
2. Czy umożliwia nowe scenariusze ataku?
3. Czy zmienia prawdopodobieństwo wystąpienia istniejących scenariuszy ataku?
4. Czy zmienia skutki istniejących scenariuszy ataku?

Jeśli odpowiedź na którekolwiek z tych pytań brzmi „tak", aktualizacja prawdopodobnie stanowi istotną modyfikację wymagającą nowej oceny zgodności.

Więcej informacji na temat klasyfikacji produktów i jej interakcji z modyfikacjami zawiera nasz Przewodnik po Klasyfikacji Produktów.

5. Zasady dotyczące Open Source

Wytyczne zawierają kilka ważnych wyjaśnień dotyczących stosowania CRA do oprogramowania open source:

• Publikowanie kodu źródłowego w publicznych repozytoriach nie stanowi „wprowadzenia na rynek". CRA ma zastosowanie w momencie komercyjnej dystrybucji, a nie udostępnienia kodu.
• Wersja społecznościowa a wersja płatna = różne produkty. Jeśli oferujesz bezpłatną wersję społecznościową i płatną wersję komercyjną, obowiązki producenta dotyczą wyłącznie wersji płatnej.
• Same darowizny nie czynią FOSS komercyjnym — chyba że dostęp do oprogramowania jest uzależniony od wpłaty. Dobrowolne darowizny są wyraźnie wyłączone.
• Podmioty non-profit, których nadwyżki w całości przeznaczane są na cele non-profit, są zwolnione z obowiązków producenta, nawet jeśli prowadzą monetyzację.
• Współtwórcy bez kontroli nad wydaniami, harmonogramem lub zarządzaniem NIE są uznawani za producentów — nawet jeśli mają dostęp do repozytorium (ang. commit access). Odpowiedzialność spoczywa na tym, kto kontroluje proces wydawniczy.
• Obowiązki podmiotów zarządzających oprogramowaniem open source rosną proporcjonalnie do poziomu udzielanego wsparcia. Zarządzanie o charakterze nietech­nicznym wiąże się z lżejszymi obowiązkami niż pełne komercyjne wsparcie.

Powiązane wytyczne dotyczące skoordynowanego ujawniania podatności w kontekście open source zawiera nasz Szablon Polityki CVD.

6. Okres Wsparcia: Pięć Lat to Minimum

Komisja jasno wskazuje, że domyślny pięcioletni okres wsparcia jest wartością minimalną, a nie docelową. Produkty, które mają pozostawać w użyciu dłużej niż pięć lat, muszą mieć proporcjonalnie dłuższe okresy wsparcia.

Wytyczne wyjaśniają również ścieżkę przewidzianą w Artykule 13(10): producenci mogą zaprzestać wydawania łatek dla starszych wersji, jeśli użytkownicy mogą bezpłatnie przejść na obsługiwaną wersję. „Dodatkowe koszty" w tym kontekście oznaczają obowiązkowe zakupy sprzętu — rutinowe testowanie, rekonfiguracja czy nakład pracy użytkownika związany z wdrożeniem nie kwalifikują się jako takie koszty.

Szczegółowe strategie planowania opisano w naszym Przewodniku po Planowaniu Okresu Wsparcia.

7. Ocena Ryzyka: Wewnętrzna Tolerancja Ryzyka jest Nieistotna

Komisja nie pozostawia wątpliwości: oceny ryzyka na podstawie CRA muszą opierać się na obiektywnych kryteriach cyberbezpieczeństwa, a nie na wewnętrznej tolerancji ryzyka producenta. W szczególności:

• Strategia komercyjna i względy kosztowe nie są uwzględniane w ocenie ryzyka cyberbezpieczeństwa.
• Ryzyka cyberbezpieczeństwa nie można przenosić na użytkowników za pomocą dokumentacji, zastrzeżeń (ang. disclaimers) ani warunków korzystania z usługi.
• Jeśli zidentyfikowanych ryzyk nie można wyeliminować środkami technicznymi lub organizacyjnymi, produkt może wymagać zmian projektowych przed wprowadzeniem na rynek.

To istotne stwierdzenie. Oznacza ono, że producent nie może świadomie wprowadzić na rynek produktu z niezlikwidowanymi ryzykami cyberbezpieczeństwa wyłącznie dlatego, że przedsiębiorstwo „zaakceptowało" to ryzyko.

Przegląd implikacji kosztowych zgodności zawiera nasz Przewodnik po Szacowaniu Kosztów Zgodności.

8. Znane Podatności Mogące Być Wykorzystane

Wytyczne wyjaśniają, co oznacza pojęcie „znany" w kontekście wymogu CRA dotyczącego wprowadzania na rynek produktów bez znanych podatności mogących być wykorzystane:

• Ujęte w publicznych bazach danych: Unijna Baza Danych Podatności, CVE/MITRE, NVD.
• Ujawnione kanałami niepublicznymi: programy skoordynowanego ujawniania podatności, wewnętrzne testy bezpieczeństwa, zewnętrzne testy penetracyjne.
• Szeroko opisane w wiarygodnych mediach: poważna podatność opisana przez główne publikacje z zakresu cyberbezpieczeństwa kwalifikuje się jako „znana".

Producenci mają ograniczone okno czasowe na weryfikację, czy zgłoszona podatność rzeczywiście dotyczy ich produktu. „Dochodzenie" nie jest jednak furtką — zegar biegnie od momentu powzięcia wiedzy, a wszelkie opóźnienia będą poddane kontroli.

Praktyczne wytyczne dotyczące dokumentowania podatności zawiera nasz Przewodnik po VEX.

9. Obowiązki Sprawozdawcze (Wrzesień 2026)

Obowiązki sprawozdawcze wchodzące w życie we wrześniu 2026 roku to pierwszy termin CRA z realnym mechanizmem egzekwowania. Wytyczne potwierdzają strukturę czasową:

• 24 godziny: Wczesne ostrzeżenie do ENISA po powzięciu wiedzy o aktywnym wykorzystaniu
• 72 godziny: Szczegółowe powiadomienie z wskaźnikami technicznymi
• 14 dni: Raport końcowy dla podatności / 30 dni dla incydentów

„Świadomość" oznacza rozsądną pewność po wstępnej ocenie — nie pełne potwierdzenie kryminalistyczne. Jeśli posiadasz wiarygodne dowody aktywnego wykorzystania, zegar już tyka.

W kwestii powiadamiania użytkowników: Komisja potwierdza, że powinno ono być oparte na ryzyku i proporcjonalne. Nie istnieje obowiązek obowiązkowego publicznego ujawnienia, jeśli ujawnienie zwiększałoby ryzyko bezpieczeństwa.

Pełny opis procesu sprawozdawczego zawiera nasz Przewodnik po 24-Godzinnym Zgłaszaniu ENISA. Kompletny harmonogram zgodności przedstawia nasz Harmonogram Wdrożenia.

Co To Oznacza dla Ciebie

Niniejsze wytyczne nie zmieniają tego, czego wymaga CRA. Zmieniają jednak zakres domysłów potrzebnych do interpretacji przepisów. Producenci dysponują teraz konkretnymi testami (RDPS), konkretnymi przykładami (istotne modyfikacje) i konkretnymi terminami (sprawozdawczość), z których mogą korzystać.

Trzy natychmiastowe działania:

1. Przeprowadź test RDPS dla każdej usługi chmurowej, od której zależy Twój produkt. CRA Evidence automatyzuje tę ocenę w ramach analizy ryzyka produktu.
2. Przejrzyj swój proces aktualizacji pod kątem czterech pytań dotyczących istotnych modyfikacji. Uwzględnij je na liście kontrolnej wydań.
3. Przygotuj się na sprawozdawczość od września 2026. Wewnętrzne procesy triażu, ścieżki eskalacji i szablony raportów muszą być gotowe przed upływem terminu.

Okres konsultacji jest otwarty za pośrednictwem portalu Lepsze Regulacje (Better Regulation). Jeśli masz uwagi do wytycznych, teraz jest właściwy moment.

Krokowe podejście do gotowości CRA opisuje nasz Przewodnik po Zgodności dla Startupów.

Niniejszy artykuł powstał na podstawie projektu komunikatu Ares(2026)2319816, datowanego na 3 marca 2026 roku. Wytyczne te nie zostały jeszcze formalnie przyjęte przez Komisję Europejską i zostaną sfinalizowane po udostępnieniu wszystkich wersji językowych UE.