Blog
Co naprawdę zaczyna się 11 września 2026 i 11 grudnia 2027
Zdjęcie: ThisisEngineering / Unsplash
Dwie daty dominują każdą rozmowę o Cyber Resilience Act: 11 września 2026 i 11 grudnia 2027. To nie jest ten sam obowiązek. Żadna z nich nie spada rano w dzień deadline’u. Rozporządzenie (UE) 2024/2847 już obowiązuje. Daty poniżej otwierają konkretne obowiązki producenta, który wprowadza produkt z elementami cyfrowymi na rynek Unii.
Jeśli obie daty traktujecie jako „wtedy zaczyna się CRA”, przegapicie pierwszy zegar operacyjny i dojdziecie do CE z pustym plikiem technicznym.
Kalendarz ma cztery daty, nie dwie
| Data | Co naprawdę się zaczyna |
|---|---|
| 10 grudnia 2024 | Rozporządzenie weszło w życie. Tekst prawny działa. Pełne stosowanie wymagań zasadniczych przychodzi później. |
| 11 czerwca 2026 | Przepisy o notyfikacji jednostek oceny zgodności. Ma znaczenie, jeśli klasa wyrobu będzie wymagać jednostki notyfikowanej. |
| 11 września 2026 | Art. 14: aktywnie wykorzystywane podatności i poważne incydenty. Wczesne ostrzeżenie 24h, zgłoszenie 72h, potem raport końcowy. |
| 11 grudnia 2027 | Wymagania zasadnicze z Annex I, ocena zgodności, deklaracja UE i znak CE przy wprowadzeniu produktu na rynek. |
Większość slajdów pomija czerwiec 2026 i spłaszcza wrzesień 2026 do „czegoś o incydentach”. Tak zespoły planują projekt CE na 2027 i w sierpniu 2026 odkrywają, że w dwadzieścia cztery godziny nie potrafią nazwać produktu, właściciela ani CSIRT.
Czego te poranki nie uruchamiają
Nic w rozporządzeniu nie tworzy gotowego SBOM, oceny ryzyka ani pliku technicznego w dniu, w którym obowiązek zaczyna obowiązywać. Nadzór rynku może zażądać pliku po 11 grudnia 2027. Art. 14 może odpalić 12 września 2026 o 2:00. System, który odpowiada na oba pytania, musi istnieć wcześniej.
Daty nie uruchamiają też „programu privacy” w stylu RODO. CRA to reguła bezpieczeństwa wyrobu. Adresatem jest producent konkretnego produktu, nie „firma” raz. Istotna zmiana to nowe wprowadzenie na rynek.
Nie uruchamiają subskrypcji skanera podatności. CRA to nie skaner. Skanowanie jest jednym wejściem do Annex I część II i do kolejki art. 14.
11 września 2026 - art. 14 to zegar operacyjny
To pierwsza data, która zmienia pracę producenta w piątkową noc. Od 11 września 2026 zgłaszacie aktywnie wykorzystywane podatności i poważne incydenty dotyczące wyrobu.
Zegary w tekście są krótkie celowo:
- wczesne ostrzeżenie w 24h od chwili, w której wiecie,
- pełne zgłoszenie w 72h,
- raport końcowy: 14 dni od poprawki przy podatności albo miesiąc od zgłoszenia 72h przy incydencie.
Jeden kanał: jednolity punkt, do CSIRT miejsca siedziby i do ENISA. Nie wymyślacie bocznej skrzynki. Nie czekacie na poniedziałkowy standup.
Co znaczy „wiecie”
Zegar 24h startuje, gdy producent jest świadomy, nie gdy zgłoszenie jest schludne. Jeśli świadomość siedzi w mailu od badacza, w tickecie klienta i w wątku na Slacku, godziny uciekły zanim kolejka w ogóle powstała. Pytanie operacyjne: kto może powiedzieć „wiemy” i do której wersji produktu to się przypina?
Bez katalogu produktów nie odpowiecie, które SKU, która wersja, który rynek i jaki koniec wsparcia. Bez SBOM zgodnego z wysłanym buildem nie powiecie, który komponent płonie. Bez nazwanego właściciela okno 24h jest przypomnieniem w kalendarzu, nie procesem.
Co zgłaszacie, a czego nie
Art. 14 to nie „każde CVE z backlogu”. To aktywnie wykorzystywane podatności i poważne incydenty. Nadal potrzebujecie kolejki, która umie to rozróżnić: liczba CVSS w skanerze to nie to samo co aktywne wykorzystanie, a awaria laptopa w biurze to nie incydent produktu.
Zgłoszenie musi wskazywać produkt wprowadzony na rynek. Jeśli ten sam firmware idzie pod trzema markami, plik musi o tym wiedzieć. Jeśli dostawca komponentu ujawnia pierwszy, należyta staranność wobec tego komponentu i tak zostaje przy was.
Co musi działać już w sierpniu 2026
- Katalog PDE z nazwą, wersją, typem, rynkami i końcem wsparcia (miesiąc i rok).
- SBOM z pipeline, przypięty do wersji, którą faktycznie wysyłacie.
- Kolejka podatności z zegarem 24h / 72h i nazwanym właścicielem przy produkcie.
- Spisana ścieżka do jednolitego punktu i CSIRT siedziby.
- Plik techniczny, który otworzycie bez wynoszenia danych z sieci.
Jeśli którekolwiek z tego jest „postawimy we wrześniu”, pierwsza wykorzystana podatność będzie archeologią maili.
11 grudnia 2027 - wymagania zasadnicze i CE
Od tej daty produkt wprowadzany na rynek Unii musi spełniać Annex I, przejść ocenę zgodności, mieć deklarację UE i znak CE. Trzeba też utrzymać ocenę ryzyka cyberbezpieczeństwa, dokumentację, SBOM i okres wsparcia podany przy zakupie z miesiącem i rokiem.
To nie jest „włączamy CE w grudniu 2027”. Plik musi istnieć, zanim wyrób wyjdzie z magazynu. Organ może go zażądać później. Brak SBOM albo wiersz ryzyka, który nie wskazuje Annex I, to nie problem formatowania. To nie domknięta ścieżka zgodności.
Moduł A to nadal dowody
Większość wyrobów klasy domyślnej zostaje przy module A (wewnętrzna kontrola produkcji). To nie jest przepustka. Nadal potrzebujecie oceny ryzyka, dowodów Annex I, SBOM, okresu wsparcia, instrukcji, deklaracji i znaku. Jednostka notyfikowana to inna klasa wyrobu, nie zamiennik pliku.
11 czerwca 2026 ma tu znaczenie: zaczynają obowiązywać przepisy o notyfikacji jednostek. Jeśli wyrób będzie wymagał jednostki notyfikowanej, odkrycie tej kolejki pod koniec 2027 to druga przegapiona data.
Wprowadzenie na rynek jest spustem
CRA dotyczy chwili, w której wprowadzacie produkt na rynek Unii pod własną nazwą lub znakiem. Produkty udostępnione przed 11 grudnia 2027 nie są czekiem in blanco. Istotna zmiana jest traktowana jako nowe wprowadzenie na rynek. Nowa wersja główna, nowa funkcja cyfrowa, która zmienia ryzyko, rebrand, po którym to wy jesteście producentem w dokumentach: to zdarzenia pliku, nie marketingu.
Okres wsparcia podany przy zakupie (miesiąc i rok) jest częścią tożsamości wyrobu. To nie slogan na stronie. Musi zgadzać się z katalogiem, oknem utrzymania SBOM i obowiązkiem obsługi podatności z Annex I część II.
Co naprawdę jest w pliku 2027
Nie PDF z podatnościami. Plik to tożsamość wyrobu, ocena ryzyka z art. 13 przez cykl życia, dowody wobec Annex I część I (właściwości produktu) i część II (obsługa podatności), SBOM, okres wsparcia, instrukcje, deklaracja UE i znak CE. Jeśli któregoś brakuje, ścieżka nie jest zamknięta.
Typowe złe odczytanie dat
„Mamy czas do 2027.” Art. 14 jest czternaście miesięcy wcześniej. Zegar 24h nie czyta waszego planu projektu CE.
„Wrzesień 2026 to tylko incydenty.” To aktywnie wykorzystywane podatności i poważne incydenty. Pierwsze potrzebuje SBOM i mapy produktów tak samo jak drugie.
„Kupimy skaner w 2026.” Skaner nie da wam tożsamości producenta, dat wsparcia, luk Annex I ani deklaracji. Zasila kolejkę. Nie zastępuje kolejki.
„Oprogramowanie jest później.” Samodzielne oprogramowanie wprowadzane na rynek Unii jest produktem z elementami cyfrowymi. Daty są te same.
„CE to robota jednostki notyfikowanej.” Dla większości wyrobów to wasza robota. Jednostka, jeśli wymagana, ocenia. Dowody trzymacie wy.
Co ma działać przed pierwszym terminem
Liczycie wstecz od 11 września 2026, nie w przód od slajdu na 2027.
- Katalog każdego PDE: wersja, rynek, data wprowadzenia, koniec wsparcia z miesiącem i rokiem.
- Ocena ryzyka z art. 13 przypięta do Annex I. Luka w osobnym Excelu to nie ocena.
- SBOM z pipeline, zablokowany do wysłanej wersji.
- Kolejka 24h / 72h z nazwanym właścicielem i ścieżką do CSIRT i ENISA.
- Plik techniczny on-premise, do wyeksportowania bez wynoszenia SBOM z sieci.
Crado AI jest systemem on-premise do tej pętli: katalog, ryzyko, SBOM, art. 14, plik techniczny i CE. Daty się nie przesuną. Plik nie pojawi się rano 11 września.