Terminy CRA 2026 i 2027: co obowiązuje, co jest zablokowane

Na dzień 30 maja 2026 r. zero jednostek notyfikowanych zostało wyznaczonych pod CRA. Żadna norma zharmonizowana nie została opublikowana w Dzienniku Urzędowym. Platforma zgłaszania ENISA jeszcze nie istnieje. Do rozpoczęcia stosowania Artykułu 14, czyli do 11 września 2026 r., pozostało 3,4 miesiąca.

Producent wprowadzający produkty z elementami cyfrowymi na rynek UE musi znać rzeczywisty stan rzeczy: co należy zbudować przed wrześniem, co jest dziś zablokowane i dlaczego samoocena Istotnej klasy I dziś nie działa.

Trzy przeszkody, których nie da się ominąć

Brak norm zharmonizowanych

Artykuł 32 ust. 2 daje producentom Istotnej klasy I trzy ścieżki oceny zgodności: samoocena, ocena przez podmiot trzeci na podstawie norm zharmonizowanych lub specyfikacji wspólnych albo ocena przez jednostkę notyfikowaną. Środkowa ścieżka wymaga norm zharmonizowanych CRA. Jednak żadna norma zharmonizowana CRA nie została opublikowana w Dzienniku Urzędowym. Na dzień 30 maja 2026 r.:

• Strona Komisji dotycząca norm zharmonizowanych nie zawiera żadnego wpisu dla Rozporządzenia (UE) 2024/2847.
• Nie przyjęto żadnych specyfikacji wspólnych na podstawie Artykułu 27 ust. 2.
• Żaden akt delegowany z Artykułu 27 ust. 9 nie wyznacza europejskiego programu certyfikacji cyberbezpieczeństwa jako ścieżki domniemania zgodności z CRA.

W przypadku braku norm Artykuł 32 ust. 2 wymaga zastosowania Module B+C (badanie typu UE) lub Module H (pełne zapewnienie jakości). Oba wymagają jednostki notyfikowanej.

W konsekwencji producent produktu Istotnej klasy I nie może dziś korzystać z samooceny. Jedyną zgodną ścieżką jest ocena przez jednostkę notyfikowaną.

CEN-CLC/JTC 13/WG 9 opracowuje serię EN 40000:

• prEN 40000-1-1 (Słownictwo): ankieta publiczna zakończona, jeszcze nie na etapie głosowania formalnego.
• prEN 40000-1-2 (Zasady): ankieta publiczna zakończona, jeszcze nie na etapie głosowania formalnego.
• prEN 40000-1-3 (Obsługa podatności): ankieta publiczna trwała od grudnia 2025 r. do lutego 2026 r., obecnie w fazie rozpatrywania uwag.
• prEN 40000-1-4 (Ogólne wymagania bezpieczeństwa): wciąż w fazie opracowywania.
• Normy wertykalne Typu C (przeglądarki, VPN, SIEM i inne): zaawansowany etap projektu, jeszcze nie w ankiecie publicznej.

Realistycznie najwcześniejsza cytacja w Dzienniku Urzędowym: IV kwartał 2026 r. Kilka norm wertykalnych przesunie się prawdopodobnie na 2027 r.

Brak jednostek notyfikowanych

Rozdział IV stosuje się od 11 czerwca 2026 r. Cel Komisji to wystarczająca przepustowość jednostek notyfikowanych do 11 grudnia 2026 r. (Artykuł 35 ust. 2, sformułowanie typu best-efforts). Na dzień 30 maja 2026 r. w Jednolitej Przestrzeni Zgodności z Rynkiem nie figuruje żadna jednostka notyfikowana wyznaczona pod CRA.

Producent, który potrzebuje oceny Istotnej klasy I zakończonej przed grudniem 2027 r., powinien zaplanować:

• Przygotowanie dokumentacji technicznej: 3 do 6 miesięcy.
• Ocena Module B+C: 2 do 4 miesięcy na produkt.
• Dostępność jednostki notyfikowanej: niepewna do czasu otwarcia formalnego wyznaczania po czerwcu 2026 r.

