Cyber Resilience Act od września 2026 — co muszą zrobić producenci software i hardware w Polsce

Po NIS2 i KSC 2.0 na polskich producentów software i hardware czeka kolejna fala obowiązków: Cyber Resilience Act (CRA) — rozporządzenie UE, którego pierwsze wymogi zaczynają obowiązywać już we wrześniu 2026. To nie jest „kolejny NIS2" — CRA dotyczy produktów, nie procesów. Jeśli sprzedajesz w UE oprogramowanie, urządzenie IoT, sterownik przemysłowy, kontroler IoT, biblioteki SDK lub jakikolwiek produkt z elementami cyfrowymi (PDE), regulacja dotyczy Cię bezpośrednio — niezależnie od tego, czy jesteś producentem, importerem czy dystrybutorem.

W tym artykule wyjaśniamy, kogo CRA dotyczy, jakie obowiązki ruszają jako pierwsze, czym akt różni się od NIS2 oraz jak partner data center pomaga skrócić drogę do zgodności w czasie, który już zaczyna się kurczyć.

Czym jest Cyber Resilience Act i dlaczego dotyczy Twojej firmy

CRA to unijne rozporządzenie horyzontalne, które wprowadza wymogi cyberbezpieczeństwa dla wszystkich produktów z elementami cyfrowymi sprzedawanych w UE. W odróżnieniu od NIS2 (która adresuje procesy w firmach uznanych za kluczowe lub ważne), CRA reguluje produkt przez cały jego cykl życia — od projektu, przez wprowadzenie na rynek, po wsparcie i wycofanie.

W praktyce „produkt z elementami cyfrowymi" to bardzo szeroka kategoria:

• aplikacje desktopowe i mobilne,
• oprogramowanie SaaS dystrybuowane jako produkt,
• sterowniki sprzętowe, firmware, BIOS,
• urządzenia IoT i Smart Home,
• kontrolery przemysłowe (PLC/RTU),
• biblioteki open-source dystrybuowane komercyjnie,
• routery, kamery, drukarki, sprzęt sieciowy.

Jeśli Twoja firma cokolwiek z powyższych projektuje, integruje lub sprzedaje pod własną marką — CRA dotyczy Cię bezpośrednio.

Pierwsze obowiązki startują we wrześniu 2026

CRA wchodzi w życie etapami. Pierwsza fala obowiązków — i ta, która już dziś powinna trafić na agendę zarządu — to obowiązek zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów bezpieczeństwa.

Po wejściu w życie pierwszej fazy producent musi:

1. Zgłosić do ENISA (przez krajowy CSIRT — w Polsce CSIRT NASK) każdą aktywnie wykorzystywaną podatność w ciągu ściśle określonych terminów — pierwszy raport „wczesny" w bardzo krótkim oknie, kolejne aktualizacje w ciągu kolejnych dni.
2. Zgłosić poważny incydent bezpieczeństwa, który wpływa na bezpieczeństwo produktu — niezależnie od tego, czy incydent dotknął tylko jednego klienta, czy szerszej bazy.
3. Powiadomić użytkowników o znanej, aktywnie wykorzystywanej podatności i udostępnić — bez nieuzasadnionej zwłoki — środki naprawcze (patch, mitigation, advisory).

Kolejne wymogi — pełna deklaracja zgodności, znak CE dla cyberbezpieczeństwa, dokumentacja techniczna, polityka wsparcia bezpieczeństwa przez minimalny okres po sprzedaży — wchodzą w życie w późniejszym terminie. Ale gotowość operacyjna do raportowania w 24 godzinach musi być na miejscu już we wrześniu 2026.

Czym CRA różni się od NIS2, KSC 2.0 i DORA

Wiele firm zaczyna mylić te akty — co w praktyce kończy się tym, że spełnia się formalnie jeden, a tworzy luki w innym. Krótko:

• NIS2 (w PL: KSC 2.0) — reguluje procesy zarządzania ryzykiem w organizacjach uznanych za podmioty kluczowe lub ważne. Dotyczy operatora usługi, nie produktu.
• DORA — reguluje odporność operacyjną sektora finansowego (banki, ubezpieczenia, brokerzy kryptoaktywów). Wymogi nakłada na instytucję finansową i jej dostawców ICT.
• CRA — reguluje produkt z elementami cyfrowymi. Nakłada wymogi na producenta, importera, dystrybutora — niezależnie od sektora.

W praktyce wielu firm będzie podlegać dwóm lub trzem aktom jednocześnie. Producent sprzętu sieciowego sprzedawany do banków będzie objęty CRA (jako producent), a jego klient — DORA i NIS2.

Co musisz przygotować w najbliższych 3 miesiącach

Realistycznie do września 2026 firma powinna mieć uruchomione co najmniej:

• Inwentaryzację portfolio produktowego — które produkty to PDE? Czy są wprowadzane na rynek UE? Pod jaką marką?
• Proces obsługi podatności (vulnerability handling) — kanał zgłoszeń (PSIRT, security@), klasyfikację, SLA na patch, koordynację disclosure z badaczami i CSIRT-em.
• Kanał komunikacji z użytkownikami — security advisory, mailing, RSS, podpisane CSAF/VEX dla profesjonalnych odbiorców.
• Telemetrię produktową — bez monitoringu nie zauważysz, że jakaś podatność jest aktywnie wykorzystywana. Bez tego rozkład raportów jest praktycznie zerowy.
• Procedurę raportowania incydentów — kto, w jakim narzędziu, w jakim czasie, do jakiego CSIRT-u.
• Dokumentację techniczną dla CE — SBOM, ocena ryzyka, ślady testów bezpieczeństwa.

Każdy z tych elementów wymaga infrastruktury — i tu zaczyna się rola partnera data center.

Jak partner data center wspiera zgodność z CRA

CRA wprowadza obowiązki organizacyjne i procesowe, ale realizujesz je na infrastrukturze technicznej. Dobrze dobrany partner data center skraca drogę do zgodności kilkoma równoległymi liniami:

1. Bezpieczna infrastruktura dla środowisk dev / build / release. CI/CD, repozytoria kodu, build farm, signing infrastructure — każdy z tych komponentów musi spełniać wymogi bezpieczeństwa łańcucha dostaw oprogramowania. Kolokacja lub serwery dedykowane w polskim data center dają pełną kontrolę nad jurysdykcją, fizycznym dostępem i izolacją sieciową. Sprint Data Center prowadzi obiekt w Olsztynie z certyfikatem ISO 27001, AQAP 2110, WSK oraz Świadectwem Bezpieczeństwa Przemysłowego I stopnia ABW — to istotne, jeżeli Twoje produkty trafiają również do sektora obronnego lub administracji państwowej.

2. SOC 24/7 i monitoring podatności. Pierwsza fala CRA wymaga zdolności do raportowania w krótkich oknach — to nie zadziała bez stałego monitoringu. Sprint Tech / SOC w Sprint Data Center prowadzony jest przez własny zespół analityków bezpieczeństwa, pracuje w trybie 24/7 i obsługuje incydenty od detekcji po raportowanie.

3. Pentesty produktów i audyt zgodności. CRA nakłada obowiązek udokumentowanej oceny ryzyka i testów bezpieczeństwa. Sprint Data Center realizuje pentesty oparte na OWASP ASVS (aplikacje webowe i mobilne), IEC 62443 (systemy OT/SCADA, PLC, RTU) oraz testy infrastruktury kontenerowej (Docker, Kubernetes, OpenShift). Dla producentów OT i IoT to często najszybsza droga do zamknięcia luki dokumentacyjnej.

4. Audyty NIS2, DORA, KSC, ISO 27001, ISO 22301. Jeżeli już dziś prowadzisz proces zgodności z NIS2, większość kontroli technicznych pokrywa się z wymogami CRA — to dobry punkt startowy. Sprint Data Center realizuje audyty NIS2 readiness, KSC, DORA oraz pełne certyfikacje ISO 27001 / 22301. Pojedynczy partner zamiast trzech różnych konsultantów to mniej silosów i krótszy łańcuch komunikacji.

