Sprawdź gotowość do CRA

Rejestracja na Single Reporting Platform ENISA

Osobiste konta EU Login z uwierzytelnianiem wieloskładnikowym dla osób, które będą składać zgłoszenia, i zweryfikowana firma na platformie. Jeden główny przedstawiciel i do dwudziestu dodatkowych.

Art. 14, 16Zegar zgłoszeń →

Wskaż, kto decyduje i kto go zastępuje

Jedna osoba decyduje, że podatność jest aktywnie wykorzystywana albo że doszło do poważnego incydentu, a druga zastępuje ją na urlopie i w weekend. Spisz kroki od pierwszego sygnału do wczesnego ostrzeżenia tak, żeby dało się je wykonać o drugiej w nocy.

Art. 14(1), 14(2)Zegar zgłoszeń →

Wiedz, co działa i gdzie

Dla każdego produktu: jakie wersje firmware działają w terenie i w których państwach członkowskich jest sprzedawany. Wczesne ostrzeżenie pyta o kraje, a bez wersji nie ocenisz, czy problem cię dotyczy.

Art. 14(2)(a)

Obserwuj, czy twoje komponenty są atakowane

Prowadź SBOM dla każdego wydania i codziennie porównuj go z listami podatności wykorzystywanych w praktyce, takimi jak CISA KEV i EUVD prowadzona przez ENISA. Samo trafienie nie uruchamia zegara, ale to sygnał, żeby jeszcze tego dnia ocenić własny produkt.

Art. 14(1), Annex I Part II(1)Monitor podatności SBOM →

Zauważ poważny incydent

Logi i alerty na backendzie, serwerze aktualizacji i w infrastrukturze podpisywania. Wyciek klucza do podpisywania albo przejęty serwer aktualizacji to poważny incydent, a zgłosić możesz tylko to, co widzisz.

Art. 14(3)

Kanał do użytkowników, których to dotyczy

Po tym, jak się dowiesz, musisz poinformować użytkowników, których problem dotyczy, a w razie potrzeby wszystkich, o problemie i o tym, co mogą zrobić. Ustal zawczasu, czy to lista mailingowa, portal klienta, komunikat w aplikacji czy telefon do klientów B2B.

Art. 14(8)

Opublikowany kontakt do zgłaszania podatności

Formalnie wymagany od grudnia 2027, ale bez niego nikt nie powie ci o problemie już dziś. Plik security.txt i krótka polityka ujawniania to godzina pracy.

Annex I Part II(5), (6) · recommended nowGenerator security.txt →

Udokumentowana ocena ryzyka cyberbezpieczeństwa

Na podstawie przeznaczenia, racjonalnie przewidywalnego użycia, środowiska pracy, chronionych zasobów i czasu, przez jaki produkt będzie używany. Uwzględnij backend w chmurze, bo jest częścią produktu. Od tej oceny zależą wszystkie decyzje poniżej.

Art. 13(2), 13(3)

Każde wymaganie z załącznika I spełnione albo uzasadnione

Dla każdego punktu części I załącznika I poniżej ocena ryzyka mówi, jak jest spełniony albo dlaczego nie ma zastosowania. Wymaganie pominięte bez słowa to najłatwiejsze ustalenie dla organu nadzoru rynku.

Art. 13(3), 13(4)

Bez znanych podatności możliwych do wykorzystania

Przeskanuj SBOM wydania przed wysyłką i napraw albo uzasadnij każde trafienie, które da się wykorzystać. Firmware, który leżał miesiącami w magazynie, trzeba sprawdzić przed wysyłką.

Annex I Part I(2)(a)Monitor podatności SBOM →

Bezpieczna konfiguracja domyślna i reset

Bez wspólnych haseł domyślnych, z wyłączonym debugowaniem i nieużywanymi usługami, z najbezpieczniejszymi ustawieniami od razu po wyjęciu z pudełka i z możliwością przywrócenia stanu fabrycznego.

Annex I Part I(2)(b)

Aktualizacje bezpieczeństwa, domyślnie automatyczne

Tam, gdzie to ma zastosowanie, aktualizacje instalują się domyślnie automatycznie w odpowiednim czasie, z jasną możliwością rezygnacji, powiadomieniem o dostępnych aktualizacjach i opcją ich odłożenia.

Annex I Part I(2)(c)

Ochrona przed nieuprawnionym dostępem

Osobne poświadczenia dla każdego urządzenia, wzajemne TLS do backendu, uwierzytelnianie na każdym lokalnym interfejsie i rejestrowanie możliwych prób nieuprawnionego dostępu, na przykład nieudanych logowań.

Annex I Part I(2)(d)

Poufność danych

Aktualne TLS w transmisji, a wrażliwe dane i sekrety zaszyfrowane w pamięci, na przykład przez szyfrowanie flasha albo secure element.

Annex I Part I(2)(e)