Trzeba nawiązać kontakt z jednostkami oceniającymi zgodność już teraz. Formalny mechanizm nie otworzy się przed połową 2026 r. Czekanie do tego momentu sprawia, że ukończenie oceny przed grudniem 2027 r. jest mało prawdopodobne.

Brak platformy zgłaszania ENISA

Jednolita Platforma Zgłaszania z Artykułu 16 nie jest dostępna na dzień 30 maja 2026 r. ENISA zawarła umowę z dostawcą. Platforma ma zostać uruchomiona przed 11 września 2026 r. Nie opublikowano żadnego adresu URL rejestracji ani wytycznych skierowanych do producentów.

Co można zrobić teraz:

• Przygotować szablony powiadomień zgodne z wymaganiami formatu z Artykułu 14: powiadomienia 24-godzinne i 72-godzinne, 14-dniowy raport końcowy dotyczący podatności oraz miesięczny raport końcowy dotyczący poważnego incydentu.
• Zidentyfikować koordynatora CSIRT wyznaczonego przez dane państwo członkowskie.
• Określić, kto wewnętrznie jest upoważniony do uruchomienia powiadomienia 24-godzinnego w weekend lub dzień wolny od pracy.

Strona SRP ENISA: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

Co musi być gotowe przed 11 września 2026 r.

Pozostało 3,4 miesiąca. Jeśli poniższe elementy nie są gotowe, problem nie polega na opóźnieniu zadań. Opóźnienie dotyczy infrastruktury, a budowa infrastruktury wymaga miesięcy.

Inwentarz produktów i klasyfikacja

Producent potrzebuje pełnej listy każdego produktu z elementami cyfrowymi (PDE) wprowadzanego na rynek UE, z potwierdzoną klasyfikacją CRA dla każdego produktu:

• Klasa domyślna: dostępna ścieżka samooceny.
• Istotna klasa I: dziś wymagana ocena przez jednostkę notyfikowaną (zob. powyżej).
• Istotna klasa II: wymagana jednostka notyfikowana. Module B+C lub Module H.
• Krytyczna: Module B+C lub pełne zapewnienie jakości. Może mieć zastosowanie europejska certyfikacja cyberbezpieczeństwa.

Odniesienie klasyfikacyjne: Rozporządzenie wykonawcze (UE) 2025/2392 (Dz.U. 1 grudnia 2025 r., w mocy od 21 grudnia 2025 r.) zawiera techniczne opisy kategorii produktów z Załącznika III i Załącznika IV. Pomaga rozstrzygnąć przypadki graniczne.

Infrastruktura SBOM

Producent nie jest w stanie zgłosić aktywnie wykorzystywanej podatności w ciągu 24 godzin bez wiedzy o komponentach zawartych w produkcie. Generowanie SBOM musi być operacyjne przed wrześniem 2026 r.

• Format: CycloneDX lub SPDX. Oba są akceptowane w ramach CRA. Wybierz jeden i ustandaryzuj go w produktach.
• Zakres: zależności przechodnie, nie tylko bezpośrednie. Pełna widoczność komponentów jest wymagana w ocenie ryzyka z Załącznika VII.
• Przechowywanie: kontrola wersji, powiązanie z wydaniami produktu. Każdy SBOM musi odwzorowywać konkretny build.
• Integracja: pipeline CI/CD. Jednorazowy eksport nie spełnia ciągłego obowiązku.

Monitorowanie podatności

Zegar 24-godzinny startuje w momencie uzyskania świadomości, czyli rozsądnej pewności na podstawie wstępnej oceny. Potwierdzenie kryminalistyczne nie jest wymagane do uruchomienia zegara. Monitorowanie powinno być w stanie wytworzyć tę wstępną ocenę przed upływem terminu.

