EU Cyber Resilience Act стане найвпливовішою регуляцією кібербезпеки для виробників продуктів на європейському ринку. Перші зобовʼязання діють із 2026 року (звітування про вразливості та інциденти), а повне застосування — включно з оцінкою відповідності для CE-маркування — настає у 2027-му.
Якщо ваша компанія виробляє продукт із цифровими елементами і виводить його на ринок ЄС, CRA до вас застосовується. Пороги не залежать від розміру компанії — вони залежать від класу продукту. Ця стаття розбирає, як має виглядати ваш план оцінки відповідності і яку роботу варто робити вже зараз, а не наприкінці 2026-го.
Зона дії: хто підпадає?
«Продукт із цифровими елементами» мовою CRA — це будь-який програмний чи апаратний продукт, що обробляє дані та має логічне або фізичне зʼєднання. Це включає:
- Підключені споживчі продукти (камери, пристрої розумного дому, носимі гаджети).
- Компоненти промислової автоматизації та ПЛК.
- Програмні продукти, що продаються чи ліцензуються в ЄС, включно з SaaS у деяких трактуваннях (граничні випадки досі уточнюються настановами Європейської комісії).
- Операційні системи, браузери, продукти безпеки, продукти ідентифікації.
- Прямо виключені: SaaS, що не кваліфікується як «продукт» за регламентом, вільне програмне забезпечення з відкритим кодом, розроблене поза комерційною діяльністю, та кілька галузевих продуктів, покритих іншими регуляціями (медичні вироби за MDR, транспортні засоби).
Додаток I — суттєві вимоги кібербезпеки
Додаток I короткий і суворий. Продукт має:
- Бути спроєктованим, розробленим і виробленим так, щоб забезпечити належний рівень кібербезпеки.
- Не мати відомих експлуатовних вразливостей на момент виведення на ринок.
- Мати безпечну конфігурацію за замовчуванням.
- Підтримувати безпекові оновлення протягом усього періоду підтримки (який CRA вимагає задекларувати).
- Захищати конфіденційність збережених, переданих та оброблюваних даних, із криптографією за замовчуванням, де це доречно.
- Захищати цілісність збережених, переданих та оброблюваних даних.
- Обробляти лише дані, що є адекватними, релевантними та обмеженими необхідним.
- Захищати доступність основних функцій.
- Мінімізувати вплив інцидентів.
- Надавати повʼязану з безпекою інформацію через належні механізми (логи, телеметрія).
- Дозволяти усувати вразливості через безпекові оновлення, включно з автоматичними оновленнями за замовчуванням для споживчих продуктів.
Вимога «жодних відомих експлуатовних вразливостей на момент виведення на ринок» — найбільша поведінкова зміна для продуктових команд, звиклих випускати реліз зі списком відомих багів.
Додаток II — обробка вразливостей
Додаток II — це процес обробки вразливостей, який ви маєте підтримувати протягом усього життя продукту:
- Ідентифікувати та документувати компоненти продукту, зокрема створюючи software bill of materials (SBOM) у загальновживаному форматі.
- Усувати вразливості без зволікань, зокрема через безпекові оновлення.
- Регулярно та ефективно тестувати безпеку продукту.
- Координувати розкриття вразливостей, зокрема з Агентством ЄС із кібербезпеки (ENISA).
- Надати контакт для повідомлень про вразливості.
- Передбачити механізми безпечного розповсюдження оновлень.
- Забезпечити оперативне публічне розкриття усунутих вразливостей, включно з описом, впливом і коригувальними заходами.
Стаття 14 — звітування про інциденти та експлуатовані вразливості
CRA запроваджує два окремі зобовʼязання щодо звітування:
- Про «активно експлуатовану вразливість» треба повідомити ENISA протягом 24 годин з моменту виявлення, з доповненням протягом 14 днів. Поріг «активної експлуатації» — це експлуатація «в дикій природі», а не теоретична можливість.
- Про «серйозний інцидент із впливом на безпеку продукту» треба повідомити ENISA протягом 24 годин, з доповненнями протягом 72 годин і 1 місяця.
Маршрути оцінки відповідності
Маршрут залежить від класу продукту. Більшість продуктів використовуватиме Модуль A — внутрішній контроль виробництва плюс самодекларація. Важливі продукти (Клас I і Клас II) вимагають Модуля B+C, Модуля D або Модуля H, залежно від класу. Критичні продукти вимагають залучення нотифікованого органу.
Для більшості програмних продуктів практичний пакет оцінки відповідності виглядає так:
- Документована оцінка кіберризиків продукту.
- Докази практик безпечної розробки (радимо мапувати на ISO/IEC 27034 та IEC 62443-4-1).
- Звіт пентесту за вимогами додатка I, в ідеалі з повторним тестом перед кожним релізом.
- SBOM у загальновживаному форматі (CycloneDX або SPDX).
- Політика обробки вразливостей і докази роботи процесу.
- Задекларований період підтримки та опублікована політика безпекових оновлень.
- Декларація відповідності ЄС — юридичний результат оцінки.
Що робити у 2026 році
- Побудуйте SBOM-пайплайн уже сьогодні. CycloneDX або SPDX, генерація в CI, прикріплення до релізів. Це найдовша за часом робота, яку найлегше недооцінити.
- Запустіть процес координованого розкриття вразливостей із чітким контактом (security.txt, див. RFC 9116).
- Проведіть аналіз відповідності додатку I CRA для вашого найстратегічнішого продукту. Знахідки визначать продуктовий беклог 2026 року.
- Визначте період підтримки. Два роки — фактичний мінімум; багато регуляторів промацуватимуть пʼять.
- Задокументуйте життєвий цикл безпечної розробки. Аудитор читає те, що ви написали, а не те, що ви розповідаєте усно.
Де тут Sandline
Ми проводимо передринкові оцінки безпеки продуктів за додатком I, запускаємо процес координованого розкриття вразливостей, генеруємо SBOM і виконуємо аналіз прогалин. Заява про відповідність — ваша; ми готуємо технічні докази під нею.