27 июля 2026 года Европейская комиссия опубликовала подробное руководство по применению Regulation (EU) 2024/2847 — Cyber Resilience Act (CRA).

Документ разъясняет ряд наиболее спорных вопросов, которые до сих пор оставались не до конца определёнными для разработчиков программного обеспечения, производителей оборудования, IoT-компаний, поставщиков компонентов и open-source-проектов.

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

Главный вывод из нового руководства достаточно очевиден:

CRA не следует рассматривать как разовую процедуру сертификации. Это система непрерывного управления киберрисками на протяжении всего жизненного цикла продукта.

1. Не всё цифровое подпадает под действие CRA

Одно из наиболее важных разъяснений касается границы между программным продуктом и удалённым сервисом.

Standalone software может подпадать под действие CRA. Это может включать desktop applications, mobile applications, browser extensions и приложения, созданные с использованием web-технологий, если они поставляются пользователю и выполняются на его устройстве.

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

Это различие имеет прямое значение для SaaS-провайдеров.

Например:

мобильное банковское приложение, установленное на смартфоне, может подпадать под CRA;
browser extension также может входить в scope CRA;
локально устанавливаемое клиентское ПО может подпадать под регулирование;
web-only SaaS-приложение само по себе, как правило, не считается продуктом с цифровыми элементами.

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

2. Управление версиями ПО становится частью compliance-модели

Для традиционного оборудования понятие placing on the market относительно понятно. С программным обеспечением ситуация сложнее.

Комиссия разъясняет, что standalone software считается размещённым на рынке после завершения стадии разработки, когда конкретная версия впервые становится доступной пользователям на рынке ЕС.

Это означает, что повторные загрузки одной и той же версии не создают каждый раз новое событие placing on the market.

Например, если версия 1.0.0 впервые выпущена 1 января, а другой клиент скачивает ту же версию 15 января, обе копии считаются размещёнными на рынке в момент первоначального выпуска этой версии.

Однако ситуация меняется, если новая версия представляет собой существенную модификацию — substantial modification.

Если новая версия существенно меняет профиль киберрисков продукта, она может рассматриваться как новый продукт для целей CRA и потенциально требовать проведения новой процедуры conformity assessment.

В результате управление релизами программного обеспечения становится частью compliance-модели.

Уже недостаточно просто управлять версиями по схеме: Version 1.0 → Version 1.1 → Version 1.2

Для значимых релизов производитель должен быть способен определить:

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

Если новые или увеличенные риски ранее не рассматривались, обновление может квалифицироваться как substantial modification.

3. Новая функция может превратить обычное обновление в новое regulatory event

Комиссия приводит показательный пример.

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

С точки зрения кибербезопасности это уже не просто инструмент мониторинга.

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

Для производителей это означает, что оценка соответствия CRA должна быть встроена непосредственно в процесс разработки и выпуска новых версий.

Зрелый release pipeline должен включать отдельный regulatory security gate, в рамках которого оценивается:

изменилось ли intended purpose продукта;
появились ли новые trust boundaries;
были ли добавлены новые interfaces;
появились ли новые third-party dependencies;
изменились ли attack surface и threat model;
покрываются ли изменения существующей оценкой рисков;
может ли потребоваться новая процедура conformity assessment.

4. Open source не получает автоматического освобождения

Одна из наиболее подробно проработанных частей руководства посвящена free and open-source software.

Сам факт распространения программного обеспечения под open-source licence не означает автоматически, что оно находится вне scope CRA.

Комиссия проводит различие между:

некоммерческим FOSS;
FOSS, предоставляемым на рынке в рамках коммерческой деятельности;
платными версиями и enterprise editions;
open-core моделями;
монетизацией через другие сервисы;
монетизацией, связанной с обработкой персональных данных;
donations;
платной поддержкой;
open-source software stewards.

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

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

Например:

продажа скомпилированных binaries;
предоставление платных enterprise editions;
монетизация других услуг через программную платформу;
обязательная обработка персональных данных для рекламы или аналитики;
фактическое превращение donations в условие получения доступа к продукту или security updates.

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

