Акт ЄС про кіберстійкість набирає сили: що командам IoT потрібно підготувати до 2027 року
11 червня 2026 року в Європейському Союзі відбулася подія без гучних заяв, але з дуже практичними наслідками. Держави-члени ЄС мали визначити органи нотифікації. Саме ці органи відповідають за те, хто зможе оцінювати під’єднані продукти відповідно до Акта про кіберстійкість, або Cyber Resilience Act, CRA.
Без пресконференцій і гучних заголовків. Але це перший важливий етап у регуляторному ланцюгу, який змінить підхід компаній до проєктування, випуску та підтримки під’єднаного обладнання й вбудованого програмного забезпечення, що продається на ринку ЄС.
Якщо у вашій продуктовій стратегії є пристрої з мікросхемами, сенсорами або механізмом оновлення вбудованого програмного забезпечення, це вже зона уваги CRA. Йдеться про промислові контролери, телематику для автопарків, пристрої для розумної роздрібної торгівлі, носимі пристрої, під’єднані компоненти та інші цифрові продукти, які потрапляють на ринок ЄС. Місце реєстрації компанії або країна виробництва не є визначальними. Важливо те, що продукт розміщується на ринку Європейського Союзу. Це випливає з огляду Європейської комісії щодо Cyber Resilience Act.
Водночас для окремих категорій, зокрема медичних виробів, транспортних засобів, авіаційної техніки та частини морського обладнання, можуть діяти спеціальні секторальні правила. Тому для таких продуктів важливо окремо перевіряти, які саме вимоги застосовуються.
Дедлайни розтягнуті в часі, але це не привід відкладати підготовку
CRA не починає діяти в один день повністю. Саме тому багато продуктових команд недооцінюють терміновість підготовки: немає однієї дати, яка створює відчуття жорсткого дедлайну.
Насправді часову лінію варто розділити на три ключові етапи.
До 11 червня 2026 року держави-члени ЄС мали підготувати інфраструктуру для оцінювання відповідності. 11 вересня 2026 року — дата, яку кожна команда, що працює з вбудованими системами, має позначити окремо. З цього моменту виробники повинні повідомляти про активно використані вразливості протягом 24 годин після того, як їм стало про них відомо. Повідомлення має надходити до ENISA та відповідної національної CSIRT. Повне повідомлення подається протягом 72 годин, а фінальний звіт — протягом 14 днів. Про запуск цього “24-годинного годинника” для вразливостей також писав TechTimes.
11 грудня 2027 року починається повне застосування основних вимог регламенту щодо кібербезпеки. За невідповідність вимогам передбачені штрафи до 15 мільйонів євро або до 2,5% світового річного обороту компанії.
Вісімнадцять місяців можуть здаватися достатнім запасом часу. Але якщо накласти цей період на реальний цикл розробки вбудованих продуктів, стає зрозуміло: часу не так багато.
Чому більшість команд IoT і вбудованих систем не готові
У компаніях, які створюють під’єднані продукти, регулярно повторюються чотири проблеми. І жодна з них не вирішується швидко.
Починається все з документації. Вбудовані системи роками накопичують сторонні бібліотеки, компоненти операційних систем реального часу, набори засобів розробки від постачальників і внутрішні модулі. Більшість команд може сказати, що входить до поточної версії вбудованого програмного забезпечення. Але набагато менше команд можуть швидко відновити повний, версійний перелік програмних компонентів для всіх продуктів, які досі працюють у клієнтів. А саме цього вимагає 24-годинний режим реагування на вразливості. Про це також ідеться в огляді вимог CRA від ArmorCode.
Друга проблема — оновлення. Продукт, який відповідає CRA, потребує безпечного та підтвердженого механізму віддаленого оновлення протягом усього строку підтримки. Значна частина обладнання, яке вже працює в полі, проєктувалася в часи, коли регулярні оновлення вбудованого програмного забезпечення не були обов’язковим сценарієм. Інженери часто виходили з припущення, що після постачання прошивка змінюватиметься рідко або не змінюватиметься взагалі. Додавання безпечного віддаленого оновлення до продукту, який спочатку не був для цього спроєктований, — це повноцінна інженерна задача, а не невелике виправлення наприкінці розробки.
Третя проблема — реагування на інциденти. І саме її команди часто недооцінюють. Повідомити про вразливість до ENISA протягом 24 годин можна лише тоді, коли вже є три речі: моніторинг, який здатен виявити використання вразливості; зрозумілий шлях ескалації, який не залежить від того, чи відповість один конкретний інженер на телефон; і заздалегідь підготовлені шаблони повідомлень. Багато команд, що працюють із вбудованими системами, ніколи не проводили такої перевірки на практиці, бо раніше цього ніхто від них прямо не вимагав.
Четверта проблема виходить за межі інженерії. Більшість вбудованих продуктів залежить від компонентів постачальників: наборів мікросхем, модулів, операційних систем реального часу, сторонніх бібліотек і засобів розробки. Часто компанії ніколи не просили в таких постачальників підтвердження безпеки, зобов’язання щодо виправлень або навіть надійний контакт для повідомлення про вразливості. CRA фактично робить інтегратора відповідальним за стан безпеки всього, що входить до переліку компонентів продукту, включно з частинами, для яких команда не написала жодного рядка коду. Тому договори з постачальниками й критерії закупівель потрібно оновлювати паралельно з технічною роботою. І це розмова, яку багато продуктових команд ще навіть не починали.
Проблема вже випущених продуктів
Нові продуктові лінійки можна проєктувати з урахуванням CRA від самого початку. Складніше питання — що робити з продуктами, які вже були продані та працюють у клієнтів.
Йдеться про промислові контролери, трекери для автопарків і під’єднане обладнання, яке компанії продавали протягом останніх п’яти-десяти років. Значна частина таких продуктів усе ще перебуває на гарантії або приносить дохід через сервісні контракти. Але багато з них не мають безпечного механізму віддаленого оновлення, не кажучи вже про оновлення з цифровим підписом. У такій ситуації “просто надіслати виправлення” не вийде без змін в архітектурі обладнання або вбудованого програмного забезпечення.
Для продуктів із довгим життєвим циклом це стає стратегічним рішенням. Промислове, авіаційне та морське обладнання часто працює десять років і більше. Команда може доопрацювати поточне покоління продукту, додавши безпечний механізм оновлення. Вона може визначити дату завершення підтримки й прозоро повідомити про це клієнтів. Або може тимчасово керувати ризиком через компенсувальні заходи: сегментацію мережі, керований моніторинг, посилений контроль доступу. Це дає час до наступної апаратної ревізії.
Жоден із цих варіантів не є безкоштовним. Правильне рішення залежить від кількості пристроїв у полі, залишкового строку їхньої експлуатації та часу, який залишається до грудня 2027 року. Найкраще з цим справляються ті команди, які вже зараз зіставляють встановлену базу продуктів із вимогами CRA. Поки ще є час обрати стратегію свідомо, а не реагувати в останній момент.
Поверхня відповідності зростає разом із кількістю пристроїв
CRA з’являється в незручний момент для багатьох компаній. Корпоративний Інтернет речей виходить за межі пілотних проєктів і рухається до того, що аналітики називають автономними під’єднаними операціями. Це означає більше пристроїв, більше автономності й більше даних, які передаються між машинами з меншою участю людини. Про цей перехід ідеться у звіті IoT Analytics State of Enterprise IoT 2026.
Кожен новий пристрій у парку — це ще один запис у переліку програмних компонентів. Це ще одна кінцева точка, якій потрібен шлях оновлення. І це ще один елемент, який потрібно врахувати, коли починає відлік 24-годинний строк повідомлення про вразливість.
Зростання продукту й борг із відповідності вимогам накопичуються одночасно. Саме тому CRA не можна сприймати як вправу з підготовки документів, яку можна передати юридичному відділу в четвертому кварталі 2027 року. Це питання архітектури, процесів і відповідальності за весь життєвий цикл продукту.
Що означає “безпечне проєктування” на практиці
Для продуктових та інженерних керівників підготовка до CRA — це не косметичні зміни, а реальна архітектурна робота.
Почати варто з безпечного завантаження та підписаного вбудованого програмного забезпечення. Пристрій має запускати лише той код, який пройшов криптографічну перевірку. Також потрібне шифрування й підтвердження справжності обміну даними між пристроями та серверними службами. Захист має працювати не лише тоді, коли дані зберігаються, а й тоді, коли вони передаються між пристроями, серверами та іншими частинами системи.
Команді потрібен актуальний перелік програмних компонентів, який можна експортувати й який автоматично оновлюється під час збирання продукту. Це набагато надійніше, ніж документ, який інженер складає вручну лише тоді, коли його просить аудитор.
Також потрібен перевірений механізм віддаленого оновлення, який дозволяє доставити виправлення на вже встановлене обладнання. І нарешті, потрібен не просто написаний, а відпрацьований порядок реагування на інциденти. Команда має знати, хто ухвалює рішення, хто готує повідомлення, хто контактує з регуляторними органами, хто відповідає за технічне виправлення і як це все відбувається у перші 24 години. Інакше відлік почнеться з того, що хтось уперше відкриє текст регламенту.
Усе це не є чимось екзотичним. Це дисципліна, яку потрібно застосовувати раніше в життєвому циклі продукту, ніж це зазвичай дозволяють типові плани розробки вбудованих систем.
Реалістичний план підготовки на найближчі 18 місяців
Команди, які сприймають CRA як один дедлайн у 2027 році, зазвичай відкладають складні рішення до останнього кварталу. Саме тоді інженерна команда найбільш завантажена, а помилки коштують найдорожче.
Більш практичний підхід варто почати вже у другій половині 2026 року з оцінки розривів. Для цього потрібно зіставити кожну лінійку під’єднаних продуктів з основними вимогами CRA. Потім визначити, які дані про програмні компоненти вже є, а які потрібно відновити. Далі — зрозуміти, які продукти в полі реально можна доопрацювати для безпечного віддаленого оновлення, а для яких потрібно визначити дату завершення підтримки або інший шлях керування ризиком.
Результати такої оцінки мають напряму впливати на архітектурні рішення до того, як апаратна ревізія 2027 року буде остаточно зафіксована. Додавати безпечне завантаження або підписане вбудоване програмне забезпечення до вже замороженого дизайну значно дорожче, ніж закласти ці вимоги на початку.
Процеси моніторингу й реагування на інциденти можна створювати та перевіряти паралельно, задовго до початку обов’язкового звітування у вересні 2026 року. Так перше реальне повідомлення про вразливість не стане першим випадком, коли команда взагалі проходить цей процес.
Починати не потрібно чекати фінального дедлайну. Потрібно сприймати найближчі 18 місяців як робоче вікно для архітектурних рішень, технічних змін і підготовки процесів.
Як до цього підходить Allmatics
Це саме той тип задач, із якими Allmatics працює в межах розробки вбудованих IoT-рішень і технологічного консалтингу. Ми допомагаємо проводити оцінку розривів щодо основних вимог CRA, доопрацьовувати безпекову архітектуру вже випущених продуктів, проєктувати процеси віддаленого оновлення, а також створювати інструменти для ведення переліку програмних компонентів і моніторингу.
Такі інструменти роблять 24-годинне вікно для повідомлення про вразливість реальним процесом, а не теоретичною вимогою на папері.
Ми працювали з під’єднаними системами в авіації, логістиці та морській галузі. І закономірність усюди однакова: що раніше безпека стає повноцінною вимогою до архітектури, а не пунктом у перевірочному списку перед релізом, то дешевше компанії обходиться відповідність вимогам у майбутньому.
Якщо у вашій продуктовій стратегії є під’єднане обладнання, яке виходить або планує виходити на ринок ЄС до грудня 2027 року, варто діяти наперед. Найкращий момент для оцінки продуктової ідеї з урахуванням CRA — до того, як наступна апаратна ревізія буде остаточно зафіксована. Не тоді, коли регулятори вже почнуть ставити запитання.