1. Ustal zakres produktu i odpowiedzialny podmiot gospodarczy
Doradca ds. CRA powinien ustalić zakres produktu, rolę prawną i ścieżkę oceny zgodności, zanim firma zamówi badania lub sporządzi deklarację. Rezultatem jest uzasadniona decyzja dla każdej rodziny produktów, a nie ogólna oferta certyfikatu.
Rozporządzenie (UE) 2024/2847 już obowiązuje. Od 11 września 2026 r. producenci zgłaszają aktywnie wykorzystywane podatności i poważne incydenty; większość pozostałych obowiązków stosuje się od 11 grudnia 2027 r. Trzeba rozdzielić te etapy.
1. Ustal zakres produktu i odpowiedzialny podmiot gospodarczy
Określ, co rzeczywiście trafia na rynek UE i przez kogo. Marketingowe określenia „platforma” lub „IoT” nie przesądzają o zakresie CRA.
- Sporządź wykaz sprzętu, oprogramowania, osobno oferowanych komponentów, wersji, przeznaczenia, interfejsów i zdalnego przetwarzania niezbędnego do funkcji produktu.
- Wskaż producenta, właściciela marki, importera i dystrybutora; przeanalizuj projektowanie i rozwój produktu na zlecenie oraz istotne modyfikacje zamiast przypisywać wszystko fabryce.
- Sprawdź komercyjne udostępnianie, wyłączenia i sektorowe prawo UE; przy otwartym kodzie liczy się faktyczny model działalności, nie sama licencja.
2. Macierz ścieżek: kategoria to nie zakres badań
Porównaj główną funkcję z załącznikiem III (produkty ważne) i IV (krytyczne), uwzględniając techniczne opisy kategorii Komisji, zanim wybierzesz procedurę z art. 32.
| Kategoria produktu | Strategiczna ścieżka oceny |
|---|---|
| Kategoria podstawowa | Dopuszczalna jest kontrola wewnętrzna według modułu A; zewnętrzne laboratorium nie jest automatycznie wymagane. |
| Ważne, klasa I | Moduł A może być stosowany po pełnym spełnieniu właściwych warunków dotyczących norm zharmonizowanych, wspólnych specyfikacji lub odpowiedniej certyfikacji; w przeciwnym razie wymagane są B+C lub H z udziałem jednostki notyfikowanej, chyba że zastosowanie ma szczególne odstępstwo dotyczące wolnego i otwartego oprogramowania z art. 32 ust. 5. |
| Ważne, klasa II | Zaplanuj B+C lub H z udziałem jednostki notyfikowanej albo odpowiedni unijny system certyfikacji cyberbezpieczeństwa, jeśli jest wyraźnie właściwy i prawnie dostępny; osobno sprawdź odstępstwo dla wolnego i otwartego oprogramowania z art. 32 ust. 5. |
| Krytyczne (załącznik IV) | Za punkt wyjścia przyjmij udział jednostki notyfikowanej; przed decyzją sprawdź art. 32 i prawnie dostępne alternatywy certyfikacyjne. |
Wyjątek dla produktów kwalifikujących się jako wolne i otwarte oprogramowanie: zgodnie z art. 32 ust. 5 producenci produktów objętych załącznikiem III mogą stosować procedury z art. 32 ust. 1, w tym moduł A, pod warunkiem publicznego udostępnienia dokumentacji technicznej, o której mowa w art. 31, w chwili wprowadzenia produktu do obrotu. Nie oznacza to ogólnego wyłączenia spod CRA.
Dla klasy I projekt normy lub zbadanie jednej klauzuli nie uzasadnia modułu A. Zapisz dokładną podstawę kategorii, uzasadnienie techniczne i otwarte założenia.
3. Fakty, które mogą zmienić rekomendację
Ścieżka wynika z klasyfikacji, nie z nazwy handlowej ani posiadanego oznakowania CE.
- Główna funkcja ochronna: funkcja zapory może być ważniejsza niż nazwa urządzenia; integracja komponentu sama w sobie nie zmienia automatycznie klasyfikacji gotowego produktu.
- Model dostarczania: osobno sprzedawany komponent, firmware, zależność od chmury, niekomercyjny open source i istotna zmiana po wprowadzeniu na rynek wymagają odrębnej analizy.
- Status norm: odróżnij opublikowane normy zharmonizowane o właściwym zakresie od projektów, norm dobrowolnych i dowodów niespełniających prawnych warunków ścieżki.
4. Analiza luk: powiąż każdy brak z decyzją
Porównaj właściwe wymagania załącznika I z realnymi zabezpieczeniami i dowodami. Brak procesu i brak dokumentu to nie to samo.
| Luka lub przesłanka | Dowód i decyzja |
|---|---|
| Niepewna klasyfikacja | Wstrzymaj wybór ścieżki; najpierw pozyskaj architekturę, zamierzone zastosowanie i analizę kategorii według załączników. |
| Ryzyka bezpiecznego projektowania | Powiąż model zagrożeń, bezpieczne ustawienia domyślne, kontrolę dostępu i testy z oceną ryzyka cyberbezpieczeństwa produktu. |
| Nieudokumentowana obsługa podatności | Sprawdź odpowiedzialność za zgłoszenia, przyjmowanie informacji, skoordynowane ujawnianie, poprawki, aktualizacje i uzasadnienie okresu wsparcia. |
| Słaby łańcuch dowodowy | Zestaw wykaz komponentów/SBOM, dokumenty dostawców, zakres testów, wersje i dokumentację techniczną; ustal, co odnowić. |
Najpierw usuń luki zmieniające prawną ścieżkę lub uniemożliwiające kontrolę ryzyka. Osobno zapisuj lukę, osobę odpowiedzialną, dowód, decyzję i pozostałą niepewność.
5. Korzystaj ponownie z dowodów, ale nie przejmuj nieuzasadnionych wniosków
Testy penetracyjne, materiały ISO/IEC 27001, raporty dostawców i dokumenty CE mogą ograniczyć duplikację, ale same nie dowodzą zgodności CRA.
- Wykorzystuj raport tylko dla porównywalnego produktu/wersji, ryzyka, wymagania i metody; wskaż przestarzały zakres i potrzebę ponownych badań.
- Powiąż komponenty pochodzące od podmiotów trzecich i zależności oprogramowania z własną oceną producenta; certyfikaty dostawców nie przenoszą automatycznie odpowiedzialności prawnej.
- Uzgodnij ocenę ryzyka, dokumentację techniczną i procesy obsługi podatności z wybraną ścieżką.
6. Uporządkuj decyzje przed wdrożeniem
Doradztwo strategiczne ma dać weryfikowalny plan, a nie obietnicę automatycznej akceptacji.
- Utwórz rejestr zakresu, ról i wyłączeń dla produktów; oznacz nierozstrzygnięte klasyfikacje.
- Sporządź uzasadnienie ścieżki z odwołaniami do załączników, statusem norm i procedurą, w tym zależnością od jednostki notyfikowanej.
- Uporządkuj luki załącznika I, dokumentację i procesy wsparcia; przypisz zespoły i decyzje o ponownym wykorzystaniu dowodów.
- Oddzielnie uruchom zgłaszanie wymagane od 11 września 2026 r., a następnie zaplanuj zgodność na 11 grudnia 2027 r., sprawdzając przepisy przejściowe i zmiany produktu.
7. Granica doradztwa i realizacji
Ta strona dotyczy wyboru ścieżki przed realizacją. Wdrożenie, koordynacja badań i dokumentacja techniczna to osobny zakres prac; budżet wymaga analizy czynników kosztowych. Przed zakupem usług zażądaj uzasadnienia klasyfikacji i listy nierozstrzygniętych kwestii.
Oficjalne źródła pierwotne
Najczęstsze pytania
Czy backend SaaS dla UE automatycznie podlega CRA?
Nie. Ustal, czy zdalne przetwarzanie stanowi część produktu z elementami cyfrowymi i jest niezbędne dla jego funkcji; samodzielnej usługi nie można po prostu uznać za sprzęt. Sprawdź architekturę i umowy.
Czy produkt klasy I zawsze może być oceniany samodzielnie?
Nie. Zweryfikuj warunki art. 32 ust. 2 dotyczące norm zharmonizowanych, wspólnych specyfikacji lub odpowiedniej certyfikacji. Jeśli nie zostały spełnione, potrzebna jest procedura z udziałem jednostki notyfikowanej, chyba że ma zastosowanie szczególne odstępstwo dla wolnego i otwartego oprogramowania z art. 32 ust. 5.
Czy otwarty kod wyłącza gotowy produkt?
Nie. Ważne są komercyjne wprowadzenie produktu i rola organizacji. Niekomercyjna działalność związana z wolnym i otwartym oprogramowaniem oraz podmioty stale wspierające jego rozwój wymagają odrębnej oceny.
Co z urządzeniami już sprzedawanymi w UE?
Obowiązki producentów dotyczące zgłoszeń stosuje się od 11 września 2026 r., również do objętych produktów już dostępnych. Dla roku 2027 oceń pierwsze wprowadzenie, późniejsze istotne zmiany i przepisy przejściowe.
Czy test penetracyjny lub certyfikat ISO zastąpi ocenę CRA?
Nie. Wykorzystaj odpowiednie dowody, ale osobno wykaż zakres, ryzyko, warunki ścieżki, ocenę zgodności i obowiązki cyklu życia.