Wielu producentów oprogramowania patrzy na Cyber Resilience Act przez pryzmat daty wejścia przepisów w życie. To błąd. Choć większość obowiązków zacznie obowiązywać od grudnia 2027 r., regulacja wymaga zmian, których nie da się wdrożyć w ostatniej chwili. CRA nie jest projektem compliance, lecz zmianą sposobu tworzenia i utrzymywania oprogramowania.
Największa zmiana dotyczy odpowiedzialności producenta. Do tej pory bezpieczeństwo produktu często kończyło się na jego premierze. Cyber Resilience Act odwraca tę logikę. Producent ma odpowiadać za bezpieczeństwo przez cały okres wsparcia produktu – od projektowania, przez rozwój i aktualizacje, aż po zarządzanie podatnościami i reagowanie na incydenty. W praktyce bezpieczeństwo staje się integralną cechą produktu, a nie dodatkiem oferowanym po wdrożeniu.
To właśnie dlatego czas staje się dziś najważniejszym zasobem. Przepisy można przeczytać w jeden dzień, ale nie da się w kilka miesięcy zbudować organizacji, która potrafi stale monitorować podatności, bezpiecznie dostarczać aktualizacje, prowadzić dokumentację techniczną i raportować poważne incydenty w wymaganych terminach. Od 11 września 2026 r. producenci będą musieli zgłaszać aktywnie wykorzystywane podatności i poważne incydenty bezpieczeństwa, a pierwsze zgłoszenie będzie trzeba wysłać już w ciągu 24 godzin od ich wykrycia.
To oznacza, że największym wyzwaniem nie będzie przygotowanie dokumentów, ale przebudowa procesu tworzenia oprogramowania. Secure by Design, zarządzanie podatnościami, Software Bill of Materials (SBOM), kontrola komponentów open source czy DevSecOps często są postrzegane jako osobne inicjatywy. CRA łączy je w jeden spójny proces. Jeśli firma nie ma dziś pełnej wiedzy o komponentach wykorzystywanych w swoich produktach, nie potrafi szybko ocenić wpływu nowo wykrytej podatności ani sprawnie dostarczyć poprawki bezpieczeństwa, problemem nie jest brak zgodności z regulacją. Problemem jest niedojrzałość procesu wytwarzania oprogramowania.
Wiele organizacji popełnia jeszcze jeden błąd – traktuje CRA jako zadanie działu prawnego lub zespołu cyberbezpieczeństwa. Tymczasem regulacja dotyka przede wszystkim zespołów produktowych, architektów, programistów, QA i DevOps. To oni będą odpowiadać za projektowanie bezpiecznych produktów, kontrolę zmian, zarządzanie zależnościami i utrzymanie bezpieczeństwa przez cały cykl życia rozwiązania. Z tego powodu wdrożenie CRA jest projektem transformacyjnym, a nie wyłącznie regulacyjnym.
Paradoksalnie właśnie tutaj kryje się największa szansa biznesowa. Organizacje, które rozpoczną przygotowania odpowiednio wcześnie, nie tylko ograniczą ryzyko związane z nowymi obowiązkami. Zyskają również lepszą kontrolę nad własnym oprogramowaniem, szybsze reagowanie na podatności, większą przewidywalność procesu rozwoju oraz wyższe zaufanie klientów. Gdy bezpieczeństwo staje się jednym z kryteriów wyboru dostawcy, może to okazać się równie ważne jak nowe funkcje produktu.
