11 вересня 2026 року починає діяти одна з найтерміновіших вимог європейського Cyber Resilience Act — більш ніж за рік до більшості норм регламенту. Якщо виробник дізнався про вразливість, яку активно експлуатують, або про серйозний інцидент у безпеці продукту, на раннє попередження може бути лише 24 години, а на розширене повідомлення — 72.
Практична підготовка — це не ще одна політика в PDF. Потрібен окремий маршрут інциденту: визначити продукт і роль виробника, перевірити критерії CRA, зафіксувати момент обізнаності, зібрати мінімальне повідомлення та вести інженерів, юристів, підтримку й керівництво через один запис.
Це операційний матеріал, а не юридична консультація. Висновок залежить від продукту, ролі компанії, історії продажів, обставин події та інших режимів сповіщення. Перевірте застосування регламенту з профільним юристом і відповідним CSIRT.
Що зміниться 11 вересня 2026 року
Регламент ЄС про кіберстійкість набув чинності в грудні 2024 року. Основна частина вимог застосовуватиметься з 11 грудня 2027 року, але стаття 14 щодо повідомлень — уже з 11 вересня 2026-го. Вона стосується виробників продуктів із цифровими елементами, які надають на ринку ЄС. Єврокомісія відносить до них апаратні та програмні продукти, передбачене або обґрунтовано очікуване використання яких включає пряме чи опосередковане з’єднання з пристроєм або мережею.
Сторінка Єврокомісії про звітування CRA називає дві обов’язкові події: вразливість у продукті, яку активно експлуатують, і серйозний інцидент, що впливає на безпеку продукту. Виробник подає повідомлення один раз через Single Reporting Platform (SRP) агенції ENISA, а платформа спрямовує його потрібному національному CSIRT і ENISA.
Рання дата важлива й для старих версій. Офіційний огляд CRA уточнює: звітування стосується всіх цифрових продуктів, що були надані на ринку ЄС, зокрема до 11 грудня 2027 року. Отже, не варто відкладати цей процес до завершення великої програми CE-маркування та оцінювання відповідності.
Як перевірити продукт і роль компанії
Почніть із реєстру продуктів, а не з одного висновку для всієї компанії. Та сама організація може продавати десктопну програму, постачати підключений пристрій, керувати онлайн-сервісом, якому потрібен окремий аналіз, і підтримувати open-source проєкт за іншим режимом CRA.
| Запитання | Який доказ зберегти | Відповідальний |
|---|---|---|
| Це апаратний або програмний продукт із прямим чи опосередкованим з’єднанням? | Архітектура, призначення, опис продукту | Продукт + юристи |
| Його постачали в межах комерційної діяльності на ринку ЄС? | Контракти, канали, релізи й території | Комерційні операції |
| Під чиїм ім’ям або торговельною маркою продається продукт? | Пакування, сторінка продажу, ліцензія | Юристи + продукт |
| Хмарна функція необхідна для роботи продукту? | Карта залежностей і відповідальності | Інженери + юристи |
| Чи є виняток або спеціальне галузеве правило? | Письмова оцінка з посиланнями | Профільний юрист |
Розробник не завжди є виробником у розумінні CRA. Зазвичай це фізична або юридична особа, яка виводить продукт на ринок під своїм ім’ям чи торговельною маркою. Водночас замовлення розробки підряднику не обов’язково переносить відповідальність виробника. Для суто хмарних сервісів і вільного програмного забезпечення потрібен окремий аналіз. Роз’яснення Єврокомісії від липня 2026 року окремо розглядає віддалену обробку даних, open source, строки підтримки, істотні зміни та звітування.
Для кожного продукту або сімейства запишіть юридичну особу-виробника, головне представництво в ЄС або уповноваженого представника, відповідний CSIRT, країни продажу, підтримувані версії, компоненти та щонайменше двох осіб для подання повідомлення. На вісімнадцятій годині інциденту відновлювати це запізно.
Два різні критерії для повідомлення
Невиправлена вразливість не стає автоматично предметом статті 14. Для першого критерію потрібні надійні докази того, що зловмисник уже експлуатував її в системі без дозволу власника. Proof of concept, сигнал сканера, високий CVSS або лист дослідника вимагають швидкої перевірки, але самі по собі ще не обов’язково доводять активну експлуатацію.
Критерій серйозного інциденту інший. Подія вважається серйозною, якщо вона негативно вплинула або здатна негативно вплинути на захист доступності, автентичності, цілісності чи конфіденційності чутливих або важливих даних чи функцій продукту; або призвела чи здатна призвести до появи або виконання шкідливого коду в продукті чи системах користувача. Застосовуйте точні критерії до зафіксованих фактів.
- Сигнал: збережіть джерело, час, продукт і версію та первинні докази.
- Зв’язок із продуктом: перевірте, що компонент або подія стосуються продукту в межах CRA, доступного в ЄС.
- Два тести: окремо оцініть активну експлуатацію й серйозний інцидент. Запишіть «так», «ні» або «невідомо» та обґрунтування.
- Момент обізнаності: зафіксуйте, коли надійні докази стали відомі організації; не пересувайте час непомітно після ескалації.
- Паралельні дії: стримуйте атаку й виправляйте продукт, поки готується звіт. Повідомлення не замінює захист користувачів.
Поріг внутрішньої ескалації має бути нижчим за юридичний поріг повідомлення. Це не означає звітувати про кожен баг. Це означає вчасно передати докази людям, які вповноважені оцінити критерії, поки строк не сплив у пересиланні листів.
Як працюють строки 24/72 години
FAQ агенції ENISA щодо SRP, оновлений 31 серпня 2026 року, описує таку послідовність:
- До 24 годин від моменту обізнаності: без зайвої затримки подайте раннє попередження. Вкажіть виробника, продукт, тип повідомлення, назву та, де це відомо або потрібно, держави-члени чи підозру щодо зловмисних дій.
- До 72 годин від моменту обізнаності: доповніть той самий запис загальною інформацією, початковою оцінкою, уже вжитими заходами, порадами для користувачів і оцінкою чутливості. Це 72 години загалом, а не після першого повідомлення.
- Для активно експлуатованої вразливості: фінальний звіт подають не пізніше ніж через 14 днів після появи виправлення або іншого заходу.
- Для серйозного інциденту: фінальний звіт подають протягом місяця після 72-годинного повідомлення.
Раннє попередження розраховане на неповні відомості. Не чекайте точної атрибуції, повного масштабу чи root cause. Розділіть підтверджені факти, робочі гіпотези й невідоме, а потім оновлюйте ту саму картку.
Станом на 3 вересня ENISA обіцяє опублікувати адресу SRP до запуску. Уповноважені представники входять через персональний EU Login із двофакторною автентифікацією. Виробник може мати одного Primary AR і до 20 Secondary AR. Валідація представника відбувається паралельно та не зупиняє подання. Порядок ще оновлюється, тому під час кожної події перевіряйте актуальну сторінку SRP.
Єдина картка доказів і рішень
Тікет, розкиданий між месенджером, поштою, сканером і юридичною таблицею, не витримає трьох дедлайнів. Створіть захищену картку з постійним ідентифікатором і журналом рішень, який не переписує історію.
cra_case
case_id + notification_type
manufacturer + product + affected_versions
signal_received_at + awareness_at + rationale
exploitation_evidence + severity_test
eu_markets + csirt_coordinator
containment + user_mitigation + corrective_measure
confirmed_facts + hypotheses + unknowns
sensitivity + disclosure_decision
reporter + approver + deputies
24h_due + 72h_due + final_due
srp_reference + receipts + change_logСтавтеся до картки як до чутливих даних безпеки: доступ за ролями, журнал змін, копії надісланих полів і квитанцій, погоджений строк зберігання. Не вставляйте деталі експлойта в загальні канали чи універсальний ШІ-чат. Система має рахувати строки від awareness_at, показувати часовий пояс і викликати резервного відповідального, якщо основний не підтвердив задачу.
Робочий процес замість форми
ENISA вже оприлюднила поля форми, але її заповнення — остання миля. Головна робота відбувається раніше.
- Приймання: безпека, підтримка, дослідники, моніторинг, постачальники та клієнти можуть відкрити одну пріоритетну картку.
- Тріаж: власника продукту й компонента знаходять у підтримуваному реєстрі або SBOM.
- Рішення: безпека надає докази, юристи перевіряють сферу та критерії, керівник інциденту тримає час.
- Подання: два навчені представники мають доступ до EU Login і SRP; погоджувач бачить точний payload.
- Реагування: інженери, підтримка й комунікації працюють із погодженими фактами та заходами.
- Закриття: фінальний звіт, патч, дії для клієнтів, квитанції та уроки залишаються пов’язаними.
Автоматизуйте нагадування, пошук продукту, розрахунок строків, перевірку обов’язкових полів і знімки доказів. Рішення про звіт і зовнішнє подання залиште під контролем відповідальної людини. За даними ENISA, на старті API не буде, тому заплануйте надійний ручний крок, а не крихку автоматизацію браузера.
Одна подія може одночасно запускати GDPR, NIS2, умови контрактів, страхування, галузеві норми або правила іншої країни. Ведіть спільну базу фактів, але окремі юридичні рішення та строки. Подання в SRP не слід автоматично вважати виконанням іншого обов’язку.
Проведіть 90-хвилинне навчання
Сценарій: у сторонній бібліотеці підтримуваного продукту є вразливість, у п’ятницю ввечері надходять переконливі ознаки експлуатації, уражені версії ще невідомі, а тимчасовий захід може зламати інтеграцію одного клієнта.
- Запустіть годинник, коли доказ з’явився у визначеному каналі.
- Знайдіть виробника, продукт, країни ЄС, версії, компонент і CSIRT.
- Складіть 24-годинне повідомлення лише з відомих фактів.
- Призначте власників невідомого для 72-годинного оновлення.
- Змоделюйте відсутність Primary AR і передачу Secondary AR.
- Підготуйте безпечну пораду користувачам без деталей, корисних нападнику.
- Зафіксуйте затримки та дайте кожному виправленню дату й власника.
Вимірюйте час до тріажу, рішення про обізнаність, брак даних про продукт, затримку погодження та здатність резервної людини завершити процес. Результат — не красиві слайди, а доказ, що команда подасть фактичне попередження за 24 години, не зупиняючи захист.
Поширені запитання
Коли починається обов’язкове звітування за CRA?
11 вересня 2026 року. Більшість інших вимог регламенту застосовуватиметься з 11 грудня 2027 року.
Це стосується продуктів, проданих до грудня 2027 року?
Так. Єврокомісія уточнює, що звітування охоплює цифрові продукти, уже надані на ринку ЄС. Але треба окремо підтвердити сферу продукту та роль вашої компанії.
Треба повідомляти про кожну вразливість?
Ні. Обов’язковий критерій стосується вразливості з надійними доказами активної зловмисної експлуатації. Серйозний інцидент — окрема підстава. Решту вразливостей однаково треба належно опрацьовувати.
72 години рахують після першого повідомлення?
Ні. Обидва строки рахують від моменту обізнаності. Після вчасного раннього попередження на другий етап залишається не більше 48 годин.
Можна чекати на остаточну причину?
Ні. Перше повідомлення подають із доступними даними. Позначте факти, гіпотези й невідоме, а потім оновіть запис.
Чи є API для автоматичного звітування в ENISA?
У FAQ від 31 серпня ENISA зазначає, що на першому етапі API не буде. Автоматизуйте внутрішню підготовку, але залиште перевірений ручний крок у SRP.
Зробіть перші 24 години відтворюваними
Строк CRA виявляє системну проблему: власники продуктів, компоненти, країни продажу, рішення під час інциденту й доступ до звітування не можуть існувати в різних сховищах. Одна картка, визначена команда, два представники й одне реалістичне тренування корисніші за сто сторінок політики.
Rendframe може спроєктувати маршрут product security, пов’язати записи продуктів і компонентів, створити контрольований інструмент інцидентів та перевірити передачу між командами. Перегляньте наш матеріал про безпечне впровадження ключів доступу, дізнайтеся про розробку цифрових продуктів або надішліть нам анонімізовану часову шкалу одного інциденту для предметного розбору.