• Subskrybuj NVD, OSV i odpowiednie komunikaty dostawców dla używanego stosu komponentów.
• Zautomatyzuj skanowanie komponentów z SBOM.
• Udokumentuj wewnętrzną ścieżkę eskalacji i przetestuj ją od końca do końca.
• Przygotuj szablony powiadomień teraz, zanim platforma ENISA zostanie uruchomiona.

Lista kontrolna przed wrześniem 2026 r.

INWENTARZ PRODUKTÓW (zacznij tu, klasyfikacja decyduje o ścieżce oceny zgodności):
[ ] Pełna lista PDE sprzedawanych w UE z potwierdzoną klasyfikacją CRA dla każdego produktu
[ ] Istotna klasa I: nawiązany kontakt z jednostką oceniającą zgodność. Wyznaczanie jednostek
    notyfikowanych nie otworzy się przed czerwcem 2026 r.; czekanie do tego momentu przekracza grudzień 2027 r.
[ ] Zadeklarowany okres wsparcia zgodnie z oczekiwanym czasem użytkowania produktu (Artykuł 13 ust. 8)

SBOM (zacznij tu, zasila monitorowanie, dokumentację techniczną i zgłaszanie 24-godzinne):
[ ] Generowanie SBOM zintegrowane z pipeline'em CI/CD. Jednorazowy eksport nie wystarczy.
[ ] Format ustandaryzowany: CycloneDX lub SPDX
[ ] Zweryfikowane pokrycie zależności przechodnich. Same zależności bezpośrednie nie wystarczą.
[ ] SBOM-y z kontrolą wersji, powiązane z konkretnymi wydaniami produktu

MONITOROWANIE PODATNOŚCI (musi być aktywne przed 11 września):
[ ] Aktywne monitorowanie wszystkich produktów: NVD, OSV, komunikaty dostawców
[ ] Automatyczne skanowanie SBOM uruchomione
[ ] Wewnętrzna ścieżka eskalacji udokumentowana i przetestowana od końca do końca
[ ] Pokrycie 24/7 potwierdzone, z uwzględnieniem ścieżek eskalacji w święta i weekendy

PRZYGOTOWANIE DO ZGŁASZANIA (platforma ENISA jeszcze nie działa, przygotuj wszystko inne teraz):
[ ] Szablony 24h, 72h, 14-dniowy dla podatności i miesięczny dla incydentu przygotowane zgodnie z Artykułem 14
[ ] Zidentyfikowany koordynator CSIRT państwa członkowskiego
[ ] Osoba upoważniona do uruchomienia powiadomienia 24-godzinnego, dostępna całą dobę

DOKUMENTACJA:
[ ] Dokumentacja techniczna skontrolowana pod kątem Załącznika VII
[ ] Analiza luk zakończona
[ ] Ocena ryzyka w toku

Artykuł 14: czego wymaga zgłaszanie od 11 września 2026 r.

Od 11 września 2026 r. producent musi zgłaszać aktywnie wykorzystywane podatności i poważne incydenty do dwóch miejsc jednocześnie: do koordynatora CSIRT wyznaczonego przez państwo członkowskie oraz do ENISA za pośrednictwem Jednolitej Platformy Zgłaszania (Artykuł 16).

Wyjątek dla MŚP: Artykuł 64 ust. 10 lit. a zwalnia mikroprzedsiębiorstwa i małe przedsiębiorstwa z grzywien za przekroczenie wymagań czasowych z Artykułu 14 ust. 2 lit. a oraz Artykułu 14 ust. 4 lit. a. Wyjątek obejmuje wyłącznie wymagania czasowe. Sam obowiązek zgłaszania nadal obowiązuje.

Co oznacza „aktywnie wykorzystywana"

Artykuł 14 ust. 2 lit. a stosuje się, gdy istnieje wiarygodny dowód na to, że podmiot zagrożeń wykorzystał podatność w systemie bez zgody właściciela. Wskaźniki obejmują:

• Potwierdzone ataki w środowisku naturalnym.
• Wykorzystywanie zgłoszone w kanałach informacji o zagrożeniach lub przez badaczy bezpieczeństwa.
• Wykrycie w honeypotach z dowodem aktywnego wdrożenia.