Integralność danych, poleceń, firmware i konfiguracji

Secure boot, podpisane obrazy firmware, uwierzytelnione polecenia i konfiguracja oraz zgłaszanie wykrytego uszkodzenia.

Annex I Part I(2)(f)

Minimalizacja danych

Zbieraj i przetwarzaj tylko te dane, osobowe i inne, których produkt potrzebuje do swojego przeznaczenia.

Annex I Part I(2)(g)

Podstawowe funkcje pozostają dostępne

Także po incydencie: watchdog, limity zapytań, odporność na ataki odmowy usługi i rozsądne działanie, gdy backend jest niedostępny.

Annex I Part I(2)(h)

Bez szkody dla innych urządzeń i sieci

Ponowne łączenie z backoffem i losowym opóźnieniem, bez lawin ponowień i bez niczego, co zamieni dziesięć tysięcy urządzeń w zalew ruchu na cudzą usługę.

Annex I Part I(2)(i)

Ograniczona powierzchnia ataku

Zablokowane w produkcji porty debugowania, takie jak JTAG i UART, żadnych zbędnych otwartych portów i żadnych testowych endpointów w firmware ani w API.

Annex I Part I(2)(j)

Mechanizmy utrudniające wykorzystanie błędów

Ochrona stosu, ochrona pamięci albo obszary bez prawa wykonania tam, gdzie pozwala sprzęt, i minimalne uprawnienia między zadaniami i usługami.

Annex I Part I(2)(k)

Rejestrowanie zdarzeń bezpieczeństwa z możliwością rezygnacji

Rejestruj i monitoruj istotne zdarzenia wewnętrzne, takie jak dostęp do danych, usług lub funkcji albo ich zmiana, i pozwól użytkownikowi z tego zrezygnować.

Annex I Part I(2)(l)

Bezpieczne, trwałe usuwanie danych

Użytkownik może łatwo i trwale usunąć wszystkie dane i ustawienia, a ewentualne przeniesienie danych do innego produktu lub systemu odbywa się bezpiecznie.

Annex I Part I(2)(m)

SBOM dla każdego wydania

W popularnym formacie do odczytu maszynowego, takim jak CycloneDX albo SPDX, obejmujący co najmniej zależności najwyższego poziomu. Generuj go w procesie budowania, a nie ręcznie.

Annex I Part II(1)

Naprawa bez zwłoki, bezpieczeństwo osobno od funkcji

Usuwaj podatności bez zwłoki, adekwatnie do ryzyka, i tam, gdzie to technicznie wykonalne, wydawaj aktualizacje bezpieczeństwa osobno od aktualizacji funkcjonalnych.

Annex I Part II(2)

Regularne testy i przeglądy bezpieczeństwa

Skuteczne i regularne, na przykład skanowanie zależności w CI, coroczny test penetracyjny urządzenia i backendu oraz przegląd przed większymi wydaniami.

Annex I Part II(3)

Publikuj komunikaty o naprawionych podatnościach

Po wydaniu aktualizacji: na czym polega podatność, których produktów i wersji dotyczy, jakie ma skutki i wagę oraz jak ją usunąć. Publikację można odłożyć, aż użytkownicy będą mieli szansę zainstalować poprawkę.

Annex I Part II(4)

Polityka skoordynowanego ujawniania podatności

Spisana, opublikowana i faktycznie stosowana: jak przyjmujesz zgłoszenia, potwierdzasz je, naprawiasz i ujawniasz.

Annex I Part II(5), Art. 13(8)Generator security.txt →

Pojedynczy punkt kontaktowy

Łatwy do znalezienia, pozwala wybrać sposób kontaktu i nie ogranicza się do narzędzi automatycznych. Przyjmuje też zgłoszenia dotyczące komponentów firm trzecich w twoim produkcie.

Annex I Part II(6), Art. 13(17)Generator security.txt →

Bezpieczna dystrybucja aktualizacji

Podpisane obrazy przesyłane uwierzytelnionym kanałem, z ochroną przed powrotem do starszej wersji, żeby poprawki docierały do floty na czas, a tam, gdzie to ma zastosowanie, automatycznie.

Annex I Part II(7)

Bezpłatne aktualizacje z komunikatem

Aktualizacje bezpieczeństwa wychodzą bez zwłoki i bezpłatnie (chyba że w przypadku produktu na zamówienie ustalono inaczej z klientem biznesowym), razem z informacją, co użytkownik ma zrobić.

Annex I Part II(8)

Należyta staranność wobec komponentów zewnętrznych

Sprawdzaj, czy biblioteki, SDK i moduły, które integrujesz, nie osłabiają bezpieczeństwa produktu, także te open source. Gdy znajdziesz w którymś podatność, zgłoś ją opiekunowi i udostępnij swoją poprawkę.

Art. 13(5), 13(6)Monitor podatności SBOM →

