Регламент устанавливает гармонизированные требования кибербезопасности для продуктов с цифровыми элементами, предназначенных для размещения на рынке ЕС (ст. 2 CRA).
CRA охватывает не только классические IoT-устройства, но практически любой продукт, который содержит программное обеспечение или подключается к сети.

Продукт с цифровыми элементами - программное или аппаратное изделие и его программные или аппаратные компоненты, которые могут подключаться к устройству или сети.
Разберем более детально. Продукт с цифровыми элементами может принимать множество форм, например:
• Автономное программное обеспечение, которое можно загрузить и установить на устройство, например, мобильное приложение, которое можно загрузить через магазин приложений, или программа, которую можно загрузить через веб-сайт;
• Программное обеспечение, предназначенное для интеграции в электронную информационную систему, когда оно выпускается отдельно на рынке, например, микропрограммное обеспечение или программное обеспечение, предназначенное для встраивания в аппаратные устройства;
• Программное обеспечение, которое выпускается на рынок вместе с аппаратным продуктом, независимо от того, предварительно ли оно загружено в аппаратное обеспечение или нет, например, драйверы, необходимые для корректной работы принтера, операционная система в ноутбуке или инструменты, используемые для проектирования и программирования;
• Различные типы аппаратного обеспечения, такие как более базовые компоненты (например, интегральные схемы, материнские платы; датчики); потребительские устройства (например,смартфоны, ноутбуки, умные холодильники); сложные устройства (например, промышленные устройства IoT, оборудование).

Продукт с цифровыми элементами также включает в себя решения для удаленной обработки данных. ПО, доступ к которому осуществляется исключительно через веб-браузер, находится вне сферы действия CRA, если только оно не выполняет функцию удаленной обработки данных (Remote Data Processing) для физического цифрового устройства или компонента, подпадающего под CRA.

Например:

• Разработчик продает корпоративное ПО для управления персоналом. Если оно является самостоятельным продуктом с цифровыми компонентами и выводится на рынок ЕС, необходимо анализировать применение CRA.
• Онлайн-сервис бухгалтерского учета, доступный только через браузер, не будет подпадать под CRA, т.к. может рассматриваться как услуга, а не продукт с цифровыми элементами.
• А если производитель промышленного оборудования продает станок вместе с облачной системой мониторинга, то облачная часть может быть частью цифрового продукта и должна оцениваться в контексте CRA.

Если приложение использует библиотеку криптографии, сторонний SDK, то производитель конечного продукта обязан учитывать риски, связанные с этими компонентами.
Если производитель выпускает крупное обновление, которое меняет функционал, назначение или профиль киберрисков продукта, это может рассматриваться как вывод нового продукта на рынок, что потребует повторной оценки соответствия (Conformity Assessment) и обновления технической документации. Обычные патчи безопасности к «существенным модификациям» не относятся.
Регламент вводит специальное понятие «Open Source Software Steward» - это организация, которая, поддерживает разработку open source, обеспечивает устойчивость проекта, играет значительную роль в экосистеме (организации, управляющие крупными проектами; структуры, координирующие развитие критических компонентов) (CRA, Recital 77–79, Article 3(14), Article 24.)

Исключения из CRA
Регламент содержит ряд исключений:
1. Медицинские устройства. Если продукт подпадает под:

• Regulation (EU) 2017/745 (Medical Device Regulation);
• Regulation (EU) 2017/746 (In Vitro Diagnostic Medical Devices Regulation),

то применяется специальное регулирование. Однако это не означает автоматическое освобождение от всех требований кибербезопасности.
Медицинские устройства уже регулируются отдельными нормами безопасности.

2. CRA не применяется в автомобильном секторе, который регулируются специальными правилами:

• Regulation (EU) 2019/2144;
• UNECE cybersecurity requirements.

3. Авиационная отрасль;
4. Военные технологии;
5. Регламент предусматривает особый режим для бесплатного open source, который:
• развивается вне коммерческой деятельности;
• предоставляется без оплаты;
• не является частью коммерческого продукта.