При этом платная поддержка сама по себе не делает FOSS коммерческим продуктом автоматически.

Модель: Бесплатное ПО + дополнительный консалтинг

может иметь иной regulatory status, чем: Бесплатное ПО + платный доступ к обновлениям, security fixes или enterprise functionality.

Это различие особенно важно для компаний, строящих коммерческие экосистемы вокруг open-source-продуктов.

5. Contributors не становятся автоматически ответственными за весь проект

Руководство также более чётко разделяет contributors и лиц, которые фактически контролируют продукт.

Человек, который отправляет pull request или разрабатывает security patch, но не контролирует релизы, roadmap или распространение продукта, автоматически не становится ответственным за соблюдение требований CRA для всего проекта.

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

Это важное разъяснение для open-source ecosystem. Обычное участие в open-source-проекте само по себе не создаёт regulatory responsibility производителя.

6. Cloud и SaaS-зависимости необходимо разделять на разные категории

Одним из наиболее технически важных понятий в руководстве является remote data processing solutions (RDPS).

Не вся cloud infrastructure автоматически становится частью продукта.

При оценке необходимо учитывать как минимум два ключевых вопроса:

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

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

Например, smart thermostat может использовать cloud backend, разработанный производителем, но размещённый на инфраструктуре третьей стороны. Если этот backend необходим для выполнения smart-функций устройства, он может квалифицироваться как RDPS.

При этом сторонняя IaaS-инфраструктура остаётся внешней зависимостью, которую необходимо учитывать в рамках оценки рисков и due diligence производителя.

Иная ситуация возникает, когда продукт использует обычный независимый third-party SaaS.

Например, e-reader может использовать независимый SaaS storage для хранения электронных книг. Если этот сервис разработан и управляется независимым поставщиком и не находится под ответственностью производителя устройства, сам сервис автоматически не становится RDPS.

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

Необходимо учитывать:

authentication;
encryption;
protection of integrity;
отказ зависимого сервиса;
data flows;
сценарии компрометации;
риски, возникающие непосредственно из интеграции.

Основной принцип здесь простой:

Даже если внешняя система формально не является частью продукта, создаваемые ею киберриски для продукта всё равно могут требовать обработки со стороны производителя.

7. Third-party dependencies становятся предметом формального due diligence

Руководство CRA чётко разделяет два взаимодополняющих обязательства.

Cybersecurity Risk Assessment

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

Due Diligence в отношении интегрированных компонентов

Если в продукт интегрируются сторонние software или hardware components, производитель должен определить требуемые security properties этих компонентов и на основе оценки рисков убедиться, что они способны соответствовать этим требованиям.

Например, если продукт использует сторонний компонент для:

криптографических операций;
защищённой связи;
механизмов обновления;
аутентификации;
управления ключами;

производитель должен иметь достаточные доказательства того, что компонент способен обеспечить необходимые свойства безопасности.

В качестве доказательств могут использоваться:

техническая документация;
security documentation;
документы, подтверждающие соответствие;
assurance documentation;
независимое или внутреннее тестирование.

Фактически это создаёт более формализованную модель управления цепочкой поставок программного обеспечения и компонентов.

Просто сказать:

«Мы используем стороннюю библиотеку»

уже недостаточно.

Производитель должен понимать:

какую функцию выполняет компонент;
какие риски возникают в случае его компрометации;
какие security assumptions принимаются;
как эти assumptions проверяются;
что происходит при обнаружении vulnerability;
что происходит после окончания поддержки компонента;
кто отвечает за его дальнейшее сопровождение.

8. Support period — это не просто пять лет для каждого продукта

Одно из наиболее распространённых упрощений CRA заключается в утверждении:

Каждый цифровой продукт должен поддерживаться пять лет.

Руководство Комиссии показывает, что такая интерпретация слишком упрощена.

Пять лет являются минимальным ориентиром, если производитель не может обоснованно определить более короткий expected use time продукта.

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

Иными словами, пять лет не следует рассматривать как универсальный срок для любого продукта.

