Кратко
- С 11 сентября 2026 года производители продуктов с цифровыми элементами обязаны уведомлять об активно эксплуатируемых уязвимостях и серьёзных инцидентах безопасности. Раннее предупреждение направляется не позднее 24 часов после осведомления, более полное уведомление — не позднее 72 часов.
- Single Reporting Platform создаёт единое место подачи, но не единственный центр власти. Производитель выбирает национальный координирующий CSIRT, который обычно распространяет сообщение; ENISA управляет платформой. На старте интерфейс доступен только по-английски, API отсутствует, добровольные сообщения не принимаются, а обязанности распорядителей ПО с открытым исходным кодом ещё не начались.
Европейский режим безопасности цифровых продуктов сначала включил сигнализацию, а уже потом собирается вводить основные требования к зданию.
Большая часть обязательств Cyber Resilience Act — безопасная разработка, обработка уязвимостей, документация и соответствие — станет в целом применимой 11 декабря 2027 года. Но статья 14 начала действовать 11 сентября 2026 года. Это разделение прямо отражено в графике European Commission.
Теперь производитель, узнавший об активно эксплуатируемой уязвимости или об инциденте с серьёзным влиянием на безопасность охватываемого продукта, попадает в последовательность сроков. Раннее предупреждение необходимо направить без неоправданной задержки и в любом случае в пределах 24 часов. Уведомление с общими сведениями и первоначальной оценкой должно быть подано за 72 часа.
Разъяснение European Commission устанавливает разные финальные этапы. Для активно эксплуатируемой уязвимости окончательный отчёт требуется не позднее 14 дней после появления корректирующей или смягчающей меры. Для серьёзного инцидента он подаётся в течение месяца после 72-часового уведомления.
Ключевое слово здесь — «узнал». Срок не ждёт открытия портала, совещания правления или полной атрибуции атакующего. Поэтому первый орган управления расположен внутри компании: он определяет, какое достоверное свидетельство превратило подозрение в событие, подлежащее сообщению, и кто зафиксировал этот момент.
Переходный период до конца 2027 года не является свободным от отчётности. Продукты, уже предлагаемые на рынке ЕС, могут вызвать обязательство сегодня, если входят в сферу закона. Канал наблюдения начинает работать раньше полного набора превентивных правил.
Одна подача проходит через несколько мандатов
Single Reporting Platform ENISA избавляет производителя от повторной подачи одного события в каждое государство. Одного уведомления достаточно, даже если у группы несколько филиалов и дочерних компаний в ЕС или материнская компания находится за его пределами. Внутреннюю координацию всё равно обеспечивает производитель.
В форме он выбирает CSIRT, назначенный координатором. Как правило, выбор определяется основным местом учреждения производителя. Ответственность за правильный адрес остаётся на заявителе. Опубликованный ENISA список координаторов тем самым превращается из справочника в таблицу юридической маршрутизации.
В обычном режиме уведомление становится доступно выбранному CSIRT и ENISA. Первый получатель без задержки передаёт его соответствующим CSIRT в тех странах-членах, где продукт был доступен. Информация также может поступать органам надзора за рынком в объёме, необходимом для правоприменения.
У каждой стороны своя поверхность контроля. Производитель владеет знанием о продукте и событии. Национальный CSIRT проводит первичную оценку и управляет распространением. ENISA обслуживает общую инфраструктуру и видит европейский поток. Рыночный надзор решает вопрос о проверке и исправлении.
Поэтому техническое подтверждение приёма — не доказательство всей цепочки. FAQ ENISA предупреждает: выбор неверного координатора может сделать уведомление недействительным и потребовать повторной подачи. Карта производителя должна заранее связывать юридическое лицо, основное учреждение и страны доступности продукта.
Просьба об исключении не равна решению
Немедленное широкое распространение подробностей об эксплуатируемой уязвимости иногда само создаёт дополнительный риск. Для 72-часового уведомления предусмотрен узкий режим Particularly Exceptional Circumstances, или PEC.
В операционной инструкции ENISA заявитель отмечает возможное исключение и может обосновать его. Но задержку распространения решает координирующий CSIRT, а не компания.
Если основание принято, ENISA вначале получает только ограниченную информацию. Национальный координатор остаётся ответственным за решение о том, когда полное уведомление можно передать ENISA и заинтересованным CSIRT.
Этот механизм не предоставляет производителю одностороннего права на секретность и не охватывает автоматически любой чувствительный инцидент. Проверяемая запись должна отдельно показывать запрос, основание, решение органа и момент снятия задержки. Иначе координированное раскрытие и простое отсутствие сообщения выглядят одинаково.
Первая версия не равна будущей платформе
На старте портал принимает обязательные уведомления производителей об активно эксплуатируемых уязвимостях и серьёзных инцидентах. Добровольная функция статьи 15 будет добавлена позже. Тем, кто не является производителем, пока предлагается обращаться в соответствующий национальный CSIRT.
Обязанности распорядителей программного обеспечения с открытым исходным кодом по статье 24(3) начинаются только 11 декабря 2027 года. Упоминание этой группы среди будущих пользователей не переносит дату вперёд.
Интерфейс доступен только на английском языке. API в первоначальном выпуске нет. Организации могут автоматизировать внутренний сбор и согласование, но формальное действие остаётся ручным. Для производителя с большим каталогом продуктов дежурства, резервные представители и готовность учётных записей становятся частью пропускной способности контроля.
Назначенные представители используют личные учётные записи EU Login с многофакторной аутентификацией. Координатор проверяет связь человека с производителем. Руководство по регистрации предусматривает параллельную проверку, не блокирующую срочную подачу: до обязательного подтверждения непроверенный представитель может отправить до 20 уведомлений для этого производителя.
Практический вывод прост. Юридическое лицо, юрисдикцию, основного и резервного представителя, доступ и многофакторную проверку следует готовить до инцидента. Делать это после технического сигнала — значит тратить 24-часовой срок на административную настройку.
Экранный счётчик не переписывает статью 14
ENISA открыто описывает особенность текущей реализации. Счётчик 72-часового уведомления показывает момент через 48 часов после подачи 24-часового предупреждения. Закон же считает 72 часа от осведомления производителя. Если раннее предупреждение было отправлено быстро, интерфейс может пометить уведомление просроченным до фактического окончания законного срока. ENISA планирует перевести расчёт на поле времени осведомления.
Это не сокращение правовой нормы. Это наглядное различие между правилом и исполняющим его кодом. Производителю нужны отдельные поля для времени и основания осведомления, ранней подачи, собственного 72-часового расчёта, значения портала и каждого подтверждения.
Позднее напоминание тоже не продлевает срок, который начался раньше. Выбирать наиболее удобные часы между внутренней системой и экраном нельзя; их нужно сверять и объяснять расхождения.
Временная недоступность требует такой же дисциплины. ENISA предлагает дождаться восстановления и затем подать через платформу. При необходимости срочной связи можно обратиться к национальному CSIRT напрямую, но последующая подача всё равно обязательна. Один неудачный сетевой запрос не доказывает общий простой сервиса.
Публичная версия правил без раскрытия целей
Для проверки механизма обществу не нужны сведения о незакрытой уязвимости, название продукта или личность заявителя. Нужна история того, какие функции работали в конкретный момент.
ENISA могла бы публиковать безопасный журнал состояния и версий: доступность, разрешённые классы заявителей, поддерживаемые типы отчётов, языки, состояние API, логику счётчиков и время действия каждого изменения. Такой журнал не раскрывает угрозу, но позволяет связать действие с фактической конфигурацией.
Это моя редакционная рекомендация, а не действующее требование CRA и не обещание ENISA. Метод задают три текста Lu Heng. The Policy Mirror заставляет назвать носителя полномочия; Running Code Primary — проверить фактически исполняемую конфигурацию; Why BTW Media Exists — не выдавать желаемое состояние учреждения за наблюдаемый факт.
Европа объединила дверь. Все решения за ней остаются распределёнными — и каждое должно сохранять своего автора и время.
Источники
- FAQ ENISA о CRA Single Reporting Platform
- Обзор Single Reporting Platform
- Руководство по регистрации представителей
- Руководство по подаче и обновлению уведомлений
- Руководство по Particularly Exceptional Circumstances
- Список координирующих CSIRT
- European Commission: обязанности CRA по уведомлению
- European Commission: обзор Cyber Resilience Act
- Regulation (EU) 2024/2847
- European Commission: график внедрения
- The Policy Mirror
- Running Code Primary
- Why BTW Media Exists
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