Но если open source используется коммерческой компанией внутри продукта, ситуация меняется, т.е. если open-source компонент монетизируется, поставляется в рамках платная поддержки или интегрируется в коммерческий продукт, на него и/или на компанию-интегратора распространяются полноценные требования CRA.

CRA использует риск-ориентированный подход.

Все продукты делятся на несколько категорий:

• Обычные продукты, для них применяются общие требования безопасности.
• Продукты с повышенным риском (класса I), например, системы управления паролями, операционные системы, определенное программное обеспечение безопасности.
• Важные продукты класса II, например, сетевые устройства, системы управления промышленными процессами, критические компоненты безопасности.
• Критические продукты, для них предусмотрены наиболее строгие процедуры оценки соответствия.

Полный перечень содержится в Annex III и Annex IV CRA.

Производитель — это физическое или юридическое лицо, которое:

• разрабатывает или производит продукт с цифровыми элементами;
• либо поручает его разработку или производство;
• размещает этот продукт на рынке под своим именем или торговой маркой.

Именно производитель несет основной объем обязанностей по CRA.
Компания разрабатывает CRM-систему и продает доступ к ней под собственным брендом. Компания является производителем цифрового продукта.
Компания берет open source компонент, добавляет собственные функции и распространяет коммерческий продукт. В зависимости от обстоятельств она может стать производителем.
Обязанности производителя:
1. Обеспечение соответствия продукта требованиям кибербезопасности, гарантировать, что продукт соответствует Essential Cybersecurity Requirements, разработан с учетом рисков, безопасен по умолчанию.
2. Проведение оценки рисков. До вывода продукта на рынок производитель должен провести анализ киберрисков, оценку применимых требований, определение мер защиты.
Оценка риска должна учитываться при проектировании, разработке, производстве, сопровождении продукта.
3. Подготовка технической документации. Она должна содержать описание продукта, архитектуру, процесс разработки, анализ рисков, примененные стандарты, результаты тестирования, сведения о безопасности.
4. Выполнение процедуры оценки соответствия.
5. Выпуск обновлений безопасности
6. Поддержка продукта в течение периода поддержки, который должен соответствовать ожидаемому сроку использования продукта.
Срок поддержки должен основываться на обоснованном ожидаемом сроке службы. Производители должны прозрачно информировать пользователей о сроке поддержки до покупки продукта. При этом минимальный срок поддержки не может быть менее пяти лет, кроме случаев, когда предполагаемый жизненный цикл продукта меньше.

Если американская компания разрабатывает приложение управления промышленными датчиками и продает его польским предприятиям, то она должна оценить:

• подпадает ли продукт под CRA;
• какие обязанности производителя возникают;
• нужен ли представитель в ЕС.

Обязанности представителя:

• хранить декларацию соответствия;
• обеспечивать доступ к документации;
• сотрудничать с органами надзора;
• выполнять порученные производителем задачи (Art. 14 CRA)

Импортер — это компания в ЕС, которая вводит на рынок ЕС продукт производителя из третьей страны.
Обязанности импортера

• убедиться, что производитель выполнил требования CRA;
• имеется CE маркировка;
• подготовлена техническая документация;
• имеется декларация соответствия;
• указаны контактные данные производителя.
• не размещать несоответствующий продукт на рынке;
• сообщать о рисках;
• сотрудничать с органами надзора.

Дистрибьютор — лицо в цепочке поставок, которое распространяет продукт, не затрагивая его свойства, но не является производителем или импортером.
Обязанности дистрибьютора:

• Проверить перед продажей наличие CE маркировки, наличие необходимых документов, идентификацию производителя и импортера.
• Если дистрибьютор обнаруживает, что продукт может создавать риск, то приостановить продажу, уведомить соответствующих участников, сотрудничать с органами контроля

