Obowiązki zgłoszeniowe CRA: wyraźnie rozdziel paszport produktu, zgłoszenie bezpieczeństwa i historię aktualizacji

11 września 2026 r. rozpoczyna się dla producentów produktów z elementami cyfrowymi jeden z najwcześniejszych obowiązków operacyjnych wynikających z Cyber Resilience Act (CRA): aktywnie wykorzystywane podatności i poważne incydenty bezpieczeństwa muszą być zgłaszane za pośrednictwem nowej centralnej platformy zgłoszeniowej. To coś więcej niż nowy termin dotyczący zgodności. W ciągu kilku godzin trzeba połączyć tożsamość produktu, rynki, których dotyczy problem, ocenę techniczną i podjęte działania.

Cyfrowy paszport produktu lub strona produktu powiązana z kodem QR może pomóc jednoznacznie przypisać urządzenie i później poinformować użytkowników o aktualizacji. Nie jest jednak ani ustawowym kanałem zgłoszeniowym, ani właściwym miejscem do przechowywania poufnych szczegółów dotyczących wykorzystania podatności. Dlatego producenci powinni już teraz rozdzielić trzy ścieżki danych: zgłoszenie do organów, publiczną informację o produkcie oraz wewnętrzną historię aktualizacji.

Nowy impuls: wytyczne z 27 i 31 lipca

Komisja Europejska opublikowała 27 lipca 2026 r. swoje pierwsze kompleksowe wytyczne CRA. Obejmują one między innymi obowiązki zgłoszeniowe, ocenę ryzyka, okresy wsparcia i istotne zmiany. Wytyczne nie są wiążące, ale dzięki 67 przykładom doprecyzowują, jak przedsiębiorstwa mogą stosować rozporządzenie w praktyce.

Cztery dni później, 31 lipca, ENISA zaktualizowała swoje informacje dotyczące Single Reporting Platform. Zawierają one obecnie planowany przebieg procesu, przewidziane pola formularza i wskazówki dotyczące rejestracji. Platforma ma być gotowa do działania do 11 września 2026 r.; według Komisji testy funkcjonalne i bezpieczeństwa już trwają.

Harmonogram ma znaczenie: główne obowiązki CRA zasadniczo obowiązują od 11 grudnia 2027 r. Artykuł 14, dotyczący obowiązków zgłoszeniowych, zaczyna jednak obowiązywać już 11 września 2026 r. Potwierdza to zarówno artykuł 71 rozporządzenia (UE) 2024/2847, jak i zaktualizowany 31 lipca przegląd procedury zgłoszeniowej CRA Komisji.

Trzy przestrzenie danych zamiast przeciążonego paszportu produktu

Zgłoszenie CRA i publiczna strona produktu mają różne cele. Odwzorowanie obu elementów w jednym zbiorze danych grozi albo przekazaniem zespołowi ds. incydentów zbyt małej ilości informacji, albo udostępnieniem w publicznym internecie zbyt wielu poufnych szczegółów.

1. Poufne zgłoszenie do SRP, CSIRT i ENISA

Single Reporting Platform jest ustawowym kanałem przyjmowania zgłoszeń. Należy zgłaszać dwa typy zdarzeń: aktywnie wykorzystywaną podatność, w przypadku której istnieją wiarygodne przesłanki nieuprawnionego wykorzystania, oraz poważny incydent, który narusza dostępność, autentyczność, integralność lub poufność danych bądź funkcji.

Zgłoszenie zawiera nie tylko oznaczenie produktu. ENISA wymienia między innymi państwa członkowskie, których dotyczy problem, wstępną ocenę, już podjęte środki zaradcze, możliwe działania użytkowników oraz wrażliwość informacji. Późniejsze etapy mogą obejmować poziom dotkliwości, skutki, informacje o atakującym i szczegóły techniczne aktualizacji bezpieczeństwa. Takie informacje nie powinny automatycznie trafiać na publicznie dostępną stronę DPP.

2. Publiczna informacja o produkcie i bezpieczeństwie

