Cyber Resilience Act: 11 września 2026 to prawdziwy termin

Większość unijnych rozporządzeń daje datę zgodności i okres łaski, w którym wszyscy po cichu się organizują. Cyber Resilience Act robi coś innego. Jego pierwszym twardym obowiązkiem jest zegar zgłoszenia 24 godzin, a rusza 11 września 2026.

Zegara 24 godzin nie da się wdrożyć etapami. Albo proces istnieje tego dnia, albo nie zdążysz.

Czym jest CRA

Rozporządzenie (UE) 2024/2847 ustanawia wymogi cyberbezpieczeństwa dla produktów z elementami cyfrowymi wprowadzanych na rynek UE. To określenie obejmuje znacznie więcej, niż początkowo się zakłada: każdy produkt programowy lub sprzętowy oraz jego rozwiązania zdalnego przetwarzania danych, których przewidziane lub racjonalnie przewidywalne użycie obejmuje bezpośrednie lub pośrednie połączenie danych.

Urządzenia połączone są objęte. Podobnie większość oprogramowania komercyjnego, systemy operacyjne, przeglądarki, aplikacje mobilne, firmware i komponenty wewnątrz innych produktów.

Rozporządzenie opublikowano w listopadzie 2024 i stosuje się etapami:

• 11 czerwca 2026: obowiązki jednostek oceniających zgodność.
• 11 września 2026: obowiązki zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów.
• 11 grudnia 2027: pełne stosowanie, w tym zasadnicze wymogi cyberbezpieczeństwa, oznakowanie CE, dokumentacja techniczna i wykaz składników oprogramowania.

To środkowa data jest tą, pod którą trzeba planować, bo przychodzi pierwsza i zależy od zdolności, których możesz nie mieć.

Co dzieje się 11 września 2026

Od tej daty producenci muszą zgłaszać:

Aktywnie wykorzystywane podatności w swoich produktach z elementami cyfrowymi oraz

poważne incydenty wpływające na bezpieczeństwo tych produktów.

Zgłoszenie idzie przez jedną platformę zgłoszeniową CRA prowadzoną przez ENISA, do wyznaczonego CSIRT w państwie członkowskim głównej siedziby producenta, który następnie dzieli się z innymi zainteresowanymi CSIRT i z ENISA.

Harmonogram:

• W ciągu 24 godzin od powzięcia wiedzy: wczesne ostrzeżenie.
• W ciągu 72 godzin: pełne zgłoszenie, w tym podjęte środki naprawcze lub łagodzące.
• W ciągu 14 dni od udostępnienia środka naprawczego: raport końcowy dla aktywnie wykorzystywanej podatności.
• W ciągu miesiąca: raport końcowy dla poważnego incydentu.

Dwadzieścia cztery godziny od powzięcia wiedzy, nie od potwierdzenia ani od naprawy. Jeśli podatność w komponencie twojego produktu jest wykorzystywana na wolności w sobotę, zegar tyka w sobotę.

Dlaczego to trudniejsze, niż wygląda

Sam obowiązek zgłoszenia to formularz. Trudność tkwi we wszystkim, co musisz mieć, zanim będziesz mógł go wypełnić.

Musisz wiedzieć, co jest w twoim produkcie

Żeby zgłosić, że podatność w twoim produkcie jest aktywnie wykorzystywana, musisz wiedzieć, że podatny komponent jest w twoim produkcie. Dla nowoczesnej aplikacji z setkami zależności przechodnich to nie jest coś, na co człowiek odpowie z pamięci.

Dlatego zespoły budują teraz potoki wykazu składników oprogramowania, ponad rok przed formalnym wymogiem SBOM z grudnia 2027. SBOM nie jest celem. Celem jest umiejętność odpowiedzi na pytanie „czy nas to dotyczy?" w ciągu godzin, a SBOM sprawia, że pytanie ma odpowiedź.

