CRA за производителите на машини след насоките на Комисията от 27 юли 2026 г. Какво наистина трябва да се внедри?

С години киберсигурността на машините се свеждаше до три стъпки: контролер от утвърдена марка, VPN „защото така се прави“ и класическото „клиентът ще си защити мрежата“. А ако някой добавеше и firewall в шкафа, темата често се смяташе за приключена — поне докато някой не опиташе да провери какво става при реална атака, а не в презентация.

Само че киберсигурността не се пренася по PROFINET. Компонентите може да имат сертификати, декларации и „secure by design“ в маркетинговата брошура, но машината като цяло пак може да е предвидима по начин, който няма нищо общо със сигурността. Както релето за безопасност не прави системата безопасна, ако логиката на управление позволява то да бъде заобиколено, така и „сигурният“ HMI не решава проблемите на архитектурата, интеграцията, правата за достъп, актуализациите и онова, което се случва, когато някой спре да пита за разрешение.

CRA (Cyber Resilience Act, Регламент (ЕС) 2024/2847 на Европейския парламент и на Съвета) не е добавка за ИТ. Това е продуктов регламент, който навлиза в жизнения цикъл на машината, без да пита отдела по автоматизация. Той обхваща проектирането на управлението, анализа на риска съгласно EN ISO 12100, веригата на доставки, конфигурацията, актуализациите, както и поддръжката на продукта дълго след като FAT е подписан и машината е напуснала производствената зала. И не, аргументът „не я излагаме в интернет“ не затваря темата. На практика е достатъчен сервизен лаптоп, USB памет, дистанционна диагностика „само за малко“ или интеграция със заводска система, за да престане да съществува границата между изолация и експониране.

Насоките на Комисията от 27 юли 2026 г. не промениха самия регламент, но ефективно ограничиха полето за тълкуване, което по-рано позволяваше киберсигурността да се третира като незадължителен слой. Беше уточнена, наред с другото, границата на продукта, ролята на дистанционната обработка, отговорността за промени след доставката, както и това, че „това вече не е наш проблем след FAT“ вече не е безопасно допускане.

Най-важната промяна обаче е още по-фундаментална: кибератаката престава да бъде само ИТ събитие и се превръща в сценарий, който влияе върху функционалната безопасност на машината. Ако неоторизирана промяна в програмата може да предизвика движение на ос, заобикаляне на блокировка, промяна на параметрите на процеса или загуба на функция за безопасност, тогава вече не говорим за „мрежов инцидент“. Говорим за потенциално неконтролирано поведение на машината — независимо дали източникът е грешка в конфигурацията, уязвимост в софтуера или умишлена намеса.

В този контекст еднократният pentest преди FAT престава да бъде доказателство за съответствие и се превръща само в моментна снимка на състоянието на системата в конкретен момент. CRA изисква непрекъснат подход: от проектирането, през производството и пускането в експлоатация, до актуализациите, управлението на уязвимостите, реакцията при инциденти и поддръжката през декларирания период на поддръжка.

На практика това означава отказ от мисленето „направено = сигурно“ в полза на „поддържано = контролирано“. Без илюзии, че firewall в шкафа, VPN и сертификат на компонента затварят темата. И без допускането, че киберсигурността приключва в момента на подписване на приемо-предавателния протокол.

В тази статия разглеждаме какво реално променят насоките по CRA за производителите, интеграторите и модернизаторите на машини — без да свеждаме цялата тема до лозунга „да сменим паролата и да добавим checkbox cybersecurity“.

1. За да не попадне под CRA, машината трябва почти да е само на контактори

В много проекти обхватът на CRA се проверява с един въпрос:

Ще бъде ли машината свързана с интернет?

Няма да бъде.

Значи темата е приключена.

На схемата има PLC, HMI, няколко задвижвания, разпределени входове и изходи, клапанен остров, скенер за безопасност и порт за качване на програмата. Контролерът комуникира с панела по PROFINET, със задвижванията обменя управляващи и статусни думи, а сензорите предават данни чрез IO-Link.

Но няма router със SIM карта.

Както е известно, данните стават данни едва когато напуснат производствената зала.

