Cyber Resilience Act: как уведомлять ENISA за 24/72 часа

11 сентября 2026 года начинает действовать одно из самых срочных требований европейского Cyber Resilience Act — более чем за год до большинства норм регламента. Если изготовитель узнает об активно эксплуатируемой уязвимости или серьезном инциденте в безопасности продукта, на раннее предупреждение может остаться лишь 24 часа, а на развернутое уведомление — 72.

Практическая подготовка — это не еще одна политика в PDF. Нужен отдельный маршрут инцидента: определить продукт и роль изготовителя, проверить критерии CRA, зафиксировать момент осведомленности, собрать минимальное уведомление и вести инженеров, юристов, поддержку и руководство через одну карточку.

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

Что изменится 11 сентября 2026 года

Регламент ЕС о киберустойчивости вступил в силу в декабре 2024 года. Основная часть требований применяется с 11 декабря 2027 года, но статья 14 об уведомлениях — уже с 11 сентября 2026-го. Она касается изготовителей продуктов с цифровыми элементами, предоставляемых на рынке ЕС. Еврокомиссия относит к ним аппаратные и программные продукты, предусмотренное или обоснованно ожидаемое использование которых включает прямое либо косвенное соединение с устройством или сетью.

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

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

Как проверить продукт и роль компании

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

Разработчик не всегда является изготовителем по CRA. Как правило, это физическое или юридическое лицо, выводящее продукт на рынок под своим именем либо товарным знаком. При этом заказ разработки подрядчику не обязательно переносит ответственность изготовителя. Чисто облачные сервисы и свободное ПО требуют отдельного анализа. Разъяснения Еврокомиссии от июля 2026 года отдельно рассматривают удаленную обработку данных, open source, сроки поддержки, существенные изменения и отчетность.

Для каждого продукта или семейства запишите юридическое лицо-изготовителя, основное представительство в ЕС либо уполномоченного представителя, ответственную CSIRT, страны продаж, поддерживаемые версии, компоненты и как минимум двух сотрудников для подачи уведомлений. На восемнадцатом часу инцидента восстанавливать это поздно.

Два разных основания для уведомления

Неисправленная уязвимость не становится автоматически предметом статьи 14. Для первого основания нужны надежные доказательства того, что злоумышленник уже эксплуатировал ее в системе без разрешения владельца. Proof of concept, сигнал сканера, высокий CVSS или письмо исследователя требуют быстрой проверки, но сами по себе не обязательно доказывают активную эксплуатацию.

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

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

Как работают сроки 24/72 часа

FAQ агентства ENISA по SRP, обновленный 31 августа 2026 года, описывает такую последовательность:

1. До 24 часов с момента осведомленности: без неоправданной задержки подайте раннее предупреждение. Укажите изготовителя, продукт, тип уведомления, заголовок и, где это известно или требуется, государства-члены либо подозрение на злоумышленные действия.
2. До 72 часов с момента осведомленности: дополните ту же карточку общими сведениями, первоначальной оценкой, уже принятыми мерами, советами пользователям и оценкой чувствительности. Это 72 часа всего, а не после первого сообщения.
3. Для активно эксплуатируемой уязвимости: итоговый отчет подается не позднее чем через 14 дней после появления исправления или другой меры.
4. Для серьезного инцидента: итоговый отчет подается в течение месяца после 72-часового уведомления.

Раннее предупреждение рассчитано на неполные сведения. Не ждите точной атрибуции, полного масштаба или root cause. Разделите подтвержденные факты, рабочие гипотезы и неизвестное, затем обновляйте ту же карточку.

По состоянию на 3 сентября ENISA обещает опубликовать адрес SRP до запуска. Уполномоченные представители входят через персональный EU Login с двухфакторной аутентификацией. У изготовителя может быть один Primary AR и до 20 Secondary AR. Проверка представителя идет параллельно и не блокирует подачу. Порядок еще меняется, поэтому при каждом событии проверяйте актуальную страницу SRP.

Единая карточка доказательств и решений

Тикет, разбросанный между мессенджером, почтой, сканером и юридической таблицей, не выдержит три дедлайна. Создайте защищенную карточку с постоянным идентификатором и журналом решений, не перезаписывающим историю.

