Krótka odpowiedź (TL;DR)
Cyber Resilience Act obejmuje produkty z elementami cyfrowymi, czyli sprzęt i oprogramowanie udostępniane na rynku UE. Pełne wymagania zaczną obowiązywać 11 grudnia 2027 r., ale obowiązki raportowania aktywnie wykorzystywanych podatności i poważnych incydentów bezpieczeństwa ruszają już 11 września 2026 r.
1. Oprogramowanie staje się produktem regulowanym
CRA zmienia intuicję wielu firm software'owych. Aplikacja, firmware, biblioteka, urządzenie IoT albo komponent cyfrowy nie jest tylko usługą utrzymywaną w backlogu. W wielu przypadkach staje się produktem z wymaganiami cyberbezpieczeństwa, dokumentacją techniczną, oceną zgodności i obowiązkiem reagowania na podatności.
W orzecznictwie produktowym od lat widać, że producent odpowiada za przewidywalne użycie. W „producent powinien przewidzieć także niewłaściwe użycie maszyny" → I Ca 21/17 sąd wymagał przewidywania łatwych do przewidzenia zachowań użytkowników. W CRA ta sama myśl dotyczy cyber: trzeba przewidzieć realne scenariusze ataku, a nie tylko idealne użycie systemu.
2. Raportowanie podatności zaczyna się wcześniej niż pełna zgodność
Najbliższy termin to 11 września 2026 r. Od tej daty producenci będą musieli raportować aktywnie wykorzystywane podatności i poważne incydenty wpływające na bezpieczeństwo produktów z elementami cyfrowymi. To wymaga procesu vulnerability handling: kanału zgłoszeń, triage, oceny wpływu, decyzji o poprawce, komunikacji z użytkownikami i śladu audytowego.
Nie wystarczy adres security@. Potrzebna jest procedura, kto ocenia CVE, kto decyduje o zgłoszeniu, kto publikuje advisory i jak długo produkt dostaje aktualizacje bezpieczeństwa.
3. Aktualizacje bezpieczeństwa są częścią odpowiedzialności
CRA łączy się z nową dyrektywą produktową i GPSR: cykl życia produktu nie kończy się w dniu sprzedaży. TSUE w C-887/24 oceniał wadę bezpieczeństwa piły tarczowej przez pryzmat funkcji ochronnej. W oprogramowaniu odpowiednikiem osłony i awaryjnego wyłącznika są poprawki bezpieczeństwa, bezpieczne ustawienia domyślne i odporność na znane klasy podatności.
NSA w „delikt polega na samym tylko wprowadzeniu na rynek produktu niespełniającego wymagań bezpieczeństwa" → II GSK 57/25 przypomniał, że naruszenie może istnieć już przez samo wprowadzenie produktu niespełniającego wymagań. Po CRA podobnie może być z produktem cyfrowym bez podstawowej higieny bezpieczeństwa.
4. Najciekawszy take: compliance zaczyna się w repozytorium
Najlepsze dowody zgodności nie powstaną w Wordzie. Powstaną w procesie developmentu: SBOM, review zależności, podpisywanie wydań, testy bezpieczeństwa, polityka aktualizacji, changelog podatności i dokumentacja decyzji ryzyka. CRA może więc mocno zbliżyć prawników, product security i DevOps.
Praktyczna lista kontrolna
- zrób katalog produktów z elementami cyfrowymi, bibliotek, firmware i komponentów open source.
- wdroż SBOM, proces zgłaszania podatności i publiczny kanał kontaktu security.
- opisz politykę aktualizacji bezpieczeństwa, w tym minimalny okres wsparcia produktu.
- ustal procedurę raportowania aktywnie wykorzystywanych podatności od 11 września 2026 r..
- połącz release management z oceną zgodności, dokumentacją techniczną i historią poprawek.
Najczęstszy błąd
Najczęstszy błąd to oddzielenie compliance od procesu wydawniczego. Jeżeli zespół prawny nie widzi zależności open source, terminów wsparcia i podatności, dokumentacja zgodności będzie spóźniona.
Źródła
Cyber Resilience Act, rozporządzenie (UE) 2024/2847; terminy 11 września 2026 r. i 11 grudnia 2027 r.; orzecznictwo produktowe SN, NSA i TSUE.