Publiczna ścieżka danych odpowiada na inne pytania: Jaki mam produkt i wersję? Czy produkt jest nadal wspierany? Czy dostępna jest aktualizacja bezpieczeństwa? Co konkretnie powinienem zrobić jako użytkownik? W tym celu przydatna może być stabilna strona produktu dostępna za pośrednictwem kodu QR lub innego nośnika danych.

Publiczna strona powinna prezentować wyłącznie zatwierdzone informacje: zakresy modeli i wersji, dostępną bezpieczną wersję, wskazówki dotyczące instalacji, kontakt do wsparcia oraz datę publikacji. Szczegóły dotyczące wykorzystania podatności, wewnętrzne reguły wykrywania, niezałatane ścieżki ataku ani dane osobowe dotyczące incydentu pozostają w chronionej procedurze. Decyzja o publicznym ostrzeżeniu nie należy do kodu QR: zgodnie z artykułem 17 CRA koordynujący CSIRT może poinformować opinię publiczną lub wezwać do tego producenta, jeśli jest to konieczne do zapobiegania zagrożeniu albo jego ograniczenia.

3. Wewnętrzna historia aktualizacji i dowodów

Trzecia ścieżka to możliwa do prześledzenia dokumentacja robocza. Łączy ona identyfikator produktu, wersję sprzętu i oprogramowania, zestawienie elementów oprogramowania, moment uzyskania wiedzy, decyzje dotyczące triage, poziomy zgłoszeń, zatwierdzenie poprawki i komunikat publiczny. Historia ta musi wersjonować zmiany, zamiast po cichu nadpisywać wcześniejsze oceny.

Dla środowiska DPP ta różnica ma kluczowe znaczenie: widok publiczny pokazuje aktualny zatwierdzony stan, a wewnętrzna historia dokumentuje, jak do niego doszło. Kto już prowadzi dane produktów w sposób zdarzeniowy, może wykorzystać tę samą zasadę co w przypadku DPP-aktualizacji i webhooków: zdarzenie uruchamia procesy następcze, ale każdy odbiorca otrzymuje tylko pola przeznaczone dla jego roli.

Zegar CRA zaczyna biec od momentu uzyskania wiedzy

Artykuł 14 przewiduje stopniowane terminy. W przypadku aktywnie wykorzystywanej podatności bez zbędnej zwłoki, najpóźniej w ciągu 24 godzin od uzyskania wiedzy, konieczne jest wczesne ostrzeżenie. W ciągu 72 godzin należy złożyć bardziej szczegółowe zgłoszenie podatności. Raport końcowy musi być dostępny najpóźniej 14 dni po udostępnieniu środka naprawczego lub ograniczającego skutki.

W przypadku poważnego incydentu bezpieczeństwa również obowiązuje 24-godzinny termin na wczesne ostrzeżenie i 72-godzinny termin na zgłoszenie incydentu. Raport końcowy należy złożyć w ciągu miesiąca od zgłoszenia w terminie 72 godzin. Terminy nie biegną więc od publikacji CVE ani od kolejnego regularnego wydania, lecz od momentu, w którym uznaje się, że producent został poinformowany.

W praktyce zalecany jest jasny przebieg działania:

Rejestrować wpływ informacji z działu wsparcia, monitoringu, badań lub łańcucha dostaw wraz ze znacznikiem czasu.
Przypisać produkt i wersję do stabilnego wewnętrznego identyfikatora produktu.
Ocenić wykorzystanie podatności lub dotkliwość incydentu przez właściwy zespół.
Utworzyć 24-godzinny zbiór danych na podstawie potwierdzonych informacji minimalnych i przesłać go przez SRP.
Uzupełniać ustalenia techniczne do etapu 72 godzin, nie tracąc pierwotnego stanu.
Oddzielnie zatwierdzić poprawkę, działanie użytkownika i informację publiczną.
Powiązać raport końcowy z wewnętrzną historią.

