# Jakie obowiązki nakłada Cyber Resilience Act na producentów oprogramowania? *Data publikacji: 2026-06-07 · obszar prawa: cyberbezpieczeństwo · Wersja HTML: https://lexedit.ai/odpowiedzi/cyber-resilience-act-producent-oprogramowania-obowiazki* ## 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](https://lexedit.ai/orzeczenia/i-ca-21-17/odpowiedzialnosc-producenta-za-niebezpieczna-maszyne-2113465)) 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](https://lexedit.ai/orzeczenia/c-887-24/wada-pily-tarczowej-narusza-wymogi-bezpieczenstwa-ue-3234892) 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](https://lexedit.ai/orzeczenia/ii-gsk-57-25/kara-za-niebezpieczne-kostki-do-lodu-881548)) 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. ## Źródła (orzeczenia) - [III CSK 261/07](https://lexedit.ai/orzeczenia/iii-csk-261-07/odpowiedzialnosc-producenta-wadliwa-dachowka-czyn-niedozwolony-641416) — Sąd Najwyższy — wyrok z 2008-02-27 > „wprowadzenie do obrotu materiałów budowlanych, które nie spełniają norm jakościowych jest zachowaniem zawinionym, rodzącym odpowiedzialność za szkodę opartą na art. 415 k.c." - [I Ca 21/17](https://lexedit.ai/orzeczenia/i-ca-21-17/odpowiedzialnosc-producenta-za-niebezpieczna-maszyne-2113465) — Sąd Okręgowy w Sieradzu — wyrok z 2017-02-22 > „producent powinien przewidzieć także niewłaściwe użycie maszyny, które może wynikać z dających się łatwo przewidzieć ludzkich zachowań" - [C-887/24](https://lexedit.ai/orzeczenia/c-887-24/wada-pily-tarczowej-narusza-wymogi-bezpieczenstwa-ue-3234892) — Trybunał Sprawiedliwości — wyrok z 2026-04-23 - [II GSK 57/25](https://lexedit.ai/orzeczenia/ii-gsk-57-25/kara-za-niebezpieczne-kostki-do-lodu-881548) — Naczelny Sąd Administracyjny — wyrok z 2025-07-10 > „delikt, za który wymierzono skarżącej karę pieniężną, polega na samym tylko wprowadzeniu na rynek produktu niespełniającego wymagań bezpieczeństwa" - [C-264/21](https://lexedit.ai/orzeczenia/c-264-21/odpowiedzialnosc-producenta-znak-towarowy-dyrektywa-ue-3121012) — Trybunał Sprawiedliwości Unii Europejskiej — wyrok z 2022-07-07 --- **Lexedit** — agent AI do researchu prawnego po polskim prawie: 1,4 mln orzeczeń (SN, NSA, WSA, sądy apelacyjne), 100 tys. aktów prawnych z wersjami historycznymi. Każde cytowanie w memo jest klikalne i weryfikowane względem treści źródła. Wypróbuj: https://lexedit.ai/research Więcej odpowiedzi: https://lexedit.ai/odpowiedzi · Indeks dla agentów AI: https://lexedit.ai/llms.txt