Projekt wytycznych Komisji (Ares(2026)2319816, 3 marca 2026 r.) stosuje standard „wiarygodnego dowodu aktywnego wykorzystywania", który jest niższy niż wymóg potwierdzenia kryminalistycznego.

Lista kontrolna gotowości Fazy 2

INFRASTRUKTURA ZGŁASZANIA (przed 11 września 2026 r.):
[ ] Szablony powiadomień przygotowane: formaty 24h, 72h, 14-dniowy dla podatności i miesięczny dla incydentu
[ ] Zidentyfikowany koordynator CSIRT państwa członkowskiego. To główny punkt zgłaszania
    obok ENISA.
[ ] Potwierdzona ścieżka eskalacji 24/7, z pokryciem świąt i kontaktami zapasowymi
[ ] Zakończony przegląd prawny obowiązków z Artykułu 14

ZARZĄDZANIE PODATNOŚCIAMI:
[ ] Aktywne monitorowanie operacyjne dla wszystkich produktów
[ ] Integracja CVE/NVD na żywo
[ ] Gotowe szablony powiadomień dla klientów

GOTOWOŚĆ ZESPOŁU:
[ ] Zespół ds. bezpieczeństwa przeszkolony z obowiązków Artykułu 14 i czterostopniowego harmonogramu
[ ] Eskalacja do kierownictwa udokumentowana
[ ] Zespół prawny poinformowany o obowiązkach zgłaszania
[ ] Komunikacja przygotowana na publiczne ujawnienia

Pełna zgodność do 11 grudnia 2027 r.

Zasadnicze wymagania cyberbezpieczeństwa (Załącznik I)

Każdy zgodny PDE musi spełniać te wymagania:

Bezpieczeństwo na etapie projektowania

• Poziom bezpieczeństwa odpowiedni do ryzyka produktu (Załącznik I, Część I, §1).
• Ochrona przed nieautoryzowanym dostępem.
• Poufność, integralność i dostępność danych oraz funkcji zasadniczych.
• Minimalna powierzchnia ataku, bezpieczne ustawienia domyślne, brak zakodowanych na stałe danych uwierzytelniających.

Zarządzanie podatnościami

• Udokumentowany proces identyfikowania i usuwania podatności.
• Terminowe, bezpłatne aktualizacje zabezpieczeń w okresie wsparcia.
• Polityka skoordynowanego ujawniania podatności (Artykuł 13 ust. 6).

Możliwość aktualizacji

• Bezpieczny, niezawodny mechanizm aktualizacji.
• Możliwość oddzielenia aktualizacji zabezpieczeń od aktualizacji funkcjonalnych.

Dokumentacja techniczna (Załącznik VII)

Okres wsparcia: dwa odrębne obowiązki

CRA nakłada dwa odrębne obowiązki dotyczące aktualizacji zabezpieczeń.

Artykuł 13 ust. 8: producent musi wydawać aktualizacje zabezpieczeń przez minimum pięć lat od daty wprowadzenia produktu do obrotu lub przez oczekiwany czas użytkowania produktu, jeśli jest krótszy. Pięć lat to dolna granica, nie wartość domyślna. Produkt o 10-letnim oczekiwanym czasie użytkowania wymaga 10-letniego zobowiązania wsparcia.

Artykuł 13 ust. 9: każda wydana aktualizacja zabezpieczeń musi pozostać dostępna do pobrania przez minimum 10 lat od daty wydania lub przez pozostały czas trwania okresu wsparcia, w zależności od tego, który okres jest dłuższy.

To odrębne obowiązki. Aktualizacja wydana w czwartym roku pięcioletniego okresu wsparcia musi pozostać dostępna do pobrania do czternastego roku od jej wydania. Producent, który usuwa stare pakiety aktualizacji lub dopuszcza do zaniku infrastruktury dystrybucji, narusza Artykuł 13 ust. 9, nawet jeśli w dalszym ciągu wydaje nowe aktualizacje zgodnie z harmonogramem. Zaplanuj infrastrukturę przechowywania i dystrybucji na długi okres przed wydaniem pierwszej aktualizacji w ramach CRA.