Niewygodne jest to, że dotyczy to produktów wysłanych lata temu. Jeśli masz wspierane urządzenia w terenie z firmware zbudowanym w 2022 z drzewa zależności, którego nikt nie zapisał, odtworzenie tego to realna praca.

Musisz obserwować

Powzięcie wiedzy uruchamia zegar, a oczekuje się, że będzie aktywne, a nie przypadkowe. To znaczy monitorowanie kanałów o podatnościach, subskrypcję biuletynów dla swoich komponentów, śledzenie katalogów znanych wykorzystywanych podatności i posiadanie kanału, którym badacze bezpieczeństwa mogą się z tobą skontaktować i dostać odpowiedź.

Musisz mieć ścieżkę decyzyjną

Ktoś musi móc zdecydować, o dowolnej porze, czy incydent przekracza próg i czy zegar ruszył. Bez nazwanej roli i ścieżki eskalacji pierwsze godziny idą na ustalanie, kto może podjąć decyzję.

Zależności po końcu wsparcia stają się zobowiązaniem

Jeśli komponent w twoim produkcie nie dostaje już aktualizacji bezpieczeństwa, nadal masz obowiązek zgłoszenia, gdy zostanie wykorzystany, a nie masz żadnej poprawki wyżej w łańcuchu, na którą mógłbyś wskazać. Audyt zależności po końcu wsparcia to jedna z bardziej użytecznych rzeczy w okresie przygotowawczym, bo odpowiedź czasem wymusza migrację z własnym czasem realizacji.

Co przynosi pełne stosowanie w grudniu 2027

Obowiązki z grudnia 2027 to większy program i trzeba je zacząć długo wcześniej.

Bezpieczeństwo w fazie projektowania i domyślne. Produkty muszą być zaprojektowane, opracowane i wytworzone tak, by zapewnić odpowiedni poziom cyberbezpieczeństwa oparty na ryzyku. Brak domyślnych haseł. Bezpieczna konfiguracja od razu. Minimalizacja powierzchni ataku. Ochrona danych w tranzycie i w spoczynku.

Obsługa podatności. Udokumentowany proces obejmujący identyfikację, naprawę, testy, dystrybucję i ujawnianie. Aktualizacje bezpieczeństwa muszą być dostarczane bez zwłoki i bezpłatnie, przez okres wsparcia odzwierciedlający oczekiwany czas życia produktu, przy czym pięć lat to częsty punkt odniesienia.

Wykaz składników oprogramowania. W formacie czytelnym maszynowo, obejmujący co najmniej zależności najwyższego poziomu i utrzymywany na bieżąco.

Dokumentacja techniczna i ocena zgodności. Większość produktów ocenia się samodzielnie. Kategorie ważne i krytyczne, w tym menedżery haseł, VPN-y, systemy operacyjne i przemysłowe systemy sterowania, wymagają udziału strony trzeciej.

Oznakowanie CE. Cyfrowy odpowiednik znaku fizycznego, deklarujący zgodność.

Polityka skoordynowanego ujawniania podatności. Opublikowana, z działającym punktem kontaktowym.

Kogo to faktycznie obejmuje

Kilka przypadków granicznych wraca bez przerwy.

Wolne i otwarte oprogramowanie tworzone poza działalnością komercyjną w dużej mierze jest poza zakresem. Rozporządzenie wprowadza pojęcie opiekuna oprogramowania otwartego z lżejszymi obowiązkami. Ale jeśli komercjalizujesz otwarte oprogramowanie albo dostarczasz je wewnątrz sprzedawanego produktu, obowiązki produktowe są twoje.

Oprogramowanie jako usługa zwykle wypada poza CRA i mieści się raczej w NIS2, choć rozwiązania zdalnego przetwarzania danych będące integralną częścią produktu z elementami cyfrowymi zostają wciągnięte. Jeśli twoje urządzenie do działania zależy od twojego backendu w chmurze, ten backend jedzie razem z produktem.

