Cyber Resilience Act (CRA) 2026–2027: какво вече знаем, какво все още липсва и как реално да подготвим продукта — преди да се появят хармонизирани стандарти

Какво знаем със сигурност към днешна дата (и защо това не е „тема за 2027“)

Cyber Resilience Act може да изглежда като поредния документ „от Брюксел“, който може да се остави за по-късно. Това е естествена реакция, особено когато компанията работи в ритъма на проектите: прототип, внедряване, серийно производство, сервиз. Регулациите често идват като „финално изискване“ — нещо, което се довършва накрая. CRA променя тази логика, защото не се отнася само до това, което се вижда в продукта в деня на продажбата. Отнася се до това дали производителят може да поддържа сигурността на продукта във времето и да докаже, че го е направил съзнателно, а не случайно.

Най-важният факт е прост, но със стратегически последствия: CRA е продуктова регулация, вградена в механиката на пазара на ЕС (включително маркировката CE). Европейската комисия изрично посочва, че продуктите следва да носят маркировка CE като сигнал за съответствие с CRA, а прилагането се осъществява от органите за надзор на пазара. Следователно това не е „ИТ стандарт“, който може да се третира като вътрешна програма за подобрение. Това е рамка, която влияе върху възможността за продажба.

Дати, които подреждат мисленето

В самия текст на Регламент (ЕС) 2024/2847 се вижда поетапно прилагане. CRA се прилага от 11 декември 2027, но с ясно посочени изключения. Член 14 (докладване) се прилага от 11 септември 2026, а главата за нотифицирането на органите за оценяване на съответствието (Глава IV) — от 11 юни 2026. Това са три дати, които си струва да се приемат като „етапни ориентири“, защото отговарят на три различни вида готовност: оперативна, институционална и продуктова.

Комисията го комуникира още по-просто: CRA е влязъл в сила на 10 декември 2024, основните задължения — от 11 декември 2027, а докладването — от 11 септември 2026. Ако някой в компанията казва „имаме време до 2027“, най-често има предвид проектните изисквания и оценяването на съответствието. Но докладването е по-рано и се отнася до събития, които не чакат графика.

Докладване: задължение, което налага процес (а не документ)

Изискването за докладване е добър лакмус, защото показва как CRA разбира „киберсигурността на продукта“. Това не е декларация за намерения или „политика“. Това е процес, който трябва да сработи в стресова ситуация: когато се появи активно експлоатирана уязвимост или сериозен инцидент.

Комисията го описва еднозначно: производителят трябва да докладва активно експлоатирани уязвимости и тежки инциденти, които влияят върху сигурността на продукта. Изисква се „ранно предупреждение“ в рамките на 24 часа от момента на узнаване, пълно уведомление в рамките на 72 часа, а финален доклад: до 14 дни след наличието на коригираща мярка за активно експлоатирани уязвимости и в рамките на един месец за тежки инциденти.

На практика това означава, че на организацията ѝ трябва нещо повече от чеклист. Нужен е механизъм, който да отговаря на три въпроса: откъде ще разберем, че проблемът съществува; кой квалифицира дали вече е „активно експлоатирано“ или „тежко“; и как ще организираме предаването на информация и корекцията в срок, който не оставя място за импровизация.

Ако по време на обученията настъпва хаос, често причината е, че CRA попада в празнината между ИТ и продукта. За ИТ „инцидент“ често е събитие в инфраструктурата. За производителя „инцидент“ е събитие, което засяга продукта при клиента — версията, конфигурацията, начина на внедряване. CRA налага свързването на тези два свята в една обща отговорност.

Какво обхваща CRA: продуктът като връзка с мрежата, а не „устройство на масата“

На практика, когато сме изучавали оценяване на риска при машини, сме научили, че рискът не е характеристика само на машината — той възниква във взаимодействието човек–машина. В CRA има подобно изместване на гледната точка: сигурността не съществува „в устройството“, а във връзката на продукта с цифровата среда, начина на използване и способността на производителя да реагира.

Комисията, обобщавайки CRA, обръща внимание на дефиницията за „продукти с цифрови елементи“ и на това, че задълженията за докладване се отнасят за всички такива продукти, предоставени на пазара на ЕС — включително тези, пуснати преди 11 декември 2027. Това е ключово уточнение, защото премахва един често срещан мит: „за старите продукти това не важи“. Докладването — важи.

Какво все още липсва (хармонизирани стандарти) и защо това не бива да парализира

В разговорите за CRA често се появява фразата: „още няма хармонизирани стандарти, значи не може да се действа“. Звучи логично, но тук има скрит капан. Хармонизираните стандарти са инструмент, който улеснява доказването на съответствие (презумпция за съответствие), но не са единственият път към реална безопасност на продукта. И не са условие, за да започнеш да проектираш правилно.

Комисията директно води темата за стандартите през страницата „CRA Standardisation“ и съобщава, че е приела искане за стандартизация M/606, който обхваща пакет от 41 стандарта в подкрепа на CRA — както хоризонтални, така и вертикални (продуктови). Това е важно, защото показва, че ЕС разбира пазарния проблем: без стандарти компаниите ще изграждат съответствие всяка по свой начин, а пазарният надзор ще има по-трудна задача.

Хоризонтални и вертикални стандарти: какво означава това за производителя

Накратко:

• хоризонталните стандарти трябва да описват „как“ да се изгражда и поддържа безопасността на продукта независимо от категорията (процеси, методи, подход, основан на риска),
• вертикалните стандарти трябва да конкретизират изискванията за определени класове продукти (там, където рисковете и архитектурите са типични).

Това разграничение има практични последици. Ако разработваш индустриален продукт, при който част от средата е „OT“ и жизненият цикъл е дълъг, ще ти трябват стандарти, които не са писани за SaaS приложение. И точно затова вертикалните стандарти са важни: те помагат да се слезе от нивото на общите принципи до това какво да се контролира в реални архитектури.

График на работата: стандартите ще идват поетапно, а не „в пакет преди 2027“

Комисията в материалите за прилагането на CRA показва, че CRA се въвежда поетапно, а стандартите трябва да подкрепят този процес във времето. На ниво факти, които днес са сигурни: имаме формално приет регламент и имаме задействан механизъм за стандартизация (M/606).

Най-важното за практиката е да се разбере едно изречение: дори когато стандартът бъде разработен от организациите по стандартизация, „презумпция за съответствие“ в правния смисъл възниква едва когато позоваването на стандарта бъде публикувано като хармонизиран стандарт в Официалния вестник на ЕС. Това е механизъм, общ за подхода на ЕС към хармонизацията: стандартите са мост между правото и инженерната практика, но този мост трябва формално да бъде „признат“ от ЕС.

От гледна точка на производителя това означава, че 2026–2027 ще бъдат период, в който част от фирмите ще работят на база собствени методи за доказване на съответствие (подход, основан на риска + доказателства), а друга част вече ще се „мапва“ към появяващите се стандарти. И това е нормално.

„Липса на стандарти“ не означава „липса на задължение“ — означава по-голяма тежест на доказателствата

Тук се появява важна последица: ако няма стандарти, които дават най-лесния път за доказване на съответствие, нараства значението на това, което в одитната практика винаги е решаващо: последователна следа на вземаните решения.

Какви рискове оценихме? Кои сценарии приехме за реалистични? Как подбрахме защитните мерки? Как управляваме уязвимостите? Колко дълго поддържаме продукта? Как информираме клиента? CRA не изисква производителят „да отгатва бъдещите EN стандарти“. Изисква производителят да може да покаже, че решенията му не са били случайни, а основани на риска и на най-добрите налични практики.

Как реално да подготвиш продукт за CRA (пътна карта за производителя и интегратора)

Най-голямата стойност на CRA е, че налага зрелост: киберсигурността престава да бъде добавка към продукта и се превръща в негова присъща характеристика. Само че зрелостта не се ражда от декларации. Тя се ражда от процес, който е достатъчно прецизен, за да работи на практика, и достатъчно прост, за да не започне инженерният екип да го заобикаля.

При оценката на риска при машини най-добрите проектни решения се появяват, когато спрем да питаме „какви опасности има машината“ и започнем да питаме „в кои задачи и състояния човекът е изложен“. При CRA аналогично: спираме да питаме „какви уязвимости има продуктът“ и започваме да питаме „при какви условия продуктът става уязвим и какво производителят може да направи тогава“. Това изместване подрежда работата.

Стъпка 1: Дефинирай продукта като система (а не като устройство)

Започни с дефиниране на това какво в твоя случай е „продукт с цифрови елементи“. Не само хардуер и фърмуер, а и онова, което често се пропуска, защото не се побира в кутията: компоненти, библиотеки, механизми за актуализации, услуги, без които продуктът не изпълнява функцията си. В CRA това е важно, защото отговорността на производителя се отнася до това, което излиза на пазара като продукт — а не само до това, което е изработил механичният отдел.

Това е и първият момент, в който интеграторите трябва да бъдат честни със себе си: ако интегрираш компоненти и ги конфигурираш по начин, който създава „краен продукт“ в очите на клиента, ти не си само „внедрител“. Ти си съавтор на риска и съавтор на отговорността.

Стъпка 2: Направи оценката на риска по CRA така, че да е инструмент за вземане на решения

Не става дума за „матрица“ в слайдове. Става дума за оценка на риска, която води до проектни решения и може да се повтаря по един и същи начин.

На практика добрият подход към CRA започва с прост въпрос: какви са реалните сценарии на злоупотреба в средата на клиента, а не само в лабораторията? Кой има сервизен достъп? Как изглежда мрежата? Колко често актуализираме? Какви са последствията от престой? В индустрията тези въпроси са по-неудобни, отколкото в ИТ, защото отговорите често звучат: „не можем да актуализираме всяка седмица“ или „нямаме телеметрия“. И точно затова трябва да бъдат зададени. CRA е закон, но последствията му са проектни.

Стъпка 3: Изгради „обработката на уязвимости“ като производствен процес, а не като реакция при криза

Изискванията за докладване, описани от Комисията (24h/72h/14 дни/месец), са безпощадни за организация, която няма процес. Ако искаш да си готов за 11 септември 2026, трябва да третираш „обработката на уязвимости“ като елемент от жизнения цикъл на продукта, а не като „задача на security екипа“.

Това означава:

• един канал за приемане на сигнали (CVD policy + контакт),
• първоначална оценка с ясен собственик и критерии,
• механизъм за изграждане и доставяне на security updates,
• модел за комуникация към клиентите, който не е импровизация,
• готовност за докладване (кой подава, с какви данни, колко бързо).

Всичко това звучи като „организационна“ работа. На практика това е продуктова работа, защото засяга версии, съвместимост, архитектурата на актуализациите и стратегията за поддръжка.

Стъпка 4: Избери периода на поддръжка като бизнес решение, а не като минимално изискване

Ако продуктите ти се използват в индустрията по 10–15 години, периодът на поддръжка е стратегически. CRA налага поддръжката да не е обещание без покритие. Това означава, че периодът на поддръжка трябва да произтича от анализ: колко дълго продуктът ще се използва, как изглежда веригата за доставки на компонентите, колко дълго ще можеш да доставяш поправки. На практика периодът на поддръжка започва да „дърпа“ цялата екосистема: договорите с доставчици, наличността на build environment, поддръжката на toolchain-ите, а дори и решенията дали продуктът да има отдалечени функции или да е изолиран.

Ако приемеш периода на поддръжка като формалност, най-късно през 2027 ще влезеш в конфликт: клиентът очаква поддръжка, а ти вече нямаш нито ресурси, нито зависимости, за да я осигуриш. CRA не създава този проблем — CRA само го прави видим.

Стъпка 5: Подреди веригата за доставки: разговорът с доставчиците е част от съответствието

В CRA няма „магия“, която да направи външните компоненти безопасни. Ако устройството ти се базира на библиотеки, комуникационни модули, операционна система, SDK или хардуерни компоненти, рискът ти зависи пряко от качеството на практиките на доставчика.

Затова още сега си струва да въведеш разговор за неща, които не звучат като маркетинг, а като инженеринг:

• дали доставчикът може да информира за уязвимости по предвидим начин,
• какво е времето му за реакция,
• дали има процес за публикуване на поправки,
• дали може да поддържа компонента за период, който е съгласуван с твоя период на поддръжка.

Тук CRA наистина засяга бизнеса: доставчик, който не може да управлява уязвимости, не е „по-евтин“. Той е регулаторен риск.

Стъпка 6: Изгради документацията като последователна следа: право → риск → решение → доказателство

В одитите за съответствие винаги печели последователността. Ако от оценката на риска следва, че даден интерфейс е критичен, а документацията не описва как го защитаваш; ако заявяваш, че актуализациите са сигурни, а не можеш да покажеш как гарантираш целостта на пакетите; ако казваш, че имаш процес за обработка на уязвимости, а не можеш да покажеш как правиш triage на сигналите — това не е „липса на хартия“. Това е липса на доказателство, че процесът работи.

В CRA, при липса на хармонизирани стандарти, тази следа е особено важна. Защото тя ще бъде основата на разговора с органа за надзор на пазара, с enterprise клиент, а при някои категории продукти — и с органа за оценка на съответствието. И също толкова важно: тя ще бъде основа за вътрешна стабилност. Екипът знае защо правим нещо, а не само „че трябва“.

Заключение: CRA като ново проектно изискване, а не „проект за съответствие“

Ако трябва да оставя една мисъл, която обединява трите части: CRA не е проблем, който се решава накрая. Това е рамка, която променя начина на мислене за продукта. Както ISO 12100 учи, че рискът възниква във връзката човек–машина, така CRA учи, че киберсигурността възниква във връзката продукт–среда–жизнен цикъл на производителя.

Хармонизираните стандарти ще дойдат и ще опростят някои пътища. Но липсата им не е причина за бездействие. Тя е причина да се фокусираш върху това, което CRA винаги оценява: решенията, доказателствата и способността да действаш в реалността — не в презентацията.