Производитель должен определить expected use time с учётом характера продукта и других релевантных факторов.

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

Это особенно важно для компаний, работающих по модели continuous delivery и регулярных software releases.

9. Существенная модификация не всегда перезапускает срок поддержки

Существенная модификация может потребовать повторной оценки продукта, но это не означает автоматически, что support period начинается заново.

Ключевой вопрос заключается в том, изменяет ли модификация факторы, на основании которых первоначально определялся expected use time.

Например, software update может добавить новую функциональность hardware-продукту, не влияя на физический срок службы самого устройства.

В таком случае срок поддержки может остаться привязанным к первоначально определённому expected use time.

Однако если производитель проводит серьёзную модернизацию оборудования или существенно перерабатывает core software таким образом, что это реально меняет ожидаемый жизненный цикл продукта, support period может потребовать пересмотра.

10. Одного vulnerability management недостаточно — критична скорость реакции

Одна из наиболее важных с операционной точки зрения частей руководства касается incident reporting.

Производители могут быть обязаны уведомлять соответствующий coordinated CSIRT и ENISA о:

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

Обязанности по отчётности в соответствии со статьёй 14 начинают применяться с 11 сентября 2026 года для продуктов, подпадающих под соответствующую область применения CRA, включая некоторые продукты, размещённые на рынке до полного вступления в силу основных требований CRA.

Важно, что reporting obligations могут продолжать действовать даже после окончания срока поддержки продукта.

Руководство предусматривает многоэтапную модель reporting:

early warning без необоснованной задержки и не позднее 24 часов с момента получения достаточной информации;
последующее уведомление в течение 72 часов;
финальный отчёт в установленные применимыми требованиями сроки.

Особенно важным является определение момента awareness.

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

Производитель считается осведомлённым после проведения initial assessment, когда появляется разумная степень уверенности в том, что:

уязвимость действительно активно эксплуатируется; либо
произошёл серьёзный инцидент, который привёл к компрометации безопасности продукта.

Однако сама initial assessment должна проводиться без необоснованной задержки.

Производитель не может использовать бесконечно затягиваемое расследование для искусственного переноса reporting deadline.

11. Известная уязвимость не означает автоматически, что она эксплуатируема

Руководство вводит важное практическое различие между просто обнаруженной уязвимостью и известной эксплуатируемой уязвимостью.

Информация об уязвимости может поступить из:

публичных vulnerability databases;
coordinated vulnerability disclosure;
внутреннего тестирования;
security research;
надёжных публичных источников.

Однако наличие CVE или security advisory само по себе не означает, что уязвимость применима к конкретному продукту или практически в нём эксплуатируема.

Производитель должен оценить:

applicability;
reachability;
exploitability;
реальные эксплуатационные условия;
потенциальный impact.

Это различие особенно важно для организаций, использующих Software Composition Analysis и автоматизированное vulnerability scanning.

Большое количество CVE в SBOM само по себе не доказывает несоответствие требованиям CRA.

Однако отсутствие документированного процесса оценки applicability и exploitability может стать значительно более серьёзной compliance-проблемой.

12. Vulnerability management должен работать и в направлении upstream

Если производитель выявляет уязвимость в интегрированном компоненте, CRA также регулирует взаимодействие с upstream.

В соответствующих случаях информация об уязвимости должна передаваться relevant maintainer или производителю затронутого компонента.

Если производитель самостоятельно разработал security fix для компонента, это исправление также должно быть передано upstream надлежащим способом.

Для open-source components security fixes должны распространяться с учётом применимой лицензии и модели управления соответствующим проектом.

При этом CRA не требует от производителя гарантировать, что upstream maintainer примет или включит предложенный patch.

Обязанность заключается в responsible disclosure и надлежащем распространении security fixes, а не в контроле над решениями независимого maintainer.

13. Security testing должен быть risk-driven, а не просто периодическим

Руководство также разъясняет понятие regular testing.

Регулярное тестирование не обязательно означает механическое повторение одного и того же penetration test или vulnerability scan через фиксированные интервалы.