Okres wsparcia ustalony i uzasadniony

Co najmniej pięć lat, a dłużej, jeśli produkt będzie dłużej używany. Licznik, który wisi na ścianie piętnaście lat, potrzebuje piętnastu. Udokumentuj, na czym opierasz tę decyzję.

Art. 13(8)

Koniec wsparcia widoczny przy zakupie

Co najmniej miesiąc i rok, wyraźnie widoczne w momencie zakupu. Tam, gdzie to technicznie wykonalne, produkt informuje użytkownika o zakończeniu wsparcia.

Art. 13(19)

Przechowuj każdą aktualizację bezpieczeństwa

Przez co najmniej dziesięć lat od wydania albo do końca okresu wsparcia, zależnie od tego, co trwa dłużej. Zaplanuj na ten czas przechowywanie plików i kluczy do podpisywania.

Art. 13(9)

Informacje i instrukcje dla użytkownika

Kontakt do producenta, kontakt do zgłaszania podatności i polityka CVD, identyfikacja produktu, przeznaczenie i właściwości bezpieczeństwa, przewidywalne ryzyka, adres deklaracji zgodności, data końca wsparcia, bezpieczna instalacja, sposób aktualizacji i wyłączenia automatycznych aktualizacji, bezpieczne wycofanie z użytku i informacje dla integratorów. Wersja online wystarczy, jeśli będzie dostępna przez dziesięć lat.

Annex II, Art. 13(18)

Oznaczenie i dane kontaktowe na produkcie

Typ, numer partii lub numer seryjny na produkcie oraz nazwa producenta, adres pocztowy i kontakt elektroniczny na produkcie, opakowaniu albo w dołączonym dokumencie.

Art. 13(15), 13(16)

Dokumentacja techniczna

Opis produktu (ze zdjęciami sprzętu), architektura, obsługa podatności z SBOM, polityką CVD i dystrybucją aktualizacji, produkcja i monitorowanie, ocena ryzyka, uzasadnienie okresu wsparcia, zastosowane normy, raporty z testów i deklaracja zgodności. Aktualizuj ją przez cały okres wsparcia.

Art. 31, Annex VII

Zaplanuj ocenę zgodności, prawdopodobnie z jednostką notyfikowaną

Klasa I może skorzystać z samooceny tylko wtedy, gdy w pełni stosuje normy zharmonizowane, wspólne specyfikacje albo europejski program certyfikacji na poziomie co najmniej „substantial”. W przeciwnym razie, a w klasie II zawsze, jest to badanie typu UE (B+C) albo pełne zapewnienie jakości (H). Produkty krytyczne mogą wymagać europejskiego certyfikatu. Jednostki notyfikowane mogły ruszyć od 11 czerwca 2026, a ich kalendarze zapełnią się przed grudniem 2027.

Art. 32(2)–(4), Art. 71Test zakresu →

Deklaracja zgodności UE

Jedna deklaracja dla wszystkich aktów UE, które mają zastosowanie, na przykład CRA razem z dyrektywą radiową. Dołącz kopię albo uproszczoną deklarację z dokładnym adresem pełnej wersji.

Art. 28, 13(20), Annex V, VI

Oznakowanie CE

Widoczne, czytelne i trwałe na produkcie, zanim zostanie wprowadzony do obrotu, albo na opakowaniu i deklaracji, jeśli na produkcie nie da się go umieścić. Dla oprogramowania na deklaracji albo na stronie produktu.

Art. 30

Produkcja seryjna pozostaje zgodna

Procedura, która wychwytuje zmiany w projekcie, produkcji albo normach, żeby dziesięciotysięczna sztuka była tak samo zgodna jak pierwsza.

Art. 13(14)

Przechowuj dokumentację przez dziesięć lat

Dokumentacja techniczna i deklaracja pozostają do dyspozycji organów przez dziesięć lat od wprowadzenia do obrotu albo przez okres wsparcia, jeśli jest dłuższy.

Art. 13(13)

Aktualizuj ocenę ryzyka i dokumentację

Zapisuj podatności, o których się dowiadujesz, i informacje od stron trzecich, a gdy zmieniają obraz sytuacji, aktualizuj ocenę ryzyka i dokumentację techniczną.

Art. 13(3), 13(7), 31(2)

Reaguj na niezgodność

Jeśli dowiesz się, że produkt albo twoje procesy nie spełniają wymagań załącznika I, natychmiast to napraw albo wycofaj produkt z rynku lub od użytkowników.

Art. 13(21)

Uważaj na istotne zmiany

Sztuki wprowadzone do obrotu przed 11 grudnia 2027 nie podlegają wymaganiom projektowym, ale istotna zmiana po tej dacie obejmuje je pełnym zakresem CRA. Sama poprawka bezpieczeństwa z reguły nią nie jest.

Art. 69(2)