ISMS Copilot Docs

Unijny Akt o Cyberodporności (CRA) dla producentów produktów

Unijny Akt o Cyberodporności (CRA) to rozporządzenie wymagające od producentów produktów z elementami cyfrowymi spełnienia wymogów cyberbezpieczeństwa przez cały cykl życia produktu. Przyjęty w 2024 roku, z egzekwowaniem rozpoczynającym się pod koniec 2027 roku, CRA ma na celu poprawę bezpieczeństwa podłączonych urządzeń, oprogramowania i sprzętu sprzedawanego w UE poprzez nakazanie bezpiecznego projektowania, zarządzania podatnościami i przejrzystości właściwości bezpieczeństwa.

Unijny Akt o Cyberodporności (CRA) to rozporządzenie wymagające od producentów produktów z elementami cyfrowymi spełnienia wymogów cyberbezpieczeństwa przez cały cykl życia produktu. Przyjęty w 2024 roku, z egzekwowaniem rozpoczynającym się pod koniec 2027 roku, CRA ma na celu poprawę bezpieczeństwa podłączonych urządzeń, oprogramowania i sprzętu sprzedawanego w UE poprzez nakazanie bezpiecznego projektowania, zarządzania podatnościami i przejrzystości właściwości bezpieczeństwa.

CRA dotyczy producentów produktów, a nie dostawców usług. Jeśli oferujesz usługi SaaS lub chmurowe, CRA prawdopodobnie nie ma do Ciebie zastosowania – skup się na NIS2, RODO lub DORA.

Kto musi przestrzegać przepisów?

CRA dotyczy producentów wprowadzających na rynek UE „produkty z elementami cyfrowymi”:

  • Producenci sprzętu: urządzenia IoT, routery, inteligentne urządzenia domowe, czujniki przemysłowe, sprzęt sieciowy
  • Dostawcy oprogramowania: systemy operacyjne, przeglądarki, oprogramowanie zabezpieczające, aplikacje biurowe, aplikacje mobilne (jeśli sprzedawane jako samodzielne produkty)
  • Producenci systemów wbudowanych: urządzenia medyczne, komponenty motoryzacyjne, inteligentne urządzenia AGD z oprogramowaniem układowym
  • Opiekunowie oprogramowania open-source: organizacje świadczące komercyjne wsparcie lub oznaczanie CE dla produktów open-source

Produkty zwolnione z CRA obejmują:

  • Urządzenia medyczne, systemy motoryzacyjne, systemy lotnicze już objęte sektorowymi przepisami UE
  • Czyste usługi SaaS lub chmurowe (bez pobieranego oprogramowania)
  • Oprogramowanie niestandardowe opracowane dla jednego klienta
  • Oprogramowanie open-source opracowane lub dostarczane poza działalnością komercyjną (bez oznaczania CE lub monetyzacji)

Jeśli produkujesz sprzęt lub sprzedajesz pobieralne oprogramowanie w UE, CRA prawdopodobnie ma zastosowanie.

Klasyfikacja ryzyka według CRA

Produkty są klasyfikowane do poziomów ryzyka określających wymagania dotyczące zgodności:

Produkty domyślne (standardowe wymogi cyberbezpieczeństwa):

  • Większość produktów konsumenckich i biznesowych (inteligentne urządzenia domowe, oprogramowanie biurowe, sprzęt sieciowy)
  • Samoocena zgodności
  • Producent deklaruje zgodność poprzez oznakowanie CE

Produkty ważne (Klasa I):

  • Systemy zarządzania tożsamością, narzędzia uwierzytelniające, VPN-y, zapory sieciowe, oprogramowanie antywirusowe, przeglądarki, menedżery haseł
  • Produkty kluczowe dla infrastruktury krytycznej lub wysokowartościowych aktywów
  • Wymagana ocena zgodności przez stronę trzecią
  • Jednostka Notyfikowana dokonuje przeglądu projektu i procesów

