Portal CRA SRP, logowanie i rola CRA Workspace
Oficjalny portal ENISA: portal.cra-srp.enisa.europa.eu służy do logowania i wysłania zgłoszenia. Dla Primary AR wejście prowadzi przez wybór roli Assigned Representative, właściwego CSIRT i EU Login z MFA. Secondary AR korzysta z zaproszenia Primary AR. Nie wpisuj danych dostępowych EU Login w formularzach CRACompliance.pl.
Niezależna instrukcja: ten przewodnik wyjaśnia obsługę SRP. To, co i kiedy producent musi zgłosić, opisuje osobna strona CRA Reporting — obowiązki i terminy Article 14.
Przygotowanie w Workspace: CRA Workspace porządkuje dane produktu, terminy, role i dowody ręcznej wysyłki. Nie zastępuje konta SRP, nie loguje do ENISA i nie wysyła zgłoszenia. Sam formularz lub checker nie potwierdza wykonania obowiązku.
ENISA zaleca rozpoczęcie rejestracji w SRP przy konkretnym zgłoszeniu, nie prewencyjnie. Wcześniej można przygotować osobisty EU Login z MFA, właściwy CSIRT i zastępstwo.
CRA Single Reporting Platform: pełna sekwencja
SRP nie jest osobnym procesem compliance. To kanał wykonania decyzji podjętej przez triage. Zegar raportowy biegnie od uzyskania wiedzy przez producenta, dlatego dostęp, routing, dane i approvals muszą zadziałać równolegle.
- 01EU Login
Primary AR powinien mieć aktywne konto EU Login. ENISA nie zaleca jednak zakładania konta SRP prewencyjnie.
- 02Wybór CSIRT
Wskaż CSIRT Designated as Coordinator właściwy według art. 14 ust. 7 — zwykle według głównego miejsca prowadzenia działalności.
- 03Primary AR
Wybierz rolę Assigned Representative, uwierzytelnij się, zaakceptuj warunki i potwierdź dane osobowe.
- 04Manufacturer association
Wprowadź dane producenta. Konto Primary AR staje się aktywne, a powiązanie może nadal oczekiwać na walidację CSIRT.
- 05Secondary AR
Po weryfikacji powiązania producenta Primary AR może zaprosić maksymalnie 20 Secondary AR. Wysłane zgłoszenia są wspólne dla wszystkich AR producenta, natomiast draft widzi tylko jego autor.
- 06Early warning
Utwórz notification, wybierz producenta — także pending validation — uzupełnij dane i wyślij lub zapisz draft.
- 0772h notification
Otwórz istniejącą notyfikację po wysłaniu early warning, uzupełnij zakładkę 72-hour Notification i wyślij.
- 08Final report
Po early warning i 72h uzupełnij Final Report. Po jego wysłaniu notyfikacja nie może być dalej edytowana.
Prawo określa obowiązek, ENISA opisuje obsługę platformy
Stosowanie art. 14 od 11 września 2026 r. oraz terminy zgłoszeń wynikają z rozporządzenia CRA. Zasady kont, ról, widoczności zgłoszeń i walidacji relacji z producentem są oficjalnym guidance operacyjnym ENISA, a nie odrębnym źródłem prawa.
Brak dodatkowego mechanizmu uwierzytelniania firmy nie znosi potrzeby walidacji powiązania przez właściwy CSIRT.Primary AR i Secondary AR
- Dla producenta może istnieć jeden Primary AR oraz maksymalnie 20 Secondary AR.
- Primary AR może zgłaszać podczas statusu Pending — do 20 zgłoszeń przed obowiązkową weryfikacją relacji.
- Po wysłaniu notification wszyscy Primary i Secondary AR tego producenta mogą je widzieć, aktualizować i kontynuować kolejny etap.
- Draft pozostaje prywatny dla AR, który go utworzył.
- Secondary AR może przejąć rolę Primary po akceptacji właściwego CDaC.
- Secondary AR można przypisać po zweryfikowaniu powiązania producenta.
- Obecnie dostęp opiera się na osobistym EU Login z MFA, a powiązanie z producentem waliduje właściwy CSIRT.
Korekta danych nie nadpisuje błędnego wpisu
Przy błędnej nazwie producenta utwórz poprawny wpis ponownie. Jeżeli błędny wpis ma status Verified, poproś CDaC o jego odrzucenie. Zweryfikowane powiązanie AR można usunąć zgodnie z uprawnieniami roli; dla relacji Pending można poczekać na weryfikację albo poprosić CDaC o odrzucenie.
Primary może usunąć własne powiązanie lub Secondary AR; Secondary może usunąć tylko własne powiązanie.CRA SRP Readiness Checker
Oceń dostęp, role, routing, dane, approvals i evidence. Checker działa lokalnie w przeglądarce, nie wymaga konta i nie wysyła odpowiedzi do ENISA ani CSIRT.
Dostęp i role
Primary AR ma osobiste konto EU Login, 2FA i potrafi się uwierzytelnić.
Nie używaj functional mailbox. EU Login i 2FA można przygotować wcześniej; nie oznacza to prewencyjnej rejestracji w SRP.Wyznaczyliśmy Primary Assigned Representative.
Ta osoba rejestruje się, wiąże konto z producentem i może zaprosić Secondary AR.Mamy zastępstwo i kandydata na Secondary AR.
Po wysłaniu case jest wspólny dla Primary i Secondary AR, a kolejny etap może przejąć inna osoba. Draft pozostaje prywatny dla autora.Playbook odróżnia przygotowanie od rejestracji w SRP.
Zgodnie z ENISA rejestrację rozpocznij przy konkretnym zgłoszeniu. Playbook powinien też obejmować ponowne utworzenie błędnego wpisu producenta i kontakt z CDaC, gdy potrzebne jest odrzucenie powiązania.Routing i producent
Potrafimy wskazać właściwy CSIRT Designated as Coordinator.
Sprawdź resolver CDaC poniżej: decyzje o cyberbezpieczeństwie produktów, następnie zakład z największą liczbą pracowników w UE. Przy braku zakładu w UE zastosuj kolejno upoważnionego przedstawiciela CRA, importera, dystrybutora i użytkowników. Brak danych nie uprawnia do pomijania wcześniejszych kryteriów.Dane producenta są gotowe do wprowadzenia w SRP.
Nazwa, adres i wymagane informacje dodatkowe powinny być pod ręką podczas rejestracji.Potrafimy jednoznacznie zidentyfikować produkt i dotknięte wersje.
Nazwa handlowa, model, wersja, identyfikatory i granice produktu muszą być spójne z triage.Mamy listę państw członkowskich, w których produkt jest dostępny.
Ta informacja wpływa na dalsze rozpowszechnienie zgłoszenia do concerned CSIRTs.Notification workflow
Działa triage dla AEV i severe incident.
Zespół rozróżnia aktywnie wykorzystywaną podatność od poważnego incydentu i rejestruje moment uzyskania wiedzy.Minimalny pakiet danych do early warning jest dostępny w 24h.
Proces pozwala złożyć pierwsze zgłoszenie mimo niepełnego obrazu technicznego.Mamy właściciela i dane potrzebne do notification 72h.
Aktualizacja odbywa się w istniejącej notyfikacji po wysłaniu early warning.Ścieżka akceptacji działa w terminach godzinowych.
Zdefiniuj, kto zatwierdza wysłanie i co dzieje się przy braku dostępności decydenta.Dowody i domknięcie
Chronimy dowody, decyzje i momenty wysłania kolejnych etapów.
Zachowaj źródła faktów, wersje danych, approvals, identyfikator notification i potwierdzenia SRP.Wyznaczyliśmy właściciela final report.
Final report kończy możliwość edycji notyfikacji, dlatego wymaga kontroli kompletności.Zespół rozumie prywatność draftów i współdzielenie wysłanych case'ów.
Draft widzi tylko autor. Po pierwszym submission Primary i Secondary AR widzą oraz aktualizują case; audit trail powinien wskazać autora każdego etapu i handover.CDaC / Reporting Jurisdiction Resolver — właściwy CSIRT
Najpierw ustal państwo, w którym przeważnie podejmowane są decyzje o cyberbezpieczeństwie produktów. Jeśli nie można go określić, użyj zakładu z największą liczbą pracowników w UE. Dopiero brak głównego zakładu w UE uruchamia kolejność: upoważniony przedstawiciel → importer → dystrybutor → użytkownicy. Nie myl CDaC odbierającego zgłoszenie z concerned CSIRTs państw udostępnienia produktu.
Producent odpowiada za prawidłowy wybór. Rationale, dowody i potwierdzenie człowieka trzeba przygotować przed transferem pakietu. Awareness i terminy 24h/72h nie zaczynają się od nowa przy korekcie routingu.
Ustal, czy producent ma zakład w UE. Brak wiedzy nie oznacza braku zakładu.
Odpowiedzi pozostają tylko w tej karcie przeglądarki; nie są zapisywane ani wysyłane. W Workspace potwierdzenie wraz z uzasadnieniem i dowodami jest wymagane przed udostępnieniem pakietu do ręcznego transferu. Zegar 24h/72h nie jest przez to zatrzymywany.
Reguły wyboru: art. 14 ust. 7 CRA. Obsługa SRP i ryzyko unieważnienia: FAQ ENISA z 3.10.2026, pkt 18 i 33.
Art. 14 ust. 7 dopuszcza dla kolejnych zdarzeń ponowne użycie pierwszego CSIRT, jeżeli wcześniejszy wybór oparto na liczbie użytkowników. Ten uproszczony resolver nie rozstrzyga automatycznie tej opcji — odnotuj wcześniejsze zgłoszenie i skonsultuj routing. Remisy i brak danych wymagają przeglądu, nie arbitralnego wyboru.
Po statusie Rejected powiązania AR–manufacturer kontaktuj się z właściwym CDaC przez oficjalną listę ENISA (FAQ 33). Workspace przechowuje ten stan i informację o potrzebie działań naprawczych; nie zmienia statusu w SRP.
Potwierdź routing i dowody w CRA Workspace →Jakie dane obejmuje formularz zgłoszenia do ENISA?
Workspace odwzorowuje aktualny słownik SRP v1.1 i rozdziela pola wspólne od dwóch rodzajów zdarzeń. Każde pole zachowuje oznaczenie ENISA dla danego etapu: wymagane, opcjonalne, warunkowe, automatyczne, odziedziczone albo niemające zastosowania.
| Zakres | Pola | Przykładowe dane |
|---|---|---|
| Wspólne | 1–18 | typ notification, producent, concerned CSIRT, produkt, wersja, opis, środki i państwa udostępnienia |
| Actively Exploited Vulnerability | v19–v29 | CVE/EUVD, informacje ogólne, data środka, severity, impact, awareness, malicious actor i PEC |
| Severe Incident | i30–i38 | podejrzenie malicious acts, charakter incydentu, mitigation, severity, impact, root cause, awareness, occurrence i initial assessment |
Formularz przygotowuje submission, ale go nie wysyła
Pola pochodzące z Product, Release i Article 14 Review są oznaczone jako dane Workspace. Pozostałe uzupełnia człowiek. Walidacja kontroluje kompletność techniczną etapu, nie autentyczność danych ani spełnienie przesłanek prawnych.
Gotowy pakiet trzeba nadal przenieść do oficjalnego interfejsu SRP i wysłać ręcznie.Early warning → 72h → final report
| Etap | Warunek | Działanie w SRP | Stan po wysłaniu |
|---|---|---|---|
| Early warning | Aktywny AR, dashboard i trigger reportingowy | Nowa notification, producent approved lub pending validation, wymagane pola, submit | Early Warning |
| 72-hour Notification | Wysłane early warning | Otwórz istniejącą notification, uzupełnij zakładkę 72h, submit | 72h Submitted albo 72h Submitted under PEC dla właściwego przypadku AEV |
| Final Report | Wysłane early warning i notification 72h | Uzupełnij Final Report i sprawdź kompletność przed submit | FR Submitted / Final Report |
Każdy etap można wcześniej zapisać jako draft. Brak wymaganych danych wywołuje błąd i blokuje wysłanie, ale nie powinien skłaniać do odkładania wewnętrznej eskalacji.
Draft → EW Ready → EW Submitted → 72h Due → 72h Submitted → Final Report Due → FR Submitted → Locked
Workspace prowadzi case w tej kolejności i zapisuje osobno SRP Notification ID, osobę wysyłającą, faktyczny timestamp oraz submission evidence. Handover Timeline wskazuje autora Early Warning, osobę przejmującą 72h i autora Final Report. Wysłanie Final Report natychmiast zamraża historyczny rekord regulacyjny.
Dalsze remediation, patching i rollout mogą być prowadzone dalej, ale nie nadpisują zamrożonego Final Report.Licz własne 24h i 72h od awareness timestamp
ENISA podkreśla pomocniczy charakter liczników. W obecnej wersji licznik etapu 72h pokazuje 48 godzin od wysłania Early Warning, podczas gdy prawny limit 72h liczy się od momentu uzyskania wiedzy. Jeżeli Early Warning wysłano wcześniej lub później niż dokładnie po 24 godzinach, wartości mogą się rozjechać.
Wewnętrzny workflow powinien alarmować według terminu prawnego i osobno rejestrować wartość widoczną w SRP.Wewnętrzna automatyzacja tak, API SRP nie
ENISA publikuje matrycę pól oznaczonych X, O, C, A, I i N dla 24h, 72h oraz Final Report. Organizacja może przygotować dane w swoim systemie, ale finalny transfer i submission odbywa się ręcznie w interfejsie SRP.
Workspace nie wysyła danych do ENISA ani CSIRT i nie udaje integracji API.Opóźnienie rozpowszechniania nie jest pominięciem etapu 72h
Dla zgłoszenia aktywnie wykorzystywanej podatności AR może zaznaczyć w etapie 72h jedną lub więcej przyczyn Particularly Exceptional Circumstances dostępnych w SRP. Platforma przekazuje żądanie do właściwego CSIRT; samo zaznaczenie opcji nie rozstrzyga jego zasadności.
Workspace zapisuje wybrane przesłanki, uzasadnienie, timestamp i dowód statusu „72h Submitted under PEC”.Submission i dissemination to dwa odrębne zdarzenia
Early Warning jest dostępny dla właściwego CSIRT Designated as Coordinator i ENISA. Pozostałe zainteresowane CSIRT-y otrzymują go dopiero po manual dissemination przez CDaC. Dla 72h i Final Report pełne dane trafiają automatycznie do ENISA tylko wtedy, gdy nie uruchomiono PEC; przy PEC CDaC kontroluje dalsze udostępnienie.
Aktualizacja przed Final Report powiadamia CDaC, ENISA i CSIRT-y, do których notification zostało już rozpowszechnione.Kontakt z CSIRT nie zastępuje późniejszej wysyłki przez SRP
Jeżeli platforma jest niedostępna, zapisz czas awarii oraz dowód statusu. Przy pilnej komunikacji można udokumentować kontakt z właściwym CSIRT, ale po przywróceniu usługi notification nadal trzeba złożyć w SRP.
Control pozostaje otwarty i generuje alert „resubmission required”, dopóki nie zapiszesz referencji oraz dowodu wysyłki.Statusy, dostęp i handover
- Draft jest prywatny dla AR, który go utworzył.
- Submitted case jest widoczny i edytowalny dla wszystkich Primary i Secondary AR przypisanych do producenta.
- AR handover pozwala innej osobie wykonać 72h Notification lub Final Report; Workspace zachowuje role, osoby i timestampy każdego etapu.
- Early Warning potwierdza pierwsze wysłanie do właściwego CSIRT i ENISA zgodnie z regułami platformy.
- 72h Submitted oznacza wysłanie drugiego etapu; przypadki szczególnie wyjątkowe mogą mieć odrębny substatus.
- FR Submitted zamyka edycję notification. Aktualizacje są możliwe tylko przed wysłaniem final report i przed zamknięciem sprawy.
- Action Required oraz alerty na dashboardzie wymagają przypisanego właściciela i monitoringu.
SRP reference · timestamp awareness · własne terminy 24h/72h · autor i rola każdej fazy · handover timeline · CSIRT · manufacturer association · submission timestamp każdej fazy · screenshot lub PDF potwierdzenia · final report
CRA SRP FAQ
Co zrobić, jeśli wybrano niewłaściwy CDaC w SRP?
Producent odpowiada za ustalenie właściwego CDaC według art. 14 ust. 7 CRA. FAQ ENISA z 3 października 2026 ostrzega, że błędnie skierowane zgłoszenie może zostać unieważnione i wymagać ponownego złożenia do właściwego CDaC. Zmiana routingu nie resetuje momentu awareness ani terminów prawnych.
Kto wyjaśnia odrzucenie powiązania AR z producentem?
Powiązanie weryfikuje właściwy CSIRT Designated as Coordinator, nie ENISA. Zgodnie z FAQ 33 skontaktuj się z tym CDaC przez oficjalną listę kontaktów ENISA. Zapis statusu Rejected lub działań naprawczych w Workspace nie jest ponowną walidacją w SRP.
Jak zalogować się do portalu CRA SRP ENISA?
Otwórz portal.cra-srp.enisa.europa.eu, wybierz Assigned Representative i właściwy CSIRT Designated as Coordinator, a następnie uwierzytelnij się przez osobisty EU Login z MFA. Secondary AR rozpoczyna rejestrację z zaproszenia Primary AR. CRACompliance.pl nie prowadzi logowania do SRP i nie zbiera danych dostępowych ENISA.
Co oznacza SRP w CRA?
SRP to Single Reporting Platform ENISA — oficjalny kanał składania zgłoszeń z art. 14 CRA dotyczących aktywnie wykorzystywanych podatności i poważnych incydentów wpływających na bezpieczeństwo produktu.
Czy trzeba założyć konto CRA SRP wcześniej?
ENISA zaleca rozpocząć rejestrację i walidację AR dopiero wtedy, gdy trzeba złożyć konkretne zgłoszenie. Wcześniej warto przygotować EU Login, role, dane producenta, routing CSIRT i wewnętrzny playbook.
Czy brak walidacji AR blokuje zgłoszenie?
Nie od razu. Według FAQ ENISA zaktualizowanego 3 października 2026 r. Primary AR może wysłać do 20 zgłoszeń podczas weryfikacji powiązania z producentem. Przed kolejnym zgłoszeniem walidacja przez właściwy CSIRT staje się obowiązkowa. Odrzucone powiązanie to inny stan niż Pending i wymaga wyjaśnienia z właściwym CDaC.
Czy CRA SRP udostępnia API?
Nie na starcie. ENISA wskazuje, że organizacja może automatyzować workflow wewnętrzny, ale obecnie nie udostępnia API SRP. Finalne dane trzeba przenieść i wysłać w interfejsie platformy.
Co zrobić, gdy SRP jest niedostępny?
Poczekać na przywrócenie platformy i wysłać notification przez SRP. Jeśli potrzebna jest natychmiastowa komunikacja, można skontaktować się z właściwym CSIRT, ale nie zastępuje to późniejszego submission w SRP.
Czy Primary i Secondary AR mają taki sam dostęp?
Po wysłaniu zgłoszenia Primary i Secondary AR przypisani do tego samego producenta mogą je widzieć i aktualizować niezależnie od autora. Inny AR może kontynuować etap 72h albo Final Report. Wyjątkiem są drafty — pozostają prywatne dla osoby, która je utworzyła.
Czy Secondary AR może przejąć rolę Primary AR?
Tak, Secondary AR może zainicjować przejęcie roli Primary, ale zmiana wymaga przeglądu i akceptacji właściwego CSIRT Designated as Coordinator.
Jak poprawić błędnego producenta albo usunąć powiązanie AR?
Przy błędnej nazwie producenta utwórz poprawny wpis ponownie. Jeśli błędny wpis został już zweryfikowany, poproś właściwy CDaC o jego odrzucenie. Zweryfikowane powiązanie można usunąć zgodnie z rolą: Primary własne lub Secondary, a Secondary wyłącznie własne. Dla powiązania oczekującego można poczekać na weryfikację i je usunąć albo poprosić CDaC o odrzucenie.
Czy można pominąć early warning i zacząć od zgłoszenia 72h?
Instrukcja ENISA wskazuje wcześniejsze wysłanie early warning jako warunek zgłoszenia 72h. Final report wymaga wcześniejszego early warning i notification 72h.
Kto otrzymuje aktualizację istniejącego zgłoszenia?
Według guidance ENISA aktualizacja przed Final Report automatycznie powiadamia właściwy CDaC, ENISA oraz te zainteresowane CSIRT-y, które otrzymały już notification przez dissemination. Po wysłaniu Final Report notification staje się nieedytowalna.
Gdzie jest oficjalna platforma CRA SRP?
ENISA udostępnia platformę pod adresem portal.cra-srp.enisa.europa.eu oraz osobną stronę bieżącego statusu usługi. Zgłoszenia należy składać wyłącznie w oficjalnym SRP.
Oficjalne instrukcje ENISA i podstawa prawna
Workflow sprawdzono 5 października 2026. ENISA zastrzega, że instrukcje mogą się zmieniać, dlatego przed realnym zgłoszeniem otwórz ich najnowszą wersję.