Ten łańcuch należy przećwiczyć przed wrześniem. ENISA wskazuje, że organizacje mogą automatyzować swoje wewnętrzne procesy i bazy danych, ale w momencie uruchomienia platforma nie będzie oferować interfejsu API. Dlatego proces eksportu i kontroli przez dwie osoby jest bardziej realistyczny niż niesprawdzona bezpośrednia integracja.

Jeden wspólny identyfikator produktu, ale rozdzielone prawa dostępu

Rozdzielenie nie oznacza prowadzenia trzech niepowiązanych kopii. Lepszym podejściem jest wspólne, niezmienne odniesienie do produktu z widokami zależnymi od roli.

Należy dysponować co najmniej następującymi przypisaniami:

wewnętrzny identyfikator produktu oraz odniesienie do modelu, partii lub numeru seryjnego;
wersja sprzętu, oprogramowania układowego i oprogramowania;
państwa członkowskie, w których udostępniono wersję, której dotyczy problem;
status oceny bezpieczeństwa i moment uzyskania wiedzy;
odniesienia do zgłoszeń w terminie 24 i 72 godzin oraz raportu końcowego;
zatwierdzone działanie użytkownika i bezpieczna wersja docelowa;
status publikacji publicznej strony produktu.

Autoryzację należy rozumieć na poziomie poszczególnych pól. Zespół ds. incydentów i osoby odpowiedzialne za CRA potrzebują pełnej dokumentacji. Wsparcie i sprzedaż potrzebują zatwierdzonej instrukcji działania. Użytkownicy widzą tylko komunikat publiczny. Kod QR powinien w idealnym przypadku przenosić jedynie do stabilnego adresu produktu; platforma znajdująca się za nim decyduje na podstawie statusu i roli, jakie informacje zostaną przekazane.

Co producenci powinni przetestować do września

Dobry przypadek testowy nie wymaga prawdziwej podatności. Wybierz produkt połączony z siecią, wersję oprogramowania układowego, której dotyczy problem, oraz trzy państwa członkowskie. Zasymuluj uzyskanie wiedzy w dzień roboczy i sprawdź:

Czy zespół może w ciągu 24 godzin potwierdzić zakres produktów, których dotyczy problem, oraz informacje minimalne?
Czy jest jasne, kto jako przedstawiciel powinien uzyskać dostęp do SRP za pośrednictwem EU Login?
Czy można uzupełnić informacje wymagane w ciągu 72 godzin, nie ujawniając publicznie poufnych szczegółów?
Czy zatwierdzenie poprawki prowadzi do sprawdzonej informacji dla użytkowników we wszystkich wymaganych językach?
Czy publiczny adres URL pozostaje stabilny, gdy zmieniają się wersja i działania?
Czy można prześledzić, kto, kiedy i jaki stan zatwierdził?

W ostatnim punkcie pomaga konsekwentne, wersjonowane zarządzanie danymi. Artykuł qr3 o ciągłej DPP-aktualizacji pokazuje podstawową zasadę: tożsamość pozostaje stabilna, a dane merytoryczne są kontrolowanie aktualizowane. W procesie CRA dochodzi do tego bardziej rygorystyczna warstwa poufności i zatwierdzania.

Wniosek: paszport produktu jest dystrybutorem, nie punktem zgłoszeniowym

Nowe wytyczne sprawiają, że wrześniowy termin staje się konkretnym zadaniem operacyjnym. Producenci nie muszą umieszczać poufnej bazy danych podatności w swoim Cyfrowym paszporcie produktu. Potrzebują natomiast niezawodnego przejścia między trzema wyraźnie rozdzielonymi obszarami: zgłoszeniem do organów, wewnętrznymi dowodami i zatwierdzoną informacją dla użytkowników.

Wspólny identyfikator produktu spina te obszary. Role, zatwierdzenia i wersjonowanie zapobiegają wydostaniu się poufnych szczegółów na zewnątrz oraz zbyt późnemu poinformowaniu użytkowników o dostępnych działaniach. Kod QR pozostaje przydatny, ale celowo niepozorny: trwale prowadzi do właściwego kontekstu produktu. Właściwa zgodność z CRA powstaje w procesach znajdujących się za nim.