Cyber Resilience Act: обязанности уведомления с 11 сентября 2026 года

Компания, разрабатывающая программное обеспечение, узнаёт, что уязвимость её продукта уже используется в реальных атаках. С 11 сентября 2026 года, если продукт и компания подпадают под действие Cyber Resilience Act, реагирование не ограничивается выпуском обновления безопасности: возникает конкретная процедура уведомления. Первый предельный срок — 24 часа с момента, когда производителю стало известно об активной эксплуатации уязвимости.

Для греческого предприятия, которое разрабатывает приложения или поставляет подключённые устройства, практические вопросы таковы: кто выявляет событие, кого уведомляют внутри организации и кто своевременно направляет сообщение компетентным органам?

Что начинается в сентябре, а что остаётся на 2027 год

CRA — это Регламент (ЕС) 2024/2847, который непосредственно применяется в государствах-членах, в том числе в Греции. Его основные требования к продуктам начинают применяться, по общему правилу, с 11 декабря 2027 года. Однако обязанности производителей по уведомлению, предусмотренные статьёй 14, применяются раньше — с 11 сентября 2026 года.

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

Какие продукты и предприятия охватываются

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

Само использование программы не делает предприятие её производителем. Кроме того, информационный сайт или приложение, работающее исключительно через браузер и не обеспечивающее функцию охватываемого продукта, не подпадает под CRA автоматически. Напротив, необходимая удалённая обработка данных, за которую отвечает производитель, может составлять часть продукта.

Свободное программное обеспечение с открытым исходным кодом, предоставляемое вне коммерческой деятельности, исключено из сферы CRA. Это не освобождает автоматически все продукты, содержащие открытые компоненты. Обозначения «бесплатно» недостаточно: следует изучить способ предоставления и экономического использования. Для организаций, поддерживающих открытое программное обеспечение, предусмотрен отдельный режим с соответствующими обязанностями с 11 декабря 2027 года. Есть и отраслевые исключения, например для продуктов, охватываемых определёнными правилами ЕС о медицинских изделиях. Руководство Комиссии от 27 июля 2026 года помогает провести индивидуальную оценку.

Когда возникает обязанность уведомления

Статья 14 охватывает две категории:

• Активно эксплуатируемая уязвимость: имеются надёжные доказательства того, что злоумышленник использовал уязвимость без разрешения владельца системы.
• Серьёзный инцидент, влияющий на безопасность продукта: выполнены критерии статьи 14(5), например фактическое или потенциальное воздействие на защиту важных данных или функций либо возможность внедрения или выполнения вредоносного кода.

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

Сроки в 24 часа, 72 часа и срок окончательного отчёта

Первые два сообщения направляются без неоправданной задержки, в пределах указанных ниже максимальных сроков. Срок в 72 часа отсчитывается от того же момента осведомлённости, а не от предыдущего сообщения.

Таким образом, у срока окончательного отчёта в этих двух категориях разные начальные моменты. Уведомление на 72-часовом этапе содержит имеющуюся информацию и меры реагирования; завершения всего технического расследования для него не требуется. См. обзор Комиссии об обязанностях уведомления.

Пример, позволяющий не перепутать даты

Предположим, что производителю охватываемого приложения стало известно об активной эксплуатации в понедельник, 14 сентября 2026 года в 10:00. Раннее предупреждение необходимо направить не позднее 15 сентября в 10:00. Предельный срок уведомления на 72-часовом этапе — 17 сентября в 10:00.

Если первая исправляющая мера или мера по снижению риска стала доступна 18 сентября, окончательный отчёт должен быть направлен не позднее 2 октября. Компания не ждёт готовности исправления, чтобы отправить первые уведомления.

Пример относится к уязвимости. Для серьёзного инцидента месячный срок окончательного отчёта отсчитывается от направления уведомления на 72-часовом этапе. Даты в примере условные и указаны в одном часовом поясе.

Куда направлять уведомление и что подготовить

Процедура осуществляется через единую платформу CRA — Single Reporting Platform — SRP. В соответствии с Регламентом получателями выступают компетентная координирующая группа CSIRT и ENISA. В разъяснениях от 8 сентября ENISA указывает, что начало работы запланировано на 11 сентября 2026 года. Это не подтверждает, что обычная подача сообщений уже доступна.

Практическая проверка готовности производителя включает:

1. Перечень продуктов: версии, ответственные лица, критически важные компоненты и рынки поставки.
2. Понятный маршрут оповещения: кто принимает сообщения клиентов или исследователей и кто немедленно их оценивает.
3. Ответственного и его заместителя: полномочия на отправку, актуальные контакты и подготовленный персональный EU Login с многофакторной аутентификацией.
4. Журнал события: момент осведомлённости, технические сведения, решения, отправленные сообщения и дата доступности мер.
5. Подготовленную информацию для пользователей: какая версия затронута и какие конкретные действия они могут предпринять.
6. Учение с условным событием: проверку того, укладывается ли внутреннее взаимодействие в установленные законом сроки.

Это практическое предложение по организации работы. ENISA рекомендует начинать регистрацию производителя в SRP, когда требуется направить сообщение, при уже активном EU Login представителя. Детали следует проверять по действующим официальным инструкциям платформы.

Почему GDPR и NIS2 требуют отдельной проверки

Сообщение по CRA не следует считать автоматическим исполнением всех других обязанностей. GDPR регулирует нарушения безопасности персональных данных. Статья 33 предусматривает, когда это требуется, уведомление компетентного надзорного органа контролёром без неоправданной задержки и, по возможности, в течение 72 часов с момента осведомлённости. Исключение действует, если нарушение с малой вероятностью создаёт риск для прав и свобод физических лиц. См. руководство Европейского совета по защите данных.

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

Краткие ответы на частые вопросы

Распространяются ли правила на уже выпущенные продукты?

Да. Обязанности уведомления охватывают и продукты в сфере действия CRA, выведенные на рынок до 11 декабря 2027 года. Более ранняя дата выпуска сама по себе не даёт исключения.

Нужно ли задним числом сообщать о каждой старой уязвимости?

ENISA поясняет, что ретроспективной обязанности нет в отношении активной эксплуатации, о которой производителю уже было известно до 11 сентября 2026 года. Важен момент осведомлённости, а не только возраст ошибки.

Достаточно ли уведомить органы?

Статья 14(8) также предусматривает информирование затронутых пользователей, включая необходимые меры снижения риска. Техническое сообщение органам и понятная инструкция пользователю служат разным целям.

По переходным ситуациям см. ответы ENISA и статьи 14, 69 и 71 CRA.

Редакционная группа Nomika Epilekta
Официальные источники проверены 9 сентября 2026 года.

Статья подготовлена с помощью искусственного интеллекта и сверки приведённых официальных источников. Она содержит общую правовую информацию и не заменяет оценку конкретного дела. Источники проверены 9 сентября 2026 года.