Само че CRA не пита дали машината има достъп до интернет.

Той пита дали предназначението ѝ или разумно предвидимата ѝ употреба включва пряка или непряка, логическа или физическа връзка за данни с устройство или мрежа. Не е нужно това да е връзка с облак, сървър на производителя или публичния интернет. Тя може да се осъществява по кабел, по радиовълни, чрез програмен интерфейс или като част от по-голяма система.

И сега ключовият въпрос: какво в една типична машина реално предава данни?

Дали HMI чете състояния от PLC и записва настройки?

Дали PLC изпраща към задвижването управляваща дума, а в отговор получава скорост, статус и код за грешка?

Дали островът с входове и изходи предава образа на процеса?

Дали IO-Link сензорът изпраща измерената стойност, идентификатора на устройството и диагностични данни?

Дали safety PLC комуникира с модулите чрез PROFIsafe?

Дали програмата, хардуерната конфигурация или firmware се качват от сервизен лаптоп?

Дали рецепти, отчети или актуализации могат да се прехвърлят чрез USB?

Ако отговорът дори веднъж е „да“, тогава най-вероятно имаме връзка за данни.

И това не се променя от факта, че:

• машината работи в локална мрежа,
• няма публичен IP адрес,
• Ethernet портът се използва само при пускане в експлоатация,
• лаптопът се свързва единствено от сервиза,
• комуникацията се осъществява само вътре в системата за управление,
• клиентът е обещал, че никога няма да свърже машината към интернет.

CRA обхваща не само употребата, описана в инструкцията като основна, но и разумно предвидимата употреба. Следователно сервизният порт не спира да предава данни само защото на схемата до него е добавено „SERVICE ONLY“.

Насоките на Комисията от 27 юли 2026 г. обаче въвеждат важно разграничение.

Не всеки проводник и не всеки електрически сигнал представлява връзка за данни.

Ако сигналът служи единствено за включване, изключване или захранване на определена функция и не предава цифрово кодирана информация, самото наличие на две електрически състояния все още не е достатъчно, за да бъде приет за връзка за данни.

Бутон, който подава напрежение към бобината на контактор, не се превръща в цифров интерфейс само защото състоянието му може да се опише като нула или единица.

По същия начин класически краен изключвател, включен в релейно-контакторна верига, може единствено да прекъсне или да затвори веригата. Той не предава номер на устройство, процесна стойност, диагностичен код, версия на firmware или телеграма, съдържаща няколко информации.

Но когато същото това състояние постъпи в интелигентно устройство, бъде кодирано, предадено по шина, свързано с диагностика и интерпретирано от приемника като информация, тогава ситуацията вече е различна.

Следователно границата не минава между машина „online“ и „offline“.

Тя минава между обикновен управляващ сигнал и обмен на цифрово кодирана информация.

Затова на практика машина, която би останала извън обхвата на CRA единствено поради липса на връзка за данни, би трябвало да прилича повече на класическа схема с бутони, крайни изключватели, релета и контактори, отколкото на съвременен проект, отварян в TIA Portal.

Разбира се, това не е законово изключение за контакторите.

Може да се изгради проста машина с PLC, която след подробен анализ да не изпълни критерия за обхват. Може също към контакторна схема да се добави цифров регулатор, сервизен интерфейс или комуникационен модул и тя да се окаже точно от другата страна на границата.

Името на компонента не решава въпроса.

Решаващо е какво продуктът действително прави и с какво обменя данни.

Затова, преди да се отговори на въпроса дали дадена машина попада в обхвата на CRA, трябва да се установи:

• къде минава границата на оценявания продукт,
• кои устройства и софтуерни елементи влизат в състава му,
• какви физически и логически интерфейси има,
• каква информация се предава чрез тях,
• кои връзки са директни и кои се осъществяват чрез по-голяма система,
• кои от тях са налице по време на нормална работа, пускане в експлоатация, диагностика, актуализация или сервиз,
• какви начини на употреба са разумно предвидими, дори ако производителят би предпочел да не ги предвижда.

Докато не отговорим на тези въпроси, не знаем дали машината остава извън обхвата на CRA.