5. Polska jurysdykcja, polski CSIRT. Raportowanie do ENISA odbywa się przez krajowy CSIRT — w Polsce to CSIRT NASK. Kiedy Twój zespół, dane operacyjne i partner techniczny są w tej samej jurysdykcji, droga komunikacji jest o rząd wielkości krótsza niż w modelu hyperscaler-w-USA + dostawca-w-Irlandii + krajowy regulator w Polsce.

Podsumowanie

Cyber Resilience Act to nie jest „NIS2 dla większych firm" — to równoległa regulacja produktowa, która od września 2026 dotknie każdej polskiej firmy sprzedającej w UE oprogramowanie, sprzęt lub usługi cyfrowe. Mniej niż cztery miesiące to mało jak na uruchomienie pełnego procesu obsługi podatności, monitoringu i raportowania od zera — ale wystarczająco, by przy wsparciu doświadczonego partnera data center zamknąć krytyczne luki przed pierwszym deadline’em.

Jeśli chcesz omówić, co Twoja firma musi przygotować, sprawdzić jak SOC i pentesty od Sprint Data Center wpisują się w Twój plan CRA, lub poprosić o ocenę gotowości — skontaktuj się z naszym zespołem lub zapoznaj się z naszą ofertą usług cyber-ochrony.

FAQ – najczęściej zadawane pytania o Cyber Resilience Act

Czy CRA dotyczy mojej firmy, jeżeli sprzedaję wyłącznie w Polsce?

Tak, jeżeli sprzedajesz w jakimkolwiek kraju UE — a Polska jest jego częścią. CRA stosuje się do produktów z elementami cyfrowymi wprowadzanych na rynek UE, niezależnie od kraju pochodzenia producenta. Sprzedaż w jednym kraju członkowskim wystarcza, aby Twój produkt podlegał wymogom rozporządzenia.

Czy CRA dotyczy oprogramowania open-source?

Co do zasady nie — CRA wprowadza zwolnienie dla niekomercyjnego rozwoju open-source. Jeżeli jednak Twoja firma dystrybuuje open-source jako produkt komercyjny (np. wsparcie płatne, wersja enterprise, integracja na zamówienie), regulacja może objąć tę aktywność. Tu szczegóły zależą od konkretnego modelu biznesowego — w razie wątpliwości warto poprosić o opinię prawną.

Czym CRA różni się od NIS2 i czy muszę spełnić obie regulacje?

NIS2 (i jej polska implementacja KSC 2.0) reguluje procesy w firmach uznanych za kluczowe lub ważne. CRA reguluje produkty z elementami cyfrowymi — niezależnie od wielkości firmy i sektora. Wielu producentów będzie objętych obiema regulacjami jednocześnie: NIS2 jako operator (jeżeli spełnia kryteria sektorowe) i CRA jako producent (jeżeli wprowadza PDE na rynek UE).

Jakie są pierwsze terminy CRA, na które muszę być gotowy?

Pierwsza fala obowiązków — zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów do ENISA (przez krajowy CSIRT) — wchodzi w życie we wrześniu 2026. Pełna stosowalność rozporządzenia (CE dla cyberbezpieczeństwa, deklaracja zgodności, dokumentacja techniczna, wsparcie po sprzedaży) ma miejsce w późniejszym terminie. Operacyjna gotowość do raportowania w krótkich oknach to absolutne minimum na wrzesień 2026.

Czy istniejący proces ISO 27001 i NIS2 wystarcza do zgodności z CRA?

Częściowo — ISO 27001 i NIS2 pokrywają większość kontroli technicznych i procesowych potrzebnych do CRA, więc nie zaczynasz od zera. Brakuje jednak komponentów produktowych: vulnerability handling skoncentrowanego na produkcie, PSIRT, kanału komunikacji z użytkownikami, SBOM i procedury CSAF/VEX. Te elementy trzeba dobudować nawet w organizacjach z dojrzałym SZBI.