Производитель должен обеспечить, чтобы продукт:
1. Был разработан безопасным образом. Необходимо учитывать угрозы, архитектурные риски, возможные сценарии атак, последствия компрометации.
2. Имел безопасные настройки по умолчанию.
3. Защищал конфиденциальность и целостность данных.
4. Обеспечивал безопасную идентификацию пользователей.
5. Поддерживал безопасные обновления.
CRA впервые на уровне закона ЕС закрепляет обязанность иметь постоянный процесс управления уязвимостями.

Производитель должен:
• выявлять уязвимости;
• получать информацию от исследователей безопасности;
• оценивать риски;
• выпускать исправления;
• информировать пользователя

Компания должна иметь процедуру приема сообщений об уязвимостях.
Производитель должен понимать какие open source компоненты используются, какие версии применяются, есть ли известные CVE.

С 11 сентября 2026 года производители обязаны уведомлять ENISA о активно эксплуатируемых уязвимостях, серьезных инцидентах безопасности.

Отчетность требуется при серьезных событиях, которые влияют на безопасность продукта, приводят к компрометации, создают риск для пользователей.

Сроки уведомления:
24 часа – первоначальное уведомление;
72 часа – дополнительная информация;
14 дней – итоговый отчет.

ENISA создает единый механизм подачи уведомлений с целю централизовать информацию, ускорить обмен данными, обеспечить координацию между ЕС и CSIRT (ENISA Single Reporting Platform)

CRA предусматривает систему надзора.
Государства ЕС должны назначить органы, которые будут контролировать:
• соответствие продуктов;
• наличие документации;
• выполнение обязанностей производителя.

Органы контроля смогут:
• запрашивать информацию;
• проводить проверки;
• требовать устранения нарушений;
• ограничивать продажу продуктов.

Максимальные размеры штрафов за нарушение основных требований кибербезопасности до €15 млн или 2,5% мирового оборота, другие нарушения до €10 млн или 2% оборота, предоставление недостоверной информации до €5 млн или 1% оборота.

Компаниям, которые могут подпадать под CRA, рекомендуется:
1. Определить статус (производитель, импортер, дистрибьютор);
2. Провести классификацию продукта (обычный/важный/критический продукт);
3. Проверить:
• безопасность разработки;
• управление уязвимостями;
• обновления;
• документацию;
• процессы реагирования.
4. Подготовить процессы, т.е. назначить ответственных, создать Vulnerability Policy, подготовить процедуру уведомления ENISA.
5. Проверить договоры с подрядчиками, поставщиками SDK и компонентов на предмет обязательств по передаче данных об уязвимостях.

Для производителей ПО, IoT-решений, embedded-систем и оборудования требования CRA становятся базовым элементом комплаенса наравне с требованиями GDPR, NIS2 и AI Act. При этом даже разработчикам SaaS-платформ и облачных сервисов важно уже сейчас провести ревизию архитектуры, т.к. любые клиенты, локальные модули, SDK или функции удаленной обработки данных могут привести к применимости CRA. Игнорировать эти требования — значит рисковать не только штрафами, но и прямой блокировкой продаж на европейском рынке.
Подготовка к Cyber Resilience Act требует синергии юридической защиты и понимания IT-процессов. Мы готовы помочь вашему бизнесу:

• Провести правовой аудит текущих договоров разработки, лицензионных соглашений и контрактов с поставщиками компонентов.
• Разработать регламенты взаимодействия с подрядчиками, в том числе положений об отслеживании и раскрытии уязвимостей (Coordinated Vulnerability Disclosure Policy).
• Внедрить юридические механизмы защиты для своевременного выполнения обязательств по отчетности перед ENISA.

Если у Вас есть кейс для рассмотрения – вы можете связаться с нами посредством telegram или оставив заявку на сайте. Мы изучим Вашу ситуацию и поможем найти лучший вариант решения.

Компания ALG Legal предоставляет юридические услуги по вопросам легализации, трудовового, корпоративного и налогового права в Польше, а также рассматривает вопросы защиты персональных данных, интеллектуальной собственности и IT-права.

Оставляйте заявку с описанием кейса – и мы подберем для вас лучшее решение.