Насоки на Европейската комисия относно CRA

01Какво представлява това

Art. 26 изисква от Комисията да публикува насоки, които да помогнат на икономическите оператори да прилагат CRA, с особен фокус върху улесняването на съответствието за малките и средните предприятия. На 27 юли 2026 г. Комисията одобри съдържанието на тези насоки (документ с референтен номер C(2026) 5252). Те са с обем от около 80 страници и разглеждат въпросите, които производителите задават най-често.

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

02Какво се счита за продукт

Най-голямата част от насоките е посветена на обхват, най-често задаваната област. Продукт с цифрови елементи е софтуерен или хардуерен продукт (и свързаната с него отдалечена обработка на данни), чиято употреба включва пряка или непряка връзка за данни. Art. 3(1)

• Мястото, където се изпълнява софтуерът, го определя; софтуер, който се изпълнява на устройството на потребителя (изтеглено приложение, разширение за браузър, локално инсталиран клиент), е продукт с цифрови елементи. Софтуер, до който се осъществява достъп само отдалечено чрез браузър, не е такъв само на това основание.
• Уеб приложения и уебсайтове; уеб приложение, използвано само чрез браузър, и уебсайт, който само представя информация, обикновено не са продукти с цифрови елементи. Те попадат в обхвата само когато представляват отдалечена обработка на данни, поддържаща функцията на продукт.
• Изходен код; определението за софтуер в CRA обхваща както машинен, така и изходен код, но самото споделяне на код с отворен код в публично хранилище обикновено не представлява „пускане на пазара“. Art. 3(4)

Ако не сте сигурни къде се позиционира вашият продукт, Бърза проверка и тя обяснение на достъпен език разглеждат обхвата на практика.

03Софтуер с отворен код

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

• Кога FOSS е „пуснат на пазара“; насоките разглеждат начисляването на цена, монетизирането на свързани услуги или изискването на лични данни, платена поддръжка, дарения, финансови споразумения и структури с нестопанска цел, както и интегрирането на FOSS от други производители.
• Отговорници за софтуер с отворен код; определен, пропорционален набор от задължения, насочени към поддържане на сигурността и продължаващата жизнеспособност на софтуера.
• Важен FOSS; важните продукти (клас I или II), пуснати на пазара като свободен софтуер с отворен код, могат да следват по-леките процедури за съответствие на категорията по подразбиране. Art. 32(5)

04Съществени модификации

Дали дадена промяна е съществено изменение определя дали е необходима нова оценка за съответствие. Съображение 39 го формулира така: продукт е съществено модифициран, когато промяна променя нивото му на риск за киберсигурност по начин, който производителят не е разгледал вече в оценката си на риска. Art. 3(30)

• Актуализациите на сигурността обикновено не са съществени модификации; тяхната цел е намаляване на риска, така че поправка на сигурността, която не променя предназначението на продукта и не въвежда нови рискове, сама по себе си не се брои.
• Става дума за риск, а не за мащаб; критерият е въздействието на промяната върху профила на риска за киберсигурност (нови вектори на заплаха, нови сценарии на атака или промяна във вероятността или въздействието), а не мащабът на промяната.
• Последицата; съществено модифициран продукт се третира като новопуснат на пазара. Когато промяната се извършва от лице, различно от първоначалния производител, то поема задълженията на производител за модифицираната част. Art. 21 · 22

Тя Ръководство за маркировка „СЕ“ обхваща оценката за съответствие, която се задейства от ново пускане на пазара.

05Период на поддръжка

Периодът на поддръжка е времето, през което уязвимостите трябва да бъдат обработвани. Той следва да отразява колко дълго продуктът е разумно се очаква да бъде в употреба. Чл. 13(8)

• Пет години са стойност по подразбиране, а не минимален праг; периодът може да бъде по-кратък, когато се очаква продуктът да бъде в употреба по-малко от пет години, а продуктите, за които разумно се очаква да се използват по-дълго, следва да имат по-дълги периоди на поддръжка.
• Уведомете потребителите; крайната дата (поне месец и година) се посочва към момента на покупката, а потребителите се уведомяват при изтичането ѝ, когато е технически осъществимо. Art. 13(19)
• Гъвкавост за софтуера; при определени условия производителите могат да отстраняват уязвимости само в последната версия, когато потребителите могат да преминат към нея безплатно и без допълнителни разходи. Art. 13(10)
• След съществена модификация; периодът се преразглежда спрямо същите критерии; той не се нулира или удължава автоматично.

Планирайте своя с планировчик на периода на поддръжка и края на жизнения цикъл.

06Важни и критични продукти

Класификацията определя пътя за съответствие. Продуктът е важен if its основна функционалност съответства на категория от приложение III (клас I или II), и критичен ако съответства на приложение IV; всичко останало е продукт по подразбиране, който може да премине самооценка. Art. 7 · 8 · 32

• Основната функционалност е критерият; основните характеристики на продукта, без които той не би отговарял на предназначението си. Второстепенните функции не променят класа, а самото интегриране на важен или критичен компонент не прави целия продукт важен или критичен: смартфон, който вгражда операционна система, сам по себе си не е „операционна система“.
• Една основна функционалност; за целите на избора на път за съответствие се приема, че продуктът има една основна функционалност, посочена в техническата му документация.
• Определенията за категориите; техническите описания на важната и критичната категория са установени в Регламент за изпълнение (ЕС) 2025/2392 на Комисията.

Сравнете вашия продукт с категориите с помощта на инструмента за намиране на класа на продукта.

07Отдалечена обработка на данни

Решенията за отдалечена обработка на данни са част от продукт с цифрови елементи само когато са необходима на продукта за изпълнение на функциите му. Чл. 3(2) Насоките предлагат практически критерий: извършва ли се обработката „от разстояние“; би ли попречило нейното отсъствие на продукта да изпълнява една от функциите си; и дали софтуерът е проектиран и разработен от производителя или под негова отговорност.

Насоките илюстрират критерия с разработени примери за употреба (мобилно банково приложение, интелигентен термостат, електронна книга, промишлен робот и клетъчна мрежа), които показват къде минава границата между продукт и обикновена услуга.

08Докладване и уязвимости

Насоките изясняват и текущите задължения: Article 14 reporting на активно експлоатирани уязвимости и тежки инциденти, и приложение I vulnerability-handling изисквания: докладване нагоре по веригата и споделяне на поправки на сигурността, отстраняване на известни експлоатируеми уязвимости и провеждане на ефективни, редовни тестове и прегледи на сигурността. Art. 14 · Annex I

09Други официални източници

Насоките се допълват от още две официални референтни точки, които си струва да се четат заедно с тях.

Хармонизирани стандарти. Съществените изисквания в Приложение I са формулирани по отношение на резултата; след като съответен хармонизиран стандарт бъде цитиран в Официален вестник, спазването му дава презумпция за съответствие. Искането за стандартизация на Комисията M/606 беше прието от CEN, CENELEC и ETSI през 2025 г. и обхваща около 41 стандарта. Двата основни хоризонтални стандарта (сигурна разработка и управление на уязвимости) се очакват до 30 август 2026 г., вертикалните продуктови стандарти до 30 октомври 2026 г., а останалите хоризонтални стандарти до 30 октомври 2027 г., около година преди пълното прилагане.