cra_case
  case_id + notification_type
  manufacturer + product + affected_versions
  signal_received_at + awareness_at + rationale
  exploitation_evidence + severity_test
  eu_markets + csirt_coordinator
  containment + user_mitigation + corrective_measure
  confirmed_facts + hypotheses + unknowns
  sensitivity + disclosure_decision
  reporter + approver + deputies
  24h_due + 72h_due + final_due
  srp_reference + receipts + change_log

Обращайтесь с карточкой как с чувствительными данными безопасности: ролевой доступ, журнал изменений, копии отправленных полей и квитанций, согласованный срок хранения. Не вставляйте детали эксплойта в общие каналы или универсальный ИИ-чат. Система должна считать сроки от awareness_at, показывать часовой пояс и вызывать резервного ответственного, если основной не подтвердил задачу.

Рабочий процесс вместо формы

ENISA уже опубликовала поля формы, но ее заполнение — последний этап. Главная работа происходит раньше.

• Прием: безопасность, поддержка, исследователи, мониторинг, поставщики и клиенты могут открыть одну приоритетную карточку.
• Триаж: владельца продукта и компонента находят в поддерживаемом реестре или SBOM.
• Решение: безопасность дает доказательства, юристы проверяют сферу и критерии, руководитель инцидента следит за временем.
• Подача: два обученных представителя имеют доступ к EU Login и SRP; согласующий видит точный payload.
• Реагирование: инженеры, поддержка и коммуникации работают с согласованными фактами и мерами.
• Закрытие: итоговый отчет, патч, действия для клиентов, квитанции и выводы остаются связанными.

Автоматизируйте напоминания, поиск продукта, расчет сроков, проверку обязательных полей и снимки доказательств. Решение об отчете и внешнюю отправку оставьте под контролем ответственного человека. По данным ENISA, на старте API не будет, поэтому предусмотрите надежный ручной шаг, а не хрупкую браузерную автоматизацию.

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

Проведите 90-минутное учение

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

1. Запустите часы, когда доказательство поступило в выбранный канал.
2. Найдите изготовителя, продукт, страны ЕС, версии, компонент и CSIRT.
3. Составьте 24-часовое уведомление только из известных фактов.
4. Назначьте владельцев неизвестного для 72-часового обновления.
5. Смоделируйте отсутствие Primary AR и передачу Secondary AR.
6. Подготовьте безопасный совет пользователям без деталей, полезных атакующему.
7. Зафиксируйте задержки и дайте каждому исправлению дату и владельца.

Измеряйте время до триажа, решения об осведомленности, нехватку данных о продукте, задержку согласования и способность резервного сотрудника завершить процесс. Результат — не красивые слайды, а доказательство, что команда подаст фактическое предупреждение за 24 часа, не останавливая защиту.

Частые вопросы

Когда начинается обязательная отчетность по CRA?

11 сентября 2026 года. Большинство других требований регламента применяется с 11 декабря 2027 года.

Это касается продуктов, проданных до декабря 2027 года?

Да. Еврокомиссия уточняет, что отчетность охватывает цифровые продукты, уже предоставленные на рынке ЕС. Но сферу продукта и роль вашей компании нужно подтвердить отдельно.

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

Нет. Обязательный критерий касается уязвимости с надежными доказательствами активной злоумышленной эксплуатации. Серьезный инцидент — отдельное основание. Остальные уязвимости все равно требуют надлежащей обработки.

72 часа считают после первого уведомления?

Нет. Оба срока считают с момента осведомленности. После своевременного раннего предупреждения на второй этап остается не более 48 часов.

Можно ждать окончательной причины?

Нет. Первое уведомление подается с доступными данными. Отметьте факты, гипотезы и неизвестное, а затем обновите карточку.

Есть ли API для автоматической отчетности в ENISA?

В FAQ от 31 августа ENISA указывает, что на первом этапе API не будет. Автоматизируйте внутреннюю подготовку, но оставьте проверенный ручной шаг в SRP.

Сделайте первые 24 часа воспроизводимыми

Срок CRA выявляет системную проблему: владельцы продуктов, компоненты, страны продаж, решения во время инцидента и доступ к отчетности не могут жить в разных хранилищах. Одна карточка, определенная команда, два представителя и одно реалистичное учение полезнее ста страниц политики.

Rendframe может спроектировать маршрут product security, связать записи продуктов и компонентов, создать контролируемый инструмент для инцидентов и проверить передачу между командами. Изучите материал о безопасном внедрении ключей доступа, посмотрите разработку цифровых продуктов или пришлите нам обезличенную временную шкалу одного инцидента для предметного разбора.