Lista kontrolna grudnia 2027 r.

ZGODNOŚĆ PRODUKTU:
[ ] Wszystkie produkty spełniają wymagania Załącznika I: bezpieczeństwo na etapie projektowania,
    zarządzanie podatnościami i możliwość aktualizacji
[ ] Oceny zgodności zakończone: proces jednostki notyfikowanej dla Istotnej klasy I i klasy II
[ ] Umieszczone oznakowanie CE
[ ] Przygotowana deklaracja zgodności UE zgodnie z Artykułem 28

DOKUMENTACJA TECHNICZNA (Załącznik VII):
[ ] Ocena ryzyka zakończona i udokumentowana
[ ] SBOM aktualny i zatwierdzony
[ ] Dowód zgodności zorganizowany i dostępny
[ ] Okres wsparcia zadeklarowany zgodnie z oczekiwanym czasem użytkowania z Artykułu 13 ust. 8

ŁAŃCUCH RYNKOWY:
[ ] Importerzy i dystrybutorzy poinformowani o swoich obowiązkach CRA
[ ] Dokumentacja skierowana do klientów zaktualizowana

OBOWIĄZKI CIĄGŁE:
[ ] Artykuł 13 ust. 8: aktywny proces aktualizacji zabezpieczeń przez cały okres wsparcia
[ ] Artykuł 13 ust. 9: infrastruktura dostępności aktualizacji gotowa na 10 lat od każdego wydania
[ ] Aktywne i przetestowane monitorowanie podatności
[ ] Reagowanie na incydenty ćwiczone co najmniej kwartalnie

Wytyczne Komisji: projekt z marca 2026 r.

Komisja opublikowała projekt komunikatu (Ares(2026)2319816) 3 marca 2026 r., liczący ok. 70 stron. Konsultacje interesariuszy zakończyły się 31 marca 2026 r. Dokument nie jest sfinalizowany. Końcowe wersje językowe są nadal oczekiwane. Pełne omówienie znajdziesz w naszym przewodniku po wytycznych Komisji CRA.

Kluczowe rozstrzygnięcia istotne dla harmonogramu:

Test RDPS dotyczący zakresu SaaS: oprogramowanie do zdalnego przetwarzania danych jest objęte zakresem CRA tylko wtedy, gdy spełnia trzy warunki. Oprogramowanie wykonuje zdalne przetwarzanie danych. Zdalne przetwarzanie jest niezbędne do podstawowej funkcji produktu. Producent kontroluje zdalne przetwarzanie. SaaS, który nie spełnia tego testu, pozostaje poza zakresem.

Produkty starszego typu: nie jest wymagana rekonstrukcja dokumentacji historycznej. Konieczna jest ocena ryzyka na chwilę obecną. Rodziny produktów mogą być grupowane do celów oceny ryzyka.

Aktualizacje oprogramowania: aktualizacja nie stanowi „istotnej modyfikacji" wymagającej nowej oceny zgodności, chyba że wprowadza nowe wektory zagrożeń lub zmienia zamierzone przeznaczenie produktu. Wytyczne zawierają test składający się z czterech pytań.

Zegar 24-godzinny: startuje w momencie uzyskania świadomości. Wystarczy rozsądna pewność na podstawie wstępnej oceny. Potwierdzenie kryminalistyczne nie jest wymagane.

Dolna granica okresu wsparcia: pięć lat to minimum, nie wartość domyślna. Okres wsparcia musi odzwierciedlać oczekiwany czas użytkowania produktu.

Open source: publikowanie kodu źródłowego nie stanowi wprowadzenia produktu do obrotu. Współtwórcy, którzy nie kontrolują wydania gotowego produktu, nie są producentami w rozumieniu CRA.

Oficjalny komunikat: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act

Kary