В най-добрия случай разполагаме с удобно изречение:

„Машината не е свързана към интернет“.

Само че това е отговор на въпрос, който CRA не задава.

PROFINET не е интернет. А за CRA изобщо не е необходимо да бъде.

2. Киберсигурността не се разпространява по PROFINET

В много проекти темата за съответствието на машината започва още на етапа на закупуване.

PLC от утвърден производител.
HMI с актуален firmware.
Управляем switch.
Индустриален router с VPN.
Задвижвания с функции за безопасност.
Safety PLC със съответния сертификат.

За всяко устройство — декларация за съответствие, инструкция и няколко документа с думите „secure“, „encrypted“ и „defence in depth“.

На схемата всичко изглежда професионално.

Само че все още не е ясно дали цялата машина е киберсигурна.

Защото киберсигурността не се „предава“ по PROFINET.

Това е малко като при ключалката на вратата:
може да имате много добра ключалка във всяка стая, сертифицирана, изпитана, с отлична документация и холограма „secure“, но това все още не гарантира безопасност, ако някой е оставил входната врата широко отворена, „защото така беше по-бързо при пускането“.

И тук е точно същото: компонентите може да са образцови, а системата въпреки това да е… творчески отворена.

PLC не „предава“ сигурност към HMI.
Firewall не „поправя“ логиката на приложението.
Switch не „подрежда“ потребителския достъп.
А фактът, че всеки елемент има сертификат, все още не означава, че цялата машина не е една огромна, любезно документирана уязвимост.

PROFINET пренася данни.

Не пренася отговорност.
И за съжаление не пренася и здрав разум.

CRA обхваща както завършени продукти, така и компоненти, пускани на пазара отделно. Това означава, че контролер, операторски панел или комуникационен модул могат да бъдат оценявани поотделно. Но производителят на машината все пак трябва да докаже, че цялото решение работи сигурно в реалната конфигурация при клиента — тоест в тази версия, в която някой „със сигурност вече нищо не е променял… нали?“.

И тук се появява най-честата грешка.

Това е точно същият механизъм, който от години познаваме от безопасността на машините.

Завесата има PL e.
Safety PLC има SIL 3.
Задвижването има STO.

Означава ли това, че цялата машина автоматично е на същото ниво?

Това е като при скеле: фактът, че всеки негов елемент отговаря на изискванията за безопасност, още не гарантира, че цялата конструкция ще бъде стабилна.

Не.

Защото все още трябва да се провери как всичко това работи заедно — тоест онзи неособено популярен етап на „системно мислене“, който, за съжаление, няма бутон „auto-certify“.

При киберсигурността е абсолютно същото.

Може да имате „сигурни“ компоненти, но на практика:

• операторът вижда и може да променя повече данни, отколкото реално са му нужни, защото „така беше по-удобно“,
• една сервизна парола работи на всички машини, защото „сервизът така или иначе знае какво прави“,
• сервизният порт е достъпен „за всеки случай“, тоест за абсолютно всеки случай,
• отдалеченият достъп обхваща цялата мрежа, защото някой някога е казал „това е само за диагностика“,
• актуализации могат да се качват без контрол, защото „никога досега нищо не се е чупило“,
• устройствата си „имат доверие“ без ограничения, защото доверието е по-евтино от сегментацията,
• а интеграцията предполага, че никой никога няма да допусне грешка, което — както историята показва — е най-оптимистичното допускане в инженерството.

Всеки елемент поотделно може да е коректен.

Но системата като цяло е способна от тези коректни елементи да изгради нещо, което работи… само че не непременно така, както е било предвидено.

И това е важно: рискът не е в устройствата, а в тяхното свързване, конфигуриране и в легендарния „временно оставен“ достъп.

CRA изисква от производителя на машината нещо повече от това да събира декларации като трофеи. Изисква да провери дали сглобеното от компоненти решение остава безопасно като цяло — а не само „изглежда добре в таблицата за съответствие“.

На практика това означава прости въпроси от бизнес гледна точка:

• дали всеки потребител има само такъв достъп, какъвто действително му е необходим, а не „защото може някой ден да потрябва“,
• дали отдалеченият достъп е ограничен до минимум, или по-скоро до максимално удобство,
• дали сервизът няма „пълни права навсякъде“, защото някой е решил, че така животът е по-лесен,
• дали мрежата не е една обща плоскост, защото сегментацията „усложнява проекта“,
• дали актуализациите са контролирани, или по-скоро „качваме ги и се молим“,
• дали може бързо да се установи кои машини са изложени на риск, или по-скоро „ще проверим след инцидента“,
• дали отказът на един елемент не отваря цялата система, защото „така се получи при интеграцията“.

Това не са технически въпроси „за инженерите, които се занимават със сложните неща“.

Това са въпроси за бизнес риска: престои, разходи, отговорност и онази дребна подробност, че производството все пак трябва да работи.

Затова не е достатъчно да се каже:

„всички компоненти са съвместими“

Защото това все още не дава отговор на въпроса:

дали цялата машина е безопасна при реална употреба, или само в PowerPoint от прегледа на проекта?

Декларацията на доставчика е важна.

Но тя се отнася само за един елемент — този, който точно е бил изпитван в лабораторни условия, а не в среда „някъде в цеха, с VPN, USB и натиск за срокове“.

Тя не обхваща начина, по който е бил използван.
Не обхваща конфигурацията.
Не обхваща интеграцията.
Не обхваща решенията, взети „набързо по време на пускането, защото клиентът чакаше“.
Не обхваща и това, което се случва след години експлоатация, когато вече никой не помни защо нещо е било „временно оставено отворено“.

Затова оценката не може да приключва със списък на устройствата.

Трябва да се погледне на системата като на едно цяло:

• кой има достъп и защо (а не „защото винаги е имал“),
• какво е наистина необходимо и какво просто е „оставено, защото не пречеше“,
• къде данните могат да излязат извън контрол, защото някой е преценил, че „това е само диагностика“,
• какво ще стане, ако някой използва легитимен достъп по нелегитимен начин (тоест точно както действат атаките),
• колко бързо може да се реагира, когато възникне проблем, а не „след тримесечния преглед“.

Докато няма отговор на тези въпроси, имаме само набор от много добри компоненти.

Все още нямаме безопасна машина.

Съответствието на компонентите не създава автоматично съответствие на системата. Съответствието на машината трябва да бъде проектирано, проверено и — което е най-трудно — поддържано въпреки изкушението „вече нищо да не се пипа, защото работи“.

3. Не добавяйте кибератаката към списъка с опасности. Свържете двата анализа на правилното място

На пазара на машини формалният анализ на риска за киберсигурността все още е по-скоро изключение, отколкото стандартен елемент от проекта.

Най-често има индустриален рутер.

Има VPN.

Има парола за PLC.

Понякога има управляем switch, който после никой не управлява.

В по-амбициозния вариант производителят получава от доставчика презентация за „defence in depth“ и приема, че току-що е приключил анализа на риска за киберсигурността на цялата машина.

Не е приключил.

Купил е няколко технически средства.

Това все още не е анализ.

Затова няма смисъл проблемът да се описва така, сякаш във всеки проект се изготвят две професионални оценки — една според EN ISO 12100, а другата за киберсигурността — които просто случайно не са били свързани помежду си.

Най-често се изготвя само една.

Оценка на риска на машината.

А анализ на киберсигурността на продукта изобщо не се прави.

Оценката на риска на машината съгласно ISO 12100 не се свежда до това в таблица да се впише:

повреда на сензор → неочаквано движение → премазване.

Това може да е част от конкретен сценарий, но не и изходната точка.

Първо трябва да се определят ограниченията на машината.

Какво е нейното предназначение?

Кои са фазите от жизнения ѝ цикъл?

Кой ще я използва?

Какви задачи ще се изпълняват по време на транспортиране, монтаж, пускане в експлоатация, производство, настройка, почистване, отстраняване на блокирания, поддръжка, диагностика и демонтаж?

В какви режими може да работи машината?

Къде се намира човекът по време на всяка от тези операции?

