Регламентът за киберустойчивост (CRA): задълженията за докладване вече текат

На 11 септември 2026 г. — преди единадесет дни — влезе в действие първото реално задължение по Регламента за киберустойчивост. От тази дата всеки производител на продукт с цифрови елементи, пуснат на пазара на ЕС, е длъжен да подаде ранно предупреждение в рамките на 24 часа, щом научи за активно експлоатирана уязвимост в свой продукт.

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

Какво е CRA и кого засяга

Регламентът за киберустойчивост (CRA) е Регламент (ЕС) 2024/2847 — хоризонтално законодателство, което въвежда изисквания за киберсигурност към продуктите с цифрови елементи през целия им жизнен цикъл. Той работи по логиката на продуктовото законодателство на ЕС: съществени изисквания, оценяване на съответствието, техническо досие, декларация и CE маркировка.

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

Календарът

Важен нюанс: задължението за докладване от септември 2026 г. обхваща и продукти, пуснати на пазара преди пълното прилагане. Продуктовото ви портфолио от 2023 г. не е освободено — освободен е само режимът на CE маркировката за него.

Задълженията за докладване: 24 часа, 72 часа, 14 дни

Това е частта, която вече действа, и тя изисква организационна готовност, а не документация.

1. До 24 часа — ранно предупреждение. От момента, в който производителят узнае за активно експлоатирана уязвимост или за тежък инцидент, засягащ сигурността на продукта, се подава ранно предупреждение до ENISA и до националния екип за реагиране при инциденти (CSIRT).
2. До 72 часа — уведомление. По-пълна информация за уязвимостта или инцидента, включително предприетите коригиращи или смекчаващи мерки.
3. До 14 дни — окончателен доклад. След отстраняване на уязвимостта или овладяване на инцидента се подава окончателен доклад с описание на уязвимостта, въздействието и приложеното решение.

Четирите класа продукти и пътят до CE маркировката

От декември 2027 г. всеки продукт в обхвата минава през оценяване на съответствието. Колко тежка е процедурата зависи от класа:

Когато продуктът попада едновременно в няколко категории, прилага се по-строгата. Списъците на важните и критичните продукти са в приложенията към регламента — и това е първата проверка, която трябва да направите, защото от нея зависи дали изобщо ще ви трябва нотифициран орган.

Съществените изисквания към продукта

• Сигурност по проектиране и по подразбиране. Продуктът се пуска с конфигурация, която е сигурна без допълнителни настройки, и с минимизирана повърхност за атака.
• Без известни експлоатируеми уязвимости към момента на пускане на пазара.
• Процес за управление на уязвимостите — идентифициране, документиране, отстраняване и координирано оповестяване.
• Безплатни актуализации за сигурност през целия период на поддръжка, който по подразбиране е минимум 5 години и се съобразява с очакваното време на използване на продукта.
• SBOM — опис на компонентите на софтуера в машинночетим формат, в общоприет стандарт.
• Техническо досие, съхранявано 10 години, ЕС декларация за съответствие и CE маркировка.

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

Кой се смята за производител

Както при машините, ролята „производител“ се поема по-лесно, отколкото повечето фирми очакват. Производител по CRA сте и когато:

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

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

Какво става с отворения код

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

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

Санкции

Максималният размер е 15 милиона евро или 2,5 % от световния годишен оборот за предходната финансова година, което е по-високо — за нарушения на съществените изисквания и на задълженията на производителя. За други нарушения таваните са по-ниски, а за подаване на невярна или подвеждаща информация към органите има отделна санкция.

Как помага ISO 27001 и какво не покрива

Сертификатът по ISO 27001 не е доказателство за съответствие с CRA. CRA е продуктово законодателство; ISO 27001 е стандарт за системата за управление на информационната сигурност в организацията. Двете се допълват, но не се заместват.

Изводът е практичен: ако вече имате система по ISO 27001, имате процесната основа и трябва да добавите продуктовия слой. Ако нямате, ще изграждате и двете едновременно — и тогава срокът до декември 2027 г. изведнъж не е дълъг. Същото важи и за фирмите, които вече работят по NIS2: там задълженията са към организацията като субект, тук — към продукта.

План за подготовка

1. Направете списък на продуктите с цифрови елементи. Включете вградения софтуер, придружаващите приложения и облачните услуги, без които продуктът не работи.
2. Класифицирайте ги. По подразбиране, важни клас I, важни клас II или критични — от това зависи дали ви трябва нотифициран орган.
3. Осигурете готовността за докладване веднага. Това задължение вече тече: дежурен контакт, правило за преценка, регистрации в платформите.
4. Въведете SBOM в процеса на разработка. Генериран автоматично при всяко издание, а не съставен ръчно веднъж.
5. Определете периода на поддръжка за всеки продукт и го обявете публично — това е и договорно задължение към клиентите.
6. Прегледайте договорите с доставчиците на компоненти. Искайте SBOM, срокове за отстраняване на уязвимости и уведомяване.
7. Подгответе техническото досие паралелно с разработката, а не в края — при интегрираните продукти то се пише най-трудно ретроспективно.

Заключение

CRA променя нещо съществено: киберсигурността престава да бъде обещание в маркетинговия материал и става изискване към продукта, с проверка и глоба. За производителите на свързани устройства и вграден софтуер това е същата промяна, която CE маркировката донесе за механичната безопасност преди тридесет години.

Декември 2027 г. е далеч. Септември 2026 г. вече мина. Ако нямате отговор на въпроса „кой у нас получава сигнал за уязвимост в събота и какво прави с него в следващите 24 часа“, започнете оттам — това е единственото задължение по CRA, което може да ви застигне още този месец.