Czy CRA dotyczy produktów wprowadzonych przed 11 września 2026?
Tak — wcześniejsze wprowadzenie produktu na rynek nie daje automatycznego wyłączenia z art. 14. Od 11 września 2026 r. producent ma zgłaszać aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktu, jeżeli produkt i zdarzenie spełniają przesłanki CRA.
11 września 2026 r. nie jest jednak ogólną datą graniczną dla wszystkich wymagań wobec starszych produktów. Główne przepisy CRA zaczynają być stosowane 11 grudnia 2027 r., a art. 69 zawiera dla produktów wprowadzonych wcześniej odrębną regułę dotyczącą substantial modification.
11 września 2026 i 11 grudnia 2027 — dwie różne granice
Najczęstszy błąd polega na potraktowaniu jednej z tych dat jako uniwersalnego początku albo końca obowiązków. CRA rozdziela wcześniejsze stosowanie reportingu od pełnego stosowania głównych wymagań produktowych.
| Data | Co się zmienia | Znaczenie dla legacy products |
|---|---|---|
| Przed 11.09.2026 | Trwa przygotowanie do stosowania art. 14 | ustal portfolio, role, kanały intake, właścicieli i dane potrzebne do zgłoszenia |
| Od 11.09.2026 | Stosuje się obowiązki reportingowe z art. 14 | właściwe starsze produkty trzeba uwzględnić w procesie wykrywania, triage i zgłoszeń |
| Przed 11.12.2027 | Produkt został wprowadzony przed pełnym stosowaniem głównych przepisów | art. 69 przewiduje regułę przejściową, ale osobno pozostaje reporting z art. 14 |
| Od 11.12.2027 | Zaczynają być stosowane główne przepisy CRA | produkt wprowadzony wcześniej podlega tym wymaganiom, jeżeli od tej daty przejdzie substantial modification; art. 14 stosuje się odrębnie |
Co od 11 września 2026 trzeba objąć procesem Article 14?
Obowiązek nie polega na zgłoszeniu samego produktu ani całej listy historycznych CVE. Triggerem jest uzyskanie przez producenta wiedzy o aktywnie wykorzystywanej podatności albo poważnym incydencie wpływającym na bezpieczeństwo właściwego produktu z elementami cyfrowymi.
- early warning bez zbędnej zwłoki, nie później niż w 24 godziny od uzyskania wiedzy
- główne zgłoszenie bez zbędnej zwłoki, nie później niż w 72 godziny
- final report według odrębnej reguły dla podatności i poważnego incydentu
- zgłoszenie przez CRA Single Reporting Platform ustanowioną przez ENISA
- udokumentowany human triage dla konkretnego produktu, wersji i zdarzenia
Które starsze produkty trzeba odnaleźć w portfolio?
Punktem wyjścia nie jest etykieta „legacy”, lecz tożsamość produktu i jego obecność na rynku UE. Zakres trzeba potwierdzić dla konkretnego hardware, software, firmware, komponentu i związanego z nim remote data processing.
- produkty nadal sprzedawane, licencjonowane albo dostarczane klientom
- zainstalowana baza urządzeń i oprogramowania pozostająca w użyciu
- wspierane wersje on-premise oraz customer-specific releases
- forki, custom modules i backporty utrzymywane dla poszczególnych klientów
- komponenty wprowadzane oddzielnie na rynek UE
- produkty end-of-sale, dla których nadal mogą pojawić się informacje o podatnościach lub incydentach
Minimalny rejestr dla produktu wprowadzonego wcześniej
- dokładna nazwa produktu, wariantu i producenta
- data oraz evidence pierwszego wprowadzenia do obrotu w UE
- status dalszego udostępniania, end-of-sale i support period
- aktywne releases, customer deployments i baza zainstalowana
- repozytorium, utrzymywalny kod lub firmware oraz mechanizm aktualizacji
- SBOM przypisany do konkretnego wydania lub udokumentowany brak SBOM
- właściciel Security Intake i Article 14 Review
- chronologia triage, remediation, komunikacji oraz zgłoszeń
Co zmienia substantial modification po 11 grudnia 2027?
Art. 69 ust. 2 wskazuje, że produkty wprowadzone do obrotu przed 11 grudnia 2027 r. podlegają wymaganiom CRA, jeżeli od tej daty zostaną poddane substantial modification. Ocena wymaga zbadania konkretnej zmiany, a nie tylko numeru wersji lub daty wydania.
Wyłączenie interfejsu, dodanie modułu, backport, większa zmiana architektury albo customizacja klientowska powinny prowadzić do udokumentowanego Change Assessment. Sam status maintenance-only, end-of-sale lub brak nowych funkcji nie stanowi automatycznej odpowiedzi.
Po analizie daty wybierz strategię dla produktu
| Strategia | Co oznacza operacyjnie | Następny krok |
|---|---|---|
| NEEDS_DECISION | brakuje właściciela, daty lub evidence | pozostaw jawne UNKNOWN i uzupełnij fakty |
| REMEDIATE | produkt ma być dalej rozwijany lub wspierany | Release → SBOM/CVE/VEX → remediation → rollout |
| FEATURE_REDUCTION_REVIEW | rozważane jest ograniczenie interfejsu lub funkcji | utwórz Change Assessment i oceń wpływ na cyberbezpieczeństwo |
| MAINTENANCE_ONLY | ograniczony rozwój przy jawnym modelu wsparcia | zapisz wspierane wersje, okres wsparcia i mechanizm aktualizacji |
| REPLACE | planowana jest migracja do nowszego produktu | wskaż produkt docelowy i odpowiedzialność za okres przejściowy |
| EU_MARKET_EXIT_REVIEW | analizowane jest zakończenie przyszłego oferowania w UE | przeprowadź przegląd biznesowy i prawny bez usuwania historii produktu |
Jak udokumentować wynik analizy?
Rekord powinien wskazywać dokładny produkt, releases i deployment revisions, daty rynkowe, stan wsparcia, ownera, wybraną strategię, uzasadnienie i wersje dowodów. Zmiana decyzji powinna tworzyć następną wersję, a nie nadpisywać wcześniejszą historię.
Przyjęcie rekordu do dokumentacji oznacza wyłącznie zakończenie wskazanego przeglądu operacyjnego. Nie jest opinią prawną, oceną zgodności, certyfikacją ani potwierdzeniem zgodności z CRA.
CRA i produkty sprzed 11 września 2026 — FAQ
Czy produkt wprowadzony przed 11 września 2026 r. trzeba zgłosić do ENISA?
Nie zgłasza się samego produktu tylko dlatego, że został wcześniej wprowadzony na rynek. Od 11 września 2026 r. zgłoszeniu podlegają aktywnie wykorzystywane podatności i poważne incydenty spełniające przesłanki art. 14 dla produktu znajdującego się w zakresie CRA.
Czy 11 września 2026 r. jest ogólną datą graniczną dla starych produktów?
Nie. Ta data rozpoczyna stosowanie obowiązków reportingowych z art. 14. Reguła przejściowa dla głównych wymagań produktowych odwołuje się do 11 grudnia 2027 r. i substantial modification od tej daty.
Czy każde CVE w starszym produkcie trzeba raportować?
Nie. Samo CVE, alert skanera lub obecność komponentu nie dowodzą aktywnego wykorzystania ani poważnego incydentu. Potrzebne jest human triage dla konkretnego produktu, wersji i faktów zdarzenia.
Czy reporting obejmuje produkt, którego nie sprzedajemy już od kilku lat?
Sam status end-of-sale nie tworzy automatycznego wyłączenia z art. 14. Trzeba potwierdzić zakres CRA, rolę producenta, tożsamość produktu oraz fakty podatności lub incydentu; art. 69 ust. 3 obejmuje właściwe produkty wprowadzone przed 11 grudnia 2027 r.
Co zmienia data 11 grudnia 2027 r.?
Od tego dnia zaczynają być stosowane główne przepisy CRA. Dla produktów wprowadzonych wcześniej art. 69 przewiduje zastosowanie tych wymagań, jeżeli od tej daty produkt zostanie poddany substantial modification. Reporting z art. 14 stosuje się odrębnie od 11 września 2026 r.
Czy aktualizacja starego produktu jest substantial modification?
Nie każda aktualizacja. Wynik zależy od wpływu zmiany na przeznaczenie produktu i poziom ryzyka cyberbezpieczeństwa. Ocena powinna dotyczyć konkretnej zmiany i zostać udokumentowana.
Oficjalne źródła
Podstawa materiału została sprawdzona 12 września 2026.