Кои части на машината тогава остават под напрежение, налягане, натоварване или в движение?

Коя употреба не съответства на инструкцията, но все пак остава разумно предвидима?

Едва след това за конкретна задача или операция се идентифицират, наред с другото:

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

Така изглежда анализът на риска на машината.

Не започваме от компонента.

Започваме от човека, който изпълнява конкретна задача на машина, намираща се в определено състояние. Именно такава методика за идентифициране на опасностите, както и за оценяване и преценка на риска по време на съответните фази от жизнения цикъл на машината, установява ISO 12100.

Нека вземем прост пример.

Оператор отстранява заседнал детайл от вътрешността на палетизираща клетка.

Следователно имаме:

Задача: отстраняване на блокиране.

Фаза на използване: експлоатация, намеса след спиране на процеса.

Режим на работа: ръчен или сервизен.

Изложено на риск лице: оператор или служител по поддръжката.

Опасна зона: вътрешността на клетката, по-специално пространството между захващащото устройство, детайла и конструкцията на машината.

Източник на опасност: механичната енергия на робота, линейната ос или пневматичното захващащо устройство.

Опасна ситуация: човекът се намира в зоната, докато изпълнението на движение все още е възможно.

Опасно събитие: неочаквано движение на ос, затваряне на захващащото устройство или освобождаване на акумулирана енергия.

Възможна последица: удар, премазване, счупване или ампутация.

Едва сега може да се оценява рискът и да се определят мерките за неговото намаляване.

Може да е необходима блокировка на предпазния кожух.

Може да е необходимо безопасно спиране.

Може да е необходимо предотвратяване на неочаквано пускане.

Възможно е да се наложи отвеждане на пневматичната енергия.

Възможно е движението в ръчен режим да може да се извършва единствено чрез разрешаващо устройство и при безопасно ограничена скорост.

Това все още е класическа оценка на риска на машината.

Къде се появява киберсигурността?

Не като нова позиция редом с механичната, електрическата и термичната опасност.

„Хакерът“ не е източник на механична опасност

Добавянето в таблицата по ISO 12100 на позиция:

Опасност: кибератака

не допринася с много.

Кибератаката не е въртящ се вал, остър ръб, висока температура или пневматична енергия.

Тя не е и отделна опасна зона.

Операторът не бива премазан от уязвимост CVE.

Той бива премазан от елемент на машината, който е извършил движение, докато човекът се е намирал на неподходящо място.

Кибератаката обаче може да промени състоянието на системата за управление, данните, програмата, конфигурацията или начина на действие на защитната мярка.

Следователно тя може да се превърне в:

• причина за опасно събитие,
• допълнителен път, водещ до опасна ситуация,
• причина за загуба на ефективност на мярката за намаляване на риска,
• или начин за заобикаляне на допусканията, приети при проектирането на функциите за безопасност.

Именно това е правилната точка на съприкосновение.

Не списъкът с опасности.

А поведението на машината.

Анализът на киберсигурността трябва да се изготви отделно

За машина или система за индустриална автоматизация анализът на киберсигурността ще има различна структура от оценката на риска съгласно ISO 12100.

Най-естествената рамка за система за индустриална автоматизация се дава от IEC 62443-3-2.

Стандартът изисква, наред с другото:

• да се дефинира системата, която подлежи на анализ, тоест SUC,
• системата да се раздели на зони и комуникационни канали,
• да се оцени рискът за отделните зони и канали,
• да се определят целевите нива на сигурност SL-T,
• да се документират изискванията за сигурност.

Това е напълно различна изходна точка в сравнение с ISO 12100.

В IEC 62443 задаваме, наред с другото, следните въпроси:

Какво точно влиза в анализираната система?

Кои активи трябва да бъдат защитени?

Какви устройства, приложения и интерфейси се намират в системата?

Кои елементи трябва да принадлежат към една и съща зона?

Как протича комуникацията между зоните?

Кой може да получи достъп?

От кое място?

Чрез какъв интерфейс?

Кои уязвимости могат да бъдат използвани?

Кои данни, функции или компоненти могат да бъдат променени?