Produkty krytyczne (Klasa II):

  • Systemy operacyjne, hiperwizory, systemy sterowania przemysłowego, inteligentne liczniki, karty inteligentne do płatności
  • Najwyższa kontrola z kompleksową oceną przez stronę trzecią
  • Jednostka Notyfikowana audytuje cykl rozwoju i kontrole bezpieczeństwa

Większość producentów dokona samooceny jako klasy „domyślnej”, chyba że ich produkt jest wyraźnie wymieniony w załącznikach CRA.

Niewłaściwa klasyfikacja poziomu ryzyka produktu może skutkować niezgodnością. Dokładnie przejrzyj załączniki CRA III (Ważne) i IV (Krytyczne) lub skonsultuj się z Jednostką Notyfikowaną.

Podstawowe wymagania

Wszystkie produkty z elementami cyfrowymi muszą spełniać podstawowe wymogi cyberbezpieczeństwa:

Bezpieczeństwo projektowe i domyślne:

  • Minimalizacja powierzchni ataku (wyłączanie niepotrzebnych funkcji, usług i portów domyślnie)
  • Bezpieczne ustawienia domyślne (silne uwierzytelnianie, włączone szyfrowanie po wyjęciu z pudełka)
  • Zasada najmniejszych uprawnień (ograniczone uprawnienia dla procesów i użytkowników)
  • Obrona w głąb (wielowarstwowe kontrole bezpieczeństwa)

Obsługa podatności:

  • Publikacja polityki ujawniania podatności (VDP) wraz z danymi kontaktowymi
  • Ocena i usuwanie zgłoszonych podatności w określonych terminach (krytyczne: 24-72 godziny; wysokie: 14 dni; średnie: 90 dni)
  • Powiadamianie użytkowników i ENISA (agencji UE ds. cyberbezpieczeństwa) o aktywnie wykorzystywanych podatnościach
  • Zapewnienie aktualizacji bezpieczeństwa przez oczekiwany okres życia produktu lub minimum 5 lat (w zależności, co jest dłuższe)

Bezpieczne aktualizacje:

  • Dostarczanie poprawek bezpieczeństwa automatycznie lub z powiadomieniem użytkownika
  • Zapewnienie, że aktualizacje są uwierzytelnione (podpisane) i nie mogą być naruszone
  • Umożliwienie powrotu do poprzednich wersji w przypadku niepowodzenia aktualizacji

Ochrona danych:

  • Ochrona poufności i integralności przechowywanych i przesyłanych danych (szyfrowanie w spoczynku i w tranzycie)
  • Wdrożenie bezpiecznego przechowywania poświadczeń (brak haseł na stałe w kodzie)
  • Przetwarzanie tylko niezbędnych danych (minimalizacja)

Odporność i dostępność:

  • Ochrona przed atakami typu „odmowa usługi”
  • Zapewnienie funkcjonalności w warunkach nienormalnych lub podczas ataków
  • Zapewnienie możliwości rejestrowania i monitorowania zdarzeń bezpieczeństwa

Przejrzystość i dokumentacja:

  • Dostarczanie użytkownikom jasnych instrukcji bezpieczeństwa (jak skonfigurować bezpiecznie, jak aktualizować, jak zgłaszać podatności)
  • Publikacja Wykazu Materiałów Oprogramowania (SBOM) zawierającego komponenty i zależności
  • Deklaracja okresu wsparcia i dat zakończenia wsparcia

Ocena zgodności

Producenci muszą wykazać zgodność przed wprowadzeniem produktów na rynek UE:

Dla produktów domyślnych (standardowych):

  1. Przeprowadzenie oceny ryzyka i testów bezpieczeństwa
  2. Przygotowanie dokumentacji technicznej (specyfikacje projektowe, SBOM, wyniki testów, środki bezpieczeństwa)
  3. Sporządzenie Deklaracji Zgodności UE
  4. Umieszczenie oznakowania CE
  5. Rejestracja produktu w bazie danych UE (zarządzanej przez ENISA)

