Якщо ваша компанія робить hardware - промисловий контролер, систему безпеки, медичний пристрій, розумний замок або будь-який інший підключений пристрій - і ви продаєте або плануєте продавати його в Євросоюзі, у вас є рівно три місяці до першого обов'язкового дедлайну.
11 вересня 2026 року набирає чинності стаття 14 Cyber Resilience Act - регуляції ЄС яка вперше встановлює обов'язкові вимоги до кібербезпеки для всіх підключених продуктів на європейському ринку. І вона стосується не лише компаній з Німеччини чи Польщі, а й будь-якого виробника, чий продукт потрапляє на полиці в ЄС - незалежно від того, де зареєстрована компанія.
Чому це стосується українських компаній
Багато хто думає, що CRA - це "для них там в Європі". Насправді регуляція написана так, що охоплює будь-який продукт із цифровими елементами, який розміщується на ринку ЄС. Якщо ви продаєте через дистриб'ютора в Польщі, через Amazon EU або напряму корпоративному клієнту в Німеччині - ви підпадаєте під дію CRA.
Українські компанії, що виходять або вже присутні на ринку ЄС, - Ajax Systems, Petcube, Hideez та десятки менших hardware стартапів - всі вони зараз стикаються з тим самим питанням: що конкретно потрібно зробити і коли.
Два дедлайни які не можна ігнорувати
11 вересня 2026 - набирає чинності стаття 14. Це вимога обов'язкової звітності про вразливості: якщо у вашому продукті виявлено активно експлуатовану вразливість, ви зобов'язані протягом 24 годин повідомити ENISA (Агенцію ЄС з кібербезпеки) через їхню платформу. Протягом 72 годин - надати детальний звіт, протягом 14 днів - фінальний.
Важливо: ця вимога поширюється на всі продукти, які вже є на ринку ЄС - незалежно від дати їх виходу. Немає ніякого "дідівського" виключення. Якщо ваш пристрій продавався три роки тому і досі використовується - він підпадає під вимогу з 11 вересня.
11 грудня 2027 - повне застосування CRA. До цього дедлайну всі нові продукти, які виходять на ринок ЄС, мають відповідати повному переліку вимог: безпека за замовчуванням, Secure Boot, унікальна ідентифікація пристрою, захищені оновлення прошивки, SBOM (Software Bill of Materials), модель загроз і технічна документація для підтвердження відповідності.
Що таке SBOM і чому це не просто формальність
SBOM - Software Bill of Materials - це повний перелік програмних компонентів у вашому продукті. Для embedded пристроїв це означає: всі бібліотеки з відкритим кодом, RTOS, SDK від постачальника чіпа, завантажувач - кожен компонент з версією та ідентифікатором.
CRA вимагає мати SBOM, підтримувати його в актуальному стані і надавати органам ринкового нагляду на запит. Але важливіше інше: без SBOM ви не можете систематично перевіряти, чи з'явилися нові CVE для компонентів у вашому продукті. А без цього моніторингу виконати вимогу 24-годинного повідомлення про вразливості фізично неможливо.
Тобто SBOM - це не документ заради документа. Це інфраструктура яка дозволяє вам взагалі знати що відбувається з безпекою вашого продукту після релізу.
Детально про вимоги до SBOM для embedded продуктів і практичний підхід до його створення можна прочитати тут.
Чим відрізняється "вбудовано з початку" від "додано пізніше"
Це питання, яке зараз стоїть перед кожною командою що розробляє hardware для ЄС.
Якщо безпека закладена в архітектуру продукту з першого дня - Secure Boot, Device Identity, захищений OTA - це стає звичайною частиною R&D. Один інженер, кілька тижнів роботи, стандартна бюджетна стаття.
Якщо продукт вже випущений і потребує доопрацювання - картина інша: заміна компонентів, повторне тестування, перероблена архітектура прошивки, затримка з виходом оновлень. Кожен місяць очікування збільшує цю прірву.
Це не абстрактна аргументація. Виробники які зараз починають підготовку мають значно більше варіантів ніж ті хто чекатиме до кінця 2027.
Як виглядає CRA вимоги на практиці для embedded продукту
Якщо спростити: ваш продукт після 11 грудня 2027 має вміти:
Завантажуватися тільки з перевіреної прошивки (Secure Boot)
Мати унікальний ідентифікатор і сертифікат (Device Identity)
Отримувати безпечні оновлення з перевіркою цілісності (Secure OTA)
Мати актуальний SBOM з усіма компонентами
Бути задокументованим з точки зору загроз (Threat Model)
Підтримувати процес звітування про вразливості
Повний огляд вимог Annex I та практичний план відповідності для виробників IoT і hardware - в цьому гайді.
Що робити зараз
Перший крок - зрозуміти до якого класу ризику відноситься ваш продукт за класифікацією CRA. Більшість IoT пристроїв потрапляють у категорію Default або Important Class I - для них вимоги відрізняються, і від цього залежить чи потрібна стороння сертифікація.
Другий крок - оцінити поточний стан: що з перелічених вище вимог вже виконано, що відсутнє, де найбільший gap.
Третій крок - вирішити чи займатися цим власними силами або із зовнішньою командою. Для компаній без внутрішньої embedded security експертизи другий варіант часто дешевший і швидший - особливо якщо дедлайн уже за три місяці.
Якщо ваша компанія продає або планує продавати hardware в ЄС і ви ще не починали підготовку до CRA - зараз найкращий момент щоб розібратися де ви знаходитесь. Команда Platanor Technologies спеціалізується саме на embedded security для IoT виробників і може допомогти оцінити поточний стан і скласти конкретний план.