По какъв път атакуващият може да премине от сервизния рутер до PLC, HMI, задвижването или инженерната станция?

Какви ще бъдат последиците от загуба на поверителност, цялост или наличност?

Какви мерки за защита са необходими?

За процеса на безопасно разработване на продукта и за изискванията към самите компоненти значение имат и други части от серията, по-специално IEC 62443-4-1 и IEC 62443-4-2. От своя страна IEC 62443-3-3 систематизира техническите изисквания за сигурност на системно ниво.

Към днешна дата CRA не изисква производителят да напише на корицата на анализа „изготвено съгласно IEC 62443“.

IEC 62443 също така не замества доказването на съответствие с изискванията на CRA.

За индустриална система за автоматизация тя обаче е много по-логична отправна точка от опита да се добавят няколко хакерски сценария в таблица по ISO 12100.

Защото двете методики дават отговор на различни въпроси.

ISO 12100:

При каква задача, къде, от какъв източник и в резултат на какво събитие човек може да претърпи вреда?

IEC 62443:

Кой, по какъв път и чрез каква уязвимост може да повлияе на системата, нейните данни или функции?

Едва след това трябва да се провери дали отговорът от втория анализ променя сценария от първия.

Един и същ сценарий, два различни анализа

Нека се върнем към оператора, който отстранява заседнал детайл.

Анализът по ISO 12100 е показал, че човекът влиза в зона, в която може да бъде притиснат от движението на робота или захващащото устройство.

Мярката за намаляване на риска е блокиращ предпазен кожух, функция за безопасно спиране и локален reset, разположен извън опасната зона.

Сега извършваме анализ на киберсигурността на системата.

Идентифицираме:

• рутер, използван за отдалечен сервиз,
• сервизен акаунт,
• инженерен лаптоп,
• HMI,
• стандартен PLC,
• safety PLC,
• задвижвания,
• интерфейс за програмиране,
• мрежата PROFINET и комуникацията PROFIsafe,
• механизмите за качване на програмата и конфигурацията.

Разглеждаме следния сценарий:

Компрометирането на сервизния акаунт позволява отдалечен достъп до стандартния PLC и изпращане на команда за движение, докато в клетката има човек.

Води ли този сценарий до опасно събитие?

Не може да се отговори само въз основа на факта, че PLC е компрометиран.

Трябва да се провери архитектурата на функциите за безопасност.

Ако отварянето на предпазния кожух се следи от safety PLC, функцията безопасно изключва въртящия момент на задвижванията, reset е само локален, а стандартният PLC не може да възстанови движението независимо от състоянието на функцията за безопасност, тогава компрометирането на стандартния контролер може да спре производството или да наруши процеса.

Но не би трябвало да предизвика движение при отворен предпазен кожух.

Тогава киберанализът показва атака.

Оценката на риска на машината показва механична опасност.

Правилно проектираната функция за безопасност обаче прекъсва пътя между двете.

А сега вторият вариант.

Сервизният режим се избира от обикновено HMI.

Стойността на ограничената скорост идва от стандартния PLC.

Отдалеченият сервизен специалист може да извърши reset.

Един и същ инженерен акаунт позволява промяна на програмата на стандартния контролер и на safety конфигурацията.

Копието на safety програмата не е обвързано с конкретна версия на машината.

Никой не проверява контролната сума след намеса.

Параметрите на задвижването могат да бъдат променяни от разстояние.

При тази архитектура компрометирането на акаунта вече не означава само загуба на поверителност или кратък престой.

То може да промени условията, върху които се е основавало намаляването на риска.

То може да доведе до:

• избор на неправилен режим,
• промяна на параметър за безопасно движение,
• неразрешен reset,
• качване на неодобрена конфигурация,
• или отслабване на функцията, която е трябвало да предотврати неочаквано пускане.

И тогава киберсценарият трябва да се свърже с конкретен сценарий за безопасност на машината:

задача по отстраняване на засядане → човек в опасната зона → неоторизирана промяна на системата за управление или защитната функция → неочаквано движение → притискане.

Източникът на опасността не се е променил.

Това все така е механичната енергия на машината.