Dla produktów ważnych/krytycznych (Klasa I/II):

  1. Wykonanie powyższych kroków
  2. Zaangażowanie Jednostki Notyfikowanej (akredytowanego oceniającego stronę trzecią)
  3. Przejście przeglądu projektu i/lub audytu procesów cyberbezpieczeństwa
  4. Otrzymanie certyfikatu Jednostki Notyfikowanej
  5. Umieszczenie oznakowania CE wraz z identyfikatorem Jednostki Notyfikowanej
  6. Rejestracja produktu w bazie danych UE

Oceny przez Jednostkę Notyfikowaną mogą trwać od 3 do 12 miesięcy i kosztować od 20 000 do ponad 100 000 euro w zależności od złożoności produktu.

Rozpocznij ocenę zgodności wcześnie. W przypadku produktów Klasy I/II opóźnienia w dostępności Jednostek Notyfikowanych mogą przesunąć termin wprowadzenia produktu na rynek o 6-12 miesięcy.

Obowiązki w cyklu życia produktu

Obowiązki wynikające z CRA trwają po wprowadzeniu produktu na rynek:

  • Ciągłe monitorowanie: Śledzenie zgłoszeń podatności, informacji o zagrożeniach i exploitach wpływających na produkt
  • Raportowanie incydentów: Powiadamianie ENISA w ciągu 24 godzin od wykrycia aktywnie wykorzystywanych podatności lub poważnych incydentów wpływających na bezpieczeństwo produktu
  • Dostarczanie aktualizacji: Zapewnienie terminowych aktualizacji bezpieczeństwa przez okres wsparcia (minimum 5 lat)
  • Prowadzenie dokumentacji: Utrzymywanie dokumentacji technicznej i dowodów zgodności przez 10 lat
  • Współpraca z organami nadzoru rynku: Reagowanie na zapytania organów nadzoru rynku UE

Niezachowanie zgodności po wprowadzeniu produktu na rynek może skutkować wycofaniem produktu lub zakazem sprzedaży.

Kary za niezgodność

CRA przewiduje znaczące kary finansowe:

  • Do 15 milionów euro lub 2,5% globalnego rocznego obrotu (w zależności, co jest wyższe) za niezgodność z podstawowymi wymaganiami
  • Do 10 milionów euro lub 2% obrotu za brak współpracy z organami lub nieprzedstawienie dokumentacji
  • Do 5 milionów euro lub 1% obrotu za dostarczenie nieprawidłowych lub niekompletnych informacji

Państwa członkowskie mogą nakładać dodatkowe kary, w tym wycofanie produktów z rynku, zakazy sprzedaży lub odpowiedzialność karną za poważne naruszenia.

Harmonogram i okres przejściowy

CRA został przyjęty w 2024 roku z fazowym wdrażaniem:

  • Koniec 2027: Rozpoczęcie pełnego egzekwowania CRA (dokładna data do ustalenia po oficjalnej publikacji)
  • Okres przejściowy: Produkty już obecne na rynku przed rozpoczęciem egzekwowania mogą pozostać, ale aktualizacje muszą być zgodne z wymaganiami CRA dotyczącymi obsługi podatności
  • Akredytacja Jednostek Notyfikowanych: Państwa członkowskie wyznaczają Jednostki Notyfikowane w latach 2025-2027

Producenci powinni rozpocząć prace nad zgodnością już teraz, szczególnie w przypadku produktów Klasy I/II wymagających oceny przez stronę trzecią.

CRA przewiduje „okres przejściowy” dla opiekunów oprogramowania open-source, ale szczegóły są jeszcze ustalane. Monitoruj akty wykonawcze UE w celu uzyskania wyjaśnień.

Kluczowa dokumentacja

Producenci muszą tworzyć i utrzymywać:

  • Dokumentacja techniczna: Opis produktu, specyfikacje projektowe, ocena ryzyka, SBOM, wyniki testów bezpieczeństwa, dowody bezpiecznego cyklu rozwoju
  • Deklaracja Zgodności UE: Formalne oświadczenie, że produkt spełnia wymagania CRA
  • Polityka ujawniania podatności: Opublikowany proces przyjmowania i obsługi zgłoszeń podatności
  • Instrukcje bezpieczeństwa: Przeznaczone dla użytkowników wskazówki dotyczące bezpiecznej konfiguracji, aktualizacji i zgłaszania incydentów
  • Certyfikaty zgodności: Certyfikaty Jednostki Notyfikowanej dla produktów Klasy I/II

