Инструменти · Контролен списък на производителя
Матрица на съответствието
Всяко задължение за производителите на продукти с цифрови елементи, представено през жизнения цикъл на продукта с препратката към съответния член. Преминете през него и проследявайте напредъка си; целият контролен списък е безплатен за преглед. Напредъкът се съхранява в този браузър.
По подразбиране · route
Продуктите по подразбиране могат да преминат самооценка съгласно модул A. Не се изисква нотифициран орган, но пълното техническо досие и DoC все пак трябва да са налице.
1 · Основи
Основи на ниво организация
0 / 4Организационни изисквания, които трябва да са налице, преди да започне каквато и да е специфична за продукта работа.
Документиран жизнен цикъл на сигурната разработка (SDL)Поддържайте документиран SDL, който определя етапите, ролите и отговорностите. Външното сертифициране (IEC 62443-4-1, ISO/IEC 27001) е по избор, но създава презумпция за съответствие.
Чл. 13, параграф 1 · Приложение I
Доказателство за съответствие със SDLКогато не се притежава външно сертифициране, съхранявайте документирани доказателства за вътрешно съответствие със SDL.
Приложение I · част I
SDL обхваща сигурност по проект и сигурност по подразбиранеНОВОSDL трябва изрично да разглежда как продуктът свежда до минимум повърхността си за атаки без конфигуриране от крайния потребител.
Приложение I · I(2)(3)
Упълномощен представител в ЕС (за производители извън ЕС)НОВОПроизводителите извън ЕС трябва да определят с писмено пълномощно представител, установен в ЕС, посочен в техническата документация и в DoC.
Art. 19
2 · Преди разработката
Преди започване на разработката
0 / 9Класификацията, оценката на риска и техническите предпоставки определят обхвата на всичко, което следва.
Определете класификацията на продуктаНОВОНАЛИЧЕН ИНСТРУМЕНТОпределете дали продуктът е по подразбиране, важен клас I/II или критичен (приложения III и IV). Класификацията определя пътя за оценяване на съответствието.
Приложение III/IV
Определете пътя за оценяване на съответствиетоНОВОПо подразбиране: самооценка по модул A. Важен клас I: модул A с хармонизиран стандарт, иначе B+C или H. Важен клас II и критични: винаги чрез нотифициран орган. Сроковете на изпълнение от 4—10 месеца са обичайни.
Чл. 32 · Приложение VIII
Специфична за продукта оценка на рисковете за киберсигурносттаИзвършете оценка на риска преди разработката. Запазете всички версии; първоначалната версия преди разработката е част от техническата документация.
Приложение I · I(1)
Моделиране на заплахитеНОВОИдентифицирайте повърхността за атаки, заплашителите, векторите на атака и произтичащите изисквания за сигурност. Документирайте използваната методология.
Приложение I · I(1)
Политика за компоненти на трети страни и с отворен кодНОВОНАЛИЧЕН ИНСТРУМЕНТОпределете как се избират, оценяват и одобряват компонентите на трети страни и с отворен код, включително минимални задължения по отношение на EOL и реакция на уязвимости.
Приложение I · част II
Проверка за EOL на инструменти и зависимостиНАЛИЧЕН ИНСТРУМЕНТПроверете датата на края на жизнения цикъл (End-of-Life) на всички ключови инструменти, ядра, бази данни и библиотеки. Избягвайте компоненти, чийто EOL попада в рамките на жизнения цикъл на поддръжка на продукта.
Приложение I · част II
Осъществимост на криптирането при съхранениеПотвърдете, че целевият хардуер поддържа криптиране на данните в покой; задължително изискване, което може да наложи смяна на хардуера.
Приложение I · I(4)(д)
Проектиране с минимална повърхност за атакиНОВОПланирайте да премахнете или деактивирате по подразбиране всеки интерфейс, услуга, порт и протокол, които не са необходими за предвидената функция.
Приложение I · I(2)(б)
Политика за идентификационни данни по подразбиранеНОВОДоставяйте без пароли по подразбиране или принудете потребителя да зададе уникални идентификационни данни при първа употреба.
Приложение I · I(2)(в)
3 · Разработка
По време на разработката
0 / 5Сигурно кодиране, изпитване и механизмът за актуализация, доказани през целия процес на компилиране.
План за изпитване, насочен към киберсигурносттаТестови случаи, насочени към удостоверяване, контрол на достъпа, валидиране на входните данни, криптиране и обработка на грешки. Документирани и съхранявани в техническото досие.
Приложение I · I(1)
Доказателство за съответствие със SDLДокажете с документирани доказателства, че SDL е спазен на всеки етап.
Приложение I · част I
Тестване за проникване / оценка на уязвимоститеНОВОПроведете изпитване на сигурността на продукта или на представителна компилация преди пускането.
Приложение I · I(1)
Механизъм за сигурна актуализация на софтуераНОВОУдостоверен механизъм за актуализация с проверен интегритет, който устройството може да провери преди инсталиране и който е автоматичен, когато е осъществимо.
Приложение I · I(2)(е)
Свеждане на данните до минимумНОВОСъбирайте, обработвайте и съхранявайте само данните, строго необходими за предвидената функция.
Приложение I · I(4)(е)
4 · Преди пускането
Преди пускането на продукта
0 / 12SBOM, одит на мрежата, EOL, оценяване на съответствието, маркировка „СЕ“ и техническото досие.
Подготвен и проверен за уязвимости SBOMНАЛИЧЕН ИНСТРУМЕНТПодгответе SBOM, обхващащ поне всички зависимости от най-високо ниво, и проверете, че никой компонент не носи известна, вече поправена уязвимост. Включването на разрешен CVE е пряко нарушение.
Приложение I · II(1)
SBOM в машинночетим форматНОВОНАЛИЧЕН ИНСТРУМЕНТСъхранявайте SBOM като SPDX или CycloneDX (JSON/XML). PDF може да бъде отхвърлен като немашинночетим.
Приложение I · част II
Списък на входящите връзкиИзбройте и обосновете поотделно всяка входяща връзка и отворен порт; премахнете или деактивирайте по подразбиране всичко, което не е необходимо.
Приложение I · I(2)(б)
Списък на изходящите връзкиОдитирайте и обосновете всички изходящи връзки, включително тези от операционната система, библиотеките на трети страни и телеметрията.
Приложение I · част I
Декларирайте края на жизнения цикъл на продуктаНАЛИЧЕН ИНСТРУМЕНТИзчислете и декларирайте EOL; той не може да надвишава EOL на ключовите зависимости. Минимален период на поддръжка от 5 години, освен ако очакваният срок на употреба е по-кратък.
Art. 13(8)
Завършете оценяването на съответствиетоНОВОИзвършете приложимата процедура (модул A или B+C / H / нотифициран орган) и я документирайте, преди да поставите маркировката „СЕ“.
Art. 32
Подгответе ЕС декларацията за съответствиеНОВОНАЛИЧЕН ИНСТРУМЕНТИзгответе и подпишете DoC съгласно приложение V, като се позовете на регламента, продукта и процедурата за оценяване. Съхранявайте на разположение в продължение на 10 години.
Чл. 28 · Приложение V
Поставете маркировката „СЕ“НОВОПоставете видима, четлива и незаличима маркировка „СЕ“. Без маркировка „СЕ“ няма достъп до пазара на ЕС от 11 дек. 2027 г.
Art. 30
Съставете техническото досиеНОВОСъставете пакета по приложение VII: описание, оценка на риска, доказателства за SDL, резултати от изпитвания, SBOM, одити на връзките, DoC и декларация за края на жизнения цикъл.
Чл. 31 · Приложение VII
10-годишен план за съхранениеНОВОАрхивирайте цялата техническа документация, включително всяка версия на SBOM, поне 10 години от първото пускане на пазара.
Art. 31(3)
Документация за потребителяНОВОСъобщавайте предвидената употреба, свойствата на киберсигурността, как да се конфигурира сигурността, декларирания EOL и как да се докладват уязвимости.
Приложение II · чл. 13, параграф 18
Публикуван контакт за оповестяване на уязвимостиНОВОПубликувайте единна, активно наблюдавана точка за контакт за докладване на уязвимости.
Art. 13(5)
5 · След пускането
След пускането на продукта
0 / 10Текущо наблюдение, срокът за докладване по член 14 и задълженията за актуализация през периода на поддръжка.
Актуализирайте оценката на риска при съществена промянаПреоценявайте при установяване на съществена промяна в продукта, значителна нова заплаха или експлоатирана уязвимост; документирайте задействащото събитие и резултата.
Приложение I · I(1)
Автоматизирано наблюдение на уязвимостите по SBOMНАЛИЧЕН ИНСТРУМЕНТВнедрете инструменти, които наблюдават компонентите на SBOM спрямо актуални емисии (NVD, EUVD, OSV) достатъчно често, за да се спази 24-часовият срок за докладване. Ръчното наблюдение е недостатъчно.
Art. 14
24-часов първоначален доклад за уязвимостНОВОПри узнаване за активно експлоатирана уязвимост подайте първоначален доклад в срок от 24 часа чрез единната платформа за докладване на ENISA. Прилага се от 11 септ. 2026 г.
Art. 14(2)
72-часов технически докладНОВОПодайте подробен технически доклад до ENISA и националния CSIRT в срок от 72 часа, включително тежестта и евентуалните мерки за смекчаване.
Art. 14(3)
Окончателен доклад в срок от 14 дни от отстраняванетоНОВОПодайте окончателен доклад не по-късно от 14 дни след предоставянето на актуализация на сигурността или заобиколно решение.
Art. 14(4)
Докладване на тежки инцидентиНОВОДокладвайте тежките инциденти, засягащи сигурността на продукта, в същия срок от 24/72 часа.
Art. 14(2)
Автоматична актуализация за уязвимости в компоненти на трети страниПоддържайте автоматична система за актуализация, способна да поправя уязвимости в компоненти на трети страни. Поправка в рамките на 24 часа освобождава от докладване, но не и от отстраняване.
Art. 14(2)(a)
Безплатни актуализации на сигурносттаНОВОПредоставяйте всички актуализации на сигурността безплатно за продължителността на периода на поддръжка.
Art. 13(9)
Предварително уведомление за края на жизнения цикълНОВОУведомявайте потребителите поне 12 месеца преди последната актуализация на сигурността, когато е осъществимо.
Art. 13(8)
Коригиращи мерки за несъответстващи продуктиНОВООтстранете, изтеглете или изземете несъответстващите продукти и уведомете надзора на пазара. Бездействието само по себе си е нарушение.
Art. 13(14)
Край на контролния списък · всички 40 елемента, показани по-горе
Експортиране (по избор)
Експортирайте Вашата матрица с текущия Ви напредък
Всичко по-горе е безплатно за четене и печат. За да изтеглите контролния списък и Вашето актуално състояние като електронна таблица или PDF, оставете имейл и ще Ви добавим към бюлетина за CRA.