Опасната зона не се е променила.

Тя все така се намира вътре в клетката.

Възможната последица не се е променила.

Това все така е нараняване на оператора.

Променил се е пътят, който води до опасното събитие.

Не всяка уязвимост попада в ISO 12100

Това разграничение е също толкова важно.

Да приемем, че уязвимост в HMI позволява прочитане на исторически производствени данни.

Това може да е съществен проблем от гледна точка на CRA.

Тя може да наруши поверителността на данните.

Може да изисква актуализация, оценка на въздействието, действия спрямо потребителите, а при определени обстоятелства и докладване.

Но ако не влияе върху поведението на машината, не променя защитната мярка и не може да доведе до опасна ситуация, няма смисъл да бъде насилствено включвана в оценката на риска по ISO 12100.

По същия начин атака, която води единствено до недостъпност на производствените отчети, може да означава бизнес проблем и проблем със съответствието с CRA.

Тя обаче не е задължително да създава риск за оператора.

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

Например когато стойността определя:

• максималната скорост на оста,
• силата на притискане,
• температурата на процеса,
• налягането,
• позицията на спиране,
• времето за отваряне на клапана,
• или допустимата граница при работа с отворен предпазител.

Затова не класифицираме киберзаплахата според това колко „технически“ звучи.

Гледаме какво реално може да направи с машината.

Регламентът за машините налага този мост

Тази връзка не е само добра инженерна практика.

Точка 1.2.1 от приложение III към Регламента за машините изисква системите за управление да бъдат проектирани и изработени така, че да предотвратяват възникването на опасни ситуации, включително в резултат на разумно предвидими злонамерени действия на трети лица.

От своя страна CRA посочва, че неговите съществени изисквания за киберсигурност могат да подпомогнат доказването на съответствие, наред с другото, с изискванията 1.1.9 и 1.2.1 от Регламента за машините.

Но това не става автоматично.

Производителят трябва да докаже тази зависимост въз основа на оценка на риска. Оценяването на съответствието по CRA и оценяването на съответствието по Регламента за машините остават отделни процеси.

Тоест не е достатъчно да се подготвят:

• оценка на риска по ISO 12100,
• анализ по IEC 62443,
• два отделни доклада,
• и да се разчита, че сходството в номерата на стандартите ще създаде между тях одитна проследимост.

Необходима е обвързаност.

За всеки съществен киберсценарий трябва да се определи:

1. кой елемент или функция може да бъде поет под контрол или променен,
2. какво поведение на машината може да предизвика това,
3. дали това поведение води до опасна ситуация или опасно събитие,
4. до коя задача и до коя опасна зона се отнася,
5. кое възможно последствие е посочено в оценката по ISO 12100,
6. коя мярка за намаляване на риска трябва да прекъсне развитието на сценария,
7. дали тази мярка остава ефективна след поемане на контрол над атакувания елемент.

Последната точка е най-важната.

Защото ако атаката и защитата зависят от:

• един и същ контролер,
• един и същ акаунт,
• една и съща мрежа,
• една и съща инженерна станция,
• или една и съща програма,

тогава е възможно да нямаме два независими слоя на защита.

Имаме един слой, описан в два документа.

Следователно не ни е нужна една огромна таблица с наименование:

„оценка на риска safety & cybersecurity“.

Нужни са ни два коректни анализа, изпълнени с подходящите методи, и контролиранa точка на допир между тях.

ISO 12100 трябва да описва човека, задачата, източника на опасност, зоната, опасната ситуация, опасното събитие и възможната вреда.

IEC 62443 трябва да помогне да се опишат системата, нейните зони, комуникационните канали, активите, заплахите, уязвимостите, пътищата на атака и необходимите мерки за защита.

А производителят трябва да покаже дали сценарий от втория анализ може да задейства сценарий от първия или да отнеме ефективността на мярката, която е трябвало да го спре.

Кибератаката не е задължително да създава нова опасност. Достатъчно е да отвори нов път към стар инцидент.

4. Пентестът преди FAT е снимка. CRA изисква филм

В много проекти киберсигурността се появява две седмици преди FAT.