CRA a inne przepisy

CRA nakłada się i współdziała z innymi przepisami UE:

  • RODO: Wymogi CRA dotyczące ochrony danych uzupełniają RODO (ale go nie zastępują)
  • NIS2: CRA skupia się na produktach; NIS2 na bezpieczeństwie organizacyjnym i raportowaniu incydentów przez dostawców usług
  • Akt o AI: Produkty z funkcjami AI mogą wymagać zgodności zarówno z CRA (cyberbezpieczeństwo), jak i Aktem o AI (bezpieczeństwo, przejrzystość)
  • Dyrektywa o urządzeniach radiowych (RED): Produkty bezprzewodowe muszą spełniać zarówno RED, jak i CRA
  • Rozporządzenie w sprawie maszyn: Maszyny przemysłowe z elementami cyfrowymi muszą spełniać oba

Koordynuj zgodność z różnymi przepisami, aby uniknąć dublowania lub sprzecznych wymagań.

Jak ISMS Copilot może pomóc

ISMS Copilot może wspierać przygotowania do zgodności z CRA:

  • Tworzenie polityk: Generowanie polityk ujawniania podatności, polityk bezpiecznego rozwoju, procedur reagowania na incydenty
  • Ocena ryzyka: Opracowywanie szablonów oceny ryzyka bezpieczeństwa produktu
  • Dokumentacja procesów: Tworzenie procedur bezpiecznego SDLC (modelowanie zagrożeń, bezpieczne kodowanie, testy bezpieczeństwa, zarządzanie poprawkami)
  • Treści dla użytkowników: Przygotowywanie instrukcji bezpieczeństwa do dokumentacji produktu
  • Analiza luk: Przesyłanie istniejącej dokumentacji bezpieczeństwa produktu w celu identyfikacji luk

Chociaż ISMS Copilot nie posiada jeszcze dedykowanej wiedzy na temat CRA, możesz zadawać ogólne pytania dotyczące bezpiecznego rozwoju produktów, zarządzania podatnościami i najlepszych praktyk dotyczących SBOM.

Spróbuj zapytać: „Utwórz politykę ujawniania podatności dla producenta sprzętu” lub „Co powinienem uwzględnić w dokumentacji bezpieczeństwa produktu?”

Jak zacząć

Aby przygotować się do zgodności z CRA przy pomocy ISMS Copilot:

  1. Sklasyfikuj swoje produkty według poziomów ryzyka CRA (domyślne, Klasa I, Klasa II)
  2. Utwórz dedykowane środowisko robocze dla projektu zgodności z CRA
  3. Przeprowadź ocenę ryzyka bezpieczeństwa produktu (zidentyfikuj zagrożenia, podatności, skutki)
  4. Wykorzystaj AI do wygenerowania polityki ujawniania podatności
  5. Opracuj procedury bezpiecznego cyklu rozwoju (modelowanie zagrożeń, przegląd kodu, testy bezpieczeństwa, procesy aktualizacji)
  6. Utwórz Wykaz Materiałów Oprogramowania (SBOM) dla każdego produktu
  7. Przygotuj instrukcje bezpieczeństwa dla użytkowników (bezpieczna konfiguracja, procedury aktualizacji, zgłaszanie podatności)
  8. W przypadku produktów Klasy I/II, wcześnie zidentyfikuj i zaangażuj Jednostkę Notyfikowaną

Powiązane zasoby

  • Oficjalny tekst rozporządzenia CRA (UE 2024/XXXX—sprawdź EUR-Lex w celu uzyskania ostatecznej publikacji)
  • Wytyczne i FAQ dotyczące CRA od ENISA
  • Katalogi Jednostek Notyfikowanych (listy akredytowanych oceniających w państwach członkowskich)
  • Standardy SBOM (SPDX, CycloneDX)

On this page