Производитель должен регулярно учитывать новые факторы:

новые угрозы;
вновь раскрытые уязвимости;
изменения продукта;
архитектурные изменения;
новые сценарии атак;
изменения threat landscape.

Если эти изменения требуют проведения новых или модифицированных тестов, соответствующее тестирование должно быть спланировано и проведено.

Частота, глубина и scope тестирования должны соответствовать cybersecurity risk profile продукта.

Это делает CRA значительно ближе к зрелой risk-based security assurance model, а не к простой checklist-driven compliance exercise.

14. Legacy products не обязательно полностью перерабатывать

Для производителей legacy hardware и software руководство содержит важное разъяснение.

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

Если актуальная cybersecurity risk assessment показывает, что существующая архитектура и реализованные security measures адекватно покрывают relevant risks, производитель может использовать существующие меры для подтверждения compliance.

При этом всё равно необходимо:

провести актуальную оценку киберрисков;
поддерживать соответствующую техническую документацию;
пройти применимую процедуру conformity assessment;
реализовать процессы vulnerability handling;
подготовить EU Declaration of Conformity;
нанести CE marking, если это требуется.

CRA не обязательно требует задним числом восстанавливать весь исторический процесс разработки и тестирования продукта.

Основная задача — доказать, что продукт в его текущем состоянии обеспечивает appropriate level of cybersecurity с учётом intended purpose и reasonably foreseeable use.

Что производителям необходимо сделать уже сейчас

Новое руководство показывает, что подготовка к CRA не должна сводиться к созданию одной compliance matrix.

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

1. Product Scope Assessment

Определить, какие продукты, компоненты, локально устанавливаемые клиенты и remote data processing solutions подпадают под действие CRA.

2. Cybersecurity Risk Assessment

Рассматривать оценку рисков как постоянно обновляемый документ, который меняется вместе с продуктом, архитектурой, threat landscape и third-party dependencies.

3. Release Compliance Gate

Перед значимыми релизами определять, является ли изменение обычным обновлением или substantial modification.

4. Dependency Governance

Для критических software и hardware components необходимо определить:

security requirements;
статус maintainer или supplier;
статус поддержки;
процессы vulnerability management;
доступные security evidence;
риски, возникающие в результате интеграции.

5. Vulnerability Management и Coordinated Disclosure

Необходимо иметь документированные процессы для:

приёма и triage уязвимостей;
оценки applicability;
анализа exploitability;
remediation;
коммуникации с клиентами;
уведомления upstream;
передачи security fixes.

6. Incident Reporting Readiness

Организации, потенциально подпадающие под reporting obligations Article 14, должны заранее иметь работающий процесс initial assessment, escalation и regulatory reporting.

При сроке первоначального уведомления в 24 часа практически не остаётся времени для принятия решений с нуля уже во время инцидента.

7. Support Lifecycle Management

Для каждого релевантного продукта необходимо определить и документировать:

expected use time;
применимый support period;
обязанности по vulnerability handling;
порядок уведомления об окончании поддержки.

Заключение

Главное изменение, которое отражает новое руководство, — переход CRA от абстрактной нормативной базы к конкретным требованиям в области engineering и governance.

Compliance всё теснее связывается с тем, как организация:

проектирует свои продукты;
выполняет threat modelling;
управляет версиями программного обеспечения;
принимает архитектурные решения;
использует cloud и SaaS;
управляет third-party dependencies;
работает с open-source components;
обрабатывает уязвимости;
проводит security testing;
управляет жизненным циклом и поддержкой своих продуктов.

Для зрелых организаций это означает необходимость интегрировать требования CRA в существующие процессы Secure SDLC, product governance, vulnerability management и third-party risk management.

Для менее зрелых организаций основной риск заключается не просто в отсутствии политики CRA или отдельного compliance-документа.

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

Именно эта связь между cybersecurity engineering и regulatory compliance, судя по новому руководству Европейской комиссии, станет одним из центральных элементов практического применения Cyber Resilience Act.