Поръчва се пентест.

Изготвя се доклад.

Критичните уязвимости се отстраняват, средните се приемат, а документът попада в проектната папка.

Машината е киберсигурна.

До следващия вторник.

Пентестът може да бъде много ценен елемент от верификацията. Той обаче показва състоянието на конкретна версия на продукта, в конкретна конфигурация и при използване на определени тестови сценарии.

Той не отговаря на въпроса какво ще направи производителят по-късно.

А CRA обхваща целия жизнен цикъл на продукта. Оценката на риска за киберсигурността трябва да влияе върху планирането, проектирането, разработването, производството, доставката и поддръжката на продукта. След пускането му на пазара производителят трябва да управлява уязвимостите през декларирания период на поддръжка.

Нека се върнем към машината за пакетиране на зеленчуци.

Машината е преминала FAT.

Пентестът не е показал критични уязвимости.

Осем месеца по-късно производителят на сервизния рутер публикува информация за уязвимост, която позволява поемане на контрол над устройството.

И точно тук започва истинската работа.

Кои доставени машини имат този модел рутер?

Коя версия на firmware е инсталирана във всеки екземпляр?

Активен ли е отдалеченият достъп?

Може ли уязвимостта да бъде използвана в реалната конфигурация?

Дава ли поемането на контрол над рутера достъп само до диагностиката, или и до HMI, PLC, задвижванията и safety PLC?

Възможно ли е само четене на данни, или и промяна на програмата или параметрите?

Може ли атаката да повлияе на функция за безопасност?

Предоставил ли е доставчикът корекция?

Ще промени ли актуализацията на рутера сертификатите, правилата за комуникация или начина на установяване на тунела?

След актуализацията необходимо ли е отново да се проверят отдалеченото обслужване, комуникацията и част от функциите за безопасност?

Кои клиенти трябва да бъдат уведомени?

И отговаря ли ситуацията на критериите за докладване на активно експлоатирана уязвимост или на сериозен инцидент?

Докладът от пенетрационния тест, изготвен преди FAT, няма да даде отговор на нито един от тези въпроси.

Той описва машина, която вече не съществува в този вид.

Защото от момента на изпитването са се променили версиите на софтуера, конфигурациите, средата на потребителя и знанията за уязвимостите.

Затова на производителя му е нужен не просто тест, а процес:

• идентифициране на версиите на хардуера, фърмуера и софтуера във всеки доставен екземпляр,
• наблюдение на информацията за уязвимости,
• оценка на тяхната приложимост в реалната архитектура,
• проверка на възможните последици за процеса и безопасността на машината,
• подготовка и тестване на актуализации,
• информиране на потребителите,
• документиране на взетите решения,
• обработване на изискуемите уведомления.

От 11 септември 2026 г. производителите са длъжни да докладват активно експлоатирани уязвимости и сериозни инциденти, които засягат сигурността на продукти с цифрови елементи. Предварително предупреждение трябва да бъде подадено в рамките на 24 часа, а пълното уведомление — в рамките на 72 часа.

Това означава, че след установяване на проблема няма да има време тепърва да започва издирване:

„Кой всъщност произведе този рутер и къде е списъкът с машините, в които сме го вложили?“

IEC 62443-4-1 много ясно показва разликата между еднократното обезопасяване на продукта и сигурния цикъл на неговото разработване. Той обхваща не само проектирането и верификацията, но и управлението на дефекти, корекции и края на жизнения цикъл на продукта.

Следователно FAT може да затвори етап от проекта.

Но не затваря жизнения цикъл на продукта.

Не прекратява периода на поддръжка.

Не слага край на наблюдението на уязвимостите.

И не означава, че конфигурацията от деня на приемането остава замразена за следващите петнадесет години.

Машината може дълго време да пакетира зеленчуци за супермаркети.

Производителят обаче не може да „опакова“ нейната киберсигурност заедно с инструкцията, да я запечата с фолио и да приеме, че е доставена веднъж завинаги.

Пенетрационният тест може да затвори точка от списъка за FAT. CRA отваря процес, който продължава до края на периода на поддръжка на продукта.