Artykuł 64 ust. 2 Rozporządzenia (UE) 2024/2847 ustanawia karę najwyższego stopnia w wysokości 15 milionów EUR lub 2,5% całkowitego rocznego światowego obrotu, w zależności od tego, która wartość jest wyższa, za:

• Niezgodność z zasadniczymi wymaganiami cyberbezpieczeństwa z Załącznika I i obowiązkami z Artykułu 13.
• Niewykonanie obowiązków z Artykułu 14 (zgłaszanie podatności i incydentów).

Oba naruszenia podlegają tej samej kategorii kar. Nie istnieje niższa kategoria dla naruszeń obowiązku zgłaszania.

Artykuł 64 ust. 3 (10 milionów EUR lub 2%) obejmuje odrębny zestaw obowiązków: Artykuły 18-23, 28, 30-33, 39, 41, 47, 49, 53. Dotyczą one przede wszystkim importerów, dystrybutorów i jednostek notyfikowanych. Artykuł 14 nie znajduje się na tej liście.

Wyjątek dla MŚP: Artykuł 64 ust. 10 lit. a zwalnia mikroprzedsiębiorstwa i małe przedsiębiorstwa z grzywien za przekroczenie konkretnych wymagań czasowych z Artykułu 14 ust. 2 lit. a oraz Artykułu 14 ust. 4 lit. a. Wyjątek dotyczy wymagań czasowych, a nie merytorycznego obowiązku zgłaszania.

Uwagi branżowe

Elektronika konsumencka

Automatyzacja SBOM to inwestycja o najwyższej wartości na wczesnym etapie. Zasila bezpośrednio monitorowanie podatności i generowanie dokumentacji technicznej. Produkty konsumenckie mają zazwyczaj złożone łańcuchy dostaw z wieloma dostawcami komponentów.

Zarządzanie aktualizacjami oprogramowania sprzętowego w dużych populacjach urządzeń wymaga infrastruktury OTA. Aktualizacja wydana w trzecim roku życia produktu musi pozostać dostępna do pobrania przez 10 lat od daty wydania (Artykuł 13 ust. 9). Zaplanuj infrastrukturę dystrybucji teraz, nie w momencie wydania.

Wydawcy oprogramowania

Zgłaszanie podatności to najbardziej operacyjnie wymagający obowiązek dla produktów programowych. Częstotliwość wykrywania jest wyższa, a śledzenie zależności na poziomie przechodnim we współczesnych stosach nie jest trywialne. Zintegruj generowanie SBOM z istniejącymi pipeline'ami CI/CD. Zasila to bezpośrednio przepływ monitorowania i reagowania.

Sprzęt przemysłowy

Długie cykle życia produktów (10 do 20 lat) kolidują bezpośrednio z 5-letnią dolną granicą wsparcia (Artykuł 13 ust. 8) oraz 10-letnim wymogiem dostępności aktualizacji na każde wydanie (Artykuł 13 ust. 9). Produkt z 20-letnim oczekiwanym czasem użytkowania może wymagać 20-letniego zobowiązania wsparcia.

Produkty przemysłowe często należą do Istotnej klasy I lub klasy II, co dziś oznacza ocenę przez jednostkę notyfikowaną. Nawiąż kontakt z jednostkami oceniającymi zgodność teraz. Formalny proces wyznaczania jednostek notyfikowanych otwiera się po czerwcu 2026 r., a przepustowość będzie ograniczona co najmniej do grudnia 2026 r.

Urządzenia IoT

Eliminacja domyślnych danych uwierzytelniających to bezwzględny wymóg (Załącznik I, Część I, §2 lit. e). Zajmij się tym w pierwszej kolejności. To oczywiste naruszenie Załącznika I i stosunkowo łatwe do naprawienia w porównaniu ze zmianami architektonicznymi. Bezpieczne mechanizmy aktualizacji dla urządzeń o ograniczonych zasobach wymagają więcej pracy. Zacznij od danych uwierzytelniających, potem przejdź do aktualizacji.