Najtrudniejsze pytanie przed 11 września 2026 roku nie brzmi: „czy mamy bezpieczny kod?”. Brzmi: „czy to, co sprzedajemy, jest produktem z elementami cyfrowymi — i kto odbierze telefon, gdy pojawi się aktywnie wykorzystywana podatność?”.
Cyber Resilience Act, czyli rozporządzenie (UE) 2024/2847, łatwo zaszufladkować jako prawo dla producentów oprogramowania. To wygodna, lecz ryzykowna interpretacja. CRA obejmuje bowiem sprzęt i oprogramowanie udostępniane na rynku Unii Europejskiej, jeżeli ich przeznaczenie albo racjonalnie przewidywalne użycie zakłada bezpośrednie lub pośrednie połączenie z urządzeniem lub siecią. W zakres mogą wejść także komponenty sprzedawane osobno oraz rozwiązania zdalnego przetwarzania danych, bez których produkt nie wykona jednej ze swoich funkcji.
Dlatego producent sterownika, inteligentnego zamka, terminala, maszyny połączonej z siecią, aplikacji desktopowej, wtyczki czy urządzenia z panelem chmurowym powinien sprawdzić CRA równie uważnie jak software house. Sama etykieta „nie jesteśmy firmą technologiczną” nie zmienia funkcji produktu ani roli przedsiębiorstwa w łańcuchu dostaw.
CRA nie zaczyna się od formularza do ENISA
Zgłoszenie w 24 lub 72 godziny będzie tylko ostatnim odcinkiem procesu. Wcześniej firma musi wiedzieć, które produkty są w zakresie, jakie komponenty zawierają, kto utrzymuje kontakt z dostawcami oraz kto może podjąć decyzję o aktualizacji i komunikacji z użytkownikami.
Najpierw rozdziel trzy daty
- 10 grudnia 2024: CRA wszedł w życie.
- 11 września 2026: zaczynają obowiązywać wymogi raportowania z art. 14.
- 11 grudnia 2027: zasadniczo zaczyna się pełne stosowanie pozostałych obowiązków.
- Dzisiaj: trzeba ustalić zakres, role, produkty, zależności i właściciela obsługi podatności.
11 września nie jest terminem „zgodności ze wszystkim”
Od 11 września 2026 roku producenci produktów z elementami cyfrowymi mają zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktu. Wczesne ostrzeżenie należy przekazać w ciągu 24 godzin od uzyskania wiedzy o zdarzeniu, natomiast pełne zgłoszenie — w ciągu 72 godzin. Raport końcowy dotyczący aktywnie wykorzystywanej podatności składa się nie później niż 14 dni po udostępnieniu środka naprawczego lub ograniczającego ryzyko; przy poważnym incydencie termin wynosi miesiąc od pełnego zgłoszenia.
Zgłoszenie ma przechodzić przez jednolitą platformę raportowania CRA, czyli Single Reporting Platform rozwijaną przez ENISA. Komisja Europejska podkreśla przy tym, że wymogi raportowania obejmują produkty z elementami cyfrowymi udostępnione na rynku Unii, również te wprowadzone przed 11 grudnia 2027 roku. To ważne: firma nie powinna ograniczać przeglądu wyłącznie do nowych modeli lub kolejnej wersji aplikacji.
Raportowanie nie zostawia czasu na szukanie właściciela procesu
Skala pokazuje dwa pierwsze terminy z art. 14 CRA. Raport końcowy ma osobny termin: do 14 dni po dostępności środka naprawczego lub ograniczającego ryzyko dla aktywnie wykorzystywanej podatności, a przy poważnym incydencie — w ciągu miesiąca od pełnego zgłoszenia.
Nie każda luka bezpieczeństwa automatycznie uruchomi raportowanie. Przepis dotyczy podatności aktywnie wykorzystywanej oraz poważnego incydentu mającego wpływ na bezpieczeństwo produktu. Mimo to kwalifikacja zdarzenia wymaga danych technicznych, wiedzy o produkcie i sprawnej decyzji. Jeżeli pierwszy dzień firma przeznaczy na ustalanie, kto utrzymuje bibliotekę, gdzie są logi i czy dany model nadal jest wspierany, termin 24 godzin minie szybciej, niż powstanie wiarygodne zgłoszenie.
Czy to w ogóle jest produkt z elementami cyfrowymi?
W praktyce warto odejść od pytania „czy sprzedajemy software?” i przejść przez cztery warunki. Jeżeli odpowiedzi układają się w jeden ciąg, produkt powinien trafić do rejestru CRA do dalszej kwalifikacji.
-
Czy istnieje sprzęt lub oprogramowanie?
Produktem może być gotowe urządzenie, program, aplikacja, biblioteka albo komponent sprzętowy czy programowy udostępniany osobno. Cyfrowy element nie musi być tym, co dominuje w opisie handlowym.
-
Czy przewidziano połączenie z urządzeniem lub siecią?
Połączenie może być fizyczne albo logiczne, bezpośrednie bądź pośrednie. Wi-Fi nie jest jedynym sygnałem. Znaczenie może mieć Ethernet, Bluetooth, USB, interfejs API, bramka, aplikacja mobilna, aktualizator czy komunikacja z panelem w chmurze.
-
Czy produkt jest udostępniany na rynku UE komercyjnie?
„Komercyjnie” nie oznacza wyłącznie sprzedaży pudełka. Liczyć może dostarczenie produktu za opłatą, monetyzacja powiązanych usług, płatne wsparcie wykraczające poza zwrot kosztów albo inny model gospodarczy opisany w CRA.
-
Czy nie działa szczególne wyłączenie?
Rozporządzenie przewiduje wyłączenia i relacje z prawem sektorowym, między innymi dla określonych wyrobów medycznych, pojazdów, lotnictwa i wyposażenia morskiego. Kwalifikacji nie warto rozstrzygać wyłącznie na podstawie nazwy branży.
Właściciel firmy: „My sprzedajemy automat bramowy, nie oprogramowanie”.
Specjalistka: „A klient steruje nim z aplikacji i dostaje aktualizacje przez internet?”.
Właściciel firmy: „Tak, lecz moduł i aplikację dostarcza partner”.
Specjalistka: „W takim razie partner jest ważny, ale odpowiedzialność za produkt pod Twoją marką nie znika. Zacznijmy od ról i komponentów”.
Pięć przykładów, które powinny zapalić lampkę
| Oferta firmy | Cyfrowy element | Pytanie rozstrzygające |
|---|---|---|
| Maszyna produkcyjna | Sterownik, panel serwisowy, zdalna diagnostyka | Kto wprowadza całość na rynek pod swoją nazwą i utrzymuje oprogramowanie? |
| Inteligentny zamek lub czujnik | Firmware, aplikacja, łączność z chmurą | Czy bez usługi zdalnej produkt traci jedną z zaprojektowanych funkcji? |
| Program instalowany u klienta | Kod aplikacji, aktualizator, biblioteki | Czy produkt jest udostępniany komercyjnie na rynku UE? |
| Moduł elektroniczny | Mikrokontroler, firmware, interfejs komunikacyjny | Czy komponent jest udostępniany osobno, czy wyłącznie integrowany we własnym produkcie? |
| Usługa internetowa | Panel SaaS lub zdalne przetwarzanie | Czy jest to samodzielna usługa, czy rozwiązanie niezbędne do funkcji konkretnego produktu? |
Samodzielny SaaS co do zasady nie staje się produktem objętym CRA tylko dlatego, że działa przez internet; usługi chmurowe podlegają również innym regulacjom. Inaczej może wyglądać rozwiązanie zdalnego przetwarzania danych zaprojektowane i rozwijane przez producenta albo na jego rzecz, którego brak uniemożliwiłby wykonanie jednej z funkcji produktu. To obszar wymagający analizy konkretnej architektury, umów i odpowiedzialności.
Open source nie znaczy automatycznie „poza CRA”
Darmowy i otwarty kod udostępniany poza działalnością komercyjną jest traktowany inaczej niż produkt monetyzowany przez producenta. Jednak wykorzystanie biblioteki open source we własnym komercyjnym produkcie nie usuwa obowiązku obsługi podatności komponentu. CRA wprowadza też osobną rolę opiekuna oprogramowania open source. Dlatego liczy się model udostępniania i rola podmiotu, nie sama licencja.
Najpierw rola firmy, dopiero potem lista obowiązków
W rozmowach o CRA często miesza się producenta faktycznego, markę na obudowie, importera i dystrybutora. Tymczasem rozporządzenie przypisuje im różne zadania. Producentem jest podmiot, który opracowuje lub wytwarza produkt albo zleca jego zaprojektowanie, opracowanie lub wytworzenie, a następnie wprowadza go na rynek pod własną nazwą lub znakiem towarowym.
Firma może więc nie napisać ani jednej linii kodu, a mimo to znaleźć się w roli producenta. Co więcej, importer lub dystrybutor może przejąć obowiązki producenta, jeżeli udostępnia produkt pod własną nazwą albo znakiem towarowym bądź dokonuje istotnej modyfikacji produktu już obecnego na rynku.
„Dostawca odpowiada za moduł”
- brak jednego rejestru wersji i zależności;
- umowa bez czasu reakcji na podatność;
- aktualizacja zależna od dobrej woli partnera;
- nikt nie ocenia wpływu luki na cały produkt;
- klient nie wie, gdzie zgłosić problem.
„Znamy zależność i właściciela”
- komponent ma nazwę, wersję i dostawcę;
- ustalono kanał alarmowy oraz terminy;
- wiadomo, kto testuje i wydaje poprawkę;
- wpływ ocenia się w kontekście produktu;
- proces obejmuje informację dla użytkownika.
Mapa produktu powinna pokazać więcej niż katalog części
Lista komponentów to początek, nie wynik. Firma potrzebuje powiązania produktu, wersji, konfiguracji, dostawcy, kanału aktualizacji, okresu wsparcia i osoby decyzyjnej. Dopiero taki obraz pozwala odpowiedzieć, czy publicznie ujawniona podatność biblioteki rzeczywiście dotyczy sprzedanego modelu i jak szybko można ograniczyć ryzyko.
CRA wymaga od producentów identyfikowania i dokumentowania podatności oraz komponentów produktu, między innymi przez zestawienie materiałów oprogramowania w powszechnie używanym, maszynowo czytelnym formacie, obejmujące co najmniej zależności najwyższego poziomu. W praktyce SBOM powinien działać jak indeks dochodzeniowy: nie zastępuje analizy, ale skraca drogę od informacji o luce do ustalenia, które produkty i wersje są narażone.
Produkt
Model, wersja, przeznaczenie, sposób połączenia, rynek, klienci i okres wsparcia.
Komponent
Nazwa, wersja, funkcja, pochodzenie, licencja, znane podatności oraz dostępna poprawka.
Odpowiedzialność
Właściciel biznesowy, opiekun techniczny, dostawca, osoba kwalifikująca zdarzenie i osoba zgłaszająca.
Trend na 2026 rok jest wyraźny: firmy przechodzą od jednorazowego generowania SBOM do ciągłego zarządzania zależnościami. Coraz większe znaczenie mają również informacje o tym, czy konkretna podatność jest możliwa do wykorzystania w danej konfiguracji produktu. Format VEX może wspierać taką komunikację, ale nie jest magicznym dokumentem zgodności z CRA. Wartość powstaje dopiero wtedy, gdy deklarację można obronić analizą techniczną i dowodami.
Kto ma być właścicielem procesu obsługi podatności?
Proces może być wspierany przez dział IT, zewnętrzny SOC, software house, serwis urządzeń i kancelarię. Nie powinien jednak należeć „do wszystkich”, ponieważ wtedy w praktyce nie należy do nikogo. Potrzebny jest właściciel zdolny połączyć trzy perspektywy: techniczną, produktową i prawną.
W większej organizacji funkcję tę często porządkuje PSIRT, czyli zespół reagowania na incydenty bezpieczeństwa produktu. W MŚP nie musi powstać nowy dział. Wystarczy nazwana osoba odpowiedzialna za proces, zastępca oraz uzgodniona grupa specjalistów, którzy włączają się zależnie od zdarzenia. Zakres decyzji powinien być zapisany przed pierwszym alarmem.
-
Odbiór i rejestracja
Jeden kanał dla badaczy, klientów, dostawców i pracowników; potwierdzenie odbioru; identyfikator sprawy oraz ochrona przekazanych informacji.
-
Weryfikacja i zasięg
Potwierdzenie podatności, ustalenie narażonych produktów, wersji i konfiguracji oraz sprawdzenie, czy komponent występuje w innych liniach produktowych.
-
Kwalifikacja raportowa
Ocena, czy podatność jest aktywnie wykorzystywana albo czy incydent spełnia próg poważnego wpływu na bezpieczeństwo produktu. Decyzja wraz z podstawą trafia do dokumentacji.
-
Naprawa i koordynacja
Kontakt z dostawcą, przygotowanie obejścia lub poprawki, test, zatwierdzenie wydania i kontrola kanału aktualizacji.
-
Zgłoszenie i komunikacja
Obsługa terminów CRA, aktualizacje zgłoszenia oraz jasna informacja dla użytkowników o ryzyku i działaniach ograniczających skutki.
-
Zamknięcie i dowody
Raport końcowy, zachowanie osi czasu, decyzji i testów, a następnie aktualizacja oceny ryzyka, SBOM, umów lub projektu produktu.
Podatność nie kończy się w dniu sprzedaży
* Okres wsparcia może być dłuższy i powinien odpowiadać oczekiwanemu czasowi używania; może być krótszy niż pięć lat tylko wtedy, gdy produkt ma krótszy oczekiwany czas używania. ** Aktualizacja bezpieczeństwa ma pozostać dostępna co najmniej 10 lat od wydania albo przez pozostałą część okresu wsparcia — zależnie od tego, który okres jest dłuższy.
Studium przypadku: producent automatyki, który „kupował całą elektronikę”
Produkt był własny. Wiedza o jego cyfrowym wnętrzu — rozproszona
Opis nie przedstawia jednego klienta ani deklarowanych wyników finansowych. Pokazuje modelowy problem organizacyjny producenta urządzenia połączonego z siecią.
Sytuacja
Polska firma sprzedawała w Unii sterownik do niewielkich instalacji przemysłowych pod własną marką. Obudowę i mechanikę projektowała wewnętrznie, moduł komunikacyjny kupowała od dystrybutora, firmware rozwijał podwykonawca, a aplikację serwisową utrzymywał drugi dostawca. Zdalny panel był oferowany jako część płatnego pakietu utrzymaniowego.
Dyrektor: „Za kod odpowiadają dostawcy. My produkujemy urządzenie”.
Osoba prowadząca przegląd: „Czyja nazwa jest na produkcie i kto obiecuje klientowi aktualizacje?”.
Dyrektor: „Nasza”.
Osoba prowadząca przegląd: „Zatem umowy z dostawcami są częścią Twojej zdolności do wykonania obowiązków, a nie zamiennikiem odpowiedzialności”.
Moment prawdy
W publicznej bazie pojawiła się krytyczna podatność biblioteki sieciowej. Firma nie potrafiła szybko stwierdzić, w których wersjach firmware biblioteka występuje. Dystrybutor znał model modułu, lecz nie miał informacji o zmodyfikowanym obrazie systemu. Pierwszy podwykonawca potrzebował czasu na odtworzenie środowiska kompilacji, drugi nie był objęty umową o alarmowym kontakcie.
Zmiana procesu
- utworzono rejestr rodzin produktów, wersji firmware, aplikacji, usług zdalnych i rynków sprzedaży;
- dla każdej wersji powiązano SBOM z dostawcą oraz repozytorium artefaktów;
- umowy uzupełniono o zgłaszanie podatności, czasy reakcji, dostęp do poprawek i współpracę przy analizie;
- wyznaczono właściciela procesu oraz zastępcę, a kontakt
security@skierowano do rejestru spraw; - przećwiczono scenariusz: zgłoszenie badacza, ustalenie zasięgu, decyzja raportowa, poprawka i komunikat do użytkowników;
- okres wsparcia połączono z realną dostępnością komponentów i zobowiązaniami dostawców.
Rezultat organizacyjny
Najważniejszym efektem nie był dokument z napisem „CRA”. Firma odzyskała zdolność udzielenia czterech odpowiedzi: czego dotyczy luka, kto podejmuje decyzję, jak dostarczyć poprawkę i co powiedzieć użytkownikowi. Dopiero na tej podstawie można budować ocenę zgodności i raportowanie.
Plan na ostatnie tygodnie przed 11 września 2026
Pełne dostosowanie cyklu rozwoju produktu wymaga czasu, lecz raportowania nie wolno odkładać do 2027 roku. Przed wrześniowym terminem zarząd powinien zamknąć przynajmniej sześć decyzji operacyjnych.
| Decyzja | Minimalny dowód | Właściciel |
|---|---|---|
| Zakres produktów | Rejestr produktów, wersji, połączeń, rynku i wstępnej kwalifikacji CRA | Produkt + prawo/compliance |
| Rola gospodarcza | Producent, importer, dystrybutor lub połączenie ról dla każdej linii | Zarząd + prawo/compliance |
| Przyjmowanie zgłoszeń | Monitorowany kanał, instrukcja i rejestr spraw | Właściciel procesu podatności |
| Kwalifikacja zdarzenia | Kryteria, lista osób decyzyjnych, zastępstwa i dokumentowanie podstawy | Bezpieczeństwo produktu + produkt |
| Zgłoszenie w SRP | Przypisana osoba, konto lub gotowość rejestracji, dane niezbędne do zgłoszenia | Wyznaczony reprezentant |
| Komunikacja i poprawka | Szablon komunikatu, kanały do użytkowników, procedura testu i wydania | Produkt + technologia + komunikacja |
Jedno ćwiczenie warte więcej niż kolejna prezentacja
Wybierz sprzedawany produkt i zasymuluj wiadomość: „podatność jest aktywnie wykorzystywana”. Uruchom stoper. Sprawdź, ile trwa wskazanie wersji, klientów, komponentu, dostawcy, obejścia, osoby decyzyjnej i danych do wczesnego ostrzeżenia. Luki w ćwiczeniu są tańsze niż luki podczas prawdziwego incydentu.
Co przygotować do pełnego stosowania CRA w 2027 roku
Wrześniowe raportowanie nie wyczerpuje CRA. Do 11 grudnia 2027 roku producenci powinni przygotować cały system zgodności produktu: ocenę ryzyka cyberbezpieczeństwa, bezpieczne projektowanie i konfigurację domyślną, obsługę podatności w okresie wsparcia, dokumentację techniczną, instrukcje dla użytkownika, ocenę zgodności, deklarację zgodności UE oraz oznakowanie CE, stosownie do kategorii produktu i właściwej procedury.
Nie każdy produkt trafi do tej samej ścieżki oceny. CRA rozróżnia kategorię domyślną oraz produkty ważne i krytyczne, dla których procedury mogą być bardziej wymagające. Klasyfikacja zależy od podstawowej funkcji produktu i kryteriów rozporządzenia, a nie od tego, czy dział handlowy określa urządzenie jako „proste”.
Równolegle dojrzewają normy zharmonizowane i praktyczne wytyczne. Komisja Europejska opublikowała w lipcu 2026 roku obszerne, niewiążące wytyczne z przykładami dotyczącymi między innymi zakresu, istotnej modyfikacji, okresów wsparcia, oceny ryzyka i raportowania. To dobry punkt odniesienia, jednak nie zastępuje analizy konkretnego produktu oraz jego dokumentacji.
Najważniejsza checklista dla zarządu i właściciela produktu
- Czy mamy listę wszystkich produktów i komponentów cyfrowych udostępnianych na rynku UE?
- Czy wiemy, które usługi zdalne są niezbędne do funkcji produktu?
- Czy dla każdej linii określiliśmy rolę producenta, importera i dystrybutora?
- Czy produkty pod własną marką zostały ocenione niezależnie od tego, kto napisał kod?
- Czy potrafimy powiązać wersję produktu z wersjami komponentów i dostawcami?
- Czy umowy zapewniają szybkie informacje o podatności, poprawkę i współpracę dowodową?
- Czy istnieje publiczny i monitorowany kanał przyjmowania zgłoszeń bezpieczeństwa?
- Czy jedna osoba odpowiada za proces, ma zastępcę i mandat do eskalacji?
- Czy umiemy odróżnić zwykłą lukę od zdarzenia podlegającego raportowaniu?
- Czy wyznaczona osoba potrafi obsłużyć Single Reporting Platform?
- Czy kanał aktualizacji jest bezpieczny, a poprawkę można przetestować i dostarczyć?
- Czy okres wsparcia produktu zgadza się z umowami i żywotnością kluczowych komponentów?
Jeżeli na trzy lub więcej pytań odpowiedź brzmi „nie wiem”, problemem nie jest jeszcze brak certyfikatu. Problemem jest brak mapy odpowiedzialności. Właśnie od niej powinien zacząć się projekt CRA.
FAQ: CRA i produkty z elementami cyfrowymi
Podstawy: zakres, terminy i odpowiedzialność
Co oznacza skrót CRA?
CRA to Cyber Resilience Act, po polsku unijne rozporządzenie w sprawie cyberodporności. Najprościej mówiąc: są to zasady bezpieczeństwa dla sprzętu i oprogramowania sprzedawanego w Unii Europejskiej. Określają między innymi, jak producent ma projektować produkt, usuwać podatności, dostarczać aktualizacje i zgłaszać najpoważniejsze zdarzenia.
Czy CRA dotyczy tylko producentów oprogramowania?
Nie. Zakres obejmuje sprzęt i oprogramowanie, w tym produkty końcowe oraz komponenty udostępniane osobno, jeżeli spełniają kryteria rozporządzenia. Urządzenie połączone z siecią, firmware lub aplikacja mogą być równie istotne jak klasyczny program komputerowy.
Czy od 11 września 2026 roku cały produkt musi już spełniać CRA?
Nie. Od tej daty stosuje się obowiązki raportowania z art. 14. Zasadnicza część pozostałych wymagań zacznie być stosowana 11 grudnia 2027 roku. Nie oznacza to jednak, że przygotowanie produktu, dokumentacji i procesu można odłożyć do końca 2027 roku.
Czy raportowaniu podlega każda wykryta podatność?
Obowiązkowe raportowanie dotyczy aktywnie wykorzystywanej podatności oraz poważnego incydentu mającego wpływ na bezpieczeństwo produktu. Każdą informację trzeba jednak przyjąć, zweryfikować, ocenić i udokumentować, aby prawidłowo ustalić, czy próg raportowy został osiągnięty.
Czy zakup modułu od dostawcy przenosi na niego całą odpowiedzialność?
Nie, jeżeli firma jest producentem produktu końcowego w rozumieniu CRA. Producent musi skutecznie obsługiwać podatności całego produktu, w tym zintegrowanych komponentów. Umowa z dostawcą powinna umożliwiać wykonanie tego obowiązku.
Dokumentacja i zespoły bezpieczeństwa
Czy SBOM musi być publiczny?
SBOM to Software Bill of Materials, czyli uporządkowana lista składników oprogramowania. Można porównać ją do listy części wykorzystanych w urządzeniu: pokazuje biblioteki, moduły i zależności znajdujące się w produkcie. Dzięki niej firma może szybciej sprawdzić, czy wykryta luka dotyczy konkretnej wersji produktu. CRA wymaga dokumentowania komponentów, w tym przez SBOM w powszechnie używanym i maszynowo czytelnym formacie, obejmujący co najmniej zależności najwyższego poziomu. Nie oznacza to ogólnego obowiązku publikowania pełnej listy każdemu odbiorcy.
Czy mała firma może wyznaczyć jedną osobę zamiast tworzyć PSIRT?
PSIRT to Product Security Incident Response Team, czyli zespół reagujący na podatności i incydenty dotyczące produktu. Sprawdza, których wersji dotyczy problem, koordynuje poprawkę, zgłoszenie i komunikację z użytkownikami. Mała firma nie musi tworzyć osobnego działu. Może wyznaczyć jedną odpowiedzialną osobę, zastępcę i specjalistów włączanych zależnie od zdarzenia. Liczy się działający proces, a nie angielska nazwa zespołu.
Czym różnią się SOC, CSIRT i PSIRT?
SOC (Security Operations Center) stale obserwuje bezpieczeństwo systemów organizacji i wykrywa podejrzane zdarzenia. CSIRT (Computer Security Incident Response Team) reaguje na incydenty komputerowe, ogranicza ich skutki i pomaga przywrócić działanie. PSIRT koncentruje się natomiast na bezpieczeństwie produktu sprzedawanego klientom. W mniejszej firmie te zadania mogą wykonywać te same osoby lub zewnętrzni specjaliści, ale odpowiedzialność za produkt nadal powinna być jasno przypisana.
Instytucje, platformy i pozostałe skróty
Co oznaczają ENISA i SRP?
ENISA to Agencja Unii Europejskiej ds. Cyberbezpieczeństwa. Wspiera państwa i firmy w podnoszeniu poziomu bezpieczeństwa oraz uczestniczy w obsłudze zgłoszeń wymaganych przez CRA. SRP (Single Reporting Platform) to jednolita platforma, przez którą producenci mają przekazywać wymagane zgłoszenia o aktywnie wykorzystywanych podatnościach i poważnych incydentach. Z punktu widzenia firmy ENISA jest instytucją, a SRP — narzędziem do raportowania.
Co oznacza VEX i czym różni się od SBOM?
VEX to Vulnerability Exploitability eXchange, czyli informacja, czy znana podatność danego komponentu rzeczywiście może zostać wykorzystana w konkretnym produkcie. SBOM odpowiada na pytanie „co znajduje się w produkcie?”, natomiast VEX pomaga odpowiedzieć „czy ta luka ma tu praktyczne znaczenie?”. VEX może ułatwić analizę i komunikację, ale sam nie jest certyfikatem zgodności z CRA.
Co znaczą SaaS, firmware i open source?
SaaS (Software as a Service) to program używany przez internet, zwykle w abonamencie, bez instalowania całego systemu na komputerze klienta. Firmware to oprogramowanie wbudowane w urządzenie, na przykład sterownik bramy, routera lub czujnika. Open source oznacza oprogramowanie z dostępnym kodem źródłowym, które można wykorzystywać zgodnie z warunkami jego licencji. Otwarty kod nie oznacza jednak automatycznie braku odpowiedzialności za jego użycie we własnym produkcie.
Co oznaczają IT, MŚP, UE i oznakowanie CE?
IT to technologie informacyjne, czyli systemy, sieci, urządzenia i oprogramowanie używane przez firmę. MŚP oznacza mikro-, małe i średnie przedsiębiorstwa. UE to Unia Europejska. CE jest oznakowaniem, przez które producent deklaruje, że produkt spełnia mające do niego zastosowanie wymagania prawa Unii. Sam znak CE nie jest przyznawaną przez Unię „nagrodą za bezpieczeństwo” i nie zastępuje dokumentacji ani właściwej procedury oceny zgodności.
Wniosek: produkt kończy się tam, gdzie kończy się odpowiedzialność — nie obudowa
- Sprawdź funkcję i połączenie produktu, zamiast polegać na branżowej etykiecie.
- Ustal rolę firmy, zwłaszcza przy własnej marce i modyfikacjach.
- Połącz produkt z komponentami, dostawcami, wersjami i okresem wsparcia.
- Wyznacz właściciela podatności, zanim zacznie biec termin 24 godzin.
CTA: zróbmy mapę produktu, zanim zrobi ją za Ciebie incydent
AP Market Cell porządkuje cyfrowy ekosystem firmy: produkty, systemy, dostawców, przepływy danych i odpowiedzialność operacyjną. Nie zastępujemy kancelarii, laboratorium oceny zgodności ani wyspecjalizowanego zespołu bezpieczeństwa produktu. Możemy natomiast pomóc zbudować czytelny punkt wyjścia do pracy z tymi ekspertami — bez zgadywania, które urządzenie, aplikacja lub integracja należy do kogo.
Sprawdź gotowość cyfrową firmy Porozmawiajmy o mapie produktu
Jeżeli chcesz najpierw uporządkować szerszy kontekst bezpieczeństwa, przeczytaj także: Cyberbezpieczeństwo firmy nie zaczyna się od antywirusa oraz Branże kluczowe dla gospodarki pod presją.
Źródła i odwołania
- Rozporządzenie (UE) 2024/2847 — Cyber Resilience Act, tekst urzędowy.
- Komisja Europejska: podsumowanie przepisów Cyber Resilience Act.
- Komisja Europejska: CRA — obowiązki raportowania.
- Komisja Europejska: wytyczne dotyczące stosowania CRA, 27 lipca 2026.
- Komisja Europejska: FAQ dotyczące wdrażania CRA.
- ENISA: Single Reporting Platform dla zgłoszeń CRA.
- Komisja Europejska: CRA i oprogramowanie open source.
Stan prawny i źródła zweryfikowane 22 sierpnia 2026 roku. Materiał ma charakter informacyjny i nie stanowi porady prawnej, oceny zgodności ani audytu cyberbezpieczeństwa.