Importerzy i dystrybutorzy też mają obowiązki. Jeśli wprowadzasz produkt osoby trzeciej na rynek UE pod własną nazwą lub znakiem, jesteś traktowany jak producent.

Produkty regulowane gdzie indziej, jak wyroby medyczne, pojazdy i sprzęt lotniczy, są obsługiwane we własnych ramach.

Pytania o zakres naprawdę nie są trywialne i to miejsce, gdzie godzina z prawnikiem oszczędza miesiące źle ukierunkowanej inżynierii.

Co zrobilibyśmy w pozostałym czasie

Jeśli podlegasz i zaczynasz teraz, taka kolejność działa:

Po pierwsze, ustal inwentarz produktów. Co faktycznie masz na rynku UE? Włącznie ze starymi wersjami wciąż w terenie, wariantami white label i produktami, które dystrybuujesz dla kogoś innego. Ta lista jest zwykle dłuższa, niż ktokolwiek się spodziewa.

Po drugie, wbuduj generowanie SBOM w CI. Generuj SBOM przy każdym buildzie, w CycloneDX albo SPDX, zapisuj przy artefakcie wydania i trzymaj w postaci przeszukiwalnej. Chodzi o to, by móc zapytać „które z naszych wydanych wersji zawierają tę bibliotekę?" i dostać odpowiedź w minuty.

Po trzecie, podłącz monitoring podatności. Zasil dane SBOM do skanera obserwującego biuletyny i katalogi znanych wykorzystywanych podatności, a alerty kieruj na kanał, który ktoś czyta.

Po czwarte, napisz instrukcję incydentu. Kto ogłasza, kto ocenia, kto zgłasza, kto komunikuje. Nazwane osoby, zastępcy i kontakty poza godzinami. Potem przećwicz raz z fałszywym biuletynem. Na ćwiczeniu odkryjesz, że osoba z danymi dostępowymi do platformy zgłoszeniowej jest na urlopie.

Po piąte, opublikuj politykę ujawniania podatności. Plik security.txt, obsługiwany adres i deklarowany czas reakcji. To popołudnie pracy i różnica między dowiedzeniem się o problemie od badacza a od dziennikarza.

Po szóste, zacznij pracę na grudzień 2027. Bezpieczne ustawienia domyślne, mechanizmy aktualizacji, decyzje o okresie wsparcia i dokumentacja to pytania architektoniczne, nie papierologia. Produkty projektowane w 2026 będą jeszcze na rynku w 2028.

Nakładka, której nikt nie wykorzystuje

Między CRA a innymi reżimami jest istotne powielenie, a większość firm traktuje każdy osobno, co jest marnotrawstwem.

SBOM zbudowany dla CRA odpowiada na większość pytań o łańcuch dostaw z NIS2. Instrukcja incydentu nakłada się na wczesne ostrzeżenie 24 godzin z NIS2 i na zgłoszenie naruszenia w 72 godziny z RODO. Procesy obsługi podatności zasilają wprost ankiety bezpieczeństwa klientów i zakupy korporacyjne.

Zbuduj to raz jako zdolność platformową. Alternatywą są trzy zespoły budujące trzy wersje tego samego inwentarza zasobów.

Gdzie szukać pomocy

Budujemy i utrzymujemy oprogramowanie dla firm sprzedających do UE, co coraz częściej znaczy budowanie widoczności łańcucha dostaw i infrastruktury aktualizacji, którą CRA zakłada. Jeśli ustalasz, czy podlegasz, albo masz wrześniową datę w kalendarzu i żadnego monitoringu, napisz na office@c9group.dev.

Nasza usługa utrzymania systemów odziedziczonych często jest punktem wyjścia, bo produkty o najgorszej widoczności zależności są zwykle najstarsze. Szerszy obraz regulacyjny znajdziesz w naszym przewodniku po zgodności cyfrowej UE 2026.

Jesteśmy inżynierami, a nie prawnikami. Decyzje o zakresie i klasyfikacji należą do twoich prawników, a my budujemy pod odpowiedź, którą dadzą.