Cyber Resilience Act.
Разработвайте сигурни продукти с цифрови елементи, управлявайте уязвимостите и подгответе подходящото доказване на съответствие.
- Регламент (ЕС) 2024/2847
- От Derya Altinay
- Актуално към: 22.10.2026 г.
- Време за четене: 8 мин.
Кратък отговор.
Cyber Resilience Act е регламентът на ЕС за киберсигурността на обхванатите продукти с цифрови елементи. Производителите отговарят за сигурността при разработването, предоставянето и поддръжката. Задълженията на производителите за уведомяване се прилагат от 11 септември 2026 г., а общите продуктови задължения — от 11 декември 2027 г. Основа е Регламент (ЕС) 2024/2847.
Cyber Resilience Act и сроковете по CRA.
Cyber Resilience Act, съкратено CRA или Регламентът за киберустойчивостта, урежда киберсигурността на продуктите. Регламент (ЕС) 2024/2847 свързва изискванията към проектирането със задължения през жизнения цикъл на продукта. Предмет на разглеждане е конкретният продукт, включително относимите компоненти и свързаното дистанционно обработване на данни. Програма за сигурност на цялото предприятие може да подпомогне тази работа, но сама не отговаря на специфичните продуктови въпроси.
Сроковете по CRA се прилагат поетапно. Съгласно член 71, параграф 2 CRA общите изисквания започват на 11 декември 2027 г.; уведомленията на производителите по член 14 се прилагат още от 11 септември 2026 г. Глава IV за нотифицирането на органи за оценяване на съответствието се прилага от 11 юни 2026 г. Тази институционална дата не е изтеглен напред общ срок за CE маркировка на всички софтуерни продукти.
По-старите продукти не са общо освободени от уведомленията на производителите. Член 69, параграфи 2 и 3 CRA разграничава преходните правила за продуктовото съответствие от уведомяването. Насоките на Комисията C(2026) 5252, раздел 9.1, поясняват това разграничение и за продукти, пуснати на пазара преди декември 2027 г. Насоките са правно необвързващо средство за тълкуване; определящ остава регламентът.
Кои продукти и предприятия са обхванати от CRA.
CRA се отнася до обхванати хардуерни и софтуерни продукти, предоставяни на пазара на ЕС, които предвиждат пряка или непряка връзка за данни с устройство или мрежа. Членове 2 и 3 CRA определят приложното поле и понятията. Това може да включва самостоятелно предлагани компоненти. Проверете действителната функция и законовите изключения, преди да класифицирате еднакво цялото портфолио.
Ролята на предприятието определя неговите задължения. Производители, вносители и дистрибутори имат различни задачи; ролята на производител може да е относима и при продажба под собствена марка. За софтуер с отворен код трябва да се разграничават търговското предоставяне, приносът на отделни лица и специалната роля на администратора на софтуер с отворен код. Свободен лиценз не освобождава общо производителя на търговски продукт от отговорността му.
SaaS услуга не попада в CRA и не се изключва от него само заради търговското си наименование. Решаващи са границата на продукта и свързаното дистанционно обработване на данни. Насоките на Комисията, раздели 2 и 8, разграничават софтуерни продукти от дистанционно предоставяни услуги. Документирайте обосновката за конкретната архитектура; общо твърдение за всички облачни предложения би било прекалено широко.
Основните области на изискванията по CRA.
Изискванията по CRA свързват основаната на риска продуктова сигурност с непрекъсната отговорност. Член 13 и приложение I CRA са основата на продуктовите задължения; член 14 урежда по-рано приложимите уведомления на производителите. Следните области дават ориентация, без да заместват отделните законови изисквания.
Разбиране на продукта и рисковете.
Оценката на риска за киберсигурността обосновава решенията за сигурност през жизнения цикъл. Производителите отчитат предвидената и разумно предвидимата употреба. Опишете на практика какви функции, интерфейси и зависимости има продуктът и какви последици може да има проблем със сигурността за неговите потребители.
Залагане на сигурност в продукта.
Сигурното проектиране и сигурните настройки по подразбиране са свързани. Приложение I CRA обхваща продуктови характеристики като защита на достъпа, защита на данните и ограничаване на повърхностите за атака. Написана впоследствие политика не може да замести техническите свойства; решенията при разработване и тяхната проверка трябва да съответстват на оценката на риска.
Отговорно включване на компоненти.
Интегрираните компоненти остават част от разглеждането на продукта. Производителите се нуждаят от проследима информация какво доставят и как уязвимостите в зависимостите засягат продукта им. Комисията изрично описва дължимата грижа за компоненти от трети страни; простото препращане на информация от доставчик не отговаря на всеки продуктов въпрос.
Управление на уязвимости и актуализации.
Управлението на уязвимости е постоянна задача през приложимия период на поддръжка. То включва достъпни канали за съобщаване, оценка, отстраняване и сигурно предоставяне на актуализации за сигурност. Разграничете техническата обработка на констатация от правната оценка дали активно експлоатирана уязвимост или тежък инцидент подлежи на уведомяване.
Определяне на поддръжката и информацията за потребителите.
Периодът на поддръжка се определя от критериите по член 13, параграф 8 CRA и очакваната употреба. По принцип са предвидени поне пет години; при по-кратка очаквана употреба важи нейната продължителност, а при по-дълга може да е необходим по-дълъг период. Насоките на Комисията, раздел 5, изрично поясняват, че пет години не са общ максимум.
Осигуряване на уведомленията на производителите.
Член 14 CRA разграничава активно експлоатирани уязвимости от тежки инциденти със сигурността. За производителите се прилага поетапно уведомяване: незабавно, най-късно до 24 часа ранно предупреждение и до 72 часа допълнителни данни след узнаването. Окончателните срокове се различават според основанието. Затова резултат от скенер сам по себе си не е нито автоматично задължително уведомление, нито достатъчно основание за приключване на събитието.
Подготовка на съответствието и документацията.
Техническата документация и оценяването на съответствието трябва да обясняват предлагания продукт. Член 32 CRA и продуктовата категория определят допустимата процедура. Съхранявайте избраната основа за оценка заедно с версията на продукта; общ набор от документи без проследима връзка с провереното изпълнение не е достатъчен като практическа стратегия за доказване.
Прилагането на CRA като продуктов процес.
Определете портфолиото и ролите.
Като практическо начало опишете предлаганите продукти, относимите им функции, отговорното юридическо лице и ролята във всеки канал за разпространение.
Разграничете етапите на прилагане.
Разделете вече приложимата готовност на производителя за уведомяване от подготовката на общото продуктово съответствие и проверете преходните правила за съществуващите продукти.
Превърнете рисковете в продуктови решения.
Свържете оценката на риска с проектирането, избора на компоненти и проверими критерии за сигурност при разработване и одобряване на версии.
Изпитайте каналите за уведомяване.
Определете отговорни лица и заместници и упражнете оценяването, ескалацията и подаването при непълна информация в рамките на приложимите срокове.
Определете поддръжката и начина на доказване.
Планирайте поддържането на продуктовите версии и изяснете според категорията какво оценяване на съответствието и техническа документация ще са необходими.
CE маркировка на софтуер и доказване за продукта.
Доказването по CRA е продуктово оценяване на съответствието. В поясненията си към член 32 CRA Комисията обяснява, че за стандартната категория е възможна вътрешна оценка. За определени важни или критични продукти се прилагат по-строги процедури с нотифициран орган или други съответно допустими начини на доказване. Действителната функция на продукта определя категорията; рекламно продуктово име не е достатъчно.
ЕС декларацията за съответствие и CE маркировката следват приложимата процедура. Те не са общ сертификат за цялото предприятие и не обещават, че продуктът никога няма да има уязвимост. Затова единен срок на сертификат не е подходящо описание на CRA: документацията, управлението на уязвимостите и съответните приложими задължения трябва да се разглеждат през релевантния жизнен цикъл.
Други рамки и самостоятелни задължения.
ISO 27001 организира система за управление на информационната сигурност; съответен сертификат сам по себе си не потвърждава съответствието на продукт с CRA. NIS2 разглежда обхванати субекти и тяхната организация на сигурността. ОРЗД защитава личните данни, поради което продуктово събитие може да породи допълнителни въпроси за защитата на данните. Свързаните работни процеси могат да се координират, но правните им основания и доказателства трябва да се проверяват отделно.
В Secani.
Secani съдържа редакционен работен каталог за CRA с източници, въпроси за проверка и примери за доказателства. Профилът на предприятието включва наред с друго роли и дата на оценката; неизяснените предпоставки остават видими като необходимост от проверка. Помощното средство подпомага организирането на проверката, но не потвърждава нито правната класификация, нито съответствието на продукт.
Започнете с ясно определен продукт.
Изберете конкретен продукт и първо изяснете границата му, отговорното юридическо лице и компетентните лица за уведомления за сигурност. След това проверете кои настоящи и бъдещи задължения се отнасят до този продукт. Тази отправна точка прави подготовката управляема и предотвратява общ проект за съответствие да прикрие вече необходимата готовност за уведомяване.
Източници.
- Регламент (ЕС) 2024/2847 — Cyber Resilience Act
- Европейска комисия: Cyber Resilience Act и дати на прилагане
- Европейска комисия: обобщение на правния акт
- Европейска комисия: задължения на производителите
- Европейска комисия: оценяване на съответствието
- Европейска комисия: CRA и отворен код
- Европейска комисия: насоки C(2026) 5252 с приложение
Често задавани въпроси.
Да, за обхванатите производители уведомленията по член 14 CRA се прилагат от 11 септември 2026 г. Общите продуктови задължения започват на 11 декември 2027 г.; специалните роли и преходните правила трябва да се проверят отделно.
Не, наименованието SaaS не определя приложното поле. Проверете софтуерния продукт, функциите му и свързаното дистанционно обработване на данни според конкретната архитектура.
Не, специалното третиране на предходни приноси с отворен код не освобождава общо производителя на търговски продукт от задълженията му. Ролята на производител и възможната роля на администратор на софтуер с отворен код трябва да се разграничават.
Не, сертификатът ISO 27001 се отнася до определена система за управление. CRA изисква отделно разглеждане на продукта и съответното приложимо доказване на съответствие.
Организирайте продуктовата сигурност с ясна проследимост.
Работете структурирано по изискванията на CRA и тяхната проверка със Secani.
Тази страница обяснява Cyber Resilience Act на общо ниво и не замества правна проверка на отделния продукт